Download GLM-5.2 FP8: Verify 141 Shards

Independent research — not an official Z.ai publication.Identity and provider disclosure

AI Infrastructure Editor

Editorial responsibility: GLM52.ai Editorial TeamPublished and editorially reviewed August 28, 2026

How we research and review Report a correction

Disclosed editorial pen name · AI-generated portrait

A dark cool-blue technical supply-chain diagram shows an immutable GLM-5.2 FP8 revision lock sending a long ordered train of shard tiles numbered 001, 002, 003, 004, 005, then 139, 140, and 141 into a bright cyan checksum and tensor-manifest comparison gate; the accepted teal path reaches a vault labeled as a pinned snapshot, while a lower red path marks shard 005 missing and shard 140 changed before a stop symbol blocks storage

Original editorial diagram. It describes the staging decision; it is not a Hugging Face screenshot, download receipt, security certification, model-load test, or promise that a verified snapshot will run on a particular server.

Downloading GLM-5.2 FP8 is an infrastructure change, not a casual model pull. The payload is roughly three quarters of a decimal terabyte, spans 141 weight containers, and may take hours even on a fast connection. If one shard is missing, truncated, or belongs to a different revision, a loader can fail late after consuming substantial storage and operator time.

The safe sequence is therefore pin → plan → dry-run → download → verify → promote. This page makes each transition observable. It does not decide whether your GPUs have enough HBM or whether FP8 quality is acceptable; the GLM-5.2 local hardware guide owns that earlier capacity decision. It also does not start a server. The handoff ends at a read-only, revision-addressed snapshot that a separate runtime can canary.

Our machine-readable FP8 manifest receipt records 12 public-source hashes, all 141 shard names and LFS SHA-256 values, three paginated Hub tree receipts, exact byte arithmetic, four theoretical transfer rows, and a deliberately incomplete local verification probe. The probe used huggingface_hub 1.29.0 in a task-owned temporary environment. It downloaded the index and config only, downloaded zero weight bytes, and correctly exited nonzero when the missing-file gate saw no shards.

In this guide

Know exactly what you are staging
Pin the repository revision first
Choose cache or local-directory layout
Budget disk with exact bytes
Estimate transfer time without promising it
Run a metadata-only dry run
Download into a revision-addressed directory
Verify remote checksums and missing files
Cross-check the tensor index locally
Resume safely after interruption
Keep the snapshot immutable at handoff
Separate integrity from runtime acceptance
Rent the canary only after the byte gate
Frequently asked questions
Sources and method

Know exactly what you are staging

The name GLM-5.2-FP8 identifies a repository, not one monolithic file. The pinned Hugging Face tree and safetensors index describe three related sizes:

Measured object at `ba978f7d…`	Exact bytes	Decimal size	Binary size	Why it differs
Tensors declared by the index	755,617,140,416	755.617 GB	703.723 GiB	Tensor payload only
141 safetensors files	755,632,050,320	755.632 GB	703.737 GiB	Includes safetensors headers and container data
Complete 150-file repository	755,663,676,164	755.664 GB	703.767 GiB	Adds index, tokenizer, config, template, README, and repository metadata
Largest single shard	5,366,353,992	5.366 GB	4.998 GiB	Relevant to temporary-write and retry headroom

The 14,909,904-byte gap between declared tensor bytes and shard-file bytes is not a discrepancy: a safetensors file contains metadata in addition to raw tensors. The complete repository adds another 31,625,844 bytes of non-shard files. Those small files are operationally important. In particular, model.safetensors.index.json maps 118,629 tensor names to the 141 shard filenames. config.json identifies the glm_moe_dsa architecture and the block-FP8 quantization contract.

Do not infer completeness from a directory size rounded to 756 GB. A missing 5.4 GB shard can hide inside that rounding. Count exact expected filenames, verify their checksums, and preserve the revision that supplied the manifest.

Pin the repository revision first

Branches are useful discovery names, but they can move. This audit resolved main to:

ba978f7d347eaf65d22f1a86833408afdb953541

Use the 40-character revision everywhere. The following variables make an operator choose both the immutable source and the destination explicitly:

export GLM52_FP8_REPO='zai-org/GLM-5.2-FP8'
export GLM52_FP8_REV='ba978f7d347eaf65d22f1a86833408afdb953541'
export GLM52_FP8_DIR='/srv/models/glm-5-2-fp8-ba978f7d347eaf65d22f1a86833408afdb953541'

These are example paths, not permission to overwrite an existing model directory. Resolve the intended mount, quota, owner, and backup policy first. Keep runtime logs, generated kernels, converted checkpoints, and evaluation outputs outside the immutable source directory so a later extra-file audit does not confuse inputs with products.

Pinning protects reproducibility; it does not make the revision trustworthy by itself. The repository owner can publish a bad commit, a dependency can parse safe bytes incorrectly, and a serving engine can contain a vulnerability. Revision identity is one control inside a larger software-supply-chain review.

Choose cache or local-directory layout

Hugging Face supports two useful layouts, and mixing their capacity assumptions causes avoidable surprises.

Layout	Command surface	Operational advantage	Capacity or audit concern
Shared Hub cache	`--cache-dir /mounted/cache` or `HF_HOME`	Reuses content-addressed blobs and revisions across clients	Snapshot entries can reference shared blobs; deleting a cache object may affect another revision
Explicit model directory	`--local-dir "$GLM52_FP8_DIR"`	Clear path for a serving runtime and human inspection	Creates `.cache/huggingface/` metadata inside the directory; a second copied directory may duplicate the payload

The official download guide recommends the cache by default and documents local_dir for a Git-like folder layout. A local directory keeps the repository structure and adds .cache/huggingface/ metadata so a rerun can avoid unchanged files. That hidden metadata is expected. It is also why this guide requires --fail-on-missing-files but does not blindly require --fail-on-extra-files: tool metadata and an operator’s own additions need a separate policy.

For a cluster, prefer one documented source of truth. If nodes consume a shared read-only filesystem, stage and verify once, then expose that same path. If each node needs a local copy, treat every copy as a separate transfer and verification event. A checksum on node A says nothing about node B’s disk.

Budget disk with exact bytes

The final repository is 755,663,676,164 bytes. Free space equal to that number is still an unsafe starting point: downloads create temporary state, filesystems allocate metadata, failed chunks may need replacement, and your runtime may create caches unless its output path is separated.

Our explicit editorial staging floor is:

755,663,676,164 repository bytes
+75,566,367,617 10% operator headroom
+ 5,366,353,992 one largest-shard retry slot
=836,596,397,773 bytes

That is 836.596 GB / 779.141 GiB. It is a planning floor, not an official Hugging Face or Z.ai requirement. It excludes Xet chunk-cache behavior, filesystem reservation, logs, engine compilation, quantization conversion, KV cache, and a second snapshot. If you download into a cache and then make a full non-reflink copy, the two payloads alone approach 1.511 TB before headroom.

Check the exact target filesystem, not a convenient parent on another mount:

df -B1 "$(dirname "$GLM52_FP8_DIR")"

Also verify quotas, inode limits, sparse-file policy, encryption overhead, and whether temporary Xet data lands on the same mount. df can show ample global space while a project quota or container overlay fills first.

Estimate transfer time without promising it

Line-rate arithmetic is useful for deciding whether to stage during a maintenance window. It is not a download benchmark.

Sustained link assumption	Payload-only theoretical time	What the estimate omits
100 Mb/s	16.79 hours	Protocol overhead, shared traffic, Hub limits, retries, disk writes, verification
500 Mb/s	3.36 hours	Same omissions
1 Gb/s	1.68 hours	Same omissions
10 Gb/s	0.17 hours	Storage and remote service may become the bottleneck

The formula is repository_bytes × 8 / bits_per_second. Real completion time is normally longer. A nominal 10 Gb/s interface does not establish an end-to-end 10 Gb/s path, and parallel workers cannot create remote capacity. Begin with bounded concurrency, observe disk and network behavior, then change one setting at a time.

Hugging Face now uses hf_xet for Xet-backed repositories. Its documentation explains that files are reconstructed from immutable chunks using content metadata. That can improve reuse, but operators should still verify the final repository revision and checksums rather than treating a chunk transfer as a complete model receipt.

Run a metadata-only dry run

Install or invoke a pinned huggingface_hub release in an environment you control. We tested 1.29.0, which was also the current PyPI release at the check time. The official CLI documents --revision, --local-dir, --dry-run, and --max-workers.

First run the exact production command with --dry-run:

hf download "$GLM52_FP8_REPO" \
  --revision "$GLM52_FP8_REV" \
  --local-dir "$GLM52_FP8_DIR" \
  --max-workers 2 \
  --dry-run

Review the resolved revision, file count, total bytes, first and last shard, and whether any files are already cached. The expected ordered boundaries are model-00001-of-00141.safetensors and model-00141-of-00141.safetensors. A different revision or shard total means the evidence on this page no longer describes your target; stop and create a new receipt instead of silently accepting drift.

Our isolated dry run used --max-workers 1 to minimize request concurrency. It enumerated all 141 shards and downloaded zero weight bytes. The repository is public and ungated in the checked model API, so the audit needed no token. If your environment uses authentication for higher rate limits, pass credentials through the tool’s supported secure environment or login store—never paste a token into a shell history, URL, article, or process argument.

Download into a revision-addressed directory

After the dry run and disk gate pass, remove only --dry-run from the reviewed command:

hf download "$GLM52_FP8_REPO" \
  --revision "$GLM52_FP8_REV" \
  --local-dir "$GLM52_FP8_DIR" \
  --max-workers 2

Do not add --force-download to a normal resume. It intentionally bypasses reuse and can turn a recoverable interruption into another 755.7 GB transfer. Keep the same repository, revision, destination, and tool version for the resume. Capture start and end time, tool version, host or node identity, filesystem, free-space readings, command exit code, and the final verification output.

The CLI returning zero means its requested operation completed. It does not prove that a later process did not change a file, that every required runtime file is understood by your serving engine, or that the checkpoint produces acceptable output. That is why download and verification remain separate gates.

Verify remote checksums and missing files

Run the official checksum verifier against the same repository, revision, and local directory:

hf cache verify "$GLM52_FP8_REPO" \
  --revision "$GLM52_FP8_REV" \
  --local-dir "$GLM52_FP8_DIR" \
  --fail-on-missing-files

The Hugging Face CLI reference says this command verifies checksums for one repository revision from cache or a local directory. --fail-on-missing-files turns an incomplete snapshot into a nonzero result. Preserve the complete output as an operational receipt. Do not convert warnings or a nonzero exit into a green deployment by filtering the log.

We tested the failure path without downloading weights. A temporary directory contained only config.json and model.safetensors.index.json; it contained zero .safetensors files. The pinned verification command exited 1, listed missing shards and tokenizer files, and reported verification failure. That establishes the local gate behavior for the tested CLI version. It does not claim a successful full 755.7 GB verification on this host.

If verification fails after a long transfer:

preserve the exact error and revision;
check whether the problem is missing, changed, unreadable, or remote access;
inspect disk health, quota, and filesystem errors;
rerun the same pinned download for resumable recovery;
rerun verification once the transfer reports completion;
never start the model from the failed directory.

Cross-check the tensor index locally

Remote checksums answer whether local files match the chosen remote revision. The tensor index supplies a second structural question: are all shard names referenced by weight_map present, and are there unexpected safetensors files?

Run this zero-dependency Node check inside the target environment:

node --input-type=module - "$GLM52_FP8_DIR" <<'NODE'
import fs from 'node:fs';
import path from 'node:path';

const modelDir = process.argv[2];
if (!modelDir) throw new Error('Pass the model directory as argv[2].');

const indexPath = path.join(modelDir, 'model.safetensors.index.json');
const index = JSON.parse(fs.readFileSync(indexPath, 'utf8'));
const expected = new Set(Object.values(index.weight_map));
const actual = new Set(
  fs.readdirSync(modelDir).filter((name) => name.endsWith('.safetensors')),
);
const missing = [...expected].filter((name) => !actual.has(name)).sort();
const extra = [...actual].filter((name) => !expected.has(name)).sort();

console.log(JSON.stringify({
  tensorNames: Object.keys(index.weight_map).length,
  expectedShards: expected.size,
  actualShards: actual.size,
  missing,
  extra,
}, null, 2));

if (expected.size !== 141 || missing.length || extra.length) process.exit(1);
NODE

At the audited revision, the passing structural result is 118,629 tensor names, 141 expected shards, 141 actual shards, and empty missing and extra arrays. This script checks names, not file contents; keep the official checksum command as the integrity gate. The two checks catch different mistakes and should both pass.

For an additional revision receipt, record the pinned index SHA-256:

e0fe7f28c1f853d4824e4d796374e3dacf1fe470988773952c79b063768134bf

That value identifies the index bytes audited here. It does not replace the 141 remote file checksums preserved in the public receipt.

Resume safely after interruption

An interruption is expected at this scale. A safe resume preserves identity and avoids broad cleanup:

keep the same 40-character revision;
keep the same destination and Hugging Face metadata;
check whether the filesystem or quota caused the interruption;
rerun the same download command without --force-download;
verify after the tool reports completion;
quarantine the directory from serving until every gate is green.

Do not delete the entire shared Hub cache to repair one task. Other revisions or processes may own blobs in it. If a specific corrupted cache object must be removed, resolve the exact repository and revision with read-only cache tools, preview the scoped action, and follow your operator change policy. A global cache prune is not a substitute for understanding the failure.

If the revision itself changes during a long project, stage the new commit into a new revision-addressed directory. Never merge two revisions in place. Verify the candidate independently, run the runtime acceptance suite, then change a service pointer through a separate rollback-capable deployment.

Keep the snapshot immutable at handoff

After both verification gates pass, make the source directory read-only to the serving identity if your filesystem and deployment model support that policy. The runtime should write logs, compiled kernels, telemetry, downloads, and temporary files elsewhere. Record this handoff tuple:

Field	Required receipt
Repository	`zai-org/GLM-5.2-FP8`
Revision	Full 40-character commit
Local path	Revision-addressed absolute path
Download tool	Exact `huggingface_hub` version
Payload	Exact file and byte count from dry run
Integrity	Passing `hf cache verify` output and exit code
Structure	Passing 141-shard index comparison
Ownership	User/group and read/write boundary
Next gate	Serving image, GPU topology, model-load and output canary

The path alone is not enough. A generic /models/glm-5-2 directory can be silently repopulated later. The commit, receipts, and immutable path let an operator prove which bytes entered the next stage and roll back to an earlier known candidate without guessing.

Separate integrity from runtime acceptance

A verified snapshot answers: “Do these local files match this public Hub revision, and are the expected shards present?” It does not answer:

whether vLLM, SGLang, Transformers, or another engine supports the exact checkpoint and quantization metadata;
whether the selected GPU count, HBM, interconnect, disk bandwidth, and context allocation are sufficient;
whether the model produces correct prose, code, structured output, or tool calls for your workload;
whether the repository, dependencies, image, drivers, or model behavior meet your security policy;
whether the model is faster or cheaper than a hosted API.

The official model card links both vLLM and SGLang. The current SGLang cookbook calls FP8 the recommended deployment and describes supported hardware profiles; the vLLM recipe supplies a separate launch matrix. Treat those as the next source checks, not as proof produced by this download.

Begin runtime acceptance with a pinned serving image, the verified path, one short request, a conservative context limit, and a frozen prompt set. Record model-load errors, peak memory, time to first token, output tokens per second, finish reasons, reasoning/content separation, and tool-call validity. Increase context and concurrency independently. Snapshot integrity should remain fixed while runtime variables change.

Rent the canary only after the byte gate

Stage once, then validate on the intended topology

Use rented infrastructure only after the dry-run byte plan is approved. Confirm persistent-storage capacity, transfer and egress terms, exact accelerator count and interconnect, image digest, region, data-retention boundary, and current price before launch. Keep the verified snapshot separate from runtime outputs and delete only resources created for the canary.

Check current GPU and storage options on RunPod →

Affiliate disclosure: This is an affiliate link and a referral link. GLM52.ai may receive a commission or referral credit after qualifying usage at no added charge from us. A rental does not verify the GLM-5.2 FP8 revision, checkpoint bytes, Hub checksums, storage durability, GPU topology, serving image, model quality, privacy, security, price, or deletion. Confirm every live property and preserve your own receipts.

Renting before the manifest is understood can leave an expensive GPU node idle while 755.7 GB transfers or a missing shard is repaired. Storage can often be staged independently of accelerator time. The commercial decision is therefore downstream of the free revision, disk, dry-run, and checksum checks.

Frequently asked questions

How large is the official GLM-5.2 FP8 download?

At revision ba978f7d347eaf65d22f1a86833408afdb953541, the complete 150-file repository is 755,663,676,164 bytes (755.664 GB / 703.767 GiB). The 141 safetensors files account for 755,632,050,320 bytes. Plan additional space for temporary writes, filesystem behavior, retries, logs, and any second copy.

Why are there 141 safetensors files but 150 repository files?

The remaining files include the tensor index, configuration, tokenizer, generation settings, chat template, README, license or repository metadata. Serving requires more than raw weight containers. Download and verify the intended repository revision, not a hand-selected shard glob alone.

Can I download only the 141 shard files?

That is not the safe default. The runtime also needs the index and model, tokenizer, and generation metadata. Selective patterns can accidentally omit a new required file. Use a full pinned-repository dry run unless your deployment has an audited allowlist and an independent compatibility test.

Does `hf download` automatically verify every file?

The downloader uses content metadata and checks during transfer, but this workflow still runs hf cache verify as a distinct, recorded gate after the download. That makes missing or changed files visible at promotion time and avoids treating a transfer exit code as the complete deployment receipt.

Should I add `--fail-on-extra-files`?

Only with a deliberate local-directory policy. --local-dir creates .cache/huggingface/ metadata, and a runtime may add files if the boundary is not read-only. This guide fails on missing remote files and separately requires that the top-level safetensors set exactly matches the index. Keep runtime outputs outside the model directory before enforcing a broader extra-file gate.

Is the FP8 repository the same size as FP8 GPU memory use?

No. Repository bytes are a weight-storage measurement. GPU memory also includes runtime buffers, communication workspaces, graph capture, KV cache, allocator headroom, and concurrent sequences. The local hardware guide and the pinned engine recipe cover capacity; neither is replaced by this manifest.

Can I launch from `main` after recording the commit?

That defeats the pin. A branch can move between download, resume, verification, and restart. Pass the immutable revision to the download and verifier, retain a revision-addressed local path, and bind the runtime to that verified path.

Did GLM52.ai download and verify all 755.7 GB?

No. This audit fetched public metadata, enumerated the full pinned tree, ran a metadata-only CLI dry run, and deliberately verified an incomplete directory to confirm the failure gate. It downloaded zero model-weight bytes and made zero model or GPU calls. The published manifest provides exact expected data; every operator still has to complete and preserve their own full-snapshot receipt.

Sources and method

Primary and official sources checked on August 28, 2026:

The evidence collector used public HTTP GET requests with an identifiable user agent. It followed three official Hub tree pages at the immutable revision, hashed 12 public artifacts, compared the 141-file tree manifest with the tensor index, and calculated bytes and theoretical line-rate times. The CLI probe used uvx, a task-owned UV_CACHE_DIR, and a task-owned HF_HOME; the exact temporary directory was removed by an exit trap. Ordinary Docker access was unavailable and no sudo was used. No secret, model weight, model output, GPU measurement, provider price, or private response is present in the receipt.

One exact paid SerpAPI query returned an HTTP error. It was recorded as failed and was not retried, paginated, or sent to another engine; it changed no topic or content decision. The topic instead passed a 93-URL sitemap, 86-page content registry, and source-corpus intent audit. The existing local guide decides hardware fit; this page owns the narrower supply-chain task of pinning, transferring, verifying, and handing off one official FP8 snapshot.