[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.