Not-a-Bandit: Provably No-Regret Drafter Selection in Speculative Decoding for LLMs
Hongyi Liu, Jiaji Huang, Zhen Jia, Youngsuk Park, Yu-Xiang Wang
ICLR'26
cs.LG
2025-10-23
Speculative decoding's verification step already reveals every draft model's quality for free, so HedgeSpec needs no exploration to pick the best one. It beats EAGLE3 by nearly 2x on Qwen-3-32B.
Speculative decoding is the standard way to speed up LLM serving: a small "draft" model guesses the next several tokens, and the big target model verifies them in a single parallel forward pass. Every correctly guessed token is a forward pass you skip. The better the draft matches the target, the bigger the speedup.
The catch: no single draft model matches the target everywhere. A draft fine-tuned for Python loses on SQL; one tuned for medical QA loses on summarization. Run the wrong drafter and the target rejects most of its guesses, wasting the speculative work. The prior fix, BanditSpec, treats picking the drafter as a multi-armed bandit: you only see how the chosen drafter did, so you must pay to explore (try drafters you are unsure about), and that cost grows as the pool grows.
The reframe is that speculative decoding's verification step is already a full-information oracle. When the target verifies a chunk, it exposes its own distribution over the next token. That distribution is enough to compute, counterfactually, how well any drafter would have done on this chunk, not just the one you ran. Theorem 3 makes this rigorous: a single verified trajectory yields an unbiased estimate of every drafter's expected acceptance length, with no extra calls to the target.
So the problem moves from a bandit (partial feedback) to full-information online learning. HedgeSpec runs a NormalHedge exponential-weights learner over the drafters, updating each weight from this counterfactual loss. Regret is O(sqrt(T log N)), logarithmic in the number of drafters, versus the polynomial-in-N dependence of bandit methods. Double the pool and HedgeSpec barely blinks; EXP3/UCB degrade visibly.
Design choices, each motivated:
Cost: evaluating a drafter is about 1/25 of a target forward pass (2.5 ms vs 75.7 ms in their setup), and parallelizable. One extra accepted token pays for evaluating roughly 25 drafters.
Three target models, each with 7 domain-specialized drafters (Python, math, biology, chemistry, MedQA, CNN/DM summarization, SQL), against EAGLE3, BanditSpec (EXP3/UCB), and a static BERT router:
| Target | Method | Avg accepted tokens | Avg throughput (tok/s) |
| LLaMA-3.1-8B-IT | EAGLE3 | 5.69 | 74.34 |
| LLaMA-3.1-8B-IT | HedgeSpec | 7.15 | 90.41 |
| Qwen-3-8B | EAGLE3 | 4.23 | 47.53 |
| Qwen-3-8B | HedgeSpec | 6.37 | 69.44 |
| Qwen-3-32B | EAGLE3 | 2.88 | 20.76 |
| Qwen-3-32B | HedgeSpec | 6.21 | 40.41 |
In throughput: LLaMA-3.1-8B about 21.6%, Qwen-3-8B about 46.1% (SQL domain 83.7%), Qwen-3-32B about 94.7%. As the drafter pool grows, HedgeSpec holds steady while bandit methods fall apart.
Distribution shift tells the other half. The offline BERT router misroutes catastrophically on reworded prompts (98% on MedQA, 90% on math); HedgeSpec adapts at runtime and reaches up to 2.34x over the static router.
In practice, production traffic is mixed: code, math, summarization, and chat arrive together, and one general drafter cannot cover all of it. HedgeSpec lets you keep a stable of specialists and route online, for free.
The bigger takeaway is conceptual: speculative decoding's verification step was hiding a full-information oracle all along, and bandit-style exploration was the wrong frame here from the start. The honest caveat is that the win has a precondition. You need to actually have specialized drafters to choose among. With a single generic drafter, there is nothing to route.