Rows of server racks with cabling in a data center

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

Server circuit boards
Photo: Custom Designed Server Boards / Intel Free Press, Wikimedia Commons, CC BY 2.0. Source

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.

Memory chips on a circuit board
Old laptop memory chips, same idea. Photo: Raymangold22, Wikimedia Commons, CC0 1.0. Source

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.

STOCK: ONE CHAIN unused runner-ups sit idle SPECPILOT: A TREE

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.

Close-up of the back of a server rack with cables
Back of a server rack, NERSC data center. Photo: Derrick Coetzee, Wikimedia Commons, CC0 1.0. Source
0 MeasureFind the biggest gap to the ceiling
1 ExploreOne idea per GPU, in parallel
2 StackSmall wins add up
3 TuneFix the slowest kernels
4 CheckToken forcing vs stock

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)

drafts 2 x 1.05glue 1.6ms

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.

Cars stuck in a traffic jam
An analogy: every car adds its own load. Photo: epSos.de, Wikimedia Commons, CC BY 2.0. Source

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?