Qwen3.8-Flash-Next EXL3: Native CoopMK trellis MoE, device QSA, and 262K recipes (M5)

[vcruz305]

Summary

Milestone M5 of #65: Atlas now serves all 512 routed experts + shared expert of Qwen3.8-Flash-Next (turboderp/Qwen3.8-Flash-Next-exl3, 4.05 bpw) as native packed EXL3 trellis on GB10 (sm_121), eliminating the interim transient-BF16 / NVFP4 expert requantization path.

In addition to native CoopMK MoE decode, this PR includes:

• Device-resident QSA selection (ATLAS_QSA_DEVICE=1) for the Qwen3.8-Flash-Next indexer.
• M-row EXL3 dense GEMV and batched verify kernels for speculative decoding.
• Full 262K Context Deployment Recipes in docs/recipes/exl3-qwen4exp-gb10.md covering single-GPU build flags and 262,144 context configurations with memory analysis.

Refs #65 (Delivers M5).

What is in here

Component	What
M5: Native Trellis MoE	crates/spark-model/src/layers/moe/forward_exl3.rs, forward_exl3_grouped.rs, exl3_coopmk.rs: Retains experts packed in memory without runtime NVFP4 requantization; binds CoopMK runtime-K cooperative decode kernels (exl3_coopmk.cu, exl3_vendor/coopmk/).
Device QSA Selection	crates/spark-model/src/layers/qsa_dev.rs, crates/spark-model/src/layers/ops/qsa_dev.rs: Capturable device selection arm for the attention indexer.
M-row Dense GEMV	crates/spark-model/src/layers/ops/exl3_dense.rs, exl3_gemv.cu: Native multi-row GEMV for verify rows across K=2..8 verify windows.
262K Recipes	docs/recipes/exl3-qwen4exp-gb10.md: Single-GPU --features cuda build instructions and full 262,144 context serving configurations.

Verification & Measurements (DGX Spark GB10)

• Unit Tests: cargo test -p spark-model --lib (918 passed, 0 failed), cargo test -p spark-server --lib (104 passed, 0 failed).
• Format: cargo fmt --all -- --check clean.
• Compilation: Clean release binary build via cargo build --release -p spark-server --bin spark --no-default-features --features cuda.
• Preflight Kernel Audit: atlas_kernel_check PASSED for (qwen3.8-flash-next, sm_121, exl3) (390 lookups, 0 unresolved, ok: true).
• Live Serve Test: Successfully loaded flashnext-exl3-4.05bpw (297,909 tensors, 48 layers, 512 packed experts) and verified live generation via /v1/chat/completions with full reasoning trace.

CLA

• I have read and agree to the Contributor License Agreement.

[github-actions]

All contributors have signed the CLA. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[vcruz305]

I have read the CLA Document and I hereby sign the CLA

[vcruz305]

recheck

[AzeezIsh]

Thanks for M5. Before this goes further, one cross-platform blocker and one measured data point, both from the AMD side.

Blocker: Flash-Next MTP verify breaks on AMD (strix-hip, Linux and Windows).

• ops/hyper_connection_lowrank_split.rs::hc_pre_split now launches hc_pre_down_mt / hc_pre_finish_x4_mt by default (ATLAS_HC_MT defaults on) whenever T is 2..=8, hc = 4 and rank ≤ 512. That's every Flash-Next MTP verify step (T=2).
• Both kernels are added only to kernels/gb10/qwen3.8-flash-next/nvfp4/hyper_connection.cu. The strix-hip target has its own kernels/strix-hip/qwen3.8-flash-next/nvfp4/hyper_connection.cu, a real file rather than a symlink, and it doesn't define them.
• So the gpu.kernel("hyper_connection", "hc_pre_down_mt")? lookup errors on the first verify step on gfx1151. That's the strix (gfx1151): DP4A batch8 GEMVs for DFlash2 γ8 verify rows 5..8 (+8.5 % decode, output identical) + FP8 batch8 tier #101 / spark-model: DFlash2 step cuts — async batched propose + opt-in GDN deferred commit (#58) #127 bug class: a lookup for a kernel that exists under only one of kernels/gb10 / kernels/strix-hip.
• Please gate the arm to NVIDIA, e.g. !cfg!(atlas_hip) && hc_mt(), or use try_kernel_gated and fall back to the existing three-launch path when the handle is 0.

Measured data point: the same two kernels are slower on gfx1151. These match the token-fused kernels Claude benchmarked in closed #154 (strix job 146, gfx1151, ROCm 7.13). They were bit-identical, but 0.69× at T=2:

case	production	fused
down	129.5 µs	213.6 µs
finish	38.9 µs	57.3 µs

The reason: one warp per rank row re-reads normed from L2 for every row and token, and fusing tokens halves the finish grid. So even ported to HIP, they shouldn't be the default there unless measured otherwise. Their GB10 speed is a separate question; that needs its own A/B number.

Two smaller notes:

• The new gpu.kernel(...) lookups sit inside per-launch functions (hc_pre_split, qsa_decode_select). Other call sites resolve handles once at init.
• There are three new ATLAS_* switches (ATLAS_HC_DECODE_FAST, ATLAS_HC_MT, ATLAS_HC_DOWN_WARPS). Per the repo rules ([job] Repo diet: env-var registry + prune 497 ATLAS_* vars, large files, merged branches #117/ci: ratchet the number of distinct ATLAS_* env names (#117) #118 ratchet; "no correctness or performance improvements as optional flags"), wins should become defaults with their switch removed. Neutral arms shouldn't land.

GB10 gate for the EXL3 path: we can queue it on reiner once that box is reachable again; it went offline today. On our side it needs EXL3 boot + byte-identity on the NVFP4 Flash-Next probes (the NVFP4 path is touched in qsa, ple, verify_*, trait_decode_batched) and the 27B boots. The AMD side needs a strix-hip build plus a Windows Flash-Next boot with MTP.

[AzeezIsh]

Verification pass on GB10 (SM121) — this works end to end on real hardware:

What verified

• builds ATLAS_TARGET_QUANT=exl3, serves turboderp/Qwen3.8-Flash-Next-exl3@3.05bpw_h5_ng5 at full 262K
• Recipe A prefill: 13.4s / 39.9s / 198.3s wall at 1k / 4k / 16k prompts (~85-90 tok/s effective)
• Recipe C (--speculative --num-drafts 1 + coop envs): 35.7 tok/s decode
• the prefix caching changes temperature-0 answers on Flash-Next; one tool round-trip goes wrong (warm replay from a Marconi anchor) #158 round-trip (Ottawa anchor → Tokyo follow-up) answers correctly on the real EXL3 ckpt

Accuracy — correction on the earlier 43.92%
That number was not real: my job's host-mem watchdog killed the serve at ~sample 650/995, so every remaining category scored 0.00 by starvation (simple_java/js/python run last → all zeroed). Clean re-run on the same ckpt/config:

subset	accuracy
non_live	75.44 (simple_python 93.15, javascript 70.97, java 66.13, multiple 91.94, parallel 69.35, parallel_multiple 63.71)
live	81.76 (simple 100, multiple 85.71)
hallucination	63.83
overall	78.29 / normalized 73.68 (n=995)

For reference the NVFP4 ckpt legs land ~81.6 and the bf16/unsloth ~84 — so EXL3 trails ~3-6pts. Worth a look whether that's expected quant loss or something the trellis/CoopMK path can reclaim — parallel_multiple and the java/js legs are where it dips.

Prefill is the bigger gap
16k at ~90 tok/s vs ~500 tok/s on the NVFP4 path on the same box — the CoopMK/trellis MoE prefill is the dominant cost. If the grouped-prefill envs (ATLAS_EXL3_PREFILL_GROUPED, COOPMK_ROWS) aren't hitting for prefill shapes that's the first place I'd look.

Merge state
Needed one small fix against main: helpers_a.rs — main's transpose now returns Result<Vec<DevicePtr>>; kept the EXL3 early-skip and returned Ok(freed). Pushed to the branch already, CLA green.

cc @vcruz305 — happy to put my agents on the prefill profile if you want eyes on it