← All guides

Is Speculative Decoding Worth It for Local LLMs in 2026?

Speculative decoding took a Qwen3.6-27B setup from 25 to 45 tok/s. It also took a mismatched Gemma 4 setup from 60 down to 45 tok/s. Acceptance rate decides which result you get.

Short answer

Speculative decoding is worth it when your draft acceptance rate is above roughly 60–70%. Below that, you usually lose speed.

  • Best case measured: Qwen3.6-27B + MTP draft on a 24GB GPU: ~25 → ~45 tok/s (+78%).
  • Worst case measured: Gemma 4 with a mismatched int4 draft at 41% acceptance: 60 → 45 tok/s (-25%).

Same technique, opposite results. The rest of this guide is how to land on the right side.

How it works, in one paragraph

A small “draft” predicts several tokens ahead. The big target model verifies them in one pass. Accepted tokens are free speed; rejected tokens are wasted work. The target model verifies every token, so output quality never changes — only speed does. That makes this the rare free lunch, but only when the draft guesses well.

The 2026 numbers (runaihome)

SetupBeforeAfterChange
Qwen3.6-27B + MTP, A10G 24GB~25 tok/s~45 tok/s+78%
Qwen3.6-27B + MTP, Apple Silicon (82% acceptance)~7 tok/s~16 tok/s~2.3x
Gemma 4 + MTP coding agent, Apple Silicon MLX——~1.9x
Llama 3.1 8B + 1B draft (draft length 5)——1.83x
Gemma 4, mismatched int4 draft (41% acceptance)60 tok/s45 tok/s-25%

The pattern: code and structured output sit at the top of the 1.5–3x band, because code is predictable and drafts guess it well. Creative and open-ended chat often falls below break-even.

The 2026 llama.cpp flags (the old ones are gone)

llama.cpp renamed its speculative decoding flags. The old --draft, --draft-n, and --draft-max now exit with an error: “the argument has been removed. use —spec-draft-n-max”. Verified against the current llama.cpp source (common/arg.cpp).

Old flagNew flag
--draft-max / --draft-n / --draft--spec-draft-n-max
--draft-min--spec-draft-n-min
(new)--spec-type

--spec-type selects the method, including draft (classic separate draft model), draft-mtp, draft-eagle3, draft-dflash, and several ngram modes.

The winning A10G config from the benchmark above:

llama-server -m qwen3.6-27b-q4.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

Starting points that measured well:

  • MTP or creative text: --spec-draft-n-max 2 to 4
  • Standalone draft model on code: start at --spec-draft-n-max 8

MTP vs a separate draft model

Multi-Token Prediction (MTP) heads are the 2026 shortcut: the model drafts for itself, so there is no second model to pick, match, or fit in VRAM.

  • Gemma 4 on the MLX runner enables speculative decoding by default (and Ollama v0.30.5 added Gemma 4 MTP spec decode on Macs, per runaihome). You may already be running it.
  • Qwen3.6 still needs a separate MTP GGUF (for example the unsloth Qwen3.6-27B-MTP-GGUF build) loaded alongside the main model.

If you use a classic separate draft, it must share the target’s tokenizer and family. The -25% Gemma 4 failure above came from a mismatched int4 draft — acceptance collapsed to 41%.

How to test if it pays on your machine

  1. Record baseline decode tok/s on your real prompts.
  2. Enable spec decode with --spec-type draft-mtp --spec-draft-n-max 2.
  3. Watch the acceptance rate in the server log. Above ~70%: keep it. Below ~60%: turn it off.
  4. Re-test per workload. Code loops and chat sessions give different acceptance rates.
  5. Check VRAM. A separate draft model steals memory from context — see KV cache quantization: Q8 vs Q4 if you get tight.
🎮 THE 24GB SPEC-DECODE TIER

The +78% Qwen3.6-27B result above ran on a 24 GB GPU. That is the RTX 3090/4090 class: enough VRAM for a 27B quant plus its MTP draft and context.

Decision table

Your workloadVerdict
Coding agent / structured outputEnable it — top of the 1.5–3x band
Qwen3.6-27B on a 24GB GPUEnable with MTP GGUF (+78% measured)
Gemma 4 on Mac (MLX)Already on by default
Creative writing / open chatTest first — often below break-even
Mismatched or wrong-quant draftDo not — this is the -25% case
VRAM already fullSkip, or use MTP instead of a second model

Final recommendation

Enable speculative decoding for code and agent workloads — MTP first, since it needs no second model. Measure acceptance, and turn it off below ~60%. It never changes your output, so the only question is whether your workload is predictable enough to pay for the drafts.

Sources:

Read next

Why Speculative Decoding Made My Local LLM Slower
You added a draft model and lost tokens/sec. The real causes — same-device contention, a Metal net loss of 11-24%, tokenizer mismatch, and low-draftability prompts — plus the acceptance-rate number that tells you whether to keep it.
Dual-Socket vs Single-Socket EPYC for LLM Inference: The Second CPU Pays 1.83x on a Dense Model and 1.02x on DeepSeek R1
Does a second CPU socket speed up local LLM inference? A controlled same-machine A/B says yes for dense models and almost not at all for DeepSeek R1. Here are the measured numbers, the NUMA fix that recovers 80%, and a correction to our own earlier page.
Qwen 3.8 27B on RTX 3090 (2026): 41 tok/s, 66 With MTP
Qwen3.8-27B on one RTX 3090: about 40 tok/s in llama.cpp at Q4, 66 tok/s with the built-in MTP head at 8K context, and only +33% at 131K. File sizes, KV cache math, the context that fits in 24GB, and when a 4090 is worth more.
Can You Run a 160GB MoE Model on 8GB VRAM? Expert Streaming Explained
A 160GB sparse MoE model can be approached as a streaming runtime problem, but 8GB VRAM expert streaming is experimental and slow. Here's what matters.