MTP Is Production-Ready: The Cheapest Throughput Win This Sprint
What Shipped
Multi-token prediction moved from papers to serving stacks inside a week. Gemma 4 ships with trained-in draft heads. llama.cpp merged MTP support (PR #22673) for Qwen3.x. vLLM, SGLang, MLX, and Ollama all have day-0 or beta support. The drafter is small enough to be noise in the memory budget: 78M parameters against a 27B+ target.
The Numbers That Matter
Community benchmarks on llama.cpp's beta with Qwen3.x report a ~75% acceptance rate at 3 draft tokens and >2× token-generation throughput. Google claims up to 3× on Gemma 4 with zero quality degradation. The numbers are real. They are also batch-size-one, single-stream numbers, which is not the regime most of us run in.
On a loaded production server the sequential-step bottleneck shrinks, GPUs are closer to saturation, and the 2-3× headline compresses to 1.3-1.5×. That is still worth the migration. It is not 2-3×.
Where It Breaks
Acceptance rate is distribution-sensitive. MTP does well on repetitive, predictable token sequences: natural language, common code patterns, JSON. It degrades on:
- Code with long unique identifiers
- Structured output with rare keys
- Languages the draft head was undertrained on
- High-concurrency serving where the GPU is already saturated
The failure mode is paying the draft-model cost for zero speedup on mismatched distributions. The fix is routing. Send MTP-friendly requests through the speculative path and keep standard decode for the rest.
Cross-Source Agreement
Five independent sources converge on the same read: MTP is real, production-viable, and worth a spike this week. They converge on the same caveat too. Measure acceptance rate per request type, not aggregate tokens per second. Aggregate throughput hides the slices where the drafter helps nothing, which is exactly the slice you need to price.
| Metric | What to measure | Target |
|---|---|---|
| Acceptance rate | Per traffic slice (code, text, JSON, tool calls) | >65% to justify routing |
| Output equivalence | KL divergence vs non-MTP baseline | <0.02 |
| Throughput gain | Tokens/sec at production batch size | >1.3× to justify integration |
| p99 latency | Under real concurrency | No regression |
Why This Week, Not Next Quarter
Most inference optimizations come with a tax: retrain, requantize, or eat a quality delta. MTP, when acceptance is high, requires no retraining, no quantization trade-off, and no quality degradation. The Gemma 4 E2B drafter is 78M parameters, smaller than most embedding models. Integration is hours on the supported frameworks. A few hours of engineering for a possible 30-50% cost reduction on qualifying traffic is an asymmetry worth taking, assuming your traffic qualifies. Measure before you assume it does.
What to do
Stand up MTP spike on highest-volume self-hosted workload (Qwen3.x or Gemma 4 + matching drafter) — log acceptance rate, throughput, and output-distribution KL per traffic slice
Build a routing classifier that separates MTP-friendly requests (natural text, common code) from MTP-hostile ones (rare identifiers, structured output with rare keys) by end of sprint
Do NOT update capacity forecasts with the 2-3× headline until you measure at production batch sizes and concurrency