vLLM 0.21: DeepSeek V4 on Blackwell and speculative decoding that respects the reasoning budget

vLLM v0.21.0 landed in the week of July 22 with two changes that sound like housekeeping and are not. First, DeepSeek V4 is now stable on Blackwell through a new TOKENSPEED_MLA attention backend. Second, speculative decoding now respects the reasoning budget of the target model. The Blackwell part gets the headlines. The budget part is the one that will change your numbers if you serve reasoning models behind an agent loop.

What shipped

The MLA backend targets throughput over DeepSeek's multi-head latent attention, where the KV cache is stored compressed and has to be decompressed on the way into attention. Getting that path fast on Blackwell is what "stable" means here; V4 ran before, it just did not run well. DeepSeek's own numbers make the motivation obvious: V4 runs with 1M context by default, and V4-Pro reports 80.6% on SWE-bench Verified at roughly one seventh the output price of the frontier alternatives. That is a model people want to self-host, and Blackwell is the box they want to self-host it on. The same week, llama.cpp merged multi-token prediction for Qwen 3.6, so the local side of speculative decoding moved too.

If you are on Hopper, the H100 vLLM serving guide still applies; this release is about the next generation.

The draft model that eats your thinking

Speculative decoding is simple in outline: a small draft model proposes several tokens, the big target model verifies them in one forward pass, and you keep the accepted prefix. I covered the local version in speculative decoding on Apple Silicon. It is lossless on the output distribution, which is why everyone likes it.

The problem with reasoning models is that tokens are not all the same tokens. A reasoning model has a budget for its thinking phase, whether you set it explicitly or it comes from the model's own stop behaviour. Before 0.21, the draft model's proposals counted against that budget the same way as target-generated tokens, but the draft is not the model that was supposed to be thinking. You could end up with a target that had spent its reasoning allowance on verified draft tokens and then produced a thinner final answer than it would have without speculation. Faster, but not the same output, which breaks the whole premise.

Speculative decoding is only free when the draft and the target agree about what a token is worth, and reasoning budgets are exactly where they disagree.

0.21 ties the speculative loop to the reasoning budget so the draft can no longer spend it on the target's behalf. The sources I have describe the change at that level and no deeper, so I would not claim to know the exact accounting rule until I have read the code.

What to measure before you enable it

If you run a reasoning model with speculation in production, upgrading is not the end of the job. Things I would check on the first day:

• Acceptance rate per workload. Speculation pays only when the draft agrees with the target often. Reasoning traces diverge more than chat completions, so measure them separately.
• Final-answer length and quality before and after. If 0.20 was silently truncating thinking, your evals may improve on upgrade and your latency may get worse. Both are correct.
• Reasoning tokens vs answer tokens in the billing. If you charge or budget by output tokens, the ratio will shift.
• KV cache memory at long context. The MLA backend changes what is resident on the GPU; re-run your capacity numbers rather than trusting the old ones.
• The break-even point. The break-even analysis I wrote for local serving applies unchanged: batch size and acceptance rate decide whether the draft pays for itself.

The honest gap

This is a release-notes article with a mechanism argument on top, not a benchmark. Neither the vLLM notes nor the secondary write-ups I have (BIZON's 2026 inference engine roundup, Codersera's runtime update) publish tok/s or acceptance-rate figures for the MLA backend or for the budget-aware speculation, and I have not yet had Blackwell time to produce my own. The 80.6% SWE-bench Verified figure is DeepSeek's. Until someone publishes a controlled comparison of 0.20 vs 0.21 on the same V4 checkpoint, the right posture is: upgrade, run your evals, and believe your own numbers.