cuda: fmt=6 (E8/IQ3) decode kernels, so E8 containers can reach VRAM (#452)

[ZacharyZcR]

qt_cuda_upload refused fmt=6 outright (colibri.c:300, "no CUDA kernel yet"), so every E8 tensor stayed on the CPU. That inverts the format's purpose: E8 buys −25% expert bytes to fit more experts in VRAM, but as shipped it pushed all of them onto the CPU tier — which is exactly the ~57 ms/token wall the #431 A/B identified as the real bound at hit ≈100%.

This is the "CUDA sibling kernels" step of the #452 ladder, riding the GroupDesc pipeline #451 opened.

Decode

A super-block is 98 bytes per 256 weights: 64 codebook indices, 8 words of (4×7 sign bits + a 4-bit sub-scale), one fp16 super-scale. Decode is inherently per 32-weight sub-block, so threads stride over sub-blocks rather than elements — expanding once per 32 weights instead of redoing the word/parity work for every element.

Two things that would silently produce wrong numbers if done the obvious way:

• Nothing inside a 98-byte block is aligned. Block b starts at base + b*98, so the 4-byte sign/scale word and the 2-byte fp16 land on arbitrary offsets. Both are assembled byte-wise; dereferencing a uint32_t* there is UB and misreads on the wrong stride.
• fp16 conversion mirrors e8_fp16_to_f32 rather than calling __half2float, so the CPU and GPU decoders cannot drift on subnormals.

The rotation split

fmt=6 stores W@Q, so activations need Q^T. Where that happens matters a lot:

	who rotates	cost on GLM dims
gate/up input	the caller, once per layer (all routed experts share the row)	~1.4 ms
down input	the device, per expert (it is the silu product — not shareable)	—

Doing the gate/up rotation per expert instead would cost ~11 ms against ~1.4 ms (the placement rule in quant.h's comment). So the GPU path mirrors the CPU split at moe() exactly: the caller hands over pre-rotated activations, and coli_cuda_expert_mlp rotates only the silu product before the down matmul.

e8_rot_rows_kernel stages each power-of-two block in shared memory (capping n at 4096 floats, which covers 6144 → 2048+4096 and 1536 → 512+1024) and regenerates the sign stream in-kernel from the same xorshift64* seeded 417+n that e8_signs uses — so no rotation data is stored, uploaded, or able to drift.

What moe() was missing

moe() fed x straight into the GPU at three packing sites — the overlap issue path, the sync group path, and the group-failure fallback — all of which continue past the rotation that the per-expert CPU path does. All three now go through one E8_XE helper that materialises the rotated copy at most once per call. The fallback's CPU recompute was also missing the down-input rotation its sibling path does two hundred lines up.

Two symmetry fixes

Both were unreachable before, because fmt=6 could never be uploaded:

• coli_cuda_tensor_free charged for a scale buffer fmt=6 never allocates. The over-subtraction tripped the >= guard, so the branch was skipped entirely and the tensor's bytes stayed on the device counter forever — this is what the new leak assertion caught.
• coli_cuda_tensor_update would cudaMemcpy O floats out of a NULL scales pointer on a repin (the scale_count ? : O fallback defeats a zero count).

Portability

cudaMemcpyToSymbol had no HIP mapping — added, or the HIP build breaks. The Windows loader resolves the new entry point optionally: an older coli_cuda.dll leaves fmt=6 on the CPU rather than taking the entire GPU backend down over one missing symbol.

Tests

test_backend_cuda.cu gains fmt=6 coverage for both the matmul and the full expert MLP including the device-side rotation, checked against a decoder + FWHT written from the format description and deliberately not shared with quant.h, so a common-mode error cannot hide in both. It uploads a synthetic codebook, which keeps the test self-contained while still exercising the upload path the real table travels. Placed after the existing exact tensor-count assertions, with its own leak check.

Also verified in isolation first, before wiring anything: the decode kernel against a double-precision decode of the same container, since CPU sequential accumulation and GPU tree reduction are both float32 and neither is the oracle. Across 8 shapes the GPU is never materially worse and on long rows is better (I=6144, S=4: 2.97e-06 vs CPU 1.14e-05) — tree reduction's O(log n) error against sequential's O(n). The FWHT matches to 1.68e-07, exact at dim=4096.

make check 211 passed. make cuda-test green on 1 and 2 devices (RTX 5090, sm_120, CUDA 13.3).

What is NOT verified

No end-to-end run against a real fmt=6 container. There isn't one to run: the GLM fmt=6 quality gate is still blocked on a genuine fp16 source (#452), and glm_tiny can't be converted since E8 needs I % 256 == 0. So this is verified at the kernel and API level — decode semantics, the rotation split, upload/free/update accounting — but not yet on a converted model. A GLM or OLMoE e8 container would be the last mile, and I'd rather land the kernels reviewed than sit on them until one exists.