GLM 5.3 Flash Parameters and Size: 320B-A18B, 328 GB, MIT Weights

Quick answer: GLM 5.3 Flash has 320 billion total parameters with 18 billion active per token — a Mixture-of-Experts model, written 320B-A18B. It has 45 layers, routes each token through 8 of 288 experts, and uses a hybrid attention stack of KDA linear-attention plus NoPE sparse MLA layers. The native FP8 weights occupy roughly 328 GB on disk and live at zai-org/GLM-5.3-Flash on Hugging Face under an MIT license. There is no dedicated GitHub repo — the code and inference recipes are in zai-org/GLM-5. That 17.8:1 total-to-active ratio is the entire reason a 320B model can be served at $0.15 per million input tokens.

Parameter counts are the most quoted and least understood number in model releases. "320B" sounds like it belongs in the same conversation as a flagship; "18B" sounds like a laptop model. For GLM 5.3 Flash both are true at once, for different resources — and getting that distinction wrong is how teams either over-provision compute by an order of magnitude or discover mid-deployment that the model will not load at all.

Everything here comes from Z.ai's Hugging Face model card, the zai-org/GLM-5 repository, and technical reporting on the launch, checked August 27, 2026. Where a number is community-measured rather than vendor-published — the on-disk size specifically — it is labelled.

What This Article Solves

The pain point: "320B parameters" tells you the storage cost, not the compute cost, and the model's assets are scattered across four locations under two different licenses. In a Mixture-of-Experts model the total and active counts diverge by more than an order of magnitude. Meanwhile the weights are on Hugging Face, mirrored on ModelScope, the code sits in a repository named after a different model, and community quantizations look official but are not.

You will leave knowing which number governs which resource, the full architecture layer by layer, the real disk and memory footprint, exactly where every official asset lives, and what the MIT license does and does not permit.

The Full Parameter Breakdown

Total vs. Active: Which Number Governs What

This is the whole article in one section.

320B (total) governs memory. Every parameter must be resident and loadable, because the router can select any expert for any token. You cannot page experts in on demand at acceptable latency. So your VRAM or unified-memory budget is sized against 320B — roughly 328 GB at FP8, and about double that at BF16.

18B (active) governs compute and speed. For a given token, only 8 of 288 experts fire. The FLOPs per token, and therefore the marginal cost of serving a token, look like an 18B dense model rather than a 320B one.

That split explains the model's pricing and its performance profile at the same time:

• Why it is so cheap ($0.15/1M input at list, versus $1.40/1M for GLM 5.3): you are billed against 18B-scale compute.
• Why it is not fast (50.2 output tokens/second measured by Artificial Analysis, below the ~67 t/s median for its class): MoE routing adds overhead, and the memory bandwidth needed to reach 320B of weights is real regardless of how few of them fire.
• Why self-hosting is hard: 328 GB does not fit on one machine, even though the compute easily would.

If you take one thing from this page: cheap to run, expensive to host. Those are not in tension — they are two different numbers.

The Architecture, Piece by Piece

45 layers, 288 experts, 8 routed. A comparatively shallow stack for the parameter count, with the width in the expert dimension. Z.ai credits mHC (Manifold-Constrained Hyper-Connections) with letting them halve both the active parameter count and the layer count relative to GLM-4.5 at a comparable total parameter count. This is the structural trick that makes a 17.8:1 sparsity ratio trainable rather than merely theoretical.

Hybrid attention — the first in the GLM series. Two kinds of layer share the work:

• KDA linear-attention layers handle local dependencies at linear rather than quadratic cost.
• NoPE sparse MLA layers pull in globally relevant context without attending to everything.

Z.ai reports the combination delivers roughly 3x less attention compute and a 4.4x smaller KV cache than GLM-5.3. The KV cache figure is the commercially important one: at long context, KV memory — not weights — is usually what makes serving expensive. Shrinking it 4.4x is what turns a million-token window from a spec-sheet number into an affordable product.

IndexPool. To keep that window tractable, indexer key vectors are compressed by weighted pooling, cutting latency and memory at long context. State the implication honestly: this is lossy by design, and no published benchmark measures how retrieval accuracy holds at 800K tokens versus 80K. The mechanism is well described; the size of the trade-off at the extremes is not.

Native FP8 with an MTP draft layer. The weights are released natively in FP8 rather than quantized down from BF16 after the fact, so the FP8 release is the reference model rather than a lossy derivative. One multi-token-prediction draft layer ships alongside for speculative decoding.

Model Size on Disk and in Memory

The number you need for a hardware conversation is ~328 GB for the FP8 release — a reading of the Hugging Face file sizes reported by users on NVIDIA's developer forums, not a vendor-published figure, so treat it as approximate.

For context, DeepSeek V4 Flash — the obvious open-weight rival — is around 160 GB, roughly half. If self-hosting on constrained hardware is the goal, that gap will decide your choice long before any benchmark does.

Where the Weights Actually Live

Two things to internalise.

There is no GLM-5.3-Flash GitHub repository. If you searched for one and came up empty, you are not missing anything. The zai-org GitHub organisation hosts GLM-5, GLM-V, GLM-4, GLM-Image and others, and GLM 5.3 Flash's inference cookbooks live inside GLM-5. Point your internal docs at zai-org/GLM-5.

The weights and the code carry different licenses — MIT for the weights, Apache-2.0 for the GLM-5 code repository. Both are permissive and neither blocks a commercial deployment, but a compliance review that records "MIT" for everything is inaccurate. Record them separately.

What the MIT License Actually Permits

This is the most permissive license in wide use for open-weight models, and the contrast with the norm is worth stating:

• Commercial use — permitted, with no revenue threshold and no separate commercial licence to negotiate.
• Modification and fine-tuning — permitted, and you own the result.
• Redistribution — permitted, including of your modified weights.
• Private forks — permitted, with no obligation to publish changes.
• No acceptable-use appendix — unlike most "open" model licences, there is no attached list of prohibited use cases.

Your only obligation is retaining the copyright notice. For a 320B-parameter model at near-frontier benchmark scores, that is an unusually clean legal position, and it is a substantive part of why this release mattered beyond its benchmark numbers.

Downloading and Serving

The standard Hugging Face client works. Check the size before you start the transfer.

pip install -U "huggingface_hub[cli]"

# FP8 reference release — roughly 328 GB
hf download zai-org/GLM-5.3-Flash --local-dir ./GLM-5.3-Flash

On a 1 Gbps connection that is roughly three-quarters of an hour at full saturation, and it needs to land on storage that can hold it plus room to serve from. If you are hitting Hugging Face rate limits, the ModelScope mirror at ZhipuAI/GLM-5.3-Flash carries the same weights.

Z.ai officially supports four inference stacks — SGLang, vLLM, TokenSpeed, and KTransformers — and the zai-org/GLM-5 repository carries the cookbook for each. That is the authoritative place for exact flags; a hybrid-attention MoE launch configuration is not something to guess at. The general shape with vLLM:

vllm serve zai-org/GLM-5.3-Flash \
  --tensor-parallel-size 8 \
  --max-model-len 1048576

Three notes that will save you a debugging session:

1. Pin the framework version the cookbook names. The KDA-linear plus NoPE-sparse-MLA stack is new; community discussion around launch centred on vLLM v0.28.0 and whether specific pull requests were required.
2. --max-model-len 1048576 is aspirational on small hardware. The full window needs KV cache headroom on top of the 328 GB of weights. Start much lower and raise it once the model serves at all.
3. The FP8 release is the reference, not a quantization. You are not trading quality for size by using it — this is the build Z.ai benchmarked.

Community Quantizations (Not Official)

The model card notes 22 quantized variants, and community GGUF repositories bring the model within reach of llama.cpp, Ollama, LM Studio, and Jan. These are the only realistic path onto consumer or small-server hardware.

They come with a caveat most download guides omit: every published benchmark for this model was run at full FP8 precision. A 4-bit quantization of an architecture whose long-context behaviour already depends on IndexPool compression is meaningfully a different model, and nobody has published the quality delta. Use quants freely for experimentation; do not assume the 84.3 Terminal-Bench number transfers.

If you would rather evaluate the model's actual output before pricing hardware, the hosted path costs nothing to try — run GLM 5.3 Flash on glm5.app and decide whether the quality justifies the infrastructure conversation at all.

How the Parameter Profile Compares

The differentiator most write-ups miss: a higher sparsity ratio is not automatically better. DeepSeek V4 Flash is sparser (21.8:1) and correspondingly faster — 119.4 output tokens/second against GLM's 50.2. GLM's less aggressive ratio buys more active capacity per token, which shows up as a higher independent intelligence score (57 vs 52 on Artificial Analysis's index).

That is the actual trade the two labs made, and it is legible directly from the parameter counts: DeepSeek optimised the ratio for throughput; Z.ai optimised it for capability per dollar. Neither is wrong. Which you want depends on whether your bottleneck is wall-clock time or answer quality.

Practical Implications

Sizing a self-host: budget against 320B / ~328 GB, not 18B. Multi-node, or quantize and accept an unmeasured quality delta.

Estimating latency: the 18B active count sets a floor, but MoE routing overhead and the bandwidth needed to reach 320B of weights put real-world throughput below what an 18B dense model would give you. Plan with the measured 50.2 t/s.

Comparing against dense models: a 320B-A18B MoE is not "like a 320B dense model." Treat it as roughly 18B-class compute with substantially better-than-18B-class quality, because the total parameter pool stores far more knowledge than the active slice uses at any moment.

Deciding hosted vs. self-hosted: the MIT license makes self-hosting genuinely free, and 328 GB makes it genuinely expensive. At $0.15 per 1M input tokens hosted, the crossover point where owning hardware beats renting tokens is far higher than most teams assume. Open weights are valuable for sovereignty, air-gapping, fine-tuning, and reproducibility — rarely for cost alone at this price. Run the arithmetic before you buy anything, and test the model itself first, since a capability mismatch makes the whole hardware question moot.

Verifying You Have the Right Model

Quick checklist for anyone auditing a deployment:

• Repo ID is zai-org/GLM-5.3-Flash (or -BF16). Anything else — including every GGUF repo — is community-maintained.
• License file in the weights repo says MIT.
• Config should reflect 45 layers and 288 experts with 8 routed per token.
• Precision is FP8 for the reference release.
• Code reference is zai-org/GLM-5 on GitHub, not a GLM-5.3-Flash repo.

If a repository fails any of those checks, it is a fork or a quantization, and its behaviour may differ from the published benchmarks.

Frequently Asked Questions

How many parameters does GLM 5.3 Flash have? 320 billion total, 18 billion active per token. It is a Mixture-of-Experts model, so the two numbers govern different resources: 320B sets your memory requirement, 18B sets your compute cost.

How big is GLM 5.3 Flash on disk? Roughly 328 GB for the native FP8 release, based on Hugging Face file-size readings reported by users on NVIDIA's developer forums. The BF16 variant is substantially larger. Community 4-bit quantizations are much smaller but have not been benchmarked against the official results.

Where are the weights? zai-org/GLM-5.3-Flash on Hugging Face for FP8, zai-org/GLM-5.3-Flash-BF16 for BF16, and ZhipuAI/GLM-5.3-Flash on ModelScope as a mirror.

Is there a GLM 5.3 Flash GitHub repo? No dedicated one. The code, inference cookbooks, and architecture notes live in zai-org/GLM-5, which is Apache-2.0 while the weights themselves are MIT.

How many experts does it have? 288 experts, with 8 routed per token across 45 layers.

Is 18B active parameters enough for serious work? The independent evidence says yes for this architecture: Artificial Analysis scores it 57 on its Intelligence Index against a ~27 median for open-weight models of similar size. The 320B total pool stores far more than any single token's 18B slice uses, which is precisely the point of MoE.

Can I fine-tune it commercially? Yes. MIT permits fine-tuning, commercial deployment, and redistribution of your modified weights with no revenue threshold and no obligation to open-source your changes.

What is mHC? Manifold-Constrained Hyper-Connections — a structural technique Z.ai credits with halving both active parameters and layer count versus GLM-4.5 at a comparable total parameter count. It is the scaling-efficiency method that makes the 320B/18B split practical.

Sources

• zai-org/GLM-5.3-Flash — Hugging Face — parameter counts, mHC, hybrid attention, MIT license, quantization availability.
• zai-org/GLM-5 — GitHub — official architecture description, FP8 and BF16 variants, inference recipes for SGLang/vLLM/TokenSpeed/KTransformers.
• Artificial Analysis — GLM-5.3-Flash — independent Intelligence Index and throughput measurements.
• GLM-5.3-Flash weights released (Ox Alpha) — NVIDIA Developer Forums — community file-size and hardware-fit reports.

Architecture figures verified August 27, 2026. On-disk sizes are community-measured from repository file listings rather than vendor specifications; confirm current file sizes and the cookbook's pinned framework versions on the official repos before provisioning hardware.