GLM-4.7 and GLM-4.7-Flash VRAM Requirements

GLM-4.7 comes in hardware classes that are easy to confuse. The official GLM-4.7-Flash BF16 checkpoint is 62.444GB, while the full GLM-4.7 model is 362.064GB in the official FP8 repository and 716.681GB in BF16. Those are checkpoint-file totals before KV cache, framework allocations, temporary buffers, batch or concurrency.

Use the LLM VRAM calculator and hardware recommender for a first-pass estimate. For these MoE checkpoints, plan from the exact artifact, per-device placement and workload—not just the active-parameter label.

Official checkpoint facts

Z.ai describes Flash as a 30B-A3B mixture-of-experts model: roughly 30B total parameters, with about 3B active per token. The full GLM-4.7 repositories report about 358.338B parameters. MoE routing reduces the parameters used in each token’s computation, but a normal resident deployment still needs the full checkpoint available across accelerator memory, host memory or an explicitly documented offload plan.

File-only capacity boundaries

Why 64GB is a trap for GLM-4.7-Flash

The 62.444GB checkpoint technically fits inside a nominal 64GB number by decimal subtraction, but only 1.556GB remains. The runtime still needs memory for weights that may be represented differently after loading, KV cache, activations, workspaces and allocator fragmentation. Capacity is also often marketed in decimal units while software reports binary GiB. Treat 64GB as a file-transfer boundary, not a responsible promise of a fully resident inference setup.

An 80GB-class accelerator leaves 17.556GB before runtime allocations and is the first common single-device class worth testing for the official Flash BF16 artifact. Whether the desired context, batch and speed fit must still be measured. A quantized community artifact may fit smaller hardware, but its repository, quantization method and measured quality belong in a separate claim.

Context can dominate the remaining margin

All three official configs declare max_position_embeddings: 202752. That is an architecture limit, not proof that 202,752 tokens fit on the minimum weight-capacity configuration. KV-cache memory grows with live sequence length and concurrency; long generations also require output headroom. Test the actual input length, output budget, batch, cache precision and number of simultaneous users.

See the KV-cache guide for the hidden memory term and the multi-GPU guide for tensor parallelism, placement and interconnect caveats.

Deployment checklist

1. Name the exact repository and revision: Flash BF16, full FP8 and full BF16 differ by hundreds of gigabytes.
2. Record every device: exact model, exposed memory and topology.
3. Choose supported software: Z.ai’s model cards list vLLM, SGLang and Transformers instructions, including development or nightly requirements at publication time.
4. Define placement: tensor, pipeline or expert parallelism; list CPU, host-memory or storage offload separately.
5. Describe the workload: prompt length, output length, batch, concurrency and cache precision.
6. Measure per-device peaks: aggregate memory can hide one overloaded shard.
7. Report speed and memory separately: loading successfully is not the same as a useful tokens-per-second result.

Sources

1. Official GLM-4.7-Flash model card
2. Official GLM-4.7-FP8 model card
3. Official GLM-4.7 model card
4. Official Flash repository API with blob sizes
5. Official FP8 repository API with blob sizes
6. Official BF16 repository API with blob sizes

Reviewed October 25, 2026. File-size arithmetic is not an independent benchmark. Vendor architecture and capability statements are labeled as Z.ai claims.

Choosing hardware for the official Flash BF16 checkpoint? The GLM-4.7-Flash hardware guide maps the exact 62.444GB files onto A100, H100, RTX PRO 6000, H200, B200 and B300 paths without turning capacity into a speed ranking.