[MiaAI-Lab]

Refs #2093.

GLM's CUDA family admits only 4-bit EXL3 mcg routed experts; anything else is error.NotExl3Mcg4. This takes each tensor's half-bit width from its trellis shape (whole bits 1..8, mixed per projection inside one layer), templates the decode and prompt expert kernels on it, and keeps the 4-bit path exactly today's: the upstream 4-bit loader runs verbatim in a test and must upload equal bytes; the 4-bit entry points keep their SASS at nvcc 13.3.

Four commits, one concern each:

1. glm cuda: EXL3 mcg experts at any whole-bit width, mixed by projection - admission keeps the codebook check and verifies each width's range; the loader reads widths from the trellises and holds them per projection; scratch stays width-independent.
2. tests: GLM EXL3 at mixed widths, synthetic and a checkpoint's own layers - synthetic mixed-width rigs and glm-exl3-layer, one real checkpoint layer's experts against float64 unpacks.
3. exl3 cuda: the common prompt kernels take 3-bit mcg gate/up and down, by projection group - tf_exl3_prompt_gu_k6 / tf_exl3_prompt_down_k6; contract records with 13.0 receipts pending and 13.3's measured usage.
4. tests: exl3-prompt-k6, the 3- and 4-bit prompt kernels at GLM's shapes - the k6 pair against the 4-bit pair's references, edges and shapes.

Gates so far (host, no GPU claims): zig build install green with -Dnvcc -Dsm=80,86,89,120,121 (nvcc 13.3.1, Zig 0.17.0 per .zig-version); test-cuda-host 4705/4708 with 2 fails in drama_voice_tool.zig, untouched by this branch (pre-exist on main's tree here); tools/zig/lean_check.py zero findings over main's baseline count; zig fmt clean. Kernel-contract and per-SM launch receipts on sm_120 hardware post below when the run completes; the 3-bit launches' 13.0 resources stay pending records per the registry's convention, 13.3 measured.

Metal, XPU, other codebooks and other families: untouched.

[garvrao80]

The #2031 native Linux sweep on main 7eae7dc00 found that test-exl3-prompt-host stops at the glm.experts.Kernels initializer: missing struct field: b32 (zig/exl3_prompt_host.zig:59). Current main's Kernels now includes the block-32 expert table.

Since this PR updates the same fixture, could you account for that field when bringing it onto current main? Draft CI-coverage PR #2095 keeps this check included and records the compile failure as a prerequisite. Its paired explicit-step/aggregate runs reproduce the same failure. I've kept the EXL3 fixture repair with this work rather than adding a competing patch.

[ashhart]

Thanks @MiaAI-Lab, the host side reads well: widths come from the trellis shape, admission still refuses by name, and the real-layer float64 check has its own planted control. To land it on the terms we set on #2093, a few things are still owed:

1. The sm_120 device evidence you mentioned: the CUDA contract SUMMARY with the two _k6 kernels registered, a planted control for them shown red, and their bounds at the served shapes.
2. The 4-bit SASS byte for byte at nvcc 13.0 as well as 13.3, since the release fatbins build with 13.0, and the _k6 launches' 13.0 receipts.
3. A served run of the width-mixed checkpoint at a pinned revision: drafted equal to plain, concurrent equal to alone.
4. As @garvrao80 noted, exl3_prompt_host.zig's glm.experts.Kernels needs main's new b32 field, or the step doesn't compile.
5. A CHANGELOG line.

On our side, we'll check on our GB10s that the pinned 4-bit checkpoint's replies equal main's, with decode level.

[Bizuayeu]

@MiaAI-Lab, a small one beside this PR's admission, in a file it doesn't touch. On main 116a0d4ca, glm/config.zig's parse reads quantization_config from the top level only (zig/src/families/glm/config.zig:168), while cuda_exl3.zig's block(), behind isExl3 and admit at the entry (cuda_engine.zig:113), also takes one inside text_config. So a config that nests it there passes admit but parses with c.exl3 false, and the loader then expects NVFP4 weights (cuda_weights.zig:338). Your checkpoint keeps it at the top level, as do the other GLM EXL3 packs I know of, so nothing breaks today; this is from reading the code, not from a run.

The fix is parse looking in the same two places, in block()'s order (top level first), and a parse test for the nested form. Would you like to fold it into this PR, or shall I send it on its own? It would touch only config.zig and its test, so it wouldn't overlap with this one.

[ashhart]

Thanks @Bizuayeu, that's right on today's main: config.zig's parse reads quantization_config at the top level
only, while cuda_exl3.zig's block() also takes text_config's, so a nested pack is admitted as EXL3 and then
asked for NVFP4 dense weights at load. Please send it on its own: parse looking in block()'s two places, top
level first, with a parse test for the nested form and a CHANGELOG line. It doesn't overlap this PR, and it
shouldn't wait on it.
@MiaAI-Lab, the five things from 4 Nov are still open on this head: the sm_120 contract SUMMARY with the _k6
kernels and a planted control, the 4-bit SASS and the _k6 receipts at nvcc 13.0, a served run of the width-mixed
checkpoint at a pinned revision (drafted equal to plain, concurrent equal to alone), main's b32 field in
exl3_prompt_host.zig, and a CHANGELOG line. The branch also needs a rebase: tests/cuda/glm_exl3_tests.zig and
tests/cuda/main.zig conflict with today's main. Are you still working on it?

[jishnuvenugopal]

Thanks @MiaAI-Lab for the width-mixed work, and @ashhart for keeping the list of what's open here. I said on #2031 that I'd coordinate the b32 item with you, so here is that one item measured, in case it saves you a step.

Verified outcome

• Why: with this pull request merged onto main, the EXL3 prompt check still does not compile, so ci: collect native Linux host checks and guard exclusions #2095 can't drop it from its exclusion list.
• What was done: I merged this head onto main locally and tested the one-line change that @ashhart's list asks for.
• Result: that one line is all this check needs: it passes all 8 tests.

Receipt

Head 7dcf80101 merged onto main 3e37f94a9, Apple M1 Pro, macOS 26.6, Zig 0.17.0, no Xcode.

zig build test-exl3-prompt-host -Dcpu=apple_m1	Result
merged, as is	zig/exl3_prompt_host.zig:59:38: error: missing struct field: b32
with .b32 = undefined after .nvfp4 = undefined on line 59	4/4 steps, 8/8 tests passed

The change belongs in this pull request, since it already edits that file, so I won't open a separate one on it. If you'd rather I took it, say so here.

Not run: the rest of this pull request's checks, including Linux, Windows, GPU and checkpoint runs. This covers only that host check, and nothing else on @ashhart's list.

[ashhart]

Thanks @MiaAI-Lab, and @jishnuvenugopal for measuring the b32 item: .b32 = undefined beside .nvfp4 in
exl3_prompt_host.zig is what item 4 needs, and it belongs here, so please fold it into the rebase. The other items
from 4 Nov still stand (the sm_120 SUMMARY with the _k6 controls, the nvcc 13.0 SASS and receipts, the served
width-mixed run, and a CHANGELOG line). @MiaAI-Lab, are you still working on it?