vLLM 0.29 makes Model Runner V2 the default for every model
594 commits in a fortnight, ten model architectures deleted, and the launch command in half the tutorials on the internet is now deprecated.
Which line in vLLM's new release notes should worry you? Not any of the new models. It is the one announcing that Model Runner V2 is now the default for every model.
That is a change of engine, not a feature.
vLLM shipped v0.29.0 on the morning of 9 September 2026, carrying 594 commits from 277 contributors. Its new runner has been rolling out since pooling models moved over, and this release finishes the job, bringing CUDA graph memory profiling for KV cache auto-sizing, batch-sharded sampling that cuts per-step logits memory, prompt embeds, and padded full-cudagraph dispatch for uniform decode under speculative decoding.
Meanwhile the old runner survives only for a handful of ROCm models and for features the new one has not caught up on. And the notes do not say which features. If you run vLLM on AMD hardware, that is the sentence to read twice.
The breaking list is short and expensive
Ten deprecated model architectures are removed. Not renamed, removed. FlexOlmo, Olmo3 and Hunyuan V1 and VL now run through the Transformers modeling backend rather than native implementations. The PyAV video decoder backend is gone entirely.
And python -m vllm.entrypoints.openai.api_server is deprecated in favour of vllm serve.
That last one is the quiet tax (nobody writes a changelog entry for the afternoon it costs you). Nearly every Dockerfile, Slurm script and tutorial written before this summer starts the server the old way:
# deprecated in 0.29.0
python -m vllm.entrypoints.openai.api_server --model openbmb/MiniCPM5-2B
# the supported form
vllm serve openbmb/MiniCPM5-2B
The best change in the release sounds like the dullest
Prefix-cache NONE_HASH is now deterministic by default, so anyone running a distributed KV cache no longer has to pin PYTHONHASHSEED across every worker to get cache hits.
If you have ever debugged a cluster where one node quietly refused to reuse anybody else's prefixes, you know roughly how many hours that single environment variable has cost the field. FlashInfer all-reduce is on by default for tensor-parallel CUDA groups too, with an environment variable to back out.
The cadence is the context the notes leave out, so we counted it
Six minor releases since late June, spaced between twelve and sixteen days apart, five times running. Call it forty-odd commits a day landing in the serving layer underneath most open-weights inference. The previous release carried 584 commits from 270 contributors, so this one is not an unusual bulge. Rather it is the ordinary rate, with a default flip inside it.
Our read is that these release notes have become an upgrade hazard list wearing a feature list's clothes, and the project does not present them that way. Running pip install -U vllm in production this week changes the runner executing your model, the launcher your scripts call, and possibly whether your architecture still exists at all.
Which is a fair thing for a fast-moving project to do before 1.0, and probably unavoidable. And it is not a fair thing for a reader to meet in paragraph nine of the highlights. We wrote about the upside of the same velocity in MiniCPM5-2B lands on stable vLLM the day it ships.
So here is a falsifiable one. Two of the last five minor releases needed a patch within three days, and this is the largest default change of the year. We expect a 0.29.1 before 23 September. If it never arrives, the rollout was as careful as the phased plan suggests, and we will say so.
What is coming next is more interesting than what shipped
On 8 September the project demonstrated Hybrid HiSparse, which lets a request keep decoding after its KV cache stops fitting in high-bandwidth memory by spilling its coldest pages out to host memory.
Sparse MLA only attends to the top-K tokens, so the rest of the KV need not live on the GPU. Hybrid HiSparse in vLLM builds on that, and a request keeps decoding after its KV stops fitting in HBM.
It keeps KV on the GPU while there is room. Under pressure a request releases its coldest pages to host memory, keeps a small hot buffer of what the indexer asks for, and keeps decoding instead of being preempted.
📊 Demonstrated on GLM 5.3, one 8× H200 node, full 1M context. Same host memory, configured concurrency 32: KV offloading kept 5-6 requests running. Hybrid HiSparse kept 19-25.
🔹 Hot pages are ordinary KV blocks from the same pool (Hybrid Memory Allocator)
🔹 One fused kernel resolves resident, hot and missing rows, CUDA-graph capturable
🔹 Prefix caching, OffloadingConnector, P/D imports and MTP keep working
Built by @RedHat_AI and @PrimeIntellect with the vLLM community. Planned for v0.30; pinned commit, flags and calculator are in the post👇
🔗 t.co/6y7u5Hfc8c
On one eight-GPU node running GLM 5.3 at full context, plain KV offloading held five or six concurrent requests. HiSparse held between nineteen and twenty-five. All of it is planned for v0.30.
Fourteen days, then.
