Repository navigation
v0.6.7 — Qwen3.6 answers concurrent requests correctly
Qwen3.6 answers concurrent requests correctly, and 3.5-4x faster.
Since at least 0.5.14, any 2 or more concurrent Qwen3.6-35B-A3B requests decoded to repeated garbage tokens, for example "The capital petró fác dó fác fác …". Past 8 concurrent requests the output was correct only because the batched step was declined: requests decoded one forward each, 16 or 32 of them slower in total than a single stream. If you serve Qwen3.6 with concurrent requests, upgrade. Qwen3.8, Bonsai-2 and Muse Glimmer were not affected.
Measured
RTX 5090, qwen3_gguf_cb_bench 256/256, Qwen3.6-35B-A3B UD-Q4_K_M:
| concurrent requests | 0.6.6 | 0.6.7 |
|---|---|---|
| 4 | garbage | 1,055 tok/s |
| 16 | 457 tok/s (one forward each) | 1,621 tok/s |
| 32 | 461 tok/s (one forward each) | 1,834 tok/s |
What changed
-
Qwen3.6's packed decode step (#1262). Three faults:
- the full-attention output gate was dropped;
- the shared expert was not computed past 8 rows;
- the bf16 row GEMVs (the MoE router among them) refused more than 8 rows.
The new
packed_decode_checkcompares packed steps with one forward per row, teacher-forced: 99-100% argmax agreement at 1-32 rows, the same as a second one-forward-per-row run (0% before). -
Bonsai-2's mixed prefill + decode steps run its FP4 FFN (#1261). A 1,024-row step takes ~86 ms instead of ~150. Continuous-batching bench at c16 / c32: 1,437 / 1,870 → 1,550 / 2,074 tok/s.
-
SPARKINFER_MIXED_ROW_TOKENS(#1261): opt-in handling of request bursts for mixed steps. The CHANGELOG has the trade-off.
Full notes: CHANGELOG.md.
Container: ghcr.io/gittensor-ai-lab/sparkinfer-qwen38:0.6.7 (attested).
What's Changed
- perf(runtime): Bonsai-2's mixed steps run its FP4 FFN (cb c32 1,870 -> 2,074 tok/s); mixing a burst becomes opt-in by @skyrocket2026 in #1261
- fix(runtime): Qwen3.6 packed decode applies the attention gate and serves 9+ rows (garbage at 2+ concurrent requests; c32 461 -> 1,834 tok/s) by @skyrocket2026 in #1262
- docs: 0.6.7 — Qwen3.6 answers concurrent requests correctly (c32 461 -> 1,834 tok/s) by @skyrocket2026 in #1263
Full Changelog: v0.6.6...v0.6.7