A draft model earns its keep out of slack. Token-by-token decoding is memory-bandwidth bound, so arithmetic units idle while weights stream, and speculative methods such as Medusa and the EAGLE series spend that idle window verifying several predicted tokens at close to the cost of one step [7]. That is the entire trick. It also tells you why batch size belongs in a scaling law at all: batching is the other consumer of the same slack. Group enough sequences into one decode step and the verifier's spare capacity is already sold to other users' tokens. Most published work sits at batch 1, while industrial serving decouples prefill from decode and runs much larger batches [8].
The two supply-side laws are the ones you can budget against. Prior LLM scaling work related cross-entropy loss to model size, dataset size and FLOPs by power law [9]; here the dependent variable is draft acceptance rate and the reported shape is log-linear in pretraining tokens and in draft capacity [1]. Take that form literally. If acceptance is a*log2(T) + b, then doubling the draft's pretraining tokens adds a, and doubling again adds another a [1]. The first few doublings are cheap and the tenth costs the same in acceptance as the second while costing 256 times the data. A log-linear law is a promise about where you stop, not just about where you gain.
Now the arithmetic on the headline figures. Read the acceptance range against EAGLE2 and the engine-level throughput number as multipliers, and the throughput figure lands above the midpoint of the acceptance range, 1.85 [2]. That is roughly what the mechanism predicts, since throughput also has to pay for draft forward passes and tree overhead, and the two measurements were not taken under the same conditions anyway.
For the throughput number to transfer, several things have to hold in your stack. The backbone has to be dense, since the study is conducted on dense architectures and the systems are built on Llama2/3 and Qwen2.5 [10][2]. Your traffic has to resemble the workloads where the paper puts its peak gains, summarization and QA, which by definition bounds everything else lower [5]. Your baseline has to be EAGLE2, because against EAGLE3 the reported acceptance margin is 0.3 [3]. And your serving engine has to run the batch regime the third law was fit in [8]. An arxiv HTML render that eats the multiplication signs and thresholds is a poor advertisement for a paper about numbers, so treat the exact figures as provisional until the PDF or the code says otherwise.
The framing deserves credit. Draft-model research has mostly gone at architecture and sampling strategy and left the pretraining and SFT scaling question alone [12], and fitting curves on tokens, capacity and batch turns draft sizing into interpolation instead of a sweep you rerun every time the backbone changes. The paper also reports Scylla using only the 8x SFT data augmentation from EAGLE, which reads as a claim that the gains came from scale rather than data tricks, though that sentence is truncated in the HTML we read [13]. Code is promised later [11]. The number I would want before committing a draft-model budget is the acceptance curve refit on my own backbone at my own batch size, and that needs the release.
