Part 2 of 6 — Speculative Decoding series. Start with The Need for Speed.
- The Need for Speed — Why LLMs are memory-bandwidth-bound and how speculation exploits the GPU's idle compute.
- Speculative Decoding, Formally (this post) — The draft-then-verify algorithm, the rejection-sampling proof, and the metrics that matter.
- A Field Guide to Speculative Decoding Methods — Separate models, Medusa, n-gram, and trees: a taxonomy of every drafting approach.
- The EAGLE Family — How predicting hidden states instead of tokens reshaped the field, across three generations.
- Parallel Drafting with Block Diffusion — DFlash collapses γ draft passes into one; DDTree turns that pass into a 7× verification tree.
- Putting It to Work — Enabling EAGLE, n-gram, and Medusa speculation in vLLM and SGLang, with a guide to measuring real speedup.
Speculative decoding makes an LLM generate faster without changing its output. It can work because LLM decoding is memory-bandwidth-bound — at batch size 1 the GPU runs at well under 1% of its compute, spending almost all its time reading the full model out of memory just to emit one token. That idle compute is the room speculation fills: verifying ten proposed tokens reads the weights once, whereas generating ten reads them ten times.
This post makes that intuition exact. We give the draft-then-verify algorithm precisely, prove that it leaves the model's output distribution untouched, and then define the metrics you need to tell a genuine speedup from a misleading one.
The draft-then-verify paradigm
Speculative decoding splits generation into two stages:
- Draft. A fast, cheap model (the draft model) generates candidate tokens autoregressively: .
- Verify. The expensive target model processes all candidates in a single forward pass and decides which to accept.
The whole game rests on one asymmetry from The Need for Speed: verification is parallel while generation is sequential. The target can compute for every at once, because all the candidate tokens are already on the table — this is a matrix–matrix multiply (a prefill), not separate matrix–vector multiplies. One read of the weights, tokens checked.
If of the tokens are accepted, we have produced tokens (the accepted, plus one fresh token — resampled at the rejection point if , or the bonus token if all are accepted) using a single forward pass of the target plus cheap draft passes. When is large relative to the drafting overhead, that is a real speedup.
The rejection-sampling algorithm
The mathematical core is a modified rejection-sampling scheme that guarantees exact distribution matching.
Input: target , draft , draft length , prefix .
Draft step. For : sample .
Verify step. Run on to obtain for all .
Accept / reject. For :
- Draw .
- If : accept .
- Otherwise: reject , sample a replacement from the adjusted distribution, discard , and stop.
Adjusted distribution. On rejection at position :
where rescales to sum to 1.
Bonus token. If all tokens are accepted, sample one extra token for free — we already computed that distribution.
Proof of losslessness
This is the property that makes speculative decoding a free lunch rather than another lossy approximation, so it is worth proving. We show the output at any position follows exactly . Fix a position and let , . The probability the output is token is
Case 1: . The token is proposed with probability and accepted with probability :
It can also arrive via rejection-and-resample. The residual mass on is , and the residual distribution is normalized by where is the total acceptance probability. The resample route contributes
The normalization is valid because, since , total excess of over equals total excess of over :
Summing: ✓
Case 2: . Now acceptance probability is , and the residual gives zero mass since :
So ✓
In both cases the output is distributed exactly as .
This argument is per-position, but it lifts to the whole sequence immediately: each accepted token extends the prefix, and the next verification conditions on that exact prefix, so applying the result position by position shows every emitted token — and therefore the entire generated sequence — is distributed exactly as the target .
The draft model's quality never appears in the conclusion. A good draft is accepted often (big speedup); a bad draft is rejected often (small speedup); neither changes the distribution. Contrast this with the lossy alternatives:
- Quantization — approximates the distribution.
- Pruning — reduces model capacity.
- Distillation — trains a smaller, weaker model.
- Early exit — truncates computation.
Speculative decoding is the rare systems-level optimization with an exact correctness guarantee.
How much do we gain? Expected tokens per step
Let be the acceptance rate at position :
where is the total-variation distance. This identity is worth pausing on: acceptance rate is one minus the TV distance between draft and target. A draft that matches the target () gives ; a draft with disjoint support gives .
Modeling each position as accepted independently with a constant rate (an idealization — real acceptances are correlated and varies by position, but it captures the dynamics well), the expected number of new tokens per step (accepted tokens plus the bonus) has a clean closed form:
A few values make the dynamics concrete:
- : tokens/step.
- : tokens/step.
- : tokens/step.
The acceptance rate is the single most important number governing performance — but, as we will see, it is necessary but not sufficient.
The metrics that matter
It is easy to report a flattering number. A method can boast a high acceptance rate yet deliver no wall-clock benefit because its drafting is too expensive. Below are the metrics a complete evaluation needs, and how they relate.
1. Token acceptance rate ()
The empirical acceptance rate over a run, pooled over every token that actually received an accept/reject test:
A "verified" token is one that was subjected to the accept/reject decision — the accepted tokens plus the single rejected token at the stopping point. The drafted tokens discarded after a rejection are not counted: they never reached verification. (Dividing by the full draft block instead would conflate acceptance rate with draft-budget utilization and systematically underestimate — e.g. reporting when the true per-token rate is .)
It is the strongest single predictor of performance, but it is distribution-, position-, and temperature-dependent: easy tokens (common words, deterministic continuations) accept more readily than hard ones (creative or technical content); early tokens in a response accept less; lower temperature concentrates mass and usually raises .
2. Expected tokens per step ()
Including the bonus token,
This is the amortized number of new tokens per target forward pass. The table below shows why blindly increasing is a trap:
| 0.5 | 1.88 | 1.97 | 1.99 | 2.00 |
| 0.7 | 2.53 | 2.94 | 3.14 | 3.27 |
| 0.8 | 2.95 | 3.69 | 4.16 | 4.57 |
| 0.9 | 3.44 | 4.69 | 5.70 | 6.86 |
| 0.95 | 3.71 | 5.30 | 6.73 | 8.62 |
For low , increasing past 3–5 buys almost nothing (every extra draft token needs all prior ones accepted, probability ); for high , longer drafts pay off handsomely.
3. Wall-clock speedup () — the metric that actually pays the bills
Let be the cost of one target forward pass, the cost of one draft pass. For tokens, autoregressive decoding costs . Speculative decoding runs steps, each costing :
Defining the draft overhead ratio :
This formula is the whole story in miniature. The numerator is what acceptance buys you; the denominator is what drafting costs you. A draft model with but (too big a draft) can easily lose to one with and . A typical well-chosen draft has — under 5% of the target's cost.
One subtlety: exactly. Verifying tokens costs slightly more than generating one because attention runs over a longer sequence and the FFN processes tokens — but since the FFN is memory-bound at batch size 1, for moderate .
4. Optimal draft length ()
Substituting into :
Setting gives an implicit equation with no closed form,
but the intuition is clean: high , low → longer drafts; low , high → shorter drafts.
5. Throughput, latency, and burstiness
- Throughput tokens/s.
- Time to first token (TTFT) is essentially unchanged — it is dominated by the target's prefill.
- Inter-token latency (ITL) becomes bursty: tokens arrive in a clump when a draft is accepted (ITL ≈ 0 within the burst), then pause for the next draft+verify cycle. Average throughput can be high while the experience feels uneven — worth keeping in mind for streaming UIs.
What to report
| Metric | Symbol | What it tells you |
|---|---|---|
| Acceptance rate | Draft quality | |
| Tokens per step | Amortized generation efficiency | |
| Wall-clock speedup | End-to-end practical benefit | |
| Optimal draft length | Configuration guidance | |
| Memory overhead | Deployment feasibility | |
| Throughput / latency | — | System-level performance and UX |
The single most common evaluation mistake is reporting only or and never measuring the clock. A high acceptance rate is necessary but not sufficient. Always close the loop with .
We now have the algorithm, the proof, and the yardsticks. What we have described so far is vanilla speculative decoding — one small model drafting for one big one. But that is only the first move in a large and inventive design space: Who drafts? How? In a chain or a tree? In A Field Guide to Methods we survey the landmark advances — Medusa, Lookahead, staged cascades, SpecInfer, Sequoia, self-speculation — and the trade-offs that distinguish them.
References
- Leviathan, Y., Kalman, M., & Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. ICML. arXiv:2211.17192.
- Chen, C., Borgeaud, S., Irving, G., Lespiau, J.-B., Sifre, L., & Jumper, J. (2023). Accelerating Large Language Model Decoding with Speculative Sampling. arXiv:2302.01318.
- Xia, H., et al. (2024). Unlocking Efficiency in LLM Inference: A Comprehensive Survey of Speculative Decoding. ACL Findings. arXiv:2401.07851.
- Leviathan, Y., et al. — see the original paper's appendix for the formal correctness proof of speculative sampling.