Blog/Speculative decoding: MTP vs EAGLE-3
Inference · November 2026

Speculative decoding speedup: MTP vs EAGLE-3 vs DFlash on RTX 5090 and DGX Spark, November 2026

By Samuel Seidel · Published November 7, 2026 · Sources checked November 7, 2026

For one user on local hardware, speculative decoding speeds up decode by about 1.5 to 2.5 times in reports from May to August 2026: llama.cpp's MTP took Qwen3.6-27B from 63.7 to 105.5 tok/s on an RTX 5090, and vLLM's MTP took Gemma 4 26B-A4B from 30.3 to 54.9 tok/s on a DGX Spark. Use the model's own MTP head when it has one, EAGLE-3 when it does not, and switch speculation off for heavily batched serving, where published tests show it falling below 1x.

MethodWhere the draft comes fromHeadline published resultSource
MTPExtra prediction layer trained with the model85-90% second-token acceptance, 1.8x TPS (DeepSeek-V3)DeepSeek-V3 report
EAGLE-3Small head trained on the target's hidden statesUp to 6.5x; 1.38x throughput at batch 64 in SGLangEAGLE-3 paper
DFlashBlock-diffusion drafter, whole block in parallel4.9x average on Qwen3-8B (greedy), about 2.4x over EAGLE-3DFlash paper
Draft modelSeparate smaller model, same tokenizerDepends on the pair; no shared benchmarkengine docs
N-gram, suffixText already in the prompt or historyModest, little extra load at peakvLLM docs

How does speculative decoding speed up one user?

A cheap drafter proposes several tokens and the big model checks them all in one forward pass, so each read of the weights can yield more than one token.

Single-user decode is limited by memory bandwidth, not compute: every token means reading the active weights once (the glossary has the arithmetic). Checking four tokens in one pass costs little more than generating one, so if three of them are accepted you got four tokens for about one weight read. With standard rejection sampling the output is still the target model's own distribution; vLLM calls this lossless up to hardware numerical precision and tests greedy-output equality with speculation on and off.

The gain depends on how many drafts survive. A DGX Spark run of Gemma-4-26B-A4B-NVFP4 on vLLM 0.26.1rc1, posted on the NVIDIA developer forum on 10 August 2026, logged per-position acceptance of 0.84, 0.60, 0.39 and 0.27. By my arithmetic, that gives:

tokens per verify step = 1 + sum of per-position acceptance
2 draft tokens: 1 + 0.84 + 0.60               = 2.44
4 draft tokens: 1 + 0.84 + 0.60 + 0.39 + 0.27 = 3.10
positions 3 and 4 add 0.66 tokens but double the drafting and verify width

The poster found 2 tokens beat 4 and measured 30.3 to 54.9 tok/s single-stream, +81%. That pattern repeats in almost every report below: n=2 or n=3 wins on local hardware.

Which 2026 models ship MTP heads?

Most large 2026 releases do, which makes MTP the default choice rather than an add-on.

Modelconfig.json fieldValueNotes
Qwen3.6-35B-A3B, Qwen3.8-27B, Qwen3.8-Flash-Nextmtp_num_hidden_layers1Qwen3.8-27B card: MTP "trained with multiple steps"
DeepSeek-V4-Flashnum_nextn_predict_layers1V4 report: MTP setup identical to DeepSeek-V3
DeepSeek-V4.1-Flashnum_nextn_predict_layers3
GLM-4.5-Air, GLM-4.7-Flash, GLM-5.2, GLM-5.3-Flashnum_nextn_predict_layers1
MiMo-V2.6-Flashnum_nextn_predict_layers3Card: 5-layer sliding-window drafter predicting 7 tokens
Nemotron 3 Super 120B-A12Bnum_nextn_predict_layers1Card: shared-weight head, examples use 3 tokens; separate MTPv2 checkpoint
MiniMax-M2.5, MiniMax-M3num_mtp_modules3, 7
Kimi K3, Kimi K2.5num_nextn_predict_layers0No MTP head
gpt-oss-120b, gpt-oss-20bnonenoneEAGLE-3 drafts: ggml-org GGUF repos include eagle3-*-Q8_0.gguf (0.8 to 0.9 GB)

Read from each model's config.json and file list on Hugging Face, 7 November 2026; notes from the MiMo-V2.6-Flash and Nemotron 3 Super model cards. Some MTP heads ship in a separate GGUF, for example unsloth's Qwen3.6 MTP repositories. vLLM's docs say Gemma 4 uses separate "assistant" checkpoints with "method": "mtp".

What speedups are published on RTX 5090, DGX Spark and datacenter GPUs?

On an RTX 5090 and a DGX Spark, MTP roughly doubles single-user decode on dense models; on datacenter GPUs the research numbers are higher but come from tuned setups.

HardwareModel, engine, methodWithoutWithAcceptanceSourceDate
RTX 5090Qwen3.6-27B q4_0, llama.cpp, MTP n=363.7105.579.7%llama.cpp PR #226732026-05
RTX 5090Qwen3.6-27B, llama.cpp, MTP n=2~41~90not statedunsloth discussion #62026-05-21
RTX 5090Qwen3.6-35B-A3B Q4_K_XL, llama.cpp, MTP n=2171 (Ollama)267not statedDEV post2026-05-18
RTX 3090 + 3060Qwen3.6-27B Q6_K, llama.cpp, MTP n=322.9742.4576.0%PR #226732026-05
DGX SparkQwen3.6-27B Q8, llama.cpp, MTP n=3~714-2272.2%PR #226732026-05
DGX SparkGemma 4 26B-A4B NVFP4, vLLM 0.26.1rc1, MTP 230.354.90.84 / 0.60NVIDIA forum2026-08-10
DGX SparkQwen3.6-35B-A3B NVFP4, vLLM, MTP n=3not run86.3 at 4knot statedSparkBench2026-08-04
DGX Sparkgpt-oss-120b, patched vLLM, EAGLE-3 K=164.368.9not statedgptoss-spark2026
RTX PRO 6000 Max-Qgpt-oss-120b, vLLM 0.14.1, EAGLE-3 k=1 / k=3177.7180.7 / 124.770.6% / 19.8%Fixstars2026-03-09
1x H100Llama 3.1 8B, SGLang, EAGLE-3158.3373.3not statedSGLang docsundated
8x B200Qwen 3.5 397B-A17B, SGLang, DFlash vs MTP1x4.3x (1.5x MTP)not statedLMSYS2026-06-15

Single-stream decode in tok/s unless stated. The DEV post compares llama.cpp with MTP against stock Ollama, so part of its gain is the engine. The DGX Spark Qwen3.6-27B baseline is the PR's approximate figure; its wall time fell from 201.1 s to 83.8 s. Every number in this table is a third-party report.

Two patterns stand out. Dense models gain most, because each verify pass reads all their weights anyway. MoE models gain less per pass in theory, since each drafted token can route to different experts, yet the 35B-A3B MoE reports above are still large; the PR's Qwen3.6-35B-A3B sweep on a 6 GB laptop GPU went from 22.92 to 29.39 tok/s at n=2. For more Spark numbers by model, see the best models for DGX Spark and the Gemma 4 26B-A4B page, which lists a third MTP figure (108 tok/s) that disagrees with the forum run.

When does speculative decoding make things slower?

At high concurrency, with low acceptance, and with long drafts on hard-to-predict text.

For a shared endpoint, the vLLM docs place model-based methods in "medium-to-low QPS" territory. GPUwerk's own vLLM 0.27.1 runs on a DGX Spark reached 3,235 tok/s total at 256 concurrent requests on Qwen3-Coder-30B-A3B without any speculation, and the capacity planning post shows how per-user speed falls as that batch grows; that is the regime where a drafter mostly adds work.

Which flags turn it on in each engine?

One flag or one JSON blob per engine; the method names differ.

# llama.cpp (merged 16 May 2026): model with an MTP head, one slot
llama-server -hf unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL \
  --spec-type draft-mtp --spec-draft-n-max 2 -np 1

# vLLM: MTP (the draft model can usually be omitted)
vllm serve <model> --speculative-config '{"method": "mtp", "num_speculative_tokens": 2}'

# vLLM: EAGLE-3 or a separate draft model
vllm serve <model> --speculative-config '{"method": "eagle3", "model": "<eagle3-head>", "num_speculative_tokens": 3}'

# SGLang: DFlash, from the LMSYS launch command
python3 -m sglang.launch_server --model-path Qwen/Qwen3.5-397B-A17B \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path modal-labs/Qwen3.5-397B-A17B-DFlash \
  --speculative-dflash-block-size 8 --tp-size 8

llama.cpp's server README lists draft-simple, draft-eagle3, draft-mtp, draft-dflash, draft-dspark and five n-gram types for --spec-type, with --spec-draft-n-max defaulting to 3; the old --draft-max flag is removed. SGLang uses --speculative-algorithm with EAGLE3, EAGLE (also covering NEXTN/MTP), DFLASH, STANDALONE or NGRAM. TensorRT-LLM takes a decoding_type of MTP, Eagle3, DFlash, PARD, DraftTarget or SA, and deprecates its NGram mode for removal in January 2027. The llama.cpp on DGX Spark doc has the full MTP command for a Spark, and the engine comparison covers which engine to pick first.

MTP, EAGLE-3 or DFlash: which should you use?

MTP if the model has it, EAGLE-3 if it does not, and DFlash when a drafter exists for your model and engine.

MTP heads are trained with the model and need no extra download, and their acceptance in the table above (72 to 80% overall in the llama.cpp tests, 84% at the first draft position on the Spark) is at or above the best EAGLE-3 figure (70.6%). EAGLE-3 is the route for gpt-oss and Llama 3.3, but the gpt-oss results are thin: +7% on a Spark at K=1 and +1.7% on an RTX PRO 6000, with longer drafts slower. DFlash has the best research numbers (6.08x on Qwen3-8B HumanEval with greedy decoding in its paper), and llama.cpp, SGLang and TensorRT-LLM all accept it, but it needs a trained drafter per target model.

My recommendation for one person on an RTX 5090 or a DGX Spark: run a dense 27B with its MTP head at n=2, check the acceptance rate the server logs on your own prompts, and keep it only if acceptance stays above about 60%. On a team endpoint with more than a handful of concurrent users, benchmark with speculation off first. A dense 27B at 105 tok/s with MTP on an RTX 5090 is faster for one user than most MoE models without it, which changes which model is worth renting for interactive work.

FAQ

How much faster is speculative decoding?

For one user, usually 1.5 to 2.5 times on decode in 2026 reports. llama.cpp MTP took Qwen3.6-27B from 63.7 to 105.5 tok/s on an RTX 5090 (PR #22673, May 2026), and vLLM MTP took Gemma 4 26B-A4B from 30.3 to 54.9 tok/s on a DGX Spark (NVIDIA forum, August 2026). The DFlash paper reports 4 to 5 times on Qwen3-8B, but in a research setup with greedy decoding.

Is MTP better than EAGLE-3?

If the model ships an MTP head, use it first: it was trained with the model, needs no extra download and reported acceptance is high (DeepSeek reported 85 to 90% for the second token). EAGLE-3 is the fallback for models without one, such as gpt-oss or Llama 3.3. In the June 2026 LMSYS post, DFlash beat EAGLE-3 on Qwen3-4B and reached 4.3 times baseline, 1.5 times MTP, on Qwen 3.5 397B at concurrency 1.

Does speculative decoding change the output?

No, with standard rejection sampling the output distribution is the target model's own. vLLM documents it as lossless up to hardware numerical precision and tests greedy-output equality with and without speculation. Exceptions are opt-in lossy modes such as vLLM's FLy verification and TensorRT-LLM's relaxed acceptance for MTP during the thinking phase.

Why is speculative decoding slower at high batch sizes?

Verification costs extra compute for every drafted token, and a large batch already keeps the GPU busy, so rejected drafts become wasted work. In the DFlash paper, EAGLE-3 with a 60-token draft fell to 0.5 to 0.6 times baseline at concurrency 32 on Llama-3.1-8B. TensorRT-LLM's docs say speedups show only at low batch sizes.

How many draft tokens should I use?

Two or three for MTP on local hardware. In llama.cpp PR #22673, a Qwen3.6-35B-A3B sweep peaked at n=2 (29.39 tok/s) and fell at n=4 (26.09), and a DGX Spark Gemma 4 run found 2 tokens beat 4. Acceptance falls with each position, 0.84, 0.60, 0.39 and 0.27 in that Spark run, so later drafts add little.

Sources

Every figure above is attributed to its source in the sentence or table where it appears. Pages were read on 7 November 2026 unless a date says otherwise.

Related pages

First top-up: pay $20, get $30 in credit

Measure your own acceptance rate.

Acceptance depends on your prompts, so run the MTP and no-MTP flags side by side on a rented RTX 5090 at $0.89 an hour, billed per minute.

A dedicated RTX 5090 machine with 32 GB of GDDR7, $0.89/hour, billed per minute, one customer per machine.

Deploy now for an RTX 5090 llama.cpp MTP setup on a Spark