Fast Inference from Transformers via Speculative Decoding
This research paper explains speculative decoding: draft-and-verify sampling that accelerates autoregressive Transformers without changing architectures, training, or the output distribution.
Autoregressive Transformers decode one token at a time. Generating tokens normally means serial runs of the large target model. That loop is often memory-bandwidth bound: the hardware has spare arithmetic capacity, but each step still waits on the previous token.
Speculative decoding attacks that serial bottleneck. A cheaper draft model proposes tokens. The large target then scores those guesses (and one extra prefix) in parallel. Speculative sampling accepts as long a prefix as possible while guaranteeing the emitted tokens still follow the target distribution alone — no architecture change, no retrain, identical outputs.
What this paper explains
Standard decoding from is:
- Condition on the prefix.
- Sample one token from .
- Append and repeat.
Speculative decoding inserts a draft:
- Sample tokens autoregressively from a faster .
- Run once across the prefixes needed to score those guesses in parallel.
- Accept the longest prefix allowed by speculative sampling; on the first rejection, resample from an adjusted residual of ; if everything is accepted, still sample one bonus token from .
So each parallel target pass produces at least one new token and at most .
Prior limits
Earlier speedups usually trade something away:
- Distillation, sparsity, early-exit, and adaptive compute often change architectures or training.
- Many adaptive methods do not preserve the exact target distribution.
- Naïve “run a small model instead” changes answers.
Speculative decoding’s claim is stricter: accelerate existing off-the-shelf models, keep identical sampling behavior, and exploit spare concurrency when memory bandwidth — not FLOPs — is the limiter.
The mechanism
Draft. proposes cheaply.
Verify. evaluates for prefixes , , …, in parallel.
Speculative sampling. For each draft token with draft probability and target probability :
- If , accept.
- If , reject with probability .
- On rejection, sample from the normalized residual .
That rule is distribution-preserving: the accepted (or resampled) token is still distributed as .
Acceptance rate. Let be the probability a draft token is accepted for a given prefix, and . Under an i.i.d. simplification, the number of tokens from one Algorithm-1 step is a capped geometric random variable:
between 1 and .
Algorithm walkthrough
- Sample draft tokens from autoregressively.
- Run in parallel on the prefixes that score those drafts.
- Draw uniforms and accept until the first with .
- If a rejection happens at position , resample token from the residual of vs .
- If all drafts pass, still sample one more token from .
The opening figure is that story as a scene: small cube proposes a chain; large cube verifies; green checks keep a prefix, a red cross marks the first reject, and a star marks the corrected or bonus token.
What to notice when reading
- Speculative execution is old hardware lore; the novelty is stochastic speculative sampling that preserves .
- Walltime gains need enough spare concurrency to run target evaluations without stretching each one’s latency.
- Draft quality and relative draft cost jointly set the best (paper Figure 3 / Theorem 3.8).
- Even a trivial bigram draft can give and a small but real speedup on En→De.
Results and evidence
Implemented against T5X for T5-XXL (11B) on a single TPU-v4, batch size 1. Drafts are existing T5 checkpoints (small / base / large). Reported walltime speedups with identical outputs:
| Task | Draft | Temp | Speed | ||
|---|---|---|---|---|---|
| En→De | T5-small (77M) | 0 | 7 | 0.75 | 3.4× |
| En→De | T5-small | 1 | 7 | 0.62 | 2.6× |
| CNN/DM | T5-small | 0 | 5 | 0.65 | 3.1× |
| CNN/DM | T5-small | 1 | 5 | 0.53 | 2.3× |
Larger drafts raise but also raise , so walltime can get worse even when guesses are better (T5-large rows). Argmax (temp=0) accepts more often than temp=1.
Limitations
- Needs spare parallel capacity; if concurrent passes inflate latency, the win shrinks.
- Rejected drafts waste work; total FLOPs can rise even when walltime falls.
- Optimal fixed depends on and ; an oracle-varying could do better (left for future work in the paper).
- Gains track how well mimics on the task — hard domains with low help less.
How to read the paper
- Abstract + §1 — serial decode vs speculative concurrency.
- §2 — speculative sampling rule and Algorithm 1.
- §3 — , expected tokens, walltime theorem, choosing .
- §4 — T5-XXL walltimes (Table 2) and supporting tasks.
- Appendix — correctness proof for speculative sampling.
Knowledge check
What does speculative decoding guarantee about outputs relative to decoding from the target alone?
In one Algorithm-1 step with draft length gamma, how many new tokens can you emit?
Why can a smaller draft (T5-small) beat a larger draft (T5-large) on walltime even when alpha is lower?
Keep reading
- Original paper (arXiv:2211.17192) — Algorithm 1, Eq. 1, Table 2.
- Related Fanout Daily: Orca continuous batching, GQA, FlashAttention, PagedAttention.
- Follow-on systems literature on speculative decoding in production LLM servers (same draft-verify idea; implementations differ).
Sources
- Leviathan, Kalman, Matias, Fast Inference from Transformers via Speculative Decoding, ICML 2023 — arXiv:2211.17192