Trees from Marginals: Autoregressive drafting with factorized priors
Abstract: Speculative decoding greatly increases the interactivity of autoregressive LLMs by trading off computation for extra tokens generated in a single forward pass. Factorized draft models are especially efficient because they predict future-token marginals in parallel, but their independence assumption causes acceptance rates to degrade sharply as the speculative budget grows. We analyze this limitation and introduce Weaver, a lightweight autoregressive adapter that constructs proposal trees from the top-K marginals of a factorized drafter. Weaver restores conditional dependencies between proposed tokens while avoiding a full-vocabulary projection. To support fast verification for models with Gated Delta Net layers, we derive a rollback-free tree-verification algorithm and implement optimized CUDA kernels in SGLang. By combining these model and systems contributions we achieve a 4.37-fold speedup over autoregressive decoding, and outperform a highly optimized DFlash baseline by 24.7%.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper is about making LLMs respond much faster without changing what they say. It improves a technique called speculative decoding, where a small, quick “guesser” model suggests several next tokens at once, and the big “main” model checks them in one go. The authors create a new drafter called Weaver and a smart way to check guesses quickly, especially for models that use special layers called Gated Delta Nets (GDN). Together, these ideas make generation up to 4.37 times faster than the normal step-by-step method, and about 25% faster than a strong previous baseline.
The big questions
In simple terms, the paper asks:
- How can we make LLMs generate more than one token per step while still being accurate?
- Why do some current quick-guess methods slow down when you try to guess farther ahead?
- Can we combine the best parts of two different guessing styles to keep both speed and accuracy?
- How do we quickly verify many guesses at once on models with special “recurrent-like” layers (GDN) without wasting time?
How did they try to solve it?
To follow the paper, it helps to understand a few ideas:
Quick recap: What is speculative decoding?
Imagine writing with a partner:
- The “drafter” guesses several next words quickly.
- The “verifier” (the main model) checks all those guesses at once and accepts as many as it agrees with. If many guesses get accepted, you move forward faster than writing one word at a time.
The problem with “factorized” drafters
Some fast drafters predict several future positions in parallel, treating each position independently. That’s like trying to guess letters of a word without looking at the letters you already picked. This works well for very short lookahead, but as you try to guess more tokens ahead, the guesses stop matching the verifier’s preferences, so the verifier accepts fewer tokens. Speed gains then flatten or even drop.
Their idea: Trees from Marginals (DFlash‑TfM) with Weaver
The authors combine the strengths of two approaches:
- Factorized drafter (DFlash): very fast, predicts top candidates (say, top 512 likely tokens) at several future positions in one go.
- Autoregressive drafter (Weaver): small and smart, it uses the factorized drafter’s top candidates but builds a tree of guesses that depends on earlier choices, restoring the “if this, then that” relationships the factorized model ignored.
Analogy: The factorized model gives you the top suspects for each future position. Weaver then narrows down the best sequence by considering how each choice affects the next, but only among those top suspects. Because Weaver only looks at a small list (top-K, often K=512) instead of the entire vocabulary, it avoids expensive work and stays light.
Key points about Weaver:
- It shares the big model’s token embeddings and output head but never does a full-vocabulary projection. It only scores the top-K candidates, which saves memory bandwidth and time.
- It learns to provide a “residual correction” on top of the factorized drafter’s predictions, nudging them closer to what the verifier wants.
Building the proposal tree efficiently
Weaver builds a tree of possible continuations using a best-first strategy (expand the most promising nodes first). To make this fast on GPUs, they expand several top nodes at once (a small batch, like 2–8), which uses the hardware more efficiently without losing much quality.
Fast, rollback-free verification for Gated Delta Nets
Verifying a whole tree at once is easy for pure attention models. But many strong modern models (like Qwen3.6) include GDN layers, which keep a running internal state. Naively checking each branch one-by-one is slow, and “rewinding” that state after each branch is even worse.
The authors design a special GPU kernel that:
- Checks the entire tree in a single pass without ever committing to a branch prematurely.
- Avoids rolling the internal state backward (“rollback-free”).
- Uses a math trick (a masked triangular solve) to apply only the relevant ancestor information for each node in the tree.
- Fits neatly into the SGLang framework for practical use.
In short: they can generate a tree of guesses and check them all at once, even with GDN layers, very efficiently.
What did they find, and why does it matter?
Here are the main results from tests on the Qwen3.6‑27B model in bfloat16 on a single NVIDIA B200 GPU:
- Speed: Their method achieves a 4.37× speedup over standard autoregressive decoding and is 24.7% faster than an optimized DFlash baseline.
- Acceptance length: On average, more of the drafted tokens are accepted per step.
- 77% longer accepted sequences than a chain-style DFlash baseline.
- 32% longer accepted sequences than another tree method (DDTree) at the same tree size.
- Consistent across tasks: Gains show up in chat, math, and coding benchmarks.
- Theoretical insight: They argue and show experimentally that factorized drafters face an acceptance ceiling at longer depths because they ignore dependencies between positions. Their hybrid approach (Weaver over top‑K marginals) surpasses that ceiling by conditioning each guess on previously selected draft tokens, even though it still only looks at the top-K candidates.
Why it matters:
- Faster responses improve user experience (more interactive systems).
- Better energy efficiency: doing more useful compute per memory read saves power and time.
- Works well when you can’t batch many users together (common on local or personal devices), because speculative decoding boosts throughput per single sequence.
A few extra details for curious readers
- Weaver is small: about 56.7 million parameters (tiny compared to the main model).
- It’s trained to match the verifier’s preferences within the top‑K candidate set, using a loss that gradually focuses on improving acceptance.
- For GDN verification, their fused CUDA kernel checks the whole tree faster than branch-by-branch methods, and avoids costly state rewinds.
- Everything runs in SGLang; the Weaver weights are available, and the method can work on top of other factorized drafters too (not only DFlash).
What’s the bigger impact?
This work shows a practical way to:
- Keep the speed of parallel guessing (factorized marginals).
- Regain the accuracy of “if this, then that” reasoning (autoregressive conditioning).
- Verify trees efficiently, even in models with recurrent-like layers.
Looking ahead, the authors suggest improving tree building by directly targeting acceptance probability (not just draft probability), extending the lookahead window, co-training Weaver with the factorized drafter, and using the kernels for multi-request serving to boost throughput as well as interactivity.
Overall, the approach makes LLMs respond faster without sacrificing quality, bringing snappier, more energy-efficient AI to real-world apps.
Knowledge Gaps
Unresolved knowledge gaps, limitations, and open questions
Below is a single, concrete list of what remains uncertain or unexplored in the paper, framed to guide follow‑up research:
- Generalization across backbones: Results are only shown for Qwen3.6-27B; it is unknown how DFlash‑TfM and the GDN verification kernel perform with other architectures (e.g., Llama, Mistral, Mamba, Gemma, I-DLM as the factorized drafter).
- Robustness to multilingual and domain-shifted inputs: Evaluation focuses on English chat/math/code; coverage and acceptance behavior for multilingual, non-Latin scripts, domain-specific vocabularies, and noisy inputs remain untested.
- Accuracy/quality impact: The study reports speed and mean acceptance length but not end-task accuracy (e.g., GSM8K exact match, pass@1 on code). Whether acceleration affects solution quality or error profiles is unknown.
- Candidate pool coverage limits: Top‑K=512 marginal restriction is assumed sufficient (97.8% mass on held-out), but the fraction of verifier mass outside the pool across tasks/temperatures/lengths is not systematically quantified; failure rates when the ground-truth token lies outside the candidate set are unreported.
- Adaptive candidate sizing: No exploration of dynamic K (per position or per context) vs. fixed 512; how K trades off bandwidth, acceptance, and accuracy is unstudied.
- Weaver capacity and design ablations: Only a single 56.7M, 1‑layer configuration is used; the sensitivity to model depth, width, attention heads, conditioning inputs, or alternative residual parameterizations is unknown.
- Training objective alternatives: The LK loss is adopted; comparisons to forward/reverse KL, focal losses, temperature scaling, contrastive objectives, or acceptance‑aware surrogates are not provided.
- Train–inference mismatch: Weaver is trained from temperature‑0.0 rollouts but evaluated at temperature 1.0; the impact of this distribution shift on acceptance and correctness is not quantified, and training with matched sampling policies is not tested.
- Data scale and composition: Weaver is trained on 300k completions for one epoch; scaling laws, data diversity effects, and the role of code vs. chat vs. math mixture on acceptance and generalization are unexamined.
- Joint training of drafter and adapter: Weaver is trained against a frozen DFlash; the benefits and risks of jointly training to shape marginal supports around conditional corrections are not explored (only suggested as future work).
- Longer marginal horizons: DFlash’s block size (16) limits tree depth; no experiments with longer marginal windows or mid-draft re-anchoring to extend proposals beyond this horizon.
- Tree shape optimization under acceptance estimates: Tree construction maximizes draft probability (a proxy); building/pruning trees using direct acceptance‑probability estimates or learned surrogates is not evaluated.
- Batched frontier expansion parameter (w): The effect of the parallel expansion width w (2–8) on acceptance, end-to-end latency, and memory traffic is not systematically ablated.
- Interaction with alternative verification schemes: Only traversal verification (for trees) and a comparison to naive/speculative sampling for chains are shown; coupling with OT-based approximate verifiers (e.g., SpecTr) or hybrid verifiers is not assessed.
- Theoretical guarantees beyond empirical bounds: The TV-based acceptance ceiling is estimated empirically on MTBench with finite M; no distribution-agnostic bounds or formal guarantees are provided that DFlash‑TfM will surpass marginal drafters across tasks and sampling regimes.
- Acceptance at long depths and long contexts: While acceptance surpasses marginal-oracle estimates at some depths, the asymptotic behavior with very long contexts (e.g., >32k tokens) and deeper trees is not characterized.
- Sensitivity to sampling hyperparameters: Only temperature 0.0 and 1.0 settings (with/without reasoning) are reported; effects of top‑p, top‑k, typical sampling, repetition penalties, and reasoning toggles on acceptance/speed are unstudied.
- Systems portability and hardware coverage: Kernels are implemented for SGLang and profiled on a single NVIDIA B200; performance and numerical stability on other GPUs (A100/H100/RTX), other precisions (fp8/int8), and other runtimes are unreported.
- Multi‑GPU and distributed settings: The approach is evaluated on single‑GPU; scaling behavior, KV/state sharding, and interconnect overheads for multi‑GPU or heterogeneous deployments are unexplored.
- Throughput serving vs. interactivity: Scheduling for concurrent requests (batch>1) is mentioned as future work; the trade-offs between per‑request interactivity and aggregate throughput with the fused verify and Weaver batching are unquantified.
- Memory footprint and energy efficiency: Although motivated by memory‑bound decoding, the paper does not report VRAM usage, KV cache overhead, candidate‑pool memory traffic, or energy/token metrics for each method.
- Applicability to other recurrent/SSM layers: The rollback‑free masked‑solve is derived for GDN; its applicability to other non‑diagonal SSMs (e.g., Mamba‑2 variants, Hyena‑style convolutions) and mixed‑block architectures is not evaluated.
- Numerical stability and precision choices: The fused kernel uses tf32 accumulation and tf32x3 for log‑decays; error bounds beyond ≈1e‑4 vs. fp64, behavior under extreme sequence lengths, and sensitivity to small/large decays are not analyzed.
- Failure modes and safety: Scenarios where top‑K truncation or incorrect conditional residuals cause consistent rejection cascades or degenerate proposals are not analyzed; recovery strategies (e.g., dynamic widening, verifier fallback policies) are unspecified.
- Fairness of baselines: The DFlash baseline is noted as “still under training”; comparisons to other strong open baselines (e.g., I‑DLM, LayerSkip/Hydra variants on the same backbone) and to EAGLE‑class adapters on a comparable model are absent.
- Integration constraints: Weaver shares embeddings and the output projection with the verifier; this may preclude use with closed‑weight or API‑only LLMs, and the feasibility of retrofitting to such settings is not discussed.
Practical Applications
Immediate Applications
The following applications can be deployed now using the paper’s released weights and SGLang implementation (with Qwen3.6-27B and NVIDIA GPUs), or with modest engineering to adapt to adjacent stacks.
- Faster local LLM assistants (desktop, edge, and on-prem)
- Sectors: software, privacy-first consumer apps, SMB/enterprise IT
- What: Drop-in acceleration for single-request, low-batch workloads where interactivity (tok/s per sequence) is key (e.g., note-taking assistants, document Q&A, private chatbots).
- Tools/workflows: Integrate DFlash-TfM drafting in SGLang; use Weaver weights; enable tree verification with the provided CUDA kernels; run Qwen3.6-27B bf16 on a single NVIDIA GPU.
- Assumptions/dependencies: Qwen3.6-27B or a compatible target; CUDA-capable GPU; top-K candidate pool covers most probability mass (as observed ~97.8% inside top-512); model and system fit into VRAM.
- Enterprise copilots with reduced latency and energy per token
- Sectors: software, productivity, customer support
- What: Improve responsiveness for internal copilots (search, summarization, ticket triage) that serve mostly single-user, bursty traffic where batching is limited.
- Tools/workflows: SGLang-based serving with DFlash-TfM; Tree verification with Traversal verification; autotune tree budget to meet SLAs.
- Assumptions/dependencies: Deployment on NVIDIA GPUs; slight integration work if using non-SGLang runtimes; adherence to enterprise model governance and safety layers.
- Interactive coding assistants in IDEs
- Sectors: software engineering
- What: Lower keystroke-to-completion latency for inline suggestions and refactors, especially under “reasoning on.”
- Tools/workflows: IDE plugin that routes to a DFlash-TfM-enabled inference service; tune tree budgets per context length; cache-aware request scheduling.
- Assumptions/dependencies: Model compatibility and GPU access; minor plumbing to support streaming completions with speculative acceptance.
- On-prem healthcare assistants for compliant, private workflows
- Sectors: healthcare
- What: Summarization, note drafting, order set suggestions on local servers where batching is minimal; improved interactivity without sending PHI off-prem.
- Tools/workflows: Hospital IT deploys Qwen3.6-27B + DFlash-TfM via SGLang; monitor acceptance lengths and set conservative sampling.
- Assumptions/dependencies: Regulatory compliance, domain evaluation, and guardrails; on-prem NVIDIA GPU capacity; institutional approval.
- Finance research and deal desk copilots
- Sectors: finance
- What: Rapid Q&A over internal documents and market commentary with lower energy and higher responsiveness vs. baseline AR decoding.
- Tools/workflows: SGLang service with DFlash-TfM; per-team GPU nodes; audit logging of acceptance/reject for reproducibility.
- Assumptions/dependencies: Access controls, privacy compliance; possibly retrain or adapt Weaver for proprietary models if not on Qwen3.6.
- Robotics and HRI on-board language reasoning
- Sectors: robotics
- What: Reduced-latency planning/interaction on edge compute where batch is near-zero; improved interactivity for teleoperation and dialogue grounding.
- Tools/workflows: Integrate DFlash-TfM serving on an onboard NVIDIA GPU; adjust tree budgets for thermals and power caps; use traversal verification to avoid state rollback.
- Assumptions/dependencies: GPU availability (Jetson/Orin support may require kernel porting); real-time constraints; safety validation.
- Academic RL and RLHF systems requiring fast rollouts
- Sectors: academia, AI research
- What: Higher tokens/s per sequence improves asynchronous RL (lower rollout latency, reduced bias) and speeds RLHF data generation.
- Tools/workflows: Replace AR decoding in RL pipelines with DFlash-TfM; log acceptance lengths; coordinate with trainers on sampling temperature/“reasoning on” flags.
- Assumptions/dependencies: Compatibility with training frameworks; stable reproducibility under sampling; GPU scheduling aligned with rollouts.
- Cost and sustainability optimization in LLM serving
- Sectors: cloud/energy, infra
- What: Increased arithmetic intensity and fewer DRAM-bound steps reduce energy per generated token at similar quality; lower TCO for interactive endpoints.
- Tools/workflows: Deploy DFlash-TfM in SGLang; measure GPU utilization, DRAM traffic, tok/J metrics; tune tree budget vs. SLA.
- Assumptions/dependencies: Realized energy gains depend on hardware, cooling, and workload mix; best for low-batch, latency-sensitive traffic.
- Inference engine upgrades (framework vendors and teams)
- Sectors: software infrastructure
- What: Add GDN tree verification kernels and Trees-from-Marginals to inference stacks (e.g., SGLang, then port to vLLM/TensorRT-LLM).
- Tools/workflows: Implement masked triangular-solve verification and CUDA-graph capture; expose tree budget and expansion width w; acceptance-aware profiling.
- Assumptions/dependencies: Kernel engineering for non-SGLang runtimes; platform-specific tuning; license and maintenance policies.
- Acceptance-aware serving policies and observability
- Sectors: platform engineering
- What: New runtime metrics (mean accepted length, per-depth acceptance curves) guide dynamic tree budgets and w-ary expansion to hit latency targets.
- Tools/workflows: Telemetry hooks in SGLang; auto-tuner to adjust tree shape/budget; dashboards correlating acceptance vs. temperature/context.
- Assumptions/dependencies: Reliable acceptance logging; safeguards to prevent quality regression at high temperatures.
- Education: on-device tutors and lab assistants
- Sectors: education
- What: Faster feedback for problem-solving and coding labs on lab workstations or teacher laptops without large-batch serving.
- Tools/workflows: SGLang-hosted Qwen3.6-27B with DFlash-TfM; pre-provisioned GPU nodes; usage controls for classrooms.
- Assumptions/dependencies: Hardware availability; school policy; content moderation.
- Voice and multimodal chat front-ends (text core)
- Sectors: consumer apps, CX
- What: Faster text core in speech→text→LLM→text→speech loops reduces E2E latency for voice assistants and call-center tools.
- Tools/workflows: Pipe ASR/TTS around DFlash-TfM for the LLM core; adjust budgets for streaming cadence.
- Assumptions/dependencies: Integration latencies in ASR/TTS may dominate; GPU capacity for concurrent pipelines.
Long-Term Applications
These require additional research, training, kernel ports, or system changes before broad deployment.
- Model-family generalization (beyond Qwen3.6 and GDN targets)
- Sectors: software, platform infra
- What: Train Weaver-like adapters and implement tree verification for other model families (Llama/Mistral variants, hybrid SSMs).
- Dependencies: Access to factorized drafter signals (top-K marginals) or an equivalent; new kernels for non-GDN recurrences; retraining costs.
- Joint training of drafter and Weaver
- Sectors: research, platform infra
- What: Co-train factors so marginal support and conditional residuals align, raising acceptance at depth and reducing tree budget needs.
- Dependencies: Training pipeline changes; stability tuning; potential new objectives (acceptance-aware losses).
- Acceptance-optimized tree construction
- Sectors: inference infra
- What: Replace maximum-draft-probability expansion with acceptance-probability estimators for branch selection and pruning.
- Dependencies: Efficient estimators; runtime budget; scheduler integration; theoretical guarantees.
- Throughput-mode serving for multi-tenant clusters
- Sectors: cloud/enterprise
- What: Extend verify kernels and schedulers to batch across concurrent requests while preserving interactive benefits.
- Dependencies: Cross-request tree coalescing; KV/state sharing policies; queueing theory and fairness controls.
- Hardware-software co-design for state-space tree verification
- Sectors: semiconductors, edge compute
- What: Primitive support for masked triangular solves and blockwise forward substitutions in GPUs/NPUs; on-chip memory layouts optimized for tree masks.
- Dependencies: Vendor collaboration; ISA extensions; long lead times; ecosystem adoption.
- Ports to non-NVIDIA platforms and mobile
- Sectors: mobile, edge, cross-vendor clouds
- What: ROCm (AMD), Metal (Apple), Vulkan/DirectML ports; eventual NPU/SoC implementations for laptops/phones and robotics SBCs.
- Dependencies: Kernel reimplementation; precision and perf tuning; memory constraints; quantization compatibility.
- Multimodal speculative decoding (vision, audio)
- Sectors: multimodal AI, CX
- What: Apply Trees-from-Marginals to decoder components in VLMs or speech LMs with state-space layers.
- Dependencies: Multimodal drafters and adapters; verify kernels for modality-specific recurrences; evaluation of quality under aggressive speculation.
- Policy and sustainability standards
- Sectors: policy, sustainability
- What: Encourage reporting of tok/J and DRAM traffic per token; promote interactivity-centric inference for privacy-preserving local deployments.
- Dependencies: Consensus metrics; independent audits; procurement guidelines; alignment with regulatory bodies.
- Safety and alignment workflows leveraging higher interactivity
- Sectors: safety research, governance
- What: Use faster interactive loops to collect richer human feedback, calibrate reasoning settings, and detect failure modes in near-real-time.
- Dependencies: Integrated feedback tooling; measurement frameworks; careful sampling policy design.
- Developer-facing tools that adapt budgets to context difficulty
- Sectors: developer tooling
- What: IDE and notebook extensions that estimate acceptance probability from context entropy and auto-tune tree budget and w.
- Dependencies: Lightweight predictors; user controls; UX research.
- Training-time acceleration for synthetic data generation
- Sectors: data engineering, model training
- What: Use speculative trees to generate long synthetic corpora faster (code, math, reasoning traces) feeding pretraining or SFT.
- Dependencies: Quality assurance; stability under diverse sampling params; integration with data pipelines.
Notes on Feasibility and Dependencies
- Model compatibility: Immediate deployment is easiest with Qwen3.6-27B bf16 using the released Weaver and SGLang fork. Other models require training an equivalent Weaver adapter and ensuring access to factorized top-K marginals.
- Hardware: Current kernels target NVIDIA GPUs (tested on B200) with CUDA graphs; ports are needed for AMD/Apple/CPU-only environments.
- Quality/temperature: Acceptance and speed gains depend on sampling temperature and “reasoning on” settings; tune per workload.
- Tree budget and expansion width: Performance hinges on selecting tree budget and batched expansion width w (2–8 typical) to balance throughput and acceptance quality.
- Memory and precision: Benefits come partly from avoiding full-vocab projections in the drafter and minimizing DRAM traffic; verify VRAM and precision policies (bf16/tf32 accumulation) for numerical stability.
- Safety and compliance: Domain deployments (healthcare, finance) require additional evaluation, prompt/response filtering, audit trails, and policy alignment.
Glossary
- Acceptance rate: The probability that proposed draft tokens are accepted by the verifier during speculative decoding; it often declines with deeper drafts. "the acceptance rate falls as the draft length grows (Figure 1)."
- Ancestor mask: A masking constraint that restricts attention or recurrence to a node’s ancestors in a tree, used to enable efficient parallel verification. "the sequence ancestor mask does not hold because of the non-commutative state transition."
- Argmax: The token with highest probability under a distribution; using argmax proposals can change verification behavior. "because DFlash's argmax proposals are deterministic, naive verification is a natural (and better-performing) fit for them,"
- Autoregressive decoding: Token generation where each new token is produced sequentially conditioned on all previous tokens. "we achieve a 4.37x speedup over autoregressive decoding,"
- Autoregressive drafter: A draft model that proposes multiple tokens sequentially, conditioning each on previously drafted tokens. "a small autoregressive drafter which we call Weaver."
- bfloat16: A 16-bit floating-point format commonly used to accelerate and stabilize deep learning inference and training. "in bfloat16 precision"
- BlockVerify: A verification method that jointly accepts blocks of draft tokens via optimal transport coupling. "BlockVerify[26] improves the verification procedure for multi-token drafts"
- Candidate vocabulary: A limited subset of tokens considered for prediction to reduce computation, often chosen via top-K filtering. "We constrain the candidate vocabulary at each speculative position to the top-K marginal tokens"
- Causal attention mask: An attention constraint ensuring tokens attend only to past positions; adapted for tree verification as “tree attention.” "the causal attention mask (usually referred to as tree attention)"
- CUDA graph: A CUDA mechanism to capture and replay GPU computation graphs for reduced launch overhead. "so the whole pass is captured once and replayed inside a CUDA graph."
- CUDA kernels: GPU-executed functions used here to accelerate verification and model operations. "and implement optimized CUDA kernels in SGLang."
- DDTree: A tree-based drafting method built on block diffusion priors. "relative to DDTree[11] with the same tree size."
- Delta-rule targets: Models with delta-rule style linear recurrences for state updates, which complicate tree verification. "leaving efficient single-pass tree verification for delta-rule targets an open problem."
- DFlash: A factorized, diffusion-inspired drafter that predicts future-token marginals in parallel. "We extract the top-K marginal predictions produced in a single forward pass by the factorized drafter DFlash[9]."
- Dirac delta distribution: A distribution concentrated entirely at a single outcome; used as an alternative to full marginals for drafting. "using a Dirac delta distribution with the peak at the top-1 token of the marginal distribution"
- DySpec: A method that optimizes draft-tree construction, often via dynamic programming or best-first expansion. "DySpec[31] demonstrated that constructing maximum-drafter-probability1 trees requires expanding the highest-probability node"
- EAGLE: A family of lightweight adapter drafters that reuse verifier features and projection heads. "EAGLE[15], EAGLE-2[22] and EAGLE-3[23] all train lightweight adapters"
- Factorized drafter: A drafter that predicts multiple future tokens in parallel as independent marginals conditioned on the prefix. "Factorized drafters predict T future positions in a single forward pass,"
- Gated Delta Net (GDN): A state-space layer with gated delta-rule recurrences used in modern LLMs, requiring special verification handling. "gated delta networks (GDN)[35]"
- Greedy decoding: A decoding strategy that selects the highest-probability token at each step. "Although it is optimal for greedy decoding, it has a fairly poor acceptance rate"
- Hydra: An adapter-based autoregressive drafting approach that reuses verifier activations and projection layers. "Hydra[21], EAGLE[15], EAGLE-2[22] and EAGLE-3[23] all train lightweight adapters"
- I-DLM: Introspective Diffusion LLMs that predict future-token marginals in parallel using the verifier itself. "I-DLM[7] fine-tunes the verifier to predict marginal distributions over future tokens in parallel"
- KV cache: Cached key-value tensors from attention layers that enable efficient incremental decoding. "the weights, activations and KV cache between DRAM and SRAM1,"
- Likelihood ratio test: A statistical test used in speculative sampling to decide whether to accept a draft token. "by performing a likelihood ratio test."
- Linear recurrence: A recurrence relation used in state-space layers; here, handled via chunked triangular solves for verification. "the dual chunk form of the linear recur- rence."
- LK loss: A training objective mixing KL divergence and total variation distance to align the drafter with the verifier. "We train Weaver with the LK loss[38] between the verifier distribution p and the proposal distribution q,"
- Mamba-style transition: A diagonal state-transition structure enabling efficient scans in some state-space models. "for a diagonal, Mamba-style transition the state at a node is a product of the gates along its path,"
- Marginal distribution: The per-position token distribution that ignores future conditional dependencies within the drafted block. "predict marginal distributions over future tokens in parallel"
- Masked triangular solve: A linear-algebra solve restricted by ancestor masks that enables efficient tree verification for state-space layers. "reduces tree verification for delta-rule layers to a masked triangular solve"
- Medusa: A method adding multiple decoding heads to the verifier to predict future tokens in parallel. "Medusa[14] adds lightweight decoding heads on top of the last layer features of the verifier,"
- Naive verification: A baseline verification method that samples the verifier independently conditioned on the draft, often with lower acceptance. "We call this algorithm naive verification."
- Optimal transport: A coupling framework used to maximize acceptance jointly over token sequences during block or tree verification. "by searching for an optimal transport coupling between joint distributions over sequences of tokens."
- Prefix tree: A tree of candidate continuations whose nodes share ancestral prefixes, enabling parallel verification. "construct a prefix tree from multiple proposals."
- SGLang: An inference framework used here for implementing and benchmarking kernels and speculative methods. "in the SGLang framework[12]."
- Speculative budget: The number of draft tokens proposed before verification in each step. "acceptance rates to degrade sharply as the speculative budget grows."
- Speculative decoding: An acceleration technique that drafts multiple tokens and verifies them in parallel to reduce latency. "Speculative decoding greatly increases the interactivity of autoregressive lan- guage models"
- Speculative sampling: The original acceptance scheme for speculative decoding based on likelihood ratios between drafter and verifier. "Speculative sampling is the original sampling scheme proposed by Leviathan et al.[5]"
- State-space models: Sequence models with recurrent state updates (e.g., GDN, Mamba) requiring specialized verification techniques. "STree[34] brought tree verification to state-space models"
- Top-K: A truncation strategy that keeps only the K most probable tokens, often to limit projection costs. "We extract the top-K marginal predictions produced in a single forward pass"
- Total variation distance (TV): A distributional distance used to express and bound acceptance probabilities. "Acceptance probability for speculative sampling can be also expressed in terms of the total variation distance"
- Traversal verification: A tree verification algorithm that generalizes block verification to hierarchical drafts. "Traversal verification[10] extends the Block Verify block-level verification idea to trees of tokens,"
- Tree attention: An attention masking scheme that restricts attention to ancestors, enabling parallel scoring of draft trees. "the causal attention mask (usually referred to as tree attention)"
- Verifier: The main target model that evaluates and accepts or rejects proposed draft tokens. "the main model (called verifier hereafter)"
- Vocabulary projection matrix: The final linear map from hidden states to token logits; often a memory bottleneck. "the verifier vocabulary projection matrix W vocab"
- Warmup-stable-decay (WSD) schedule: A learning-rate schedule with warmup and stable phases followed by decay. "under a warmup-stable-decay (WSD) schedule"
- Weaver: A lightweight autoregressive adapter that conditions on top-K marginals to build proposal trees efficiently. "We introduce Weaver, a lightweight autoregressive adapter"
Collections
Sign up for free to add this paper to one or more collections.