How Much VRAM Does GLM 5.3 Need?
The short answer, now that the weights are public: 258 GB at 2-bit, 473 GB at 4-bit, and 1.51 TB if you want the model as the lab trained it. Z.ai released GLM 5.3 in late August 2026 (Artificial Analysis dated the API evaluation to August 18, the repo was created August 25, and the weights page was updated on August 28), and it is a 753-billion-parameter Mixture-of-Experts model with a 1M context window.
The interesting number is not any of those. It is the one next to it. On Artificial Analysis's Intelligence Index, GLM 5.3 scores 45 on index version 4.3.2 (read October 15, 2026), one point ahead of Kimi K3 at 44, a model with 2.8 trillion parameters. A point ahead on a third of the memory: Kimi K3 has 3.7 times as many parameters and needs 3.3 times as much memory at the same quantization.
That is what this page is about: the GLM 5.3 VRAM requirements at every quantization tier, sized from the files Unsloth and NVIDIA actually published, and what the gap between 753B and 2.8T means for the hardware you would need to buy.
GLM 5.3 VRAM Requirements at a Glance
Every figure below comes from our VRAM calculator at 8,192 tokens of context with an FP16 KV cache on llama.cpp, re-run on October 15, 2026. The weights term is the real file: Unsloth's GGUF for each rung, with the UD-XL builds standing in for the k-quant names. These are total memory needed, weights plus cache plus runtime overhead, converted to decimal GB. The calculator itself displays GiB, so it shows 440.6 where this table says 473 GB for the same configuration.
| Quantization | Memory needed | What it takes |
|---|---|---|
| FP16 / BF16 | 1,524 GB | 4x Instinct MI430X 432GB, 82% used |
| Q8_0 | 810 GB | 2x Instinct MI430X 432GB, 87% used |
| Q6_K | 692 GB | 2x Instinct MI430X 432GB, 75% used |
| Q5_K_M | 569 GB | 2x Instinct MI430X 432GB, 61% used |
| Q4_K_M | 473 GB | 2x B300 288GB, 76% used |
| Q3_K_M | 348 GB | one Instinct MI430X 432GB, 75% used |
| Q2_K | 258 GB | one B300 288GB, 83% used |
Those are all-in-VRAM figures, which is a different question from what you can actually run. Keep reading, because the answer to the second question is a lot friendlier than the first.
The Checkpoint Z.ai Ships Is FP8, and the Config Says Otherwise
This one costs people a download if they miss it.
zai-org/GLM-5.3 is 755.62 GB across 141 shards, carrying 118,629 tensors. config.json in that same repo declares "dtype": "bfloat16". Those two facts cannot both describe the same file: 755 GB for 753B parameters is one byte per parameter, not two, and the extra tensor count is the FP8 scale factors sitting alongside each quantized weight.
The genuine BF16 weights are in a separate repository. zai-org/GLM-5.3-BF16 measures 1,506,659,919,872 bytes across 282 shards with 59,585 tensors, which divides cleanly by two bytes per parameter into 753.33 billion.
So the default repo is the FP8 build. If you want BF16, ask for it by name.
What It Actually Takes to Run GLM 5.3
Here is where the all-in-VRAM table above stops being the whole story.
Unsloth publishes a GLM 5.3 guide with a planning table (figures read on October 15, 2026, and guide figures move: the page's earlier fit claim for a 24 GB card is gone from the current guide), and its unit is total memory, system RAM and VRAM together. Beside it, the files they shipped and what our engine adds on top of each file:
| Tier | Unsloth's planning figure | Unsloth's file | Our engine, total at 8K |
|---|---|---|---|
| 1-bit | 223 GB | 216.72 to 228.49 GB | not modelled |
| 2-bit | 245 GB | 238.58 GB (IQ2_M), 253.88 GB (Q2_K_XL) | 258 GB |
| 3-bit | 290 to 360 GB | 342.97 GB | 348 GB |
| 4-bit | 372 to 475 GB | 467.29 GB | 473 GB |
| 6-bit | 570 GB | 684.37 GB | 692 GB |
| 8-bit | 810 GB | 801.36 GB | 810 GB |
Two things stand out. Our totals sit 1.1 to 1.4 percent above the file at every rung, which is the cache, the compute buffers and the backend overhead, and it is the only thing our number adds to the file. And Unsloth's 6-bit planning figure is 114 GB below its own 6-bit file: 570 GB is the neighbourhood of the 5-bit build (562.47 GB), while UD-Q6_K_XL weighs 684.37 GB. If you are budgeting for the 6-bit build, budget from the file.
Their recommended tier is the 2-bit dynamic quant, UD-IQ2_M, and their guide says it works well on 256 GB RAM devices such as two DGX Sparks or a Mac Studio. The walk-through for running it in llama.cpp asks for at least 245 GB. Because the table counts RAM and VRAM together, a card does not have to hold the whole file. That is the same trick that made a 2.8T model reachable when Kimi K3's 1-bit build landed. The mechanism is MoE offload: only a handful of experts are active per token, so the inactive ones can live in system RAM and be pulled across as needed. Our llama.cpp flags guide covers the -ncmoe and -cmoe switches that do it, and Unsloth's own app offloads to RAM automatically.
What you trade is speed. Offload moves the bottleneck from the card's memory bandwidth to the PCIe bus and your DDR, and no formula on this site models that path. For a different MoE, Qwen3.8 Flash-Next, the runs on our tokens per second page that keep experts in system RAM report 20 to 22 tok/s. We have no GLM 5.3 offload run to show you, so treat that as the shape of the trade rather than a forecast.
What You Can Download Today
File sizes below were read from the Hugging Face tree on October 15, 2026.
unsloth/GLM-5.3-GGUF now carries twelve builds, and these are the shipped file sizes rather than anybody's estimate. The last column is the rung each one feeds in the calculator.
| Build | Shards | File size | Calculator rung |
|---|---|---|---|
| UD-IQ1_S | 6 | 216.72 GB | not offered |
| UD-IQ1_M | 6 | 228.49 GB | not offered |
| UD-IQ2_M | 6 | 238.58 GB | not offered |
| UD-Q2_K_XL | 7 | 253.88 GB | Q2_K |
| UD-IQ3_XXS | 7 | 281.69 GB | not offered |
| UD-Q3_K_XL | 9 | 342.97 GB | Q3_K_M |
| UD-IQ4_XS | 9 | 365.31 GB | not offered |
| UD-Q4_K_XL | 11 | 467.29 GB | Q4_K_M |
| UD-Q5_K_XL | 13 | 562.47 GB | Q5_K_M |
| UD-Q6_K_XL | 16 | 684.37 GB | Q6_K |
| Q8_0 | 17 | 801.36 GB | Q8_0 |
| BF16 | 33 | 1,507.99 GB | FP16 |
Two files at nominally the same bit depth are not the same file. UD-Q3_K_XL is a Dynamic build: the XL suffix means the layers that matter most are held at higher precision than a uniform Q3 would use, so it comes out at 342.97 GB. When this page first went up on August 28, our calculator estimated that rung from a formula and ran 8 percent light against the real file, with 2 to 3 percent on the other two mainstream rungs. The calculator now reads the file sizes directly, which is why the totals above carry only the cache and overhead on top.
Unsloth's guide puts the 2-bit build at 239 GB and says dynamic 2-bit keeps about 81 percent accuracy while being 83 percent smaller. That 239 GB figure is UD-IQ2_M, which is in the repository at 238.58 GB. UD-Q2_K_XL at 253.88 GB is the next one up and the one our Q2_K rung is sized from.
NVFP4 comes from three publishers. NVIDIA's own nvidia/GLM-5.3-NVFP4 is 464.14 GB across 50 shards, and its model card lists Blackwell as the supported hardware with a B300 as the test machine. incoai/GLM-5.3-NVFP4 and RadixArk/GLM-5.3-NVFP4 are community conversions whose safetensors indexes both read 464,795,267,072 bytes, the same payload split into 87 and 47 shards, and their files come to 464.82 GB. At 8K of context the calculator puts the NVIDIA build at 470 GB total. NVFP4 executes natively on Blackwell tensor cores. On anything older it is the wrong file to download.
So the routes that exist right now, by download size: the 1-bit builds at 217 to 228 GB, the 2-bit builds at 239 to 254 GB, the 3-bit at 343 GB, the 4-bit at 467 GB, and NVFP4 at 464 GB for Blackwell hardware. Leave headroom above the file size for the cache and the runtime, which is what the table at the top of this page counts and the file sizes do not.
If you have 256 GB of unified memory on Apple silicon, the Mac checker handles that case, because macOS hands the GPU a share of one pool rather than a fixed allocation and the share is not published as a formula.
753B for 2.8T Intelligence
Artificial Analysis lists GLM 5.3 as released on August 18, 2026, ten days before the weights existed, while it was reachable only through Z.ai's API. The figures below are from its Intelligence Index version 4.3.2, read on October 15, 2026.
| GLM 5.3 | Kimi K3 | Claude Opus 4.8 | |
|---|---|---|---|
| Intelligence Index v4.3.2 | 45 | 44 | 42 |
| Total parameters | 753B | 2,800B | not published |
| Q4_K_M at 8K | 473 GB | 1,578 GB | not downloadable |
| As the lab ships it | 756 GB, FP8 | 1,561 GB, MXFP4 | not shipped |
One point ahead of Kimi K3 on a third of the memory, and three points ahead of Claude Opus 4.8, a model you cannot run on your hardware at any price.
A note on the scores. When this page first went up, Artificial Analysis showed 60 for GLM 5.3 and for Kimi K3 on index version 4.1.1. On version 4.3.2 the same two models read 45 and 44. That is a re-base of the index, not a model getting worse, so compare scores only within one version. The same re-base moved Claude Opus 4.8 from first to third: it read 61.4 on version 4.1.1, ahead of both open models, and reads 42 on version 4.3.2, behind both. The ordering changed with the index version, not with the models.
The argument for paying attention to this release survives the re-base. Parameter counts have been a poor proxy for capability for a while, and this is a clean demonstration: two open models, both sizes published, both measured by the same people on the same index, landing a point apart with a 2-trillion-parameter gap between them.
Z.ai's published table goes further than the index does. On the 16 rows in their model card, GLM 5.3 beats Claude Opus 4.8 on 13, including Terminal Bench 3.0 at 28.3 against 21.1, FrontierSWE at 78.1 against 66.5, and GDPval-AA v2 at 1769 against 1588. Opus 4.8 takes NL2Repo, SWE-Marathon and Toolathlon Verified. Those are Z.ai's figures, run with the harnesses and settings documented in their footnotes.
The Architecture, and Why the Context Window Is Cheap
Z.ai's first line about GLM 5.3 is that it uses the same base model as GLM 5.2, with every gain coming from post-training. The config bears that out exactly, which is why our calculator entry for it is geometrically identical to the 5.2 one:
- 78 layers, hidden size 6,144, 64 attention heads at head dim 192
- MLA compressed KV cache: a 512-wide latent plus a 64-wide rope key, so 576 per token per layer instead of the 12,288 a naive 64-head cache would want
- A sparse attention indexer at head dim 128, and
indexer_typesshows only 21 of the 78 layers store their own indexer keys. The other 57 share - 256 routed experts plus 1 shared, 8 routed per token, with the first 3 layers left dense
- 1,048,576 token native context, vocabulary 154,880, one MTP layer
The MLA compression is why the 1M window is not the problem you would expect. The weights are the wall here, not the cache.
What Changed Since GLM 5.2
Two things, and only one of them is in the architecture.
The licence is not MIT. GLM 5.2 shipped MIT. GLM 5.3 ships under license: other with license_name: glm-5.3, a custom licence carrying Z.ai's own terms. Commercial users check this first, so it is worth knowing before a 756 GB download starts.
The default repository is FP8, as covered above. GLM 5.2's default was not.
Speed, and a Figure That Disagrees With Itself
Artificial Analysis measures GLM 5.3 at 65.6 output tokens per second with a 3.25 second time to first token, on Z.ai's hosted API rather than anything local.
Z.ai's own model card cites Artificial Analysis for a different number. In the ExploitGym footnote, where they rescale time budgets by throughput, they quote 115 tok/s for GLM 5.3, 40 for Kimi K3 and 47 for Qwen3.8 Max. That is about 1.75 times what Artificial Analysis publishes on its own page for the model, and we cannot reconcile the two: it could be a different provider, a different measurement window, or the Flash model. Treat 65.6 as the citable figure and read the ExploitGym results knowing their clock was set by the other one.
The verbosity number matters more than either. Running the Intelligence Index, GLM 5.3 emitted 210 million output tokens against a 130 million median. Artificial Analysis calls it very verbose, and for anyone sizing a machine that is the figure with teeth: a model that emits 1.6 times the median tokens at 65.6 tok/s is not fast, whatever its throughput says. Note also that reasoning_effort defaults to max on this model unless you pass low or high explicitly.
Frequently Asked Questions
How much VRAM does GLM 5.3 need?
473 GB at Q4_K_M with 8K of context, and 258 GB at Q2_K, if the whole model sits in VRAM. With MoE offload the practical floor is lower: Unsloth plans in RAM plus VRAM together and puts its 2-bit build at 245 GB of total memory.
Can I run GLM 5.3 on a single GPU?
Not entirely in VRAM on a consumer card. The smallest single-card fit in our catalogue is one 288 GB B300 at Q2_K, 83% used, and Q4_K_M takes two of them. With offload, a smaller card plus roughly 245 GB of total memory is the route Unsloth's table describes for the 2-bit build.
How many parameters does GLM 5.3 have?
753 billion total, measured from the BF16 checkpoint rather than taken from an announcement. Z.ai does not publish an active-parameter count, and the config shows 8 routed experts plus 1 shared per token out of 256.
Is GLM 5.3 better than GLM 5.3 Flash?
They are different models, not tiers of one. Flash is listed as 320B with 18B active in our catalogue and scores 42 on the Intelligence Index; the full model is 753B and scores 45, both on version 4.3.2. Flash is far easier to run, which our GLM 5.3 Flash page covers.
Is GLM 5.3 MIT licensed?
No. GLM 5.2 was MIT. GLM 5.3 ships under a custom licence named glm-5.3 in the model card.
What context length does GLM 5.3 support?
1,048,576 tokens natively, and the MLA compressed cache keeps that far cheaper than the layer count suggests.
Which backends run GLM 5.3?
Z.ai lists SGLang, vLLM, TokenSpeed, Transformers, KTransformers and Unsloth, plus vLLM-Ascend, xLLM and SGLang for Ascend NPU deployments.