The “30B-A3B” label on GLM-4.7-Flash makes it sound like an ordinary small-model deployment. The official BF16 checkpoint says otherwise: its safetensors total 62,444,175,504 bytes, or 62.444GB in decimal units. That leaves only 1.556GB against a nominal 64GB capacity before the inference runtime, KV cache, activations, workspaces or allocator fragmentation.
The useful boundary
- 64GB: Flash BF16 leaves 1.556GB by file-size subtraction. Treat that as a transfer boundary, not a credible fully resident runtime promise.
- 80GB: Flash BF16 leaves 17.556GB before runtime allocations. This is the first common single-device class worth testing for the official artifact.
- 384GB: Full GLM-4.7 FP8 leaves only 21.936GB aggregate file-only margin.
- 768GB: Full GLM-4.7 BF16 leaves 51.319GB aggregate file-only margin.
The complete GLM-4.7 VRAM requirements guide shows every official byte total and maps the checkpoints from 48GB through 864GB.
Why active parameters do not settle the memory question
Z.ai describes Flash as a 30B-A3B mixture-of-experts model: about 30B total parameters and about 3B active per token. Routing fewer experts for each token can reduce compute, but it does not make the other expert weights disappear from a conventional resident deployment. The full checkpoint still has to be available in accelerator memory, host memory or an explicit offload plan.
The full GLM-4.7 repositories make the scale difference even clearer. The official FP8 safetensors total 362.064GB; the BF16 files total 716.681GB. Four 80GB accelerators do not hold the FP8 files, and eight 80GB accelerators do not hold the BF16 files. Aggregate labels are also not automatic pools: the runtime must support the model and distribute viable shards while leaving per-device headroom.
The context limit is not a minimum-hardware promise
The official configs declare 202,752 maximum positions. That is an architecture ceiling, not evidence that the maximum live sequence fits beside the weights on a minimum-capacity system. KV cache grows with sequence length and concurrency. Batch, output length, cache precision and implementation details matter too.
Before buying hardware, pin the exact repository and revision, runtime build, tensor or expert-parallel plan, device topology, intended context, batch and concurrency. Then measure peak memory on every device and report any CPU or storage offload separately. “Loaded successfully” is not a speed result.
What to do next
Plan multi-GPU placement before adding capacities together. Use the benchmark database for source-specific measurements, or build a reproducible GLM record if you have tested one of these checkpoints. Follow the RSS feed for future capacity guides and measured evidence.
Primary sources
Published October 25, 2026. File-size arithmetic is a capacity boundary, not an independent performance benchmark.