vLLM · 2026-09-22 · major
vLLM v0.30.0 — engine restarts skip the disk with a GPU weight cache
vLLM v0.30.0 adds Fast Start, a per-GPU daemon that holds quantized weights in GPU memory so a restarting engine maps them over CUDA IPC instead of reloading from disk. The release lands 762 commits from 315 contributors.
Fast Start keeps post-quantized weights resident in GPU memory, so a restarting vLLM engine maps them instead of reloading them.
Quick facts
| Maker | vLLM project |
|---|---|
| Version | v0.30.0 |
| Released | September 22, 2026 |
| License | Apache-2.0 |
| Contributors | 315 across 762 commits |
| Headline feature | Fast Start weight-cache daemon |
| Breaking change | Scale-out endpoints need --enable-scale-out |
What is it?
Fast Start is the headline addition in vLLM v0.30.0: a persistent per-GPU daemon that holds post-quantized, tensor-parallel-sharded weights in GPU memory. Engines started with `--load-format ipc_cache` map those weights over CUDA IPC rather than reading a checkpoint off disk. The cache covers FP4 checkpoints and multi-node tensor parallelism. A second new feature, Gumbel-max watermarking, can mark and later detect vLLM-generated text.
How does it work?
Startup time in v0.30.0 also drops because garbage collection is frozen during CUDA graph capture: capture falls from 12s to 2s and engine init from 28.9s to 8.2s on an H200. A new tier called HiSparse spills KV pages to pinned host memory when a sparse-MLA model runs out of GPU room, then serves top-k misses from a per-request GPU hot buffer. Kimi K3 decoding gains 5.2–7.7% end-to-end throughput after a gather/scatter step was removed from its KDA path.
Why does it matter?
Restart cost is what makes autoscaling a serving fleet expensive, and mapping cached weights removes most of it — useful for anyone who redeploys often or runs reinforcement-learning loops that tear engines down between steps. The upgrade is not free, though: scale-out endpoints are now opt-in, GPTQ activation ordering is gone, and YaRN now matches Transformers, so vendor YaRN aliases no longer re-scale `max_model_len`.
Who is it for?
inference and platform engineers
Frequently asked questions
- What breaks when upgrading to vLLM v0.30.0?
- vLLM v0.30.0 makes scale-out endpoints opt-in on plain `vllm serve` behind `--enable-scale-out`, replacing the old environment variable. GPTQ activation ordering (`g_idx`) is removed, the `all` Mamba cache mode is deprecated, and `python -m vllm.entrypoints.grpc_server` gives way to `vllm serve --grpc`. YaRN now follows Transformers, so vendor aliases stop re-scaling context length.
- Which new models does vLLM v0.30.0 serve?
- New in vLLM v0.30.0 are DeepSeek-V4.1-Flash, which stores its whole KV cache in MXFP8, plus DeepSeek-V4-Flash-Vision-Exp with ROCm and LoRA support, GLM-5.3-Flash, K2-Horizon with its reasoning and tool parsers, Cohere Compass, Bailing V3 VL, and Nanbeige4.2 through the Transformers backend. A DeepSeek-V4 CPU backend with AVX512 and AMX kernels also lands.
- How does watermarking in vLLM v0.30.0 work for users?
- Watermarking in vLLM v0.30.0 uses Gumbel-max sampling with a keyed pseudorandom function, and the release ships an example endpoint that detects the mark later. Callers can opt out per request, and a dual-key variant keeps the watermark compatible with speculative decoding. The Rust frontend forwards the per-request controls.
- Can vLLM v0.30.0 run without NVLink between GPUs?
- Yes — vLLM v0.30.0 adds an opt-in FlashInfer PCIe IPC all-reduce aimed at boxes without NVLink. The same large-scale serving work brings prefill and decode context parallelism to sparse-MLA models, Elastic EP that reuses CUDA graphs across reconfiguration, and encoder-cache sharing over NIXL and Mooncake.
Try it
pip install -U vllm && vllm serve <model> --load-format ipc_cache