GLM-5.2 FP8 / deployment worksheet

703.74 GiB FP8. 8 × H200.

Q: How much GPU memory does GLM-5.2 need?

The official GLM-5.2-FP8 repository contains 141 safetensors files totaling 703.74 GiB before KV cache and runtime workspace. The current vLLM recipe uses one 8-GPU H200 or H20 node for the standard FP8 deployment and 8 B200 GPUs with FP8 KV cache for the full one-million-token context.

Q: How many H200 GPUs does GLM-5.2 need?

The current vLLM GLM-5.2 recipe specifies tensor parallel size eight and lists 8 H200 GPUs as the standard single-node FP8 deployment. A simple artifact-plus-20-percent-reserve worksheet targets 844.49 GiB before KV cache, within eight 141 GB-class H200 devices at 90 percent usable memory.

Q: What hardware supports the full GLM-5.2 one-million-token context?

The current vLLM recipe identifies 8 B200 GPUs with FP8 KV cache as the full one-million-token configuration. It also says max-num-seqs is the main concurrency control and should be reduced if representative long prompts run out of memory.

Q: How large are the GLM-5.2 BF16 and FP8 checkpoints?

The official BF16 repository has 282 safetensors files totaling 1,403.19 GiB. The official FP8 repository has 141 safetensors files totaling 703.74 GiB. Those are downloadable artifact sizes, not complete serving-memory measurements.

Z.ai's official FP8 checkpoint spans 141 weight files. vLLM's supported single-node baseline uses eight H200-class GPUs; its full 1M-context baseline moves to eight B200s with FP8 KV cache.

Open the editable 8 × H200 plan →

Quick answer / supported tiers

Eight 80 GiB GPUs are short. Eight H200s are the practical FP8 baseline.

The first card proves the weight-floor failure. The next two pair the exact artifact with vLLM's supported NVIDIA topologies. The BF16 card makes the multi-node boundary explicit. Calculator targets exclude KV cache unless stated.

FP8 artifact · 8 × 80 GiB SHORT 127.74 GiB 576 GiB usable vs 703.74 GiB files → Standard FP8 · 8 × H200 844.49 GiB floor 703.74 artifact + 20% reserve; cache excluded → Full 1M recipe · 8 × B200 FP8 KV required vLLM-supported full-context topology; tune concurrency → BF16 floor · 16 × H200 1,683.83 GiB 1,403.19 artifact + 20% reserve; cache excluded →

Artifact vs deployment

The checkpoint proves the floor. The serving recipe proves the topology.

The official repositories expose the bytes to load. Z.ai's model card and configuration establish the 1M window and architecture. vLLM's maintained recipe establishes supported hardware and runtime flags.

Swipe the matrix horizontally →

Input	Official value	What it changes	What it does not prove
FP8 artifact	703.74 GiB · 141 files	Resident-weight floor	KV cache or runtime workspace
BF16 artifact	1,403.19 GiB · 282 files	Multi-node weight floor	Throughput or interconnect cost
Standard FP8	8 × H200 · TP=8	Supported single-node baseline	Full 1M context at every concurrency
Full context	1,048,576 tokens	Native context boundary	Concurrent-sequence fit
Full 1M NVIDIA recipe	8 × B200 · FP8 KV	Supported full-window topology	Your traffic-shaped capacity
Sparse architecture	753.38B checkpoint parameters	Artifact and routing scale	All parameters active per token

Artifact totals were calculated from the official Hugging Face safetensors file sizes on August 7, 2026. Hardware guidance follows the vLLM GLM-5.2 recipe updated July 12, 2026. Recheck both sources if either release changes.

Read the estimate

Eight H100s are not enough.
Their 576 GiB usable planning capacity is below the FP8 files alone.

H200 is the standard node.
The current vLLM recipe uses tensor parallel size eight for FP8.

B200 unlocks the 1M recipe.
FP8 KV cache and concurrency tuning remain part of the serving plan.

Context and cache boundary

One million tokens is a runtime allocation, not a checkpoint property.

Official configuration
78 layers · 1,048,576 max positions

Compressed attention inputs
512 KV LoRA rank · 64 RoPE dimensions

Standard H200 recipe
FP8 KV · TP=8 · MTP=5

The calculator cards deliberately keep cache out of the numeric floor because GLM-5.2 uses sparse, compressed attention rather than a portable dense K/V-head formula. For full context, follow the runtime's reported KV capacity and tune max-num-seqs against representative long prompts.

Primary-source inputs

Use the official files. Then prove the runtime.

Checkpoint size, parameter metadata, context support, configuration, and release claims come from Z.ai's official repositories. Hardware and serving flags come from vLLM's maintained GLM-5.2 recipe—not a third-party VRAM table.

Open the GPU memory calculator → Compare DeepSeek V4 Flash hardware → Find models for smaller GPU budgets → Official GLM-5.2 model card → Official GLM-5.2 configuration → Official FP8 checkpoint inventory → Official BF16 checkpoint inventory → Official vLLM deployment recipe → GLM-5 technical report →

How much GPU memory does GLM-5.2 need?

The official FP8 artifact is 703.74 GiB before cache and runtime workspace. vLLM's current standard recipe uses one 8-GPU H200 or H20 node; the full 1M NVIDIA recipe uses eight B200s with FP8 KV cache.

Can GLM-5.2 run on eight 80 GB GPUs?

Not as a straightforward full-checkpoint FP8 deployment. Eight 80 GiB-class GPUs expose 576 GiB at 90% usable memory—127.74 GiB less than the official artifact before cache or runtime reserve.

How many H200 GPUs does GLM-5.2 need?

The maintained vLLM recipe specifies eight H200 GPUs and tensor parallel size eight for the standard FP8 deployment. The editable worksheet adds a transparent 20% runtime reserve while leaving cache out of the numeric floor.

What hardware supports the full GLM-5.2 one-million-token context?

vLLM's current NVIDIA recipe identifies eight B200 GPUs with FP8 KV cache. It treats max-num-seqs as the main fit control, so representative concurrent long prompts still need an OOM smoke test.

How large are the GLM-5.2 BF16 and FP8 checkpoints?

The official BF16 repository totals 1,403.19 GiB across 282 safetensors files. The official FP8 repository totals 703.74 GiB across 141 files. Neither total includes the full serving allocation.