GLM-5.3

CONTEXT SCALING: null is a VERIFIED value here, checked against config rather than left blank. config.json (zai-org/GLM-5) declares rope_scaling null and no rope_theta override, max_position_embeddings 202752. So the 1M-advertised GLM-5 window is NOT a config-level interpolation; null is a verified value, not a gap. Largest open GLM and the current frontier of the line: safetensors total 753.33B. The card states GLM-5.3 reuses the GLM-5.2 base model and that all gains are post-training, so GLM-5.2 and 5.3 share this exact config - recorded once, with 5.3 as the current release. Architecture glm_moe_dsa = MoE + MLA + DSA sparse attention. kv_cache_bytes_per_token = 78 layers x (kv_lora_rank 512 + qk_rope_head_dim 64) x 2 = 78 x 576 x 2 = 89,856 B/token (87.8 KiB). That is excellent for a 753B model: compare DeepSeek-V3's 68.6 KiB. The cache cost is dominated by layer count, not total params, so a very large MoE can still be cheap in KV. index_topk 2048 with a sparse-attention indexer (HF GlmMoeDsaAttention) selects the attended positions - a decode compute saver, not a cache saver. MoE: 256 routed + 1 shared, 8 per token, first_k_dense_replace 3, moe_intermediate_size 2048, intermediate 12288. hidden 6144, head_dim 192, qk_nope 192, qk_rope 64, v_head_dim 256, q_lora_rank 2048. Context 1048576, rope_parameters rope_type default rope_theta 8000000. ACTIVE PARAMS (filled 2026-10-17): the GLM-5.3 card's model-overview table states 744B total and 40B active parameters (256 experts, 8 activated, plus the shared expert the config records as n_shared_experts 1). Previously this field was left null because only the GLM-5 config had been read. Config arithmetic on that same config (3 dense layers at intermediate 12288, 75 MoE layers, 8 routed experts of moe_intermediate 2048 plus 1 shared expert, SwiGLU as 3*H*I, MLA projections q_lora 2048 / kv_lora 512 / qk 256 / v 256 / 64 heads, untied embedding and lm_head at vocab 154880) gives 40.93B active and 743.1B total. The vendor figure of 40B and the derived 40.93B agree to about 2 percent; the field records the vendor's 40. Config total 743.1B versus the safetensors total 753.33B is the indexer, MTP head, and norms the sketch omits. flops_per_token_active = 2 * 40e9 = 8.0e10 follows the schema convention from the recorded active count. Licence is the bespoke 'GLM-5.3 License', a change from MIT on 4.5/4.6. SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=mla. REQUIRED KERNEL CLASS: an MLA decode kernel. MLA is not a variant of the GQA kernel - the cache is a shared low-rank latent (d_c) plus a decoupled RoPE key, not per-head K/V, so an engine that lacks a dedicated MLA decode path cannot serve the class at all. SUPPORTED BY (cited): vLLM native rows DeepseekV2ForCausalLM, DeepseekV3ForCausalLM, DeepseekV32ForCausalLM, DeepseekV4ForCausalLM [[mdl2-vllm-supported-models-2026-10]]; TensorRT-LLM the same four rows plus GlmMoeDsaForCausalLM (GLM-5), Glm4MoeForCausalLM (GLM-4.5/4.6/4.7), KimiK3ForConditionalGeneration and KimiLinearForCausalLM [[mdl2-trtllm-supported-models]]; SGLang generative table names DeepSeek v1/v2/v3/R1 and Kimi K2 as supported [[mdl2-sglang-generative-models]]; llama.cpp reaches MLA through the DEEPSEEK2/DEEPSEEK32/DEEPSEEK4 arch entries, which are in its supports_sm_tensor == false list, i.e. no tensor-core matmul path for the attention itself [[mdl2-llamacpp-arch-class-registry]]; ik-llama-cpp records MLA as a feature that landed there first and was later upstreamed [[ik-llama-cpp]].ENGINE KERNEL CONSTRAINTS THAT CHANGE WHAT THE ENGINE MUST STORE (this is the important class of fact): (1) FlashInfer, which is SGLang's default attention backend and selectable in vLLM [[flashinfer]], is where the MLA decode kernels live, and they are instantiated per KV cache page-block size: gotcha-sm120-sparse-mla-block-size records vLLM computing compressed-layer pbs = block_size // compress_ratio (= 32 at block_size 64 for a ratio-2 layer) while FlashInfer's SM120 planner hard-codes _PAGE_BLOCK_SIZE = 64, so DeepSeek-V4.1-Flash will not start on 8x RTX PRO 6000 at TP8 at ANY global block size (64 gives pbs=32 and crashes; 128 gives 'No common block size'). Workaround is SM100 datacenter Blackwell or a FlashInfer planner change. (2) FlashMLA's 2026.09.30 release requires SM100/SM103 and CUDA >= 13.1, REMOVED Hopper support and removed V3/V3.2/V4.0, and supports ONLY FP8 and FP4 KV cache - unquantized bfloat16 KV is explicitly not supported [[kern-flashmla-github]]. So the kernel choice decides the KV CACHE FORMAT: to use that decode kernel the engine must store an FP8/FP4 latent with per-token inlined scales, and V4.1's layout is 528 bytes/token (512 of float8_e4m3 over all 512 dims - the 64 RoPE dims are quantized too, no bf16 part - plus 16 bytes of float8_e8m0 scales, one per 32 e4m3 values), with an fp4 variant at 288 bytes/token [[flashmla-decode-fp8-fp4-kv]]. A Hopper box therefore cannot take that kernel and an engine that only offers bf16 MLA KV cannot take it either. (3) Independent of the kernel: TRT-LLM's MLA rows carry two footnotes that constrain serving rather than correctness - chunked prefill for MLA only enables on SM90/SM100/SM103/SM107/SM120, and KV cache reuse for MLA only enables on SM90/100/103/107/120/121 in BF16/FP8 [[mdl2-trtllm-supported-models]]. (4) TRT-LLM states DeepSeek-V4 is Blackwell SM100+ only and Kimi K3 is SM100 family only, with a worked recipe split (DEP16 needs GB300-class per-GPU memory, TEP16 validated on GB200) [[mdl2-trtllm-supported-models]]. ISA CONSEQUENCE: at 68.6 KiB/token MLA moves the bottleneck off KV and onto weight streaming, so MLA-capable engines find their paged-attention machinery largely idle and their GQA-era cache-pressure tuning irrelevant [[mla-latent-attention]]. TRT-LLM row GlmMoeDsaForCausalLM covers GLM-5 with MTP speculative decoding and the KV-cache-reuse footnote set that MLA requires [[mdl2-trtllm-supported-models]]. The DSA sparse indexer is a second kernel class on top of MLA - an FP8 indexer scoring pass, per flop/deepgemm-mqa-lightning-indexer-scoring, which is only available on B200/H100/GB200 per that record's affected_by_hardware. On a part outside that list the sparse path has no recorded kernel. CONTEXT_SCALING_METHOD (native): SCHEME RECLASSIFIED (2026-10-04): was null, despite a 202752 context and a `rope_parameters` block. rope_parameters declares rope_type 'default' with rope_theta 1e6 - no factor, no extension. A parameters block is not a scaling block. head_dim CORRECTED (2026-10-05): head_dim was recorded as 192, which is NOT a value config.json publishes for this model and does not correspond to any single head geometry in the stack. config.json (zai-org/GLM-5) publishes four separate width fields and they disagree with each other, which is the whole reason a single head_dim field is a poor fit for MLA+DSA models: head_dim 64, qk_nope_head_dim 192, qk_rope_head_dim 64, qk_head_dim 256 (= qk_nope + qk_rope = 192+64, the internal QK projection width), v_head_dim 256, kv_lora_rank 512, q_lora_rank 2048, index_head_dim 128. The old 192 was the qk_nope value misfiled as the general head_dim - i.e. exactly the failure mode this audit was told to hunt for, a sub-head width promoted to the stack-level field. CORRECTED to config's own head_dim 64, with qk_nope_head_dim 192, qk_rope_head_dim 64, qk_nope/qk_rope/v_head_dim left as config states them. KV CACHE IS UNAFFECTED and was already right, because MLA caches the latent rather than per-head K/V: 78 layers x (kv_lora_rank 512 + qk_rope_head_dim 64) x 2 bytes = 78 x 576 x 2 = 89,856 B/token (87.8 KiB/token). A reader who wanted the naive per-head figure would now compute 2 x 78 x 64 heads x 64 x 2 = 1,277,952 B/token, 14.2x the real figure - the MLA overstatement this field exists to prevent, and a reminder that num_key_value_heads 64 in this config is the QUERY head count carried through for MLA expansion, not 64 independent KV heads to cache. DEPLOYMENT (GLM-5.3 card, read 2026-10-17): SGLang, vLLM, xLLM on Ascend, and KTransformers have recipes; the card states llama.cpp is not supported yet. The card's quantized weight size is about 375GB, so this is not a single-GPU model. No ollama recipe is named.