Qwen3.6-Next 35B-A3B on a single DGX Spark: 25.5 → 45.2 tok/s
1× GB10 · bf16 · CUDA graphs + native MTP · temp 0 medians · per the methodology
The most useful benchmark for most Spark owners is not the biggest model — it is what a strong mid-size MoE does on one box, and how far the stock config is from the real ceiling. Answer: a long way. Same silicon, same weights, config changes only:
| config | dialogue | code |
|---|---|---|
| out of the box (eager) | 25.5 | 25.5 |
| + CUDA graph capture | 29.7 | 29.5 |
| + native multi-token prediction (k=2) | 41.2 | 45.2 |
That is +77% on code from configuration alone — no new hardware, no different weights. Draft acceptance ran 80–95% with mean acceptance length 2.6–2.9, which is why k=2 wins here while deeper drafts lose elsewhere: acceptance, not draft depth, sets the ceiling, and it must be measured per model.
The multi-node myth, addressed
This entry is deliberately single-node. For a model this size, adding nodes does nearly nothing for single-stream speed — clustering pays for models too big for one box, and for aggregate throughput. If someone tells you to buy a second Spark to make a 35B model chat faster, they have not measured it.
What the gap means
Most Spark owners are running the 25.5 line and comparing it to reviews. The 45.2 line is the same computer. The difference is knowing which two subsystems to configure and how to verify the win survives restarts — the interaction between speculation and graph capture silently cancels one or the other for many stacks.
Is your single-node config leaving +77% on the table?
A one-day diagnostic measures your exact model on our hardware, finds your recoverable headroom, and hands you the ranked list — or it's free.
Book a 1-day diagnostic →Free to read and share. Numbers are from hardware we've measured directly; your engine versions and configs will differ — measure your own, and count only delivered tokens.