DSpark speculative decoding, disproven
DSpark was projected to hit 572 tok/s on Strix Halo. We measured it end to end on the NPU and the projection did not survive: 0.1 to 0.2 tok/s at 0% draft acceptance. Here is how and why, what it would take to fix, and why these figures are historical and unsourced.
The projection
DSpark was projected to hit 572 tok/s on Strix Halo. The number came out of a model: a draft pass assumed cheaper than the target, an acceptance rate assumed high enough to matter, latency assumed hidden behind the draft. It is the kind of figure that survives a spreadsheet and dies on hardware, and we took it to the NPU to check.
A projected speedup is a hypothesis, not a result. The only way to promote it is to measure it end to end, on the device, through the real engine.
What the NPU measured
End-to-end measurement on the NPU disproved it. On this hardware DSpark measured 0.1 to 0.2 tok/s at 0% draft acceptance. Not a fraction of the projection, three orders of magnitude in the other direction. Every drafted token was rejected, so the model recomputed the distribution it had just computed, and the engine paid the full cost for nothing.
| Metric | Projected | Measured end-to-end |
|---|---|---|
| Throughput | 572 tok/s | 0.1 to 0.2 tok/s |
| Draft acceptance | unstated | 0% |
Why it fell apart
Speculative decoding only pays when the draft is cheaper than the target and right more often than wrong. Here the draft cost the same dispatch round trips as the target and agreed with it 0% of the time, so the engine did the full computation and then threw it away. On an NPU where launch and wait dominates every dispatch, a rejected token pays the round trip twice.
The projection assumed the mechanism, not the silicon. The silicon was not consulted.
What it would take to fix
A working DSpark needs two things measured before anything is published: a draft model that is measurably cheaper end to end than the target, and a live acceptance counter that is printed with every benchmark run. When draft acceptance is a number in the output rather than an assumption in a spreadsheet, the discipline does the rest. Until then, the projection stays a projection.
The record
The DSpark figures here are historical and unsourced. The projected 572 tok/s and the measured 0.1 to 0.2 tok/s at 0% draft acceptance were recorded before we had a reproducible harness, and both are quarantined in benchmarks/latest.json _unverified. They are kept because they are the honest record of a projection meeting hardware, not because they are trustworthy evidence.
The point of posting a disproven number is the same as posting a real one: the record matters more than the win. A claim that was tested and failed is worth more than a claim that was never tested at all.