GLM-5.2 to GLM-5.3 Checkpoint Migration

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 29, 2026

How we research and review Report a correction

Disclosed editorial pen name · AI-generated portrait

A cold-blue technical migration diagram shows matching GLM-5.2 and GLM-5.3 storage lattices with the same orderly shard geometry but different fingerprint symbols, a central inspection gate, green reuse paths for tokenizer and tensor index artifacts, amber review gates for the chat template, license, and runtime, and a dashed rollback rail leading back to the preserved GLM-5.2 snapshot

Original editorial diagram. It explains the artifact decision; it is not a Hugging Face screenshot, weight download, GPU run, model output, benchmark, or proof that either checkpoint loaded successfully.

The safe GLM-5.2 to GLM-5.3 checkpoint migration is a side-by-side replacement, not a model-name edit. Four pinned artifacts are byte-identical: the tokenizer, tokenizer configuration, generation configuration, and tensor index. The architecture and FP8 configuration also match. Those similarities can reduce test design and cache duplication, but they do not make the checkpoints interchangeable.

Three contracts changed materially. Every weight shard has a new content identity. The chat template removes GLM-5.2’s disabled-thinking branch and adds new reasoning and tool-history behavior. The repository changes from MIT to a named GLM-5.3 license. The official vLLM recipe also raises its minimum from 0.23.0 to 0.28.0 and names Transformers 5.15.0.

Our machine-readable checkpoint audit hashes 24 official or upstream source snapshots and compares both complete repository trees at immutable revisions. It downloaded zero model-weight bytes, made zero model calls, started zero serving processes, used zero GPUs, and ran zero containers. The result proves a static artifact contract, not runtime or output parity.

Start from the five-gate verdict

Treat the migration as five independent admissions. A green artifact gate does not waive a red policy or runtime gate.

Gate	Pinned result	Migration action
Weight identity	141 paths and sizes match; 141 content hashes differ	Download the complete GLM-5.3 snapshot; never relabel or patch the GLM-5.2 weight files
Reusable metadata	Tokenizer, tokenizer config, generation config, and tensor index are byte-identical	Reuse test expectations and content-addressed cache bytes only after checking the pinned hashes
Prompt behavior	Chat-template hash and control flow differ	Replace rendered-prompt fixtures; remove disabled thinking and test low/high/max plus multi-turn tools
Permission	MIT tag becomes a named GLM-5.3 license	Review the actual deployment and distribution model before commercial use
Runtime	vLLM floor moves from 0.23.0 to 0.28.0	Build a new image, launch a separate endpoint, and pass a model-load and task canary

That verdict closes the weight gate left open by the earlier GLM-5.2 to GLM-5.3 API migration guide. The API page still owns hosted request fields and account admission. The GLM-5.2 vs GLM-5.3 comparison still owns quality, token-use, price, and task-class adoption. This page answers the different operator question: what must change before a pinned self-hosted checkpoint can move.

Pin both repositories

The audit used these immutable coordinates:

GLM-5.2 FP8 repository: zai-org/GLM-5.2-FP8
GLM-5.2 FP8 revision:   ba978f7d347eaf65d22f1a86833408afdb953541

GLM-5.3 FP8 repository: zai-org/GLM-5.3
GLM-5.3 FP8 revision:   935644c05e76fc198714f4cca449fd8b970ff6d7

The naming change matters. GLM-5.2 exposes FP8 through the suffixed GLM-5.2-FP8 repository. The current default GLM-5.3 repository is itself the native FP8 checkpoint; the official vLLM GLM-5.3 recipe identifies the BF16 variant separately. Do not infer precision from the absence of FP8 in the new repository name. The pinned config explicitly reports block FP8 with e4m3, dynamic activations, and a 128×128 weight block.

Use the revision in every download, launch, receipt, and rollback record. main is a moving branch. A model ID plus a date is not an artifact identity.

Read the complete manifest delta

The Hugging Face tree API exposes file paths, sizes, Git identities, and LFS content identities without downloading the weight payload. Summing those pinned trees gives:

Manifest receipt	GLM-5.2-FP8	GLM-5.3	Delta
Repository files	150	153	+3 evaluation YAML files
Repository bytes	755,663,676,164	755,663,688,511	+12,347 bytes
Numbered weight shards	141	141	0
Weight-shard bytes	755,632,050,320	755,632,050,320	0
Tensor names in index	118,629	118,629	0
Unique referenced shards	141	141	0

The near-identical repository size can be misleading. The 12,347-byte delta comes from non-weight metadata; it is not evidence that most weights can be reused. All 141 large files preserve their byte lengths while their content identities change. That is consistent with post-training changing tensor values without changing tensor shapes or serialization topology.

GLM-5.3 adds deep-swe.yaml, terminal-bench-2.1.yaml, and terminal-bench-3.0.yaml beneath .eval_results/. Those publisher evaluation receipts do not affect model loading and do not turn benchmark claims into an independent reproduction.

Reuse only four exact artifacts

Four components have identical SHA-256 values across the pinned repositories:

Exact match	What can be reused	What still needs verification
`tokenizer.json`	Vocabulary and tokenization fixture expectations	The serving stack must load the file from the intended snapshot or verified content-addressed cache
`tokenizer_config.json`	Max-length and special-token metadata	Rendered prompts still depend on the changed chat template
`generation_config.json`	Temperature 1, top-p 0.95, and token-ID defaults	Application overrides and stop behavior remain runtime-specific
`model.safetensors.index.json`	Tensor-to-shard topology	The index maps names to filenames, not filenames to trusted payload bytes

“Reusable” means the exact bytes can be deduplicated or the old fixture can be used as a comparison control. It does not mean copying four files into a mixed directory is a safe installation method. Download and verify the complete GLM-5.3 revision so its snapshot has one coherent provenance receipt.

This distinction is especially important for the tensor index. Its exact hash is identical because the tensor names and shard allocation did not move. The index contains no guarantee that the shard behind a filename has the old or new values. Verification must join the pinned repository revision, the index, the complete 141-file set, and each file’s content identity.

Never reuse the 141 weight payloads

Every common weight path follows the same sequence from model-00001-of-00141.safetensors through model-00141-of-00141.safetensors. Every corresponding pair has the same byte size. Every corresponding LFS SHA-256 is different.

That produces a simple fail-closed rule:

expected GLM-5.3 revision       = 935644c05e76fc198714f4cca449fd8b970ff6d7
observed numbered shard paths   = 141 contiguous paths
observed old shard identities   = 0 accepted as GLM-5.3
observed new shard identities   = 141 pinned GLM-5.3 identities
mixed old/new snapshot          = reject

Do not use filename equality, byte-size equality, modification time, or a successful directory scan as an integrity check. The GLM-5.2 FP8 download-verification guide shows the staging pattern: pin the revision, preserve the manifest, verify the complete local snapshot, and block the serving process until completeness and identity checks pass. Apply the same method to GLM-5.3 with its own revision and expected hashes.

The static audit intentionally avoided a 755.6 GB transfer. Its tree receipts prove what should exist upstream at the check time; your local receipt must prove what actually arrived on disk.

Keep architecture similarity in scope

Eighteen selected configuration fields are identical. Both repositories name GlmMoeDsaForCausalLM with model type glm_moe_dsa, 78 hidden layers, 64 attention heads, 64 KV heads, 256 routed experts, one shared expert, and eight active experts per token. Both report a 1,048,576-position limit, 154,880-token vocabulary, one next-token prediction layer, index top-k 2048, and the same block-FP8 scheme.

The only selected config delta is transformers_version: 5.12.0 becomes 5.15.0. The SGLang GLM-5.3 cookbook also describes the same base architecture with updated post-training.

Architecture similarity helps in three ways: tensor parallel size, DSA/MoE concepts, and the broad serving flag shape remain familiar; the raw FP8 weight capacity is unchanged; and the tokenizer/index control gives a clean way to isolate template and model-behavior deltas. It does not prove that an old engine build has the needed model code, kernels, parser behavior, or bug fixes.

Rebuild the chat-template contract

The tokenizer is unchanged, but the pinned chat template grows from 5,076 to 10,465 bytes and has a different hash. That is a behavioral change, not formatting noise.

Template behavior	GLM-5.2-FP8	GLM-5.3	Migration consequence
Disable thinking	`enable_thinking=false` branch exists	Flag absent; generation opens `<think>`	Remove non-thinking requests before cutover
Reasoning effort	Explicit `high`, otherwise `max`	`low`, `high`, or default `max`	Add low-effort fixtures and reject unsupported values
Multi-turn reasoning history	Conditional preservation	`clear_thinking` explicitly defaults false	Pass `clear_thinking=true` when prior reasoning must be cleared
Tool-result ordering	Basic tool-call serialization	Additional tool-call ID validation and reordering logic	Test parallel calls, duplicate/missing IDs, and result order

Do not compare raw user text alone. Snapshot the exact rendered token IDs for system, user, assistant, tool call, tool result, image-placeholder, and multi-turn fixtures. The tokenizer control should keep plain text tokenization stable; any rendered-prompt delta then points to template policy rather than a vocabulary change.

For chat, make the GLM-5.3 policy explicit:

{
  "chat_template_kwargs": {
    "reasoning_effort": "high",
    "clear_thinking": true
  }
}

That is an example policy, not a universal optimum. Use low, high, or max according to the task and validate output acceptance and token use. The separate GLM-5.2 chat-template audit remains the control for the old route.

Review the new license separately

The GLM-5.2-FP8 model card and repository use the MIT license. The pinned GLM-5.3 license is a named license under the license:other tag.

It grants broad rights to use, copy, modify, distribute, sublicense, sell, deploy, and fine-tune subject to its conditions. It also defines “Model as a Service” and says an operator in that business whose aggregate affiliate revenue exceeds USD 10 billion over a consecutive 12-month period must pass a Z.AI security review before commercial use. It includes copyright-notice, applicable-law, and warranty terms.

This is an artifact fact, not legal advice. Preserve the exact license hash beside the model revision and ask qualified counsel to assess it when the deployment, distribution, affiliate structure, or threshold could matter. Do not label GLM-5.3 as MIT merely because GLM-5.2 was MIT or because the technical config is nearly identical.

Build a new serving environment

The official GLM-5.2 vLLM recipe names 0.23.0 as its stable minimum. The current GLM-5.3 recipe requires vLLM 0.28.0 or newer and installs Transformers 5.15.0 or newer. Its standard FP8 example still uses tensor parallel 8, MTP, the glm45 reasoning parser, and the glm47 tool-call parser.

Build a separate environment instead of mutating the working control:

uv venv .venv-glm53
source .venv-glm53/bin/activate
uv pip install "vllm==0.28.0" --torch-backend=auto
uv pip install "transformers>=5.15.0"

Then begin with the publisher’s common FP8 shape, adapted to the pinned local snapshot and your tested context cap:

vllm serve zai-org/GLM-5.3 \
  --revision 935644c05e76fc198714f4cca449fd8b970ff6d7 \
  --kv-cache-dtype fp8 \
  --tensor-parallel-size 8 \
  --speculative-config.method mtp \
  --speculative-config.num_speculative_tokens 5 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --enable-auto-tool-choice \
  --max-model-len 131072 \
  --served-model-name glm-5.3-canary

Confirm every flag with vllm serve --help in the exact installed build. The official recipe documents 8×H200 or 8×H20 for the FP8 checkpoint and 8×B200 for a full 1M-context route. Those are publisher recipes, not a capacity result from this audit. Start below the maximum context and raise one variable at a time after startup and representative memory tests.

Stage two immutable snapshots

The two repository payloads total 1,511,327,364,675 bytes—about 1.511 TB or 1.375 TiB—before cache duplication, temporary transfers, logs, runtime files, and operational headroom. Nearly every byte belongs to distinct weight objects, so content-addressed storage cannot collapse the two models into one weight copy.

Plan separate paths:

/models/glm-5.2-fp8/ba978f7d347eaf65d22f1a86833408afdb953541/
/models/glm-5.3-fp8/935644c05e76fc198714f4cca449fd8b970ff6d7/
/receipts/glm-5.2-fp8-ba978f7.json
/receipts/glm-5.3-fp8-935644c.json

Each receipt should preserve repository ID, revision, complete path/size/hash manifest, download tool and version, start/end time, final directory bytes, verification result, serving image digest, engine arguments, and operator decision. Keep the directories read-only to the serving process after promotion.

Do not delete GLM-5.2 to make room before the GLM-5.3 canary passes. If storage cannot hold both complete snapshots plus headroom, acquire temporary capacity or postpone the cutover. Deleting the rollback to fund an unverified migration turns a reversible model change into a recovery event.

Run a bounded acceptance canary

Static parity narrows the test plan; it does not replace it. Use 20–50 frozen tasks sampled from the exact production classes you may migrate. Include short and long prompts, tool calls, parallel tool results, malformed tool IDs, multi-turn history, interrupted generations, structured output, and policy- denied actions.

Run in this order:

Verify both snapshots and record their immutable manifests.
Start the old GLM-5.2 endpoint from its unchanged image and rerun the control fixtures.
Start GLM-5.3 on a different port or internal service name with bounded context, concurrency, and no consequential tools.
Compare rendered token IDs, parser fields, stop reasons, output acceptance, memory, startup time, prefill/decode behavior, and task results.
Add tools behind allowlists and idempotency controls only after harmless tool fixtures pass.
Run one rollback drill before any production percentage moves.
Canary a small task class, not arbitrary global traffic, and stop on severe tool-policy or data-contract failure.

Define thresholds before seeing results. For example, require zero malformed or unauthorized tool executions, no missing accepted-answer content, no unexpected reasoning leakage into the final field, and an accepted-task rate that clears the old control. Speed or benchmark headlines cannot waive those gates.

Preserve an instant rollback

Rollback needs more than old weights. Preserve the complete GLM-5.2 serving identity: snapshot revision, image digest, engine and parser flags, environment, template fixtures, endpoint configuration, health checks, and last clean acceptance receipt.

Route through a stable internal alias:

glm-production  -> glm-5.2-stable
glm-canary      -> glm-5.3-candidate

Promotion changes the alias or a bounded traffic rule; it does not rewrite the old directory. On rollback, stop new admissions to the candidate, drain or quarantine in-flight work according to the application’s idempotency contract, restore the stable route, and verify one known control request. Do not blindly retry ambiguous tool-bearing requests on the old model.

Rent only after static gates pass

Run a short side-by-side GLM-5.3 FP8 canary after manifest verification

Rent only after both immutable manifests, disk plan, template fixtures, license review, new image, acceptance thresholds, and rollback route are ready. Confirm that one region supplies the exact accelerator count and interconnect, persistent storage can hold the new snapshot plus runtime headroom, and the image is pinned by digest. Start with harmless prompts and remove only the task-owned resources after saving the canary and deletion receipts.

Check current GPU 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 prove GLM-5.3 availability, eight-GPU topology, interconnect, storage, checkpoint integrity, license fit, vLLM compatibility, context capacity, price, privacy, security, output quality, rollback, or resource deletion. Verify every live property and keep your own receipts.

Temporary accelerators are useful when they shorten a bounded load and acceptance test. They are not evidence that the model is viable at production concurrency or economically superior to the hosted API. Measure the actual task class before extending the rental or reserving hardware.

Frequently asked questions

Can I rename my GLM-5.2-FP8 directory to GLM-5.3?

No. The directory would retain all 141 old weight payloads. Matching filenames and byte sizes do not satisfy the pinned GLM-5.3 content identities.

Are the GLM-5.2 and GLM-5.3 tokenizers identical?

At the two revisions audited here, tokenizer.json and tokenizer_config.json are byte-identical. The chat templates are not, so a complete rendered prompt can still change even when plain tokenization does not.

Is GLM-5.3 still MIT licensed?

No. The pinned GLM-5.3 repository uses a named GLM-5.3 license under the license:other tag. Read and preserve that exact license; do not inherit the GLM-5.2 MIT label.

Does GLM-5.3 require more weight storage than GLM-5.2-FP8?

The 141 weight-shard files total exactly 755,632,050,320 bytes in both repositories. The complete GLM-5.3 tree is 12,347 bytes larger because of non-weight files. Runtime memory, KV cache, temporary storage, and headroom remain separate capacity questions.

Can GLM-5.3 disable thinking like GLM-5.2?

Not through the pinned template. GLM-5.2 has an enable_thinking=false branch; GLM-5.3 does not and instead supports low, high, and max reasoning effort. Test low effort if latency is the concern, but do not represent it as non-thinking.

Does the identical tensor index prove model compatibility?

It proves identical tensor names and shard allocation at these revisions. It does not authenticate the shard payloads, prove an old runtime can load the new revision, or predict output behavior.

Did this audit run GLM-5.3?

No. It fetched public metadata and small configuration artifacts only. It made no model call, downloaded no weight bytes, and used no GPU. A separate load and task canary is required.

Bottom line

GLM-5.3 is unusually friendly to a controlled migration because its FP8 file topology, architecture fields, tokenizer, generation config, and tensor index align closely with GLM-5.2-FP8. That lets an operator preserve familiar capacity planning and build precise differential tests.

The same evidence makes an in-place swap indefensible. Every weight shard is a different object, the prompt contract changes, the license changes, and the minimum serving environment moves. Stage the successor side by side with the intact control, verify both, rebuild the template and runtime tests, pass a bounded canary, drill rollback, and only then move one accepted task class.

Sources and method

The collector fetched 24 source byte streams and both complete repository trees at 2026-08-28T22:24:36Z. It hashed each small source, compared every common path, summed exact bytes, checked contiguous shard names, compared LFS content identities, selected configuration fields, and template/license markers, then ran a deterministic 20-invariant calculator. The public receipt lets readers inspect the full paths and hashes without downloading the weights.

Publisher model cards and recipes establish published support and hardware shapes; they are not independent performance measurements. AI HOT supplied the lead only. The failed Google request supplied no evidence. Changing upstream revisions require a fresh audit rather than silently extending these results.

Editorial Disclosure

The RunPod CTA is an affiliate or referral link. GLM52.ai may receive a commission or referral credit after qualifying usage without an added charge from us. RunPod did not review or approve this article. The relationship does not change the immutable artifact, license, runtime, acceptance, or rollback gates.