GLM-5.3: the same base as 5.2, with every gain in post-training
753B total, 40B active, a million tokens of context, and 78 layers of DeepSeek Sparse Attention. Z.ai did not retrain the base model. All of this came from post-training.
The architecture
how it is builtSeventy-eight layers, three of them dense
The first three layers are dense MLP and the remaining 75 are mixture-of-experts. Each MoE layer routes a token to 8 of 256 routed experts plus one shared expert, with an expert FFN width of 2048. 753 billion parameters sit in memory and roughly 40 billion of them do work on any given token.
DSA, with MLA-style projections
Attention is DeepSeek Sparse Attention over low-rank MLA projections: 64 heads, a query LoRA rank of 2048 and a KV LoRA rank of 512. A lightning indexer picks a sparse set of key tokens per query rather than attending over everything, which is what keeps attention cost close to flat as the context grows.
IndexShare
The piece I find most interesting. Running an indexer on every sparse layer is expensive, so one indexer is computed and then reused across every four attention layers, removing the indexer work from three layers in four. Z.ai quote 2.9x fewer per-token FLOPs at a million tokens. It is the same instinct as GLM-5.3-Flash's IndexPool, applied to compute rather than to cache.
A million tokens, and 128K out
The context window is 1,048,576 tokens with a maximum output of 128K. RoPE theta was raised to 8,000,000 from the previous 1,000,000, which is the sort of change that only matters until it is wrong, and then matters enormously.
The base model did not move
GLM-5.3 uses the same base as GLM-5.2. Every improvement, and Z.ai claim a 50% gain on their in-house code benchmark, came from scaled post-training. Cyber capability apparently grew faster than they expected as post-training scaled, which is a sentence I would want to sit with rather than skim.
Serving it
the playbookH200, B200, B300, GB300, and AMD MI300X through MI355X. SGLang documents FP8 as the production configuration, with tensor and expert parallelism sized together (--tp-size with --ep-size), data-parallel attention via --enable-dp-attention, context parallelism for prefill through --attn-cp-size, and EAGLE speculative decoding. MTP speculation ships with the model.
On a 4,000-GPU HGX B200 fleet
500 nodes, eight B200s each, 180 GB per GPU
Weights are 753 GB (FP8 quantised, derived). Usable memory is 180 GB x 0.92 per GPU,
the gpu_memory_utilization from the published recipe. A placement only counts
here if the cache gets at least 30% of what is left, because a config that fits the weights
and nothing else cannot serve a request.
Tensor parallel stays inside the NVSwitch, so no TP traffic ever crosses a NIC.
- The checkpoint is not what you serve. Hugging Face lists the tensor types as BF16, FP8 and F32 together. At BF16 the weights alone would be around 1.5 TB, which does not fit one node no matter how the memory is arranged. The 753 GB figure below is the FP8-quantised footprint, and it is derived rather than published, so I would confirm it against the actual files before committing a placement.
- reasoning_effort is a real dial. The model takes low, high or max and defaults to max. This matters more than it sounds: much of the published comparison data for GLM-5.3 is captured at max effort, so a throughput number you read elsewhere and a throughput number you measure at a lower setting are not describing the same workload.
- Two published profiles, not one number. SGLang's own figures split into a low-latency shape at concurrency 1 to 16 with TTFT in the high hundreds of milliseconds, and a high-throughput shape at concurrency 64 to 256. Quoting either alone would misrepresent it, which is exactly the problem I wrote the benchmarking page about.
- It takes the whole node. At FP8, 753 GB against 1,325 GB of usable memory across eight B200s leaves roughly 572 GB for cache. One replica per HGX node, and tensor parallel spans exactly the NVLink domain.
What I would want to know before running it
my readThe licence is the first thing I would resolve, because it is the only item here a benchmark cannot answer for me. After that the honest question is narrow: does 40B active buy me enough over Flash's 18B on my own traffic to justify a whole node per replica instead of half? I do not think a leaderboard can tell me that. What I find genuinely interesting is that this is the same base model as 5.2 with all the gain in post-training, which means the improvement is in the part of the pipeline I usually treat as a black box, and I would like to understand what that implies about how much headroom is left in checkpoints I already have.
The numbers
measured elsewhere, not here- Terminal Bench 3.0
- 28.3
- DeepSWE v1.1
- 66.9
- CyberGym
- 84.5
- ExploitBench
- 54.4
Benchmark figures from the model card. FP8 quantisation is reported to hold 97 to 98% on GSM8K and 90 to 92% on AIME25 against the unquantised model. None of this was measured on my hardware.
Sources: Hugging Face: zai-org/GLM-5.3 · SGLang cookbook: GLM-5.3 · SemiAnalysis InferenceX: GLM-5.3 · GLM-5 paper, arXiv 2602.15763