vLLM’s maintainers pushed out version 0.28.0 with 270 contributors touching the codebase, 76 of them new to the project. That is a notable roster for infrastructure software that most large language model deployments now sit on top of, whether the operator realizes it or not.
The release’s most consequential line for anyone running vLLM in production is a set of breaking changes. Support for bitsandbytes, a widely used quantization library, has moved out of the core project into a separate plugin, which means teams relying on it need to update their install path before upgrading. The Transformers dependency jumped to version 5.15.0. Two deprecated code paths, the runtime KV scale calculation function calculate_kv_scales and the override_attention_dtype setting, were removed outright rather than deprecated further. None of these are cosmetic. Any team with a pinned dependency chain or a custom quantization workflow should treat this as a required compatibility check, not an optional read.
The project also quietly raised three defaults that change behavior without any code change on the user’s end. The batched token ceiling, max_num_batched_tokens, doubled from 8,192 to 16,384, which increases the throughput vLLM will attempt to schedule per step. Prefix caching is now on by default for Mamba-architecture models. On Blackwell-class GPUs, the CUDA graph capture default rose to 1,024. Each of these is a reasonable engineering call on its own, but together they mean a server that was memory-tuned against the old defaults could behave differently after an in-place upgrade, particularly on tighter GPU memory budgets.
The bulk of the engineering effort in this cycle went toward Kimi-K3 serving performance: decode context parallelism, fused decode and prefill kernels, and an adaptive speculative token budget the release notes attribute to a roughly 60% improvement in DSpark time-to-first-token. A separate change enables optional shared-expert sharding that the notes say saves close to 17 GiB of memory per GPU, a meaningful figure for anyone trying to fit a large mixture-of-experts model onto fewer accelerators. vLLM does not publish independent verification of these figures; they come from the maintainers’ own benchmarking, which is standard for a release-notes document but worth flagging to readers who plan to cite the numbers externally.
DeepSeek V4 also gained end-to-end support for sparse multi-head latent attention across plain decoding, multi-token prediction, and speculative decoding, plus AMD Quark NVFP4 quantization support. The “Model Runner V2” execution path, still maturing rather than finished, picked up prefill/decode disaggregation and weight offloading, both features aimed at large multi-node deployments rather than single-GPU inference.
What the cadence signals matters more than any single kernel. A 584-commit release built by 270 people, most of them unaffiliated with a single vendor, is evidence that open inference serving has become infrastructure in its own right rather than a stopgap until a cloud provider’s managed endpoint catches up. Teams weighing a managed inference API against self-hosting get a monthly reminder that the open-source alternative is not standing still, and is arguably iterating faster on hardware breadth (NVIDIA, AMD, Intel, and CPU backends all shipped changes this cycle) than most single-vendor stacks attempt to.
Anyone running vLLM 0.27.x or earlier in production should read the breaking-changes section before scheduling this upgrade, and should re-run capacity tests after it, given the batched-token and CUDA-graph default changes. That is a maintenance task worth budgeting into next quarter’s infrastructure calendar rather than a routine point-release bump.
Per the vLLM project’s GitHub release notes for v0.28.0, published to the vllm-project/vllm repository.
