vLLM · 2026-11-01 · major
vLLM v0.33.0 — faster speculative decoding, and CUDA 13 builds only
In short
vLLM v0.33.0 brings 927 commits from 389 contributors: speculative decoding that no longer reserves draft slots, a ROCm MonoKernel decode path, a new /v1/decisions endpoint, and CUDA 13.0-only release builds.
vLLM · 2026-11-01 · 2 sources checked

vLLM v0.33.0 speeds up speculative decoding on NVIDIA and AMD, adds new open models, and drops CUDA 12.9 builds.
Quick facts
| Maker | vLLM project |
|---|---|
| Version | v0.33.0 |
| Released | November 1, 2026 |
| Contributors | 389 (122 new) across 927 commits |
| Platform | PyTorch 2.14, CUDA 13.0 builds only |
| Default ROCm | ROCm 10.0 (7.2 kept as -rocm72) |
| Removed | Medusa, MLP speculator, Ray compiled-graph executor |
What is it?
Speculative decoding gets the biggest share of work in vLLM v0.33.0. Block-diffusion drafters such as DFlash and DSpark no longer reserve draft slots in the token budget, and in the pull request's benchmark DeepSeek-V4.1-Flash with DSpark on GB300 rose from 1,373 to 3,390 output tokens per second. The release also adds serving support for Reflection Beam-1.0, Yandex AliceAI-Foundation-80B-A3B, Recursive Flint, Muse Spark Open, Step-5 Preview and NVIDIA Alpamayo 2 Super, among others.
How does it work?
An opt-in policy called FLy accepts some draft tokens with lossy verification, for 1.04–1.31x decode throughput on MI355X and B300. On AMD, a new `--monokernel` decode path gives DeepSeek-V4.1-Flash 2.32x P50 interactivity at concurrency 1 on MI300X/MI325X. On NVIDIA, FlashInfer DCP prefill cuts mean time-to-first-token by 39–48% at 100k input on 8xB200, and an opt-in latency-specialized decode runs Kimi-K3 1.5–2x faster on GB300.
Why does it matter?
Teams that serve large mixture-of-experts models get more tokens per GPU without changing models, on both NVIDIA and AMD hardware. The upgrade needs care: CUDA 12.9 wheels and images are no longer published, the Medusa and MLP speculators are gone, and requests sent while generation is paused now get HTTP 503.
Who is it for?
inference and platform engineers
Frequently asked questions
- What breaks when upgrading to vLLM v0.33.0?
- vLLM v0.33.0 removes the Medusa and MLP speculators and the legacy Ray compiled-graph executor. Release wheels and images are now CUDA 13.0 only, the NIXL connector needs NIXL 1.5 or newer, requests sent while generation is paused get HTTP 503, and `--mamba-cache-mode` is deprecated with no effect.
- Does vLLM v0.33.0 still support CUDA 12.9?
- No. With vLLM v0.33.0 the project stops publishing CUDA 12.9 wheels and images, so the official release artifacts target CUDA 13.0 only. The release moves to PyTorch 2.14 and adds an ABI-stable libtorch CUDA wheel. Teams on older drivers need to upgrade before installing the new version.
- What does vLLM v0.33.0 change for AMD GPUs?
- On AMD, vLLM v0.33.0 moves the default image and wheels to ROCm 10.0 and keeps ROCm 7.2 as a `-rocm72` build. A new `--monokernel` decode path gives MiniMax-M3-MXFP4 16.6% lower time per output token on MI355X, and the ROCM_OCTAVE 3–4 bit KV cache holds 4.6x the tokens of fp16 on an RX 7900 XTX.
- Is LM Format Enforcer still supported in vLLM v0.33.0?
- LM Format Enforcer is deprecated in vLLM v0.33.0. The release notes say it becomes opt-in in v0.34.0 and is removed in v0.35.0, so users of that structured-output backend should plan a move. The `--ir-op-priority` flag is also slated for removal in v0.34.0.
Try it
pip install -U vllm