[AzeezIsh]

Stacked on #153. Until #153 merges, the diff includes it; afterwards, only the last commit (25cd5b55d) remains.

What

#153 gated the one-pass BF16 batch2 LM head to HIP, on the premise that the NVIDIA dense_gemv_bf16_batch2 reorders the sum. That premise was wrong. In kernels/gb10/common/ (and kernels/strix/common/), dense_gemv_bf16 also walks 64 lanes per row (BLOCK_SIZE 256 / N_PER_BLOCK 4; the // 32 comment on that line is stale), with the same warp shuffle + smem pair-sum as its batch2 sibling. A structural diff shows batch2 only adds a second accumulator. So the pair is bit-identical on NVIDIA too, and this commit drops the HIP gate.

Why

Qwen3.8-Flash-Next ships a BF16 [248320, 2560] LM head, and its MTP K=2 verify reads it twice per step on GB10 just as it did on gfx1151. On winbox, #153 measured ~+6% decode, byte-identical.

Checks

• cargo test -p spark-model --lib: 914/914 pass. clippy and fmt are clean.
• GB10 reiner job 663 (queued): main vs main + this, Flash-Next with MTP on, 5 prompts, alternating ×2. Pass = byte-identical replies. It also reports decode tok/s. MTP verify is active only below the QSA bound on GB10, so the gain shows at the short / 2k prompts.

🤖 Generated with Claude Code

[AzeezIsh]

GB10 result (reiner job 664): PASS. M = main 4405bce35 vs C = main + 25cd5b55d. Flash-Next NVFP4 with MTP on (--speculative), util 0.90 / seq 8192, alternating M1 C1 M2 C2.

Why util 0.90 / seq 8192: with MTP pools Flash-Next does not fit at 0.88 (job 663: KV exhausted / no KV at boot), and MTP verify only runs below the 2,051-token QSA bound anyway.

prompt	M tok/s (r1 / r2)	C tok/s (r1 / r2)	Δ	wall M → C
code (37 → 256)	26.5 / 26.6	28.5 / 28.3	+6.8%	9.86 → 9.24 s
prose (31 → 200)	24.4 / 24.3	26.0 / 26.0	+6.8%	8.41 → 7.88 s
json (36 → 200)	27.0 / 27.0	28.9 / 28.9	+7.0%	7.62 → 7.13 s
1k (1,070 → 128)	22.8 / 22.6	24.3 / 24.3	+7.0%	6.41 → 6.04 s
2k (2,088 → 128)	20.5 / 20.5	21.6 / 21.7	+5.6%	7.57 → 7.25 s

• Byte-identical: 5/5 prompts in both rounds (M1 = M2 = C1 = C2), 0 faults. Acceptance (tok_step) is unchanged, as expected for a bit-identical change.
• Same size as lm_head: one-pass BF16 batch2 LM head for K=2 verify on HIP (Flash-Next, −5.9 ms/verify step) #153 on gfx1151 (~+6%): one fewer 1.27 GB LM-head read per verify step.

Ready for review after #153 merges (this is stacked on it). Its own diff is 25cd5b55d only: drop the HIP-only gate, plus comments.

[AzeezIsh]

Status (2026-10-06): GB10 gate passed; waiting only on #153 (stacked).

• GB10 (reiner 664): Flash-Next NVFP4 with MTP, byte-identical 5/5 prompts × 2 rounds, decode +5.6–7.0%, 0 faults.
• Why it can't merge first: the diff includes lm_head: one-pass BF16 batch2 LM head for K=2 verify on HIP (Flash-Next, −5.9 ms/verify step) #153 until lm_head: one-pass BF16 batch2 LM head for K=2 verify on HIP (Flash-Next, −5.9 ms/verify step) #153 lands. lm_head: one-pass BF16 batch2 LM head for K=2 verify on HIP (Flash-Next, −5.9 ms/verify step) #153's last gate is the HIP train ST-995 (see qsa: O(complete) radix-select top-k on the device by default (Flash-Next decode past the 2051-token bound) #152 / lm_head: one-pass BF16 batch2 LM head for K=2 verify on HIP (Flash-Next, −5.9 ms/verify step) #153).

To unblock: merge #153, rebase so only 25cd5b55d remains, rerun CI, merge. Nothing to re-gate: the GB10 result is on main + this commit, and HIP behaviour is #153's.

Owner: Claude.

[AzeezIsh]

Included in GB10 integration train #305 on main 8c2b672: merged unchanged. The sparky gate (job 68b) builds #305's exact head and runs tests, three model controls, agentic-50, BFCL ST-995 and error counts. The results will be posted on #305 and here.

[AzeezIsh]

Merged after the GB10 gate in train #305 (sparky; this PR's head 25cd5b5 merged unchanged on main 8c2b672, compared against an A0 binary of main at that same base).

Byte-identical controls (control.py: 4 requests, temp 0), train vs main:

• Flash-Next FP4-Local and Flash-Next NVFP4, r1short profile;
• Qwen3.8-27B NVFP4 at --speculative --num-drafts 1, so every verify is K=2, the path this PR switches to the batch2 BF16 LM head on NVIDIA.

Benchmarks, FP4-Local, train vs main:

	train	main
BFCL ST-995	87.54 / 85.94 (run-1793547282491478714)	87.54 / 85.94 (run-1793521232941271578)
agentic-webserver 50	47/50, 10.66 s/turn	47/50 at 170c3ed

• BFCL: all 15 subsets identical.
• Agentic: the same failing iterations 0/18/27 as main. That's main's 565aa68 behaviour, tracked on serving: MODEL.toml [behavior] keys to serve like the reference server; qwen3.8-flash-next adopts them #271.
• 0 errors/panics.

Earlier standalone gate (job 59, on this PR's merge ref): control identical, BFCL 87.54 / 85.94, agentic 47/50.

No speed claim: I didn't run a K=2 lm_head microbench on GB10.