zai-org/GLM-5.3-Flash declares Glm5NextForConditionalGeneration / model_type: glm5_next, a natively multimodal 321.32B-total / ~18B-active hybrid that no oracle implements at a pinned revision and that no device on this fleet can hold. This row scopes the port and states both boundaries up front.
The oracle verdict, read live 2026-08-26
- vLLM at our parity pin
555967922: implements NOTHING. git grep "Glm5\|glm5_next" returns zero hits; vllm/model_executor/models/registry.py:113-117,409-413,640-642 carries nine GLM entries and no Glm5*.
- vLLM
main (c71f6f8a81, 2026-08-26 08:42 -0700): implements NOTHING EITHER. Zero hits; vllm/models/ holds common, deepseek_v32, deepseek_v4, dots3_note, inkling, kimi_k3, minimax_m3 and no glm5next. This is absence, not pin staleness — advancing the pin does not reach it, and that advance would cost reconciling 348 commits for nothing.
- vllm#53906 "[Model] add GLM-5.3-Flash support" opened 2026-08-26T14:12:00Z is OPEN, unmerged,
mergeable: false (head 933876c388fb, 85 files, +12,511/-540). An unmerged PR is not a revision and is inadmissible as an oracle — the same rule this repo already applied to SGLang #36497 on MODEL-MM-QWEN4-EXP. It is cited only as evidence of upstream shape.
- SGLang: NOTHING. Code search 0; PR #36507 open. The cookbook PRs #36440/#36513 did merge — documentation landed ahead of the code, so the model card links a recipe SGLang
main cannot run.
- llama.cpp: NOTHING. Code search 0; PR #27752 open; our oracle is pinned at
b10451. Consequence: convert_hf_to_gguf.py cannot emit this architecture and llama-quantize cannot quantize it.
- vLLM-Omni: NOTHING.
- transformers is the only admissible reference. Implementing commit
eb4d9e2a64 (2026-08-26T14:26:40Z, transformers#48342). First release carrying it is v5.16.1, bounded rather than assumed: modeling_glm5_next.py is HTTP 200 at v5.16.1, 404 at v5.16.0, 404 at v5.15.1. Our transformers pin is 5.14.1, so this row needs a lane-scoped second pin, expiring when vLLM registers glm5_next. Note the MODEL-MM-QWEN4-EXP lane pins 5.16.0 and this one pins 5.16.1 — one day apart, because Qwen4Exp merged before the 5.16.0 cut and Glm5Next after it. Two lanes, two releases; that is what a lane pin is for.
What the model is
45 layers, hidden 4096, vocab 154880, 1,048,576 context. Hybrid attention: 34 KDA linear-attention layers + 11 DeepSeek-Sparse-Attention MLA layers (at 3, 7, 11, ... 43). MLA is fully NoPE — qk_rope_head_dim: 0, mla_use_nope: true, qk_nope_head_dim: 256, v_head_dim: 256, kv_lora_rank: 512, q_lora_rank: 1536 — and text_config carries no rope_theta and no rope_scaling at all. The language model has no rotary embedding on its main attention path; position comes from the KDA recurrence. DSA indexer: index_head_dim 128, index_n_heads 32, index_topk 2048, plus a new k-pool compression (index_kpool: 4, index_kpool_compress, index_kpool_always_select_tail). mHC: mhc: true, hc_mult: 4, hc_sinkhorn_iters: 20. MoE: 288 routed + 1 shared, top-8, moe_intermediate_size 2048, sigmoid / noaux_tc, n_group=topk_group=1, routed_scaling_factor 2.5, clamped SwiGLU at swiglu_limit 10.0. Vision: 24-layer ViT, hidden 1024, patch 14, spatial merge 2, temporal patch 2, out 4096. num_nextn_predict_layers: 1 (MTP).
Why this is not the blocked GLM-5 row
MODEL-TEXT-deepseek-v2-glm-moe-dsa-for-causal-lm (GlmMoeDsaForCausalLM) is already labelled "GLM-5" and is BLOCKED under CLAIM-GLM-DSA-LATEST-DEEPSEEK. That is DeepSeek-V3.2 verbatim (deepseek_v2.py:1917-1918), 753.9B. glm5_next is a different model_type, different parameter count, different attention topology, and has a vision tower. New row, not a revival.
Most of it is already here — and the two obvious reuses are wrong in one place each
mHC, the DSA lightning indexer and KDA all exist in this tree. Two carry a delta a token gate cannot see:
- The KDA forget gate takes the OTHER branch.
Glm5NextTextForgetGate.forward branches on safe_gate_lower_bound; the checkpoint sets gate_lower_bound: -5.0, so it computes -5.0 * sigmoid(exp(A_log) * (f_b(f_a(x)) + dt_bias)). Our kimi_kda.cpp:60 implements the other branch, -exp(A_log) * softplus(g + dt_bias). Different functions of the same inputs; both fluent; the sign of decay_rate differs too.
- The mHC head collapse is an unweighted mean.
Glm5NextTextHyperHead.forward is hidden_streams.mean(dim=2), and its own docstring says "Unlike DeepSeek-V4". Our HcHeadCollapse (deepseek_v4_mhc.cpp:168) is the V4 weighted-gated collapse. Reusing it yields a working model with a wrong final projection.
Third trap: the k-pool indexer is unobservable at or below 2048 tokens — with index_topk: 2048 a shorter context selects every candidate, so the selection is the identity and any short-prompt gate passes over a broken indexer. Same shape as the trap recorded on MODEL-MM-QWEN4-EXP.
Structural blocker: MlaBlockDims::Validate refuses qk_rope_head_dim == 0 (mla_attention.cpp:90-93 requires every dim > 0, :95-99 requires it even). Kimi-Linear is not the same case: it sets mla_use_nope while keeping qk_rope_head_dim: 64, so the rope slice still exists in the cache row.
Nothing fits, and no GGUF exists
Read live from the HF API, and for the primary repo by HTTP RANGE over all 62 safetensors headers (no payload fetched). Against ~119.63 GiB usable on dgx:gpu0:
| repo |
GiB |
vs GB10 |
zai-org/GLM-5.3-Flash (FP8 e4m3, block 128x128) |
305.78 |
2.56x over |
zai-org/GLM-5.3-Flash-BF16 |
598.53 |
5.00x over |
unsloth/GLM-5.3-Flash-FP8 |
305.82 |
2.56x over |
LibertAIDAI/GLM-5.3-Flash-NVFP4 |
181.32 |
1.52x over |
Four repositories are named *-GGUF and every one contains zero .gguf files (unsloth, AtomicChat, aj9o9, vcruz305 — READMEs and images only). A repository name is not an artifact.
Exact split from the headers: 62 shards, 76,108 tensors, F8_E4M3 314,396,639,232 + BF16 6,926,096,640 elements = 321,322,735,872 real parameters, plus 19,484,766 F32 block scales. Routed experts are 311.65B = 97.0% of the model, so any GGUF arm's mixed bpw is the experts' bpw to within a percent.
gateable = no, on memory: no oracle can run this model on any device this project can reach, so no end-to-end token gate is reachable now or ever on this fleet. That is recorded as visible debt, not waived. What replaces it is a tiny-shape reference oracle — a randomly-initialised Glm5NextConfig run on CPU from the pinned transformers, dumping per-component activations — which is a real numerical oracle for waves 1-6 and is not oracle gateability for the model.
Developer-set W7 verification target: a low GGUF quant that fits on the DGX. Arithmetic (not measurement), experts at the named type and the other 3% at Q6_K, bpw from our own reader's block traits at gguf_reader.cpp:200: Q8_0 318.0 GiB, Q6_K 245.5, Q4_K 170.6, IQ3_XXS 118.1 (~1.5 GiB left — not a margin), Q2_K 102.6 (~17 GiB left), IQ2_S 100.3, IQ2_XXS 82.3, IQ1_S 64.0. KV is small by design: ~11.7 KiB/token, so 128K is ~1.5 GiB and the full 1M ~11.4 GiB. Q2_K is the recommended first arm and the reason is producibility, not quality: i-quants need an importance matrix, an importance matrix needs a forward pass, and a forward pass needs 181 GiB — the dependency is circular on this fleet. K-quants need no imatrix. And since llama.cpp has no glm5_next, we must author the converter ourselves; there is no reference GGUF to diff against and no llama.cpp floor for the arm.
Plan
Eight waves in the spec, dispatchable from it: W0 lane oracle pin, W1 config + registry + refuse-by-name, W2 the KDA forget-gate branch, W3 NoPE MLA + k-pool indexer, W4 mHC + unweighted head, W5 MoE + decoder layer + text forward + heterogeneous KV, W6 vision + processor, W7 GGUF converter + the fitting arm. W0-W2 and W4 are CPU-gateable; W3 and W5-W8 need a GPU. W8 (speed) is not scheduled — there is no denominator.
Live seam contention to rebase onto, not fork: #1971 (DSA geometry) and #1977 (DSv4 KV multicache).
Spec: .agents/specs/glm5-next-flash.md. Matrix row: MODEL-MM-glm5-next-glm5-next-for-conditional-generation. Campaign row: MODEL-MM-GLM53-FLASH. No product code lands under the spec pull request.
zai-org/GLM-5.3-FlashdeclaresGlm5NextForConditionalGeneration/model_type: glm5_next, a natively multimodal 321.32B-total / ~18B-active hybrid that no oracle implements at a pinned revision and that no device on this fleet can hold. This row scopes the port and states both boundaries up front.The oracle verdict, read live 2026-08-26
555967922: implements NOTHING.git grep "Glm5\|glm5_next"returns zero hits;vllm/model_executor/models/registry.py:113-117,409-413,640-642carries nine GLM entries and noGlm5*.main(c71f6f8a81, 2026-08-26 08:42 -0700): implements NOTHING EITHER. Zero hits;vllm/models/holdscommon, deepseek_v32, deepseek_v4, dots3_note, inkling, kimi_k3, minimax_m3and noglm5next. This is absence, not pin staleness — advancing the pin does not reach it, and that advance would cost reconciling 348 commits for nothing.mergeable: false(head933876c388fb, 85 files, +12,511/-540). An unmerged PR is not a revision and is inadmissible as an oracle — the same rule this repo already applied to SGLang #36497 onMODEL-MM-QWEN4-EXP. It is cited only as evidence of upstream shape.maincannot run.b10451. Consequence:convert_hf_to_gguf.pycannot emit this architecture andllama-quantizecannot quantize it.eb4d9e2a64(2026-08-26T14:26:40Z, transformers#48342). First release carrying it isv5.16.1, bounded rather than assumed:modeling_glm5_next.pyis HTTP 200 atv5.16.1, 404 atv5.16.0, 404 atv5.15.1. Our transformers pin is 5.14.1, so this row needs a lane-scoped second pin, expiring when vLLM registersglm5_next. Note theMODEL-MM-QWEN4-EXPlane pins5.16.0and this one pins5.16.1— one day apart, becauseQwen4Expmerged before the 5.16.0 cut andGlm5Nextafter it. Two lanes, two releases; that is what a lane pin is for.What the model is
45 layers, hidden 4096, vocab 154880, 1,048,576 context. Hybrid attention: 34 KDA linear-attention layers + 11 DeepSeek-Sparse-Attention MLA layers (at 3, 7, 11, ... 43). MLA is fully NoPE —
qk_rope_head_dim: 0,mla_use_nope: true,qk_nope_head_dim: 256,v_head_dim: 256,kv_lora_rank: 512,q_lora_rank: 1536— andtext_configcarries norope_thetaand norope_scalingat all. The language model has no rotary embedding on its main attention path; position comes from the KDA recurrence. DSA indexer:index_head_dim128,index_n_heads32,index_topk2048, plus a new k-pool compression (index_kpool: 4,index_kpool_compress,index_kpool_always_select_tail). mHC:mhc: true,hc_mult: 4,hc_sinkhorn_iters: 20. MoE: 288 routed + 1 shared, top-8,moe_intermediate_size2048, sigmoid /noaux_tc,n_group=topk_group=1,routed_scaling_factor2.5, clamped SwiGLU atswiglu_limit10.0. Vision: 24-layer ViT, hidden 1024, patch 14, spatial merge 2, temporal patch 2, out 4096.num_nextn_predict_layers: 1(MTP).Why this is not the blocked GLM-5 row
MODEL-TEXT-deepseek-v2-glm-moe-dsa-for-causal-lm(GlmMoeDsaForCausalLM) is already labelled "GLM-5" and isBLOCKEDunderCLAIM-GLM-DSA-LATEST-DEEPSEEK. That is DeepSeek-V3.2 verbatim (deepseek_v2.py:1917-1918), 753.9B.glm5_nextis a differentmodel_type, different parameter count, different attention topology, and has a vision tower. New row, not a revival.Most of it is already here — and the two obvious reuses are wrong in one place each
mHC, the DSA lightning indexer and KDA all exist in this tree. Two carry a delta a token gate cannot see:
Glm5NextTextForgetGate.forwardbranches onsafe_gate_lower_bound; the checkpoint setsgate_lower_bound: -5.0, so it computes-5.0 * sigmoid(exp(A_log) * (f_b(f_a(x)) + dt_bias)). Ourkimi_kda.cpp:60implements the other branch,-exp(A_log) * softplus(g + dt_bias). Different functions of the same inputs; both fluent; the sign ofdecay_ratediffers too.Glm5NextTextHyperHead.forwardishidden_streams.mean(dim=2), and its own docstring says "Unlike DeepSeek-V4". OurHcHeadCollapse(deepseek_v4_mhc.cpp:168) is the V4 weighted-gated collapse. Reusing it yields a working model with a wrong final projection.Third trap: the k-pool indexer is unobservable at or below 2048 tokens — with
index_topk: 2048a shorter context selects every candidate, so the selection is the identity and any short-prompt gate passes over a broken indexer. Same shape as the trap recorded onMODEL-MM-QWEN4-EXP.Structural blocker:
MlaBlockDims::Validaterefusesqk_rope_head_dim == 0(mla_attention.cpp:90-93requires every dim> 0,:95-99requires it even). Kimi-Linear is not the same case: it setsmla_use_nopewhile keepingqk_rope_head_dim: 64, so the rope slice still exists in the cache row.Nothing fits, and no GGUF exists
Read live from the HF API, and for the primary repo by HTTP RANGE over all 62 safetensors headers (no payload fetched). Against ~119.63 GiB usable on
dgx:gpu0:zai-org/GLM-5.3-Flash(FP8 e4m3, block 128x128)zai-org/GLM-5.3-Flash-BF16unsloth/GLM-5.3-Flash-FP8LibertAIDAI/GLM-5.3-Flash-NVFP4Four repositories are named
*-GGUFand every one contains zero.gguffiles (unsloth,AtomicChat,aj9o9,vcruz305— READMEs and images only). A repository name is not an artifact.Exact split from the headers: 62 shards, 76,108 tensors,
F8_E4M3314,396,639,232 +BF166,926,096,640 elements = 321,322,735,872 real parameters, plus 19,484,766 F32 block scales. Routed experts are 311.65B = 97.0% of the model, so any GGUF arm's mixed bpw is the experts' bpw to within a percent.gateable = no, on memory: no oracle can run this model on any device this project can reach, so no end-to-end token gate is reachable now or ever on this fleet. That is recorded as visible debt, not waived. What replaces it is a tiny-shape reference oracle — a randomly-initialisedGlm5NextConfigrun on CPU from the pinned transformers, dumping per-component activations — which is a real numerical oracle for waves 1-6 and is not oracle gateability for the model.Developer-set W7 verification target: a low GGUF quant that fits on the DGX. Arithmetic (not measurement), experts at the named type and the other 3% at Q6_K, bpw from our own reader's block traits at
gguf_reader.cpp:200: Q8_0 318.0 GiB, Q6_K 245.5, Q4_K 170.6, IQ3_XXS 118.1 (~1.5 GiB left — not a margin), Q2_K 102.6 (~17 GiB left), IQ2_S 100.3, IQ2_XXS 82.3, IQ1_S 64.0. KV is small by design: ~11.7 KiB/token, so 128K is ~1.5 GiB and the full 1M ~11.4 GiB. Q2_K is the recommended first arm and the reason is producibility, not quality: i-quants need an importance matrix, an importance matrix needs a forward pass, and a forward pass needs 181 GiB — the dependency is circular on this fleet. K-quants need no imatrix. And since llama.cpp has noglm5_next, we must author the converter ourselves; there is no reference GGUF to diff against and no llama.cpp floor for the arm.Plan
Eight waves in the spec, dispatchable from it: W0 lane oracle pin, W1 config + registry + refuse-by-name, W2 the KDA forget-gate branch, W3 NoPE MLA + k-pool indexer, W4 mHC + unweighted head, W5 MoE + decoder layer + text forward + heterogeneous KV, W6 vision + processor, W7 GGUF converter + the fitting arm. W0-W2 and W4 are CPU-gateable; W3 and W5-W8 need a GPU. W8 (speed) is not scheduled — there is no denominator.
Live seam contention to rebase onto, not fork: #1971 (DSA geometry) and #1977 (DSv4 KV multicache).
Spec:
.agents/specs/glm5-next-flash.md. Matrix row:MODEL-MM-glm5-next-glm5-next-for-conditional-generation. Campaign row:MODEL-MM-GLM53-FLASH. No product code lands under the spec pull request.