GPU from 2017 just pushed Qwen3.8-27B to 251 tok/s.
1Cat-vLLM 1.5.0 is out. 🐱
4× Tesla V100:
⚡ Qwen3.8 DFlash2: 206–251 tok/s
⚡ 256K decode: 50.38 tok/s
⚡ Long-prefill Attention: ~60.8 TFLOP/s
V100 isn’t getting newer.
The software is getting better.
Make Volta Fast Again.
https://t.co/WbrDoBGIUF
🚀 We built 1Cat-vLLM-Gaudi and open-sourced it.
Gaudi2 is Intel’s AI accelerator with 96GB HBM2E per card, 2.45 TB/s memory bandwidth, and native FP8 support — a compelling option for LLM inference if you’re willing to get your hands dirty.
The challenge is software: model support, kernels, compilation, and multi-card execution still need serious work.
That’s where 1Cat-vLLM-Gaudi comes in.
Based on vLLM / vLLM-Gaudi, we’re making Gaudi2 a more practical inference platform.
What we’ve built
🔹 Model support
Qwen3.5 / 3.8
DeepSeek V4 / V4.1 Flash
MiniMax H3 audio/video generation
🔹 Native kernels & performance optimization
100+ DeepSeek-related TPC kernel source files
Weight layout, build, and validation tooling
FlashInfer-Gaudi
Optimizations for GDN, quantization, normalization, and state I/O
🔹 Multi-Gaudi execution
2-card TP2
4-card TP2 × PP2
Regional compilation + Native Replay
Reduced communication stalls, state movement, and per-token submission overhead
On our archived Qwen3.8-27B-FP8 single-Gaudi2 benchmark, compared with the previous vLLM-Gaudi GDN path:
→ GDN Prefill throughput: 2.3–2.8×
→ End-to-end request throughput: 1.27–1.55×
Full baselines and validation details are available in the README.
No Gaudi2? You can still test it on real hardware.
We run our own Gaudi2 server cluster and offer rental access and free trials for developers bringing their own models, workloads, or optimization ideas.
⭐ GitHub:
https://t.co/TtH7CUNJKT
🖥️ Gaudi2 rental / free trial:
https://t.co/iphKuu29nn
Stars, Issues, benchmarks, optimizations, and unusual workloads are all welcome.
Let’s Gaudi it. 🐱
We reuse upstream components wherever appropriate. A high-performance port, however, requires more than reusable kernels — model-specific layouts, state management, graph/replay, and TP/PP execution paths also need optimization. Our goal is to make those pieces reusable for future Gaudi ports as well.