GLM-5.3-Flash Locally: 93GB Floor, Not 18B

Z.ai released GLM-5.3-Flash on 26 August 2026 under an MIT license, and most of the coverage repeated the same two numbers: 320B total parameters, 18B active. Those numbers sound like the model should be easy to run at home. An 18B active model, after all, is roughly Qwen3-14B territory.

That reading is wrong, and it is the single most expensive mistake you can make with this model. All 320B parameters have to be resident in memory even though only 18B do arithmetic per token. The smallest usable quant on Hugging Face is 93 GB. The full BF16 GGUF set is 642 GB.

The config file and the real file sizes tell a different story from the launch posts, and the API pricing matters if you decide the local path is not worth it.

Table of contents

• Why 18B active does not mean 18B of memory
• Real quant sizes, measured from Hugging Face
• What the config.json actually reveals
• The hybrid attention change is the real news
• API pricing, and the discount that ends on 9 September
• Local or API: run the numbers on your own workload
• FAQ
• Sources

Why 18B active does not mean 18B of memory

A Mixture-of-Experts model routes each token through a small subset of its experts. GLM-5.3-Flash has 288 routed experts plus 1 shared expert, and picks 8 routed experts per token. That gives you 18B parameters doing work at any instant out of 320B sitting in memory.

The compute saving is real. The memory saving does not exist. The router can select any of the 288 experts for the next token, so every expert has to be loadable. If you offload experts to disk, you pay a disk read on nearly every token, and throughput collapses.

The Hugging Face safetensors index for zai-org/GLM-5.3-Flash reports 321,323,031,390 parameters, shipped as FP8 for the routed expert weights (314.4B params in F8_E4M3) with 6.9B in BF16. Z.ai published the weights already quantized to FP8 with 128x128 weight blocks, so the "native" download is about 321 GB rather than the 642 GB a BF16 release would be.

Real quant sizes, measured from Hugging Face

I pulled the file sizes directly from the Hugging Face tree API for unsloth/GLM-5.3-Flash-GGUF rather than trusting round numbers in blog posts. Sum of all shards per quant directory:

Two practical notes on these. The vision tower ships separately as mmproj-BF16.gguf (1.16 GB) or mmproj-F16.gguf (1.13 GB), so add roughly 1.2 GB if you want the multimodal input the model is built around. And these are weight sizes only, before KV cache and before any runtime overhead.

A 128 GB unified-memory machine can hold UD-IQ1_S or UD-IQ2_XXS with room for a modest context. Q4_K_XL at 200 GB needs something like a 256 GB box. Anything above that is server territory. At the time of writing, running these quants needs the llama.cpp pull request Unsloth links from the model card rather than a released llama.cpp build, or their desktop app.

What the config.json actually reveals

Numbers below come from text_config in the model's own config.json, not from secondhand summaries:

Three details worth pulling out. The first three layers are dense (first_k_dense_replace: 3), so the MoE routing only starts at layer 3. There is one Multi-Token Prediction layer at index 45, which speculative decoding can use. And mhc: true with hc_mult: 4 confirms the Manifold-Constrained Hyper-Connections that Z.ai credits for the scaling efficiency gain.

The attention design is not standard multi-head. kv_lora_rank of 512 with q_lora_rank of 1536 is a compressed latent KV setup in the DeepSeek MLA family, and mla_use_nope is true, so those layers run without rotary position embeddings. That compression is why a 1M context is serveable at all.

Our AI VRAM calculator now carries GLM-5.3-Flash as a preset with these exact values, so you can put your own context length and quantisation against it instead of reading someone's summary table.

The hybrid attention change is the real news

GLM-5.3-Flash is the first model in the GLM series to mix linear and sparse attention in one stack. The linear_attn_config block spells out the split: 34 of the 45 layers use Kimi Delta Attention style linear attention, and 11 layers (indices 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43) keep full attention with a sparse indexer.

The pattern is a strict stride of 4. Three linear layers, then one full attention layer, repeating. Linear attention carries local dependencies through recurrent state, which costs constant memory per token instead of growing with sequence length. The 11 full-attention layers do the long-range retrieval, and each one uses a learned indexer that selects only 2,048 keys (index_topk) rather than attending to the whole million-token window.

Z.ai's own figure for what this buys: attention compute down 3.01x and KV cache down 4.44x versus GLM-5.3. The KV cache number is the one that shows up on an inference bill, since cache is what makes long agentic sessions expensive.

For local runners, this cuts both ways. The KV cache footprint at long context is far smaller than a 320B dense-attention model would need. But the architecture is new enough that support is still landing in inference engines, which is why the GGUF quants currently want a llama.cpp PR build.

API pricing, and the discount that ends on 9 September

If 93 GB is out of reach, the API is genuinely cheap. From Z.ai's official pricing table:

The promotional rate is a flat 50% discount and Z.ai states it ends at 24:00 on 9 September 2026 (UTC+8). After that you pay $0.15 and $0.50. Worth planning around if you are benchmarking this week and budgeting for next month, because your test bill will double on the same workload.

Even at list price the gap to GLM-5.3 is roughly 9x on both input and output, for a model Z.ai says beats GLM-5.2 across their benchmark set. That is the actual argument for this release, and it is a stronger one than the license.

OpenRouter lists the same model at $0.075 input and $0.25 output with a 1,310,720-token context, slightly above the 1,048,576 in the config. Their batch endpoint sits at the $0.15/$0.50 list rate. Run your own token mix through our API cost calculator rather than comparing headline rates, because the cached-input rate is where a long agentic session actually lands.

Local or API: run the numbers on your own workload

The honest split, based on the numbers above.

Use the API if you are evaluating, prototyping, or running anything bursty. At $0.075/$0.25 you would need to push a very large volume before a 256 GB machine pays for itself, and you get the 1M context and multimodal input without fighting a PR branch of llama.cpp.

Run it locally if your data cannot leave your network, or you already own the hardware. 128 GB unified memory gets you the 1-bit and 2-bit dynamic quants. Below that, this model is not your model, and GLM-4.5-Air or a Qwen3-32B class model will serve you better than a 1-bit 320B.

Skip both if you wanted a cheap multimodal coding model on a single 24 GB GPU. That is not what this release is, regardless of what "18B active" suggests.

The FP8 native release is worth noticing on its own. Z.ai shipped the weights pre-quantized instead of publishing BF16 and leaving the community to compress them, which reads as a lab budgeting for deployment cost from the start. Same thinking as the hybrid attention.

FAQ

Can I run GLM-5.3-Flash on a 24 GB GPU? No. The smallest GGUF quant on Hugging Face, UD-IQ1_S, is 93 GB across three shards, and every parameter has to be resident because the MoE router can select any expert for the next token.

How much memory does GLM-5.3-Flash actually need? Weights alone: about 93 GB at 1-bit, 109 GB at Q2_K_XL, 200 GB at Q4_K_XL, 341 GB at Q8_0 and 642 GB at BF16. Add roughly 1.2 GB for the vision tower and your KV cache on top.

Is GLM-5.3-Flash really open source? The weights are on Hugging Face under an MIT license, which is more permissive than most open-weight model licenses. The training data and code are not published.

What is the context window? The config lists 1,048,576 tokens and Z.ai's docs say 1M with 128K maximum output. OpenRouter advertises 1,310,720 for the standard endpoint.

Why is 18B active parameters misleading? It describes compute, not memory. Only 18B parameters participate in any single token, so FLOPs are low, but all 320B must be loadable, so memory is your binding constraint.

How much does the GLM-5.3-Flash API cost? $0.075 per million input tokens and $0.25 output during the launch promotion, doubling to the $0.15 and $0.50 list price after 24:00 on 9 September 2026 (UTC+8). Cached input is $0.015 promotional, $0.03 list.

What is the model code for the API? glm-5.3-flash on Z.ai, or z-ai/glm-5.3-flash through OpenRouter.

Conclusion

The "320B total, 18B active" framing sells the compute story and hides the memory story. If you take one number from this post, take 93 GB, because that is the floor for running GLM-5.3-Flash locally at the most aggressive quantisation anyone currently publishes.

The interesting engineering is the 34/11 split between linear and sparse attention at a stride of 4, which is what makes a 1M context affordable to serve. And if you are just here to use the model, the API at $0.075/$0.25 is the cheaper answer until 9 September, then $0.15/$0.50 after.

Sources

• zai-org/GLM-5.3-Flash config.json — architecture values, read 6 September 2026
• zai-org/GLM-5.3-Flash model info API — parameter count and dtype split, read 6 September 2026
• unsloth/GLM-5.3-Flash-GGUF — quant file sizes summed from the tree API, read 6 September 2026
• Z.ai pricing — official pricing table and promotion end date, read 6 September 2026
• GLM-5.3-Flash model guide — Z.ai's architecture and efficiency claims, read 6 September 2026
• OpenRouter models API — third-party pricing and context length, read 6 September 2026