Google

The speculative decoding algorithm accelerates text generation by using a draft model to predict a sequence of future tokens, which are then evaluated by a verification model in parallel. This algorithm consists of four main steps: First, the draft model generates a sequence of $$\tau$$ candidate tokens given a prefix. Second, the verification model evaluates these predictions simultaneously. Third, the maximum number of consecutively accepted predicted tokens is determined based on their probabilities. Finally, the verification model predicts a new token following the accepted tokens, and this entire process is repeated.

Speculative Decoding Algorithm

The primary source of acceleration in speculative decoding is parallel verification. After the draft model generates a sequence of candidate tokens, the larger verification model evaluates all of them simultaneously by computing their respective conditional probabilities in a single forward pass. This ability to process multiple tokens at once is a significant departure from the standard token-by-token autoregressive approach, making the verification step highly efficient.

Parallel Verification in Speculative Decoding

In speculative decoding, the draft model prediction phase starts with a given prefix, denoted as $$[\mathbf{x}, \mathbf{y}_{\le i}]$$. The draft model is used to predict the next $$\tau$$ consecutive tokens, represented as $$\hat{y}_{i+1}, ..., \hat{y}_{i+\tau}$$. This generation is a token-by-token process where each new token $$\hat{y}_{i+t}$$ is chosen by greedily selecting the one with the highest probability according to the draft model's distribution $$\text{Pr}_q$$, conditioned on the prefix and all previously generated draft tokens. This is formally expressed as: $$\hat{y}_{i+t} = \arg\max_{y_{i+t}} \text{Pr}_q(y_{i+t}|\mathbf{x}, \mathbf{y}_{\le i}, \hat{y}_{i+1} ... \hat{y}_{i+t-1})$$.

Mathematical Formulation of Draft Model Prediction in Speculative Decoding

In speculative decoding, the draft model, denoted by `q`, defines a conditional probability distribution for generating the next token. The probability of any candidate token `y_{i+t}` is conditioned on the original input `X`, the sequence of already verified tokens `Y_{≤i}`, and all previously generated draft tokens in the current step, `ŷ_{i+1}...ŷ_{i+t-1}`. This distribution is formally expressed as `Pr_q(y_{i+t} | X, Y_{≤i}, ŷ_{i+1}...ŷ_{i+t-1})`.

Conditional Probability Distribution of the Draft Model in Speculative Decoding

In the verification phase of speculative decoding, the larger verification model evaluates the entire sequence of draft tokens, such as $(\hat{y}_{i+1}, ..., \hat{y}_{i+τ})$, in a single, parallel forward pass. This model, also known as the evaluation model, uses its probability distribution, denoted as $Pr_p(\cdot)$, to compute the likelihoods for each of the draft tokens. These probabilities are then used in the subsequent acceptance or rejection decision for each token.

Evaluation of Draft Tokens by the Verification Model

The complete output sequence after one step of speculative decoding is composed of three parts: the original context, the accepted draft tokens, and a final token from the verification model. This structure can be represented schematically as: $$[\mathbf{x}, \mathbf{y}_{\le i}] \, \hat{y}_{i+1}...\hat{y}_{i+n_a} \, \bar{y}_{i+n_a+1}$$ Here, $[\mathbf{x}, \mathbf{y}_{\le i}]$ is the context, which includes the prompt and previously confirmed tokens. This is followed by $\hat{y}_{i+1}...\hat{y}_{i+n_a}$, the sequence of $n_a$ accepted draft tokens, and is completed by $\bar{y}_{i+n_a+1}$, the single token generated by the verification model.

Structure of the Full Sequence After a Speculative Decoding Step

A text generation system uses two models: a small, fast 'draft' model and a large, accurate 'verification' model to speed up output. Arrange the following events to correctly represent one cycle of this generation process, starting from a given text prefix.

A text generation system uses a fast 'draft' model and a more accurate 'verification' model. The draft model proposes the 4-token sequence: `[jumped, over, the, moon]`. The verification model then evaluates this sequence and determines that the first two tokens (`jumped`, `over`) are correct, but the third token (`the`) is incorrect. Based on the rules of this generation algorithm, what is the immediate result of this verification step?

A text generation system uses a small, fast 'draft' model to propose a sequence of several words at once, which are then checked by a larger, more accurate 'verification' model. Describe a situation where this two-model approach would provide little to no speed advantage compared to using only the large model to generate words one by one. Justify your reasoning.

Efficiency Limits of a Two-Model Generation System

You are on-call for an internal chat product that uses speculative decoding to reduce latency. The system works as follows: a small, fast draft model autoregressively proposes a block of $\tau$ next tokens from the current prefix; then a larger verification model evaluates all $\tau$ proposed tokens in a single parallel forward pass, accepts the longest consecutive prefix of correct draft tokens starting from the first proposed token, discards the rest, and then uses the verification model to generate the next token after the accepted block before repeating the cycle.

After a recent change, you observe that end-to-end latency has increased even though the verification model still runs with parallel verification enabled. Logs show that in most cycles only 0–1 draft tokens are accepted consecutively before the first rejection, and the system frequently falls back to the verification model to generate the next token.

Write an analysis explaining (1) how the roles and interaction of the draft model, the verification model, the “maximum number of consecutively accepted tokens,” and parallel verification together determine throughput/latency in this situation, and (2) two concrete, technically plausible changes you would consider (e.g., changing $\tau$, changing the draft model, or changing how/when verification is invoked) and the tradeoffs of each. Your answer should make clear why parallel verification alone is not sufficient to guarantee speedup when consecutive acceptance is low.

Diagnosing a Speculative Decoding Slowdown in Production

You are deploying speculative decoding for a customer-facing chat product with a strict p95 latency SLO. The system uses a small, fast draft model to propose τ tokens autoregressively, then a large verification model to evaluate all τ proposed tokens in one parallel forward pass. After verification, only the maximum consecutively accepted prefix of the τ tokens is appended; at the first rejected token, the remaining draft tokens are discarded and the verification model generates the next token to continue.

In a recent A/B test, increasing τ from 4 to 16 reduced the number of verification forward passes per response, but p95 latency got worse and output quality became less stable (more abrupt shifts in tone mid-sentence). Write a recommendation memo that (1) explains, using the interaction between the draft model, the verification model, parallel verification, and the “maximum consecutively accepted tokens” rule, how a larger τ can simultaneously reduce verification-call count yet worsen tail latency and perceived quality; and (2) proposes a concrete policy for choosing τ (or adapting it online) that explicitly accounts for draft accuracy, the cost of a verification pass, and the expected consecutively accepted prefix length. Your memo should make clear what signals you would monitor in production and what trade-offs your policy is optimizing.

Choosing τ and Model Roles for Low-Latency Speculative Decoding

You are deploying speculative decoding for a customer-support chat product. Each generation cycle works as follows: (1) a small, fast draft model autoregressively proposes a block of τ candidate tokens; (2) a large verification model evaluates all τ candidates in one parallel forward pass; (3) you append only the maximum consecutively accepted prefix of the draft block (stop at the first rejected token), and then the verification model generates the next token after that accepted prefix before starting the next cycle.

Your platform team imposes a hard budget: you may run at most 1 verification-model forward pass per cycle, and the verification model is the dominant cost. You can choose between two draft models:
- Draft A: very fast but less accurate (tends to have an early rejection in the block).
- Draft B: slower but more accurate (tends to have longer consecutively accepted prefixes).

Write an evaluation recommending which draft model you would choose and how you would set τ to maximize end-to-end throughput while keeping output quality identical to the verification model alone. Your answer must explicitly connect (a) the roles of the draft vs verification model, (b) why parallel verification is the main speedup lever, and (c) how the “maximum consecutively accepted tokens” rule changes the tradeoff between draft accuracy and τ (including what happens when the first rejection occurs early vs late in the block).

Tuning Speculative Decoding Under a Fixed Verification Budget

You are reviewing a production trace from a text-generation service that uses speculative decoding with a small draft model and a large verification model. In each cycle, the draft model proposes τ=6 tokens, and the verification model performs one parallel forward pass to score all 6 proposed tokens, after which the system appends only the maximum consecutively accepted prefix of those draft tokens (stopping at the first rejection) and then uses the verification model to generate the next token before starting the next cycle.

Trace excerpt (each row is one cycle):
- Cycle 1: draft proposed 6 tokens; verification accepted/rejected = [A, A, R, A, A, A]
- Cycle 2: draft proposed 6 tokens; verification accepted/rejected = [A, R, A, A, A, A]
- Cycle 3: draft proposed 6 tokens; verification accepted/rejected = [A, A, A, A, A, A]

A product manager suggests: "To reduce latency, we should modify the system so that in Cycle 1 it appends all tokens marked A (i.e., 5 tokens) even if there is an R in the middle, because the verification model already checked them in parallel." As the on-call ML engineer, analyze this proposal and answer:

1) For each cycle, how many draft tokens would the current algorithm append to the output before the verification model generates the next token?
2) What is the most important technical reason the PM’s change would break correctness, specifically in terms of how the verification model’s parallel scoring depends on earlier draft tokens and how the algorithm defines the accepted prefix?

Interpreting a Speculative Decoding Trace and Identifying the Bottleneck

You are on-call for an internal LLM-powered customer-support drafting tool. The team recently swapped in a smaller, faster draft model to reduce latency, keeping the same large verification model. After the change, end-to-end latency improved only slightly, but GPU utilization on the verification model increased and the generated text quality remained unchanged. A trace from one representative request shows the draft model proposes τ=6 tokens each cycle, and the verification model evaluates all 6 in one parallel forward pass. The verification outcomes (from the start of each proposed 6-token block) are consistently: [Accepted, Rejected, Accepted, Accepted, Accepted, Accepted]. This pattern repeats across many cycles.

As the engineer diagnosing the regression, explain (1) what tokens actually get appended to the final output each cycle and why, and (2) how this acceptance pattern interacts with the roles of the draft model and verification model (including parallel verification) to produce the observed utilization/latency behavior. Conclude with one concrete change you would recommend (e.g., to the draft model choice or to τ) and justify it using the case details.

Explaining a “Fast but Wrong” Speculative Decoding Regression

You are on-call for an internal LLM-powered customer-support drafting tool. The team recently enabled speculative decoding to reduce latency. The system uses a small draft model to propose $\tau=6$ tokens per cycle and a large verification model to verify them in one forward pass (parallel verification). After rollout, end-to-end latency barely improves, even though GPU profiling shows the verification model is indeed doing a single forward pass per cycle.

A trace from one representative request shows the following for three consecutive speculative cycles (each cycle starts from the current verified prefix):
- Cycle 1: draft proposes 6 tokens; verification accepts tokens 1–1, rejects token 2; verification then generates the next token.
- Cycle 2: draft proposes 6 tokens; verification accepts tokens 1–0 (i.e., rejects token 1 immediately); verification then generates the next token.
- Cycle 3: draft proposes 6 tokens; verification accepts tokens 1–2, rejects token 3; verification then generates the next token.

Assume the implementation follows the standard rule: only the maximum consecutively accepted prefix of the draft tokens is appended, and at the first rejection the remaining draft tokens are discarded and the verification model supplies the next token before the next cycle begins.

As the engineer writing the incident analysis, explain (a) why parallel verification can still yield little speedup in this trace, and (b) what concrete change you would recommend—focused specifically on the draft model vs. verification model roles and/or how many tokens the draft proposes per cycle—to increase the expected number of consecutively accepted tokens and improve latency. Justify your recommendation using the interaction between draft accuracy, consecutive acceptance, and the verification step.

Root-Causing Low Speedup Despite Parallel Verification

You are implementing speculative decoding for a customer-facing writing assistant. You have two models available: a small, fast draft model (cheap per token but less accurate) and a large verification model (expensive per forward pass but accurate). The verification model can score a whole drafted block of tokens in one parallel forward pass, and the system must only append the longest consecutively accepted prefix of the drafted block; at the first rejected token, the remaining drafted tokens are discarded and the verification model must generate the next token to continue.

Your SLO is p95 end-to-end latency < 250 ms, and you have a hard budget of at most 2 verification-model forward passes per user request on average. In production you observe that for long prompts, the draft model often proposes 8 tokens, but the first rejection frequently happens at token 2 or 3, causing many discarded tokens and little speedup.

Create a concrete control policy (describe it as pseudocode or a step-by-step algorithm) that dynamically chooses (a) how many tokens the draft model should propose each cycle (τ), and (b) when to fall back to using the verification model directly, in order to maximize throughput while respecting the verification-pass budget and the “consecutively accepted tokens only” rule. Your policy must explicitly use the fact that verification is parallel, and it must specify what signals you track online (e.g., recent consecutive-acceptance lengths) and how those signals change τ and/or trigger fallback.

Learn Before

Related