Most speculative-decoding work has been a race to draft tokens faster. The interesting claim in DSpark, from Peking University and DeepSeek-AI, is that drafting stopped being the bottleneck a while ago — verification did.

Parallel drafters can propose a long block of tokens in a single forward pass, nearly independent of block length. The catch is acceptance decay: because each position is predicted independently, later tokens collide with the target distribution and get rejected. So you generate a long draft cheaply, then burn verification batch capacity on a tail of tokens that were never going to survive. Under high concurrency, that wasted capacity is exactly what tanks throughput.

DSpark attacks both ends. On quality, it goes semi-autoregressive — a parallel backbone plus a lightweight sequential module that reintroduces intra-block dependencies and slows the suffix decay. On efficiency, it uses confidence-scheduled verification: instead of verifying a fixed block, it sizes the verification length per request from the estimated prefix-survival probability and the engine’s current throughput profile. That second input is the part I’d underline — verification length becomes a function of live serving load, not a static tuning constant.

The production numbers are what make this more than a paper. Deployed inside the DeepSeek-V4 serving system under live traffic, DSpark reports 60–85% faster per-user generation versus their MTP-1 baseline at matched throughput, and claims it shifts the Pareto frontier — unlocking latency tiers that strict interactivity constraints previously made impossible. Checkpoints and the DeepSpec training repo are open-sourced. The HN thread is heavy on the acceptance-decay framing.

Here’s my question for anyone running an inference fleet: once verification length is load-aware, doesn’t your speculative-decoding config stop being a model hyperparameter and become part of the autoscaler?