Native CUDA: GLM-5.3-Flash EXL3 with DFlash2 and TP/EP/DCP #509

Native CUDA gap

TensorFold v1.0.2 registers Nemotron in the native CUDA server; glm5_next has a native Metal implementation but no native CUDA entry. The Python GLM recipes are not an engine-only upgrade path for a CUDA EXL3 deployment. This proposal follows #286 and CONTRIBUTING's issue-first gate for a backend/model-arithmetic change.

Proposed qualification scope

• GLM-5.3-Flash glm5_next checkpoint with BF16 dense tensors, FP32 routing/hyper-connection metadata and compressed EXL3 MCG routed experts, retaining raw FP16 scales.
• Two RTX PRO 6000 Blackwell Max-Q GPUs (SM120), TP2, EP2 and DCP2, with real rank-local context-cache ownership and deterministic rank-ordered collective merges.
• Physical fp8_ds_mla cache ABI used by the deployment: 656 bytes/token, E4M3 latent512, four FP32 group scales and zero BF16 RoPE64 tail. Generic DS writer scales are max(amax/448, FLT_MIN), not the compact GLM_NEXT 528-byte layout.
• External BF16 DFlash2 checkpoint, five proposals, configured post-layer target taps, six proposal query rows, BF16 KV and committed-only draft state. No substitution with the in-model MTP head.
• Native vision preprocessing/tower and GLM image-token insertion, preserving image inputs instead of admitting a text-only downgrade.
• Existing native lane scheduler, sampler, cancellation and verification contracts; no Python/PyTorch/vLLM in the inference path.

Gate requested

Before a release claim: host suite; independent projection/expert arithmetic comparisons with worst-column errors; FP8 encode/QK/PV and DCP merge checks; recurrent prefix commit/replay and reset; plain-versus-drafted token equality; concurrent-versus-solo equality; image preprocessing/features; and a fixed 180-second workload of alternating code/prose at 512, 2048 and 8192 prompt tokens, using identical request bodies, launch times and sampling before/after.

The native port is being implemented, not yet device/model qualified. No throughput improvement or cutover is claimed. The current deployment remains running until the qualification and rollback boundary is established.

Is this backend/checkpoint scope the appropriate gate for the current zig-flashnext line, or should its prerequisite native CUDA hardening land separately first?