vizmaya desk · 3 Nov 2026
SpecPilot: how an AI loop sped up LLM decoding 2.13x
184 → 416tokens a second
Same chip, same model, no retraining. No quality loss, say the authors.
But with a crowd of users, one of its best tricks made things 13% slower.
How does a program find speed that human engineers missed?
Source: arXiv:2611.02501, p1, p12 (Fig 8), p2
Photo: Wikimedia racks ULSFO 2013 06 06 02 / Mutante, Wikimedia Commons, CC BY-SA 3.0
The old world
A chatbot writes one piece at a time
Text comes out in small pieces called tokens. Each new piece needs one full trip through the model.
On this chip, plain decoding makes 49.9 pieces a second. That is 20.0 ms for each piece (computed: 1000 / 49.9).
Illustration of tokens, not data. Source: p1; Table A1, p21
So where do those 20 milliseconds go?
The crack
The chip mostly just reads
To make one piece, the chip reads all of the model's numbers from memory. That read takes 80% of a 23.61 ms step.
So extra checking is almost free. The main math took 17.88 ms for 1 row and 18.58 ms for 64.
That is the trick behind speculative decoding. A small helper guesses ahead. The big model checks every guess in one pass.

Source: p5; Fig 2a. 0.70 ms gap computed (18.58 - 17.88).
If checking is free, does the stock system use it?
The crack
Stock checks one chain, then quits at the first miss
The helper ranks several guesses for each spot. The stock system follows just one and stops at its first miss.
A tree keeps the runner-up guesses alive. In replay on the same guesses, a chain locks in 4.25 pieces per check. A 32-node tree gets 5.38.
Source: p5, p8 (Fig 6), p13 (Fig 10). Diagram is an illustration.
Illustration, not data. Green is accepted, red rejected, dashed never checked.
Who has time to hand-tune this for every chip and model?
The turn
So the authors built a loop, not a fix
An AI agent loop measures where speed is lost, tries fixes in parallel, and keeps only those that win on requests it has not seen.
Over 13 rounds it made 486 code changes. 54 survived: 11.1% (computed). The agents were Claude Opus 5.5 inside Claude Code.
Source: p4 (Fig 3), p6, p10, p22 (Table A4). 11.1% = 54 / 486, computed.
What stops an agent from cheating to look fast?
The turn
A speed-hungry agent can cheat. So every word gets checked
A faulty change can nudge the model's choices and still pass an accuracy test. Its accuracy moved by -1.6 points, with a range of -3.6 to +0.3 that includes zero.
Token forcing re-scores each output word against the original system. Honest systems matched stock (0.73% vs 0.72%). The faulty one did not (2.0%).
Source: p13 (section 6.2); p6 (Fig 4). Limit line = stock + 0.5 points, computed.
With a guard in place, what did the honest loop find?
Round 1 of 3
First, use the guesses already on the table
Three changes: a cheaper helper, a tree, a wider tree. Speed went from 184 to about 270 tokens a second.
Then the loop re-measured. A better tree on the same guesses would add little. The bottleneck had moved.
Source: p12; Fig 8; Table A3 (p21). Step values computed by adding the gains printed on Fig 8.
If guesses are no longer the problem, what is?
Round 2 of 3
Next, make every number in the model smaller
Reading the model took 80% of each step. So the loop stored each number in 12 bits, not 16. It is called W12, and it loses nothing.
The server checks every decoded number against the original at load. One layer set shrank from 44.67 GB to 33.58 GB.
A denser 11-bit version decoded 3x slower. The loop dropped it.
16 BITS PER NUMBER (BF16)
12 BITS PER NUMBER (W12): SIGN, A 4-BIT EXPONENT CODE, 7 MANTISSA BITS
Rare numbers that do not fit (7.3 in 100,000) go on an exact side list. Round 2: 269 to 354 tokens a second (computed).
Source: p7 (Fig 5), p8, p6, p23 (Table A7); round steps from p12 Fig 8 and Table A3, computed. 12 bits is 25% fewer than 16.
Fewer bytes to read. What is left to squeeze?
Round 3 of 3
Last, check cheaply first, then check once for real
The loop added a cheap first check that reads only part of each number. It picks the same top word as the exact check 98.7% of the time.
Only the exact check can accept a word, so the answers stay exact. Each exact check now locks in 11.67 pieces, up from 6.16.
ONE CYCLE ON THE H100, ABOUT 30 MS (SUM 30.1, COMPUTED)
Source: p9 (Fig 7), p21 (Fig A3, Appendix C), p12.
Add it all up. How fast is it now?
The result
416 tokens a second, from 184
416tok/s
Plain decoding makes 50, stock 184, SpecPilot 416. That is 8.3x plain decoding (computed) and 2.13x stock on requests it had never seen.
Source: p12 (Fig 8); Table 3 (p14); Table A1 (p21). 8.3x = 416.1 / 49.9, computed. On the dev bench the ratio to stock is 2.26x (416.1 / 183.9, computed); the sealed test gives 2.13x.
Does it still hold when many people use the chip at once?
The twist
Add a crowd and the speed-up shrinks
Each extra request brings its own work, so reading the model stops being the main cost.
Stock's speed-up over plain decoding fell from 3.40x to 1.89x at 24 requests. On a smaller model it fell from 3.73x to 1.49x at 32.

Source: p3 (Fig 2b); p5.
Do the one-chat tricks still work in a crowd?
The twist
Some tricks flip from win to loss
A trick that spends extra checking work wins when one chat waits on memory. In a crowd, that work adds up.
In batches, the two-level check was 13% slower, 24-node trees 14.9% slower, a 24-position draft block 9.9% slower. Picky tricks that spend work only where it pays gained a few percent.
Source: p14 (section 6.5). Different targets: BF16 and FP8 Qwen3.8-27B; blocks with DSpark; prompt admission unpaired.
So why did the loop find a different fix in each situation?
What made the difference
Re-measuring beat just trying things
A loop with no cost model reached 1.34x over stock. The full loop reached 2.13x.
The plain loop kept adding tokens per step. It never touched weight reads, which took 80% of the step. The full loop re-measured every round and followed the biggest gap as it moved.
One comparison. The paper does not state how many runs.
Source: p12 (section 6.1).
What do you do with this the next time you see a big number?
Payoff
Three questions before you believe a speed-up
- One user or many? The headline pairs are 4.46x to 10.87x with one request, and 1.94x to 3.93x with batching.
- Best case or typical? 10.87x is the top setting. Over stock, single-request gains run 2.13x to 2.44x.
- Same answers? Look for a check that catches cheating, like token forcing. Accuracy alone missed it.
If you run models yourself: measure which part is slow right now, before you tune anything. It changed three times in three rounds.
Source: p1; Tables 1 to 3 (p10, p11, p14); p13; p12.
What should you still hold loosely?
The limits
What this does not show
- Every number is the authors' own measurement, on NVIDIA H100 and RTX PRO 6000 chips.
- It is a 1-day-old preprint with no peer review. I found no replication and no outside coverage.
- "Lossless" is tested, not proved. Even stock differs from plain decoding on 0.72% of words.
ContestedTwo numbers in the paper do not line up. At 16 requests, one figure says 4.16x over plain decoding; its own table divides out to 3.76x (computed). The BF16 batched gain reads 1.71x in the text and 1.77x from the speed-ups beside it (computed).
Source: p10; p6; p20 (Fig A2a); p21 (Table A1); p11. Verified items elsewhere in this deck are as printed in the paper.
Who made it, and where can you read it?
Credit, sources & method
Sources & method
Paper: Kunjun Li, Wenhao Chai, Yihao Liang, Yuezhou Hu, Shuyao Xu, Yi Pan, William X. Zheng, Kannan Ramchandran, Kurt Keutzer and Jiantao Jiao (UC Berkeley, Princeton, Stanford, NVIDIA). SpecPilot, arXiv:2611.02501 (v1, 2 Nov 2026).
Built on: Leviathan, Kalman and Matias, speculative decoding, ICML 2023. Chen et al., speculative sampling, arXiv:2302.01318.
Method: every number is from the paper, with its page. Computed here: 20.0 ms per piece, 11.1%, 8.3x, 30.1 ms, 0.70 ms, the 16 chart step values, 3.76x and 1.77x.
No outside source confirms the figures. More at vizmaya stories.
Photos (Wikimedia Commons): Wikimedia racks ULSFO 2013 06 06 02, Mutante, CC BY-SA 3.0, source; Custom Designed Server Boards, Intel Free Press, CC BY 2.0, source; ThinkPad 360PE IC DRAM, Raymangold22, CC0 1.0, source; Rear of rack at NERSC data center, Derrick Coetzee, CC0 1.0, source; Driving Cars in a Traffic Jam, epSos.de, CC BY 2.0, source.
vizmaya desk · 3 Nov 2026

