Qwen3.6-27B NVFP4 + DFlash: my daily driver (until 3.8)

Before Qwen3.8 landed, Qwen3.6-27B (NVFP4) with DFlash speculative decoding was my favourite local model on the DGX Spark (GB10) — the dense 27B quality I wanted, finally at a speed I could live with. The earlier FP8 build of this same model only managed ~8–16 tok/s; NVFP4 + DFlash changed the picture completely.

The headline: ~6× over the FP8 baseline

Same workload (20 requests, concurrency 2, ~512 in / 128 out), FP8 baseline vs NVFP4 + DFlash:

MetricFP8 baselineNVFP4 + DFlashChange
Output throughput16.74 tok/s104.56 tok/s6.25× faster
Request throughput0.131 req/s0.817 req/s6.24× faster
Mean latency15.29 s2.45 s84% lower
p95 latency15.37 s2.45 s84% lower
TTFT589 ms1,020 ms73% slower

Roughly a 6× jump in throughput and an 84% drop in end-to-end latency. The one regression is TTFT: the speculative draft plus a busier scheduler add ~430 ms before the first token. In interactive chat that’s not noticeable, and total latency still collapses because decode is so much faster.

A second run, taken as the median of three, landed a touch lower but told the same story — 16.04 → 83.04 tok/s, a 5.2× jump, latency p50 down 81%. Across runs the stack sat in a ~83–105 tok/s band, every one of them 5–6× the FP8 baseline.

Measurement notes

A win this size needs a trustworthy yardstick, so the method matters:

  • Report the median of three identical runs, not a single shot. The FP8 baseline alone drifted ~10% run to run (15.16–16.79 tok/s), so any single number lies a little.
  • Treat changes under ~5–10% as noise, not improvement — that’s the run-to-run spread on this box. A 6× jump clears that bar with room to spare; a firmware tweak claiming +8% does not.
  • Save the winning config as the new baseline and only re-benchmark after a deliberate change (firmware, driver, recipe). Otherwise you’re chasing noise.

This was the model that made local dense-27B reasoning genuinely usable for me — right up until Qwen3.8-27B and DFlash2 raised the bar again.