GLM-5.2 on Ascend: vLLM Setup and Verification Gates

Evan Brooks

AI Infrastructure Editor

Editorial responsibility: GLM52.ai Editorial Team · Published and editorially reviewed August 21, 2026

How we research and review · Report a correction

Disclosed editorial pen name · AI-generated portrait

The deployment decision

Use the stable vLLM Ascend 0.23.0 family, then reconcile its versioned tutorial with the current corrected A2/A3 topology before launching. Treat GLM-5.2 as experimental because the current support matrix still does. Start with a bounded W4A8C8 canary on the exact documented rank layout, keep Sparse Flash Attention C8 off when DCP is on, and require repeated task-quality tests. For accuracy-sensitive production, evaluate W8A8 as the project recommends—but do not assume the W4 tutorial command is interchangeable with W8.

Original editorial illustration: the verification gate feeds one sixteen-rank node and a paired eight-rank route. The long-context lane continues only through the documented A3 path; the amber branch represents an experimental route that has not passed promotion gates.

Deploying GLM-5.2 on Ascend is not a one-command problem. Z.AI names vLLM Ascend as a supported NPU framework, and the project publishes commands for Atlas 800 A2 and A3, co-located serving, prefill/decode disaggregation, MTP, and one-million-token context. Yet the same source set also marks the model experimental, contains topology text that changed after the stable release, and records open quality and tool-call reports.

This guide turns those documents into a fail-closed deployment contract. It pins vLLM Ascend v0.23.0, compares the release tutorial with the current corrected tutorial, hashes three public ModelScope manifests, normalizes eight topology rows, and reconciles four different context numbers. The audit made zero model calls, zero NPU runs, and zero GPU runs. It does not claim throughput, accuracy, or runtime fit. The machine-readable audit receipt contains all 17 source hashes, arithmetic, scenarios, boundaries, and limits.

In this guide

1. Choose the Ascend route by evidence
2. Pin the runtime and reconcile documentation
3. Audit BF16, W8A8, and W4A8C8 artifacts
4. Match the A2 or A3 topology
5. Launch a conservative W4A8C8 canary
6. Set the context cap from scenario evidence
7. Keep DCP and prefill/decode symmetric
8. Gate W4A8C8 accuracy and W8A8 migration
9. Verify tool calling and response delivery
10. Run the Ascend promotion sequence
11. Use a non-Ascend control correctly
12. Frequently asked questions
13. Sources and method

Choose the Ascend route by evidence

The shortest defensible starting point is one Atlas 800 A3 node with 16 64-GB NPUs, the W4A8C8 artifact, and a below-one-million context cap. That is not a production endorsement. It is the smallest current tutorial topology for which card count, rank layout, quantization flag, parser flags, and a concrete launch shape are all described together.

Use the following routing table before copying any command:

Need	Evidence-backed starting route	Do not infer
Smallest documented A3 canary	1 A3 node, 16 NPUs, W4A8C8, DP2/TP8, 135K tutorial cap	That W4 quality is stable for your tasks
Smallest documented A2 canary	2 A2 nodes, 16 NPUs total, W4A8C8, DP2/TP8, 40K cap	That one A2 node can fit the service
Accuracy-sensitive service	Evaluate W8A8 on the exact target; preserve a W4 control	That W4 and W8 accept identical launch flags
One-million-token experiment	A3 only, one of three DCP layouts, command cap 1,024,000	That A2 or every A3 workload is validated to 1M
Prefill/decode isolation	Use the exact A2 or A3 P/D row and symmetric DCP state	That asymmetric context parallelism is safe
BF16 accuracy control	Budget multiple nodes and measure full runtime memory	That file bytes alone prove process fit

The word “documented” is deliberately weaker than “verified.” The current vLLM Ascend support matrix still marks GLM-5.2 experimental and lists a 200K maximum-model-length field. The tutorial supplies larger scenario recipes, including 1M on A3, but it does not convert the global support row into a production guarantee.

The route also depends on which artifact you can validate. The W4 file floor is dramatically smaller than W8 or BF16, but an open project issue reports repeat-to-repeat accuracy fluctuation in one W4 P/D configuration. W8 is the issue author’s accuracy-sensitive recommendation, but another open A2 W8 issue reports a tool response that did not reach the client. There is no artifact that lets you skip a local workload gate.

Pin the runtime and reconcile documentation

The official vLLM Ascend v0.23.0 release was published on 2026-08-16 at commit 5cb98caaadeff42b5b62b996e34bb2aaa29d20fd. Its dependency family is:

Layer	v0.23.0 contract
Upstream vLLM	0.23.0
Python	>=3.10,<3.13
CANN	9.1.0 for A2 and A3
PyTorch	2.10.0
torch_npu	2.10.0.post4
Triton Ascend	3.2.2
A3 image tag	quay.io/ascend/vllm-ascend:v0.23.0-a3
A2 image tag	quay.io/ascend/vllm-ascend:v0.23.0

Pin this family as one compatibility unit. Do not combine a newer plugin with an older CANN image merely because imports succeed. Resolve the container tag to a registry digest, record firmware and driver versions, and admit only that digest through staging. A mutable tag is useful for discovery, not sufficient provenance for rollback.

Then reconcile, rather than blindly trust, the versioned tutorial. The tutorial at the release commit describes the single-A3 prerequisite as 128GB × 8. But its ordinary single-node command uses DP2 and TP8, a 16-rank layout. The current pinned tutorial corrects the machine description to 64GB × 16.

Both descriptions add up to 1,024 decimal GB. That makes the drift easy to miss if capacity is the only check. A launch can have the right total memory and the wrong device count. The A2 BF16 prerequisite text changed too: a per-node line that said 64GB × 32 in the versioned material now says 64GB × 8.

Use a two-pin policy:

1. Pin software and images to the stable release family.
2. Pin the current tutorial revision used to interpret topology and known boundaries.
3. Before launch, compare detected NPU count, memory per NPU, hostname count, HCCL rank table, DP, TP, PP, PCP, and DCP with the intended scenario.
4. Reject the launch if the product of parallel dimensions or local rank count does not match the observed world size.

That policy does not imply that the newest documentation is always correct. It creates an auditable discrepancy instead of silently selecting whichever text was copied first.

Audit BF16, W8A8, and W4A8C8 artifacts

The public ModelScope manifests expose filename, byte size, revision, and SHA-256 for each shard. The receipt deterministically reduces every safetensors entry into these weight-file floors:

Artifact	Primary shards	Additional safetensors	Total bytes	GiB
BF16 GLM-5.2	282	none observed	1,506,667,387,408	1,403.193
W8A8 GLM-5.2	181	rot.safetensors	773,876,016,944	720.728
W4A8C8 GLM-5.2	95	rot.safetensors	404,794,116,064	376.994

By observed file bytes, W8A8 is 48.64% smaller than BF16. W4A8C8 is 73.13% smaller than BF16 and 47.69% smaller than W8A8. Against the corrected one-node A3 aggregate of 1,024 decimal GB, those files alone consume 147.14%, 75.57%, and 39.53%, respectively.

Those percentages explain why quantization is operationally important, but they do not prove a process fits. The files exclude KV cache, graph capture, quantization metadata, communication workspaces, load-time duplication, allocator fragmentation, operating software, replicas, health reserve, and failover capacity. Even division across ranks is arithmetic, not evidence that MoE experts and auxiliary tensors are placed evenly.

W4 has another easy-to-miss boundary. Its observed config.json declares max_position_embeddings: 1048576, while top-level quantization_config is null. The Ascend path is supplied at runtime through --quantization ascend. Do not let a generic loader see null and conclude that the artifact is an ordinary unquantized checkpoint.

Create a local artifact receipt before a model process starts:

Minimum Ascend artifact receipt

{
  "repository": "Eco-Tech/GLM-5.2-w4a8c8",
  "repository_revision": "<pin-an-immutable-revision>",
  "manifest_response_sha256": "<record>",
  "primary_shards": 95,
  "auxiliary_safetensors": ["rot.safetensors"],
  "all_file_hashes_verified": false,
  "quantization_runtime": "ascend",
  "image_digest": "sha256:<record>",
  "credentials_archived": false
}

Change all_file_hashes_verified only after every staged file matches its manifest. Never put model-access credentials, registry credentials, private prompts, or sensitive customer output in this receipt.

Match the A2 or A3 topology

The current tutorial contains eight useful scenario rows. Normalize one row into your deployment manifest instead of composing flags from several rows:

Scenario	Nodes / NPUs	Parallel layout	Tutorial context cap	Draft tokens
A3 single, ordinary	1 / 16	DP2 TP8	135,000	3
A3 dual, co-located	2 / 32	DP4 TP8	66,000	3
A3 P/D, ordinary	4 / 64	P: DP4 TP8; D: DP32 TP1	133,120	P1 / D5
A2 dual, co-located	2 / 16	DP2 TP8	40,000	5
A2 P/D, ordinary	8 / 64	P: DP4 TP8; D: DP8 TP4	256,000	P1 / D3
A3 single, 1M	1 / 16	DP1 TP16 DCP16	1,024,000	3
A3 dual, 1M	2 / 32	DP4 TP8 DCP8	1,024,000	3
A3 P/D, 1M	4 / 64	P and D: DP4 TP8 DCP8	1,024,000	P1 / D3

The caps are scenario settings, not a monotonic hardware ranking. The A3 dual-node ordinary throughput profile uses 66K, below the 135K single-node example, because the recipes optimize different admission and parallelism objectives. The A2 P/D row reaches 256K while the co-located row uses 40K. Do not replace the scenario cap with the largest number seen anywhere on the page.

For each host, record:

• detected product name, NPU count, and memory per NPU;
• hostname, management IP, HCCL interface, and rank range;
• image digest, driver, firmware, CANN, PyTorch, torch_npu, vLLM, and plugin;
• local and global DP ranks, TP, PP, PCP, DCP, and expert-parallel state;
• checkpoint revision and every shard hash;
• requested context, batched-token cap, sequence cap, and memory utilization;
• parser flags, MTP draft count, quantization mode, graph mode, and additional Ascend configuration.

Do not expose a public socket while this receipt is incomplete. Multi-node launches should first pass the project’s bounded communication check on the same NIC and rank assignment. HCCL success on a different interface or smaller world size does not validate the production topology.

Launch a conservative W4A8C8 canary

The tutorial’s optimized command enables MTP, DSA context parallelism, graph capture, balance scheduling, shared-expert overlap, and a large context in one step. That is useful as a project recipe, but it creates a wide diagnostic surface. Begin with a derived, loopback-only canary that keeps the model, quantization, DP/TP, expert parallelism, and parsers while reducing context and omitting speculative and optional overlap features:

Derived A3 W4A8C8 canary—validate before use

export HCCL_OP_EXPANSION_MODE=AIV
export HCCL_TRANSFER_TIMEOUT=600
export HCCL_EXEC_TIMEOUT=3600
export HCCL_CONNECT_TIMEOUT=3600
export OMP_PROC_BIND=false
export OMP_NUM_THREADS=1
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True

vllm serve /models/GLM-5.2-w4a8c8 \
  --host 127.0.0.1 \
  --port 8077 \
  --served-model-name glm-52 \
  --api-server-count 1 \
  --data-parallel-size 2 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --quantization ascend \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --enable-auto-tool-choice \
  --max-model-len 32768 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 4096 \
  --gpu-memory-utilization 0.80 \
  --seed 1024 \
  --trust-remote-code \
  --safetensors-load-strategy prefetch

This is a GLM52.ai diagnostic derivation, not a command vLLM Ascend claims to have benchmarked. Review the pinned remote code before allowing --trust-remote-code, bind only to loopback, and run it inside the approved network and host-isolation boundary. If the stripped path needs an additional plugin setting on your exact image, add one field at a time and preserve the failure receipt.

The first success criterion is not “the port opened.” Require:

1. all expected ranks to initialize on the intended devices;
2. every shard hash to match before readiness;
3. no unexpected fallback, compilation error, or missing quantized operator;
4. a deterministic greedy text fixture repeated across restarts;
5. reasoning and plain-response content delivered to the client;
6. native tool calls parsed with argument types intact;
7. maximum-output, stop, cancellation, and malformed-request behavior;
8. per-rank peak memory and a clean unload/reload cycle.

Only then add the upstream optimization layers. Add MTP and measure acceptance and output parity using the dedicated GLM-5.2 MTP guide. Add graph mode, DSA-CP, balance scheduling, and overlap individually. If several flags change together, a regression no longer has one attributable cause.

Set the context cap from scenario evidence

Four context numbers appear in the pinned source set:

Evidence layer	Tokens	Correct interpretation
Current support-matrix row	200,000	Experimental global support entry
1M launch commands	1,024,000	Scenario-specific A3 service cap
1M tuning table	1,040,000	A separate recommendation that disagrees with commands
W4 config native positions	1,048,576	Architecture/config ceiling, not a service promise

The 1,024,000 command is 24,576 tokens below the native 1,048,576 field and uses 97.65625% of it. The 1,040,000 tuning-table value is 16,000 above the commands and 8,576 below native. The support-matrix value is 824,000 below the commands. None should be silently substituted for another.

For a first service, cap context at the smallest value that satisfies the real reader workload and passes memory plus retrieval tests. A nominal 1M route is appropriate only when all of these are true:

• the hardware is A3; the release says A2 was not validated for 1M;
• the exact single, dual, or P/D DCP topology is recorded;
• the command cap is 1,024,000 unless a separately reviewed revision changes the contract;
• enable_sparse_sfa_c8 remains off in v0.23.0;
• long-prefix retrieval, position-sensitive reasoning, cancellation, and near-cap output behavior pass repeatedly;
• peak memory on every rank leaves a declared reserve under concurrency;
• queueing and prefill cost remain compatible with the service objective.

One successful short request after loading with --max-model-len 1024000 proves almost nothing about the cap. Test prompts near several boundaries, plant uniquely identifiable facts across the prefix, vary output length, and compare accepted results rather than mere HTTP 200 responses.

Keep DCP and prefill/decode symmetric

The v0.23.0 release draws two explicit boundaries around decode context parallelism. First, DCP and Sparse Flash Attention C8 (enable_sparse_sfa_c8) have known issues together and are not recommended in this release. The 1M examples enable DCP and deliberately leave SFA C8 off. Second, a P/D deployment using sparse flash attention must enable DCP on both prefiller and decoder sides or disable it on both. Asymmetric state can cause accuracy problems.

Treat this as a configuration invariant, not a tuning suggestion:

P/D admission invariant

prefiller.dcp_enabled == decoder.dcp_enabled
and not (dcp_enabled and enable_sparse_sfa_c8)

The ordinary A3 P/D row and the 1M A3 P/D row are also different systems. The ordinary route assigns prefill DP4/TP8 and decode DP32/TP1, with different MTP draft counts. The 1M route uses DP4/TP8/DCP8 on both sides. Do not add DCP8 to the ordinary row without re-deriving the world size and quality contract.

P/D serving adds boundaries beyond model correctness:

• a request ID must map to exactly one prefill and one decode lineage;
• KV-transfer version, connector, ports, and role must be explicit;
• a failed handoff must not create a second user-visible side effect;
• backpressure must stop admission before KV or decode memory is exhausted;
• prefiller and decoder image, tokenizer, template, checkpoint, and parser revisions must be compatible;
• restart tests must cover each side independently and together;
• rollback must drain or invalidate transferred state safely.

Measure time to first token, time per output token, accepted-result throughput, transfer failures, queue delay, memory by rank, and recovery time separately. Raw tokens per second can rise while delivery quality falls.

Gate W4A8C8 accuracy and W8A8 migration

Open vLLM Ascend issue #14378 reports approximately 2–3 percentage-point GPQA fluctuation across repeated GLM-5.2 W4A8C8 P/D runs with enable_sparse_sfa_c8. It calls W4 experimental, recommends W8A8 for production and accuracy-sensitive workloads, and advises keeping SFA C8 off in P/D unless memory requires it and accuracy is carefully evaluated.

This is a project report, not a GLM52.ai reproduction or a statement that every W4 route fluctuates. It nevertheless invalidates a one-pass accuracy gate. For the target application, run repeated trials with fixed dataset revision, prompt template, decoding settings, seed where applicable, parser, context distribution, and service topology. Report the distribution, not only the best run.

A useful gate has at least four layers:

Layer	Example checks	Promotion rule
Deterministic integrity	exact arithmetic, code execution, JSON schema, stop tokens	Zero severe mismatches across repeated greedy runs
Application quality	labeled support, coding, retrieval, or agent tasks	Lower confidence bound must clear the declared threshold
Protocol quality	tool name/arguments, reasoning separation, streaming, cancellation	No lost, duplicated, or malformed user-visible event
Operational quality	memory, TTFT, TPOT, errors, restart, recovery	Pass the service SLO with reserve and rollback

W8A8 is a candidate response to W4 instability, not a drop-in flag change. Its observed safetensors payload is 720.728 GiB, nearly twice W4’s 376.994 GiB. The tutorial’s detailed scenario commands use W4A8C8; they do not publish an interchangeable W8 block for each layout. Recalculate process fit, confirm the proper quantization loader, and start from a new canary receipt.

Keep BF16 as a separate control if you have enough hardware. Its observed 1,403.193 GiB file floor exceeds one corrected A3 node’s aggregate, before runtime allocation. It cannot be smuggled into a one-node plan by calling it a quality baseline.

Verify tool calling and response delivery

The tutorial uses --tool-call-parser glm47, --reasoning-parser glm45, and --enable-auto-tool-choice. Loading those flags is not a tool-call test. The client must receive a well-formed event with the expected name and typed arguments, while non-tool answers, reasoning content, streaming fragments, and finish reasons remain correct.

Open, triaged vLLM Ascend issue #12405 reports an A2 W8 path where generation appeared in internal output but the tool-call request returned no usable client result. The report is not proof of a universal W8 bug. It is evidence that server-side token generation and user-visible delivery require separate gates.

Test at least these fixtures against the exact production client:

• one required tool with two typed arguments;
• a choice between two tools with mutually exclusive schemas;
• a request that must answer normally and call no tool;
• malformed tool arguments that the client rejects safely;
• streamed arguments split across awkward chunk boundaries;
• parallel or sequential calls only if the application supports them;
• reasoning enabled and disabled, verifying no hidden content leaks into tool arguments or the visible answer;
• cancellation during arguments, timeout after execution, and retry with a stable idempotency key;
• maximum-length arguments and non-ASCII strings;
• server restart after generation begins but before the final response.

Record both the raw sanitized wire events and the parsed application object. An internal log containing plausible tokens is not success. Success is one correct, authorized, user-visible outcome without duplicate side effects. For general parser design, the separate GLM-5.2 tool-calling guide owns that broader reader job.

The older issue #12851 adds a version boundary. It reports a W4 load failure on a v0.22.1 release candidate and says v0.23.0rc1 started; it is now closed stale/not-planned. Use stable v0.23.0, not an RC, and keep cold-load, corrupt-shard, shutdown, and restart fixtures in the gate.

Run the Ascend promotion sequence

Use one promotion ladder with explicit evidence and rollback:

1. Freeze source revisions. Record the vLLM Ascend release commit, current tutorial commit, support-matrix commit, checkpoint revision, manifest hash, and container digest.
2. Prove physical topology. Compare detected A2/A3 product, device count, memory, NICs, hosts, and HCCL ranks with one normalized scenario.
3. Verify artifacts offline. Check every shard, auxiliary safetensors file, tokenizer, template, and remote-code revision before model load.
4. Pass a loopback baseline. Start the stripped canary with a small context, no MTP, no DCP, no graph capture, and no public listener.
5. Pass deterministic quality. Repeat exact-answer, code, stop, parser, and structured-output fixtures across clean restarts.
6. Add one optimization. Introduce the intended graph, DSA-CP, MTP, overlap, scheduling, or sparse-attention field separately and replay the corpus.
7. Raise context gradually. Test retrieval, memory, queueing, cancellation, and output at several caps; do not jump from 32K to 1,024K.
8. Validate protocols. Capture sanitized request, stream, parser, tool, and finish events through the real client and gateway.
9. Soak the exact workload. Mix prompt lengths, output lengths, concurrency, cache hits, failures, and restarts while measuring every rank.
10. Rehearse rollback. Drain traffic, preserve idempotency, restore the prior digest, and prove the old route still accepts requests.
11. Shadow before serving. Compare accepted results without allowing the candidate to create external side effects.
12. Promote a small slice. Stop automatically on quality, parser, memory, availability, topology, or recovery breaches; expand only after the observation window closes.

Version the gate with the deployment. A new CANN, firmware, compiler, Triton, torch_npu, vLLM, plugin, image, remote-code revision, checkpoint, tokenizer, or parallel layout reopens the relevant evidence. A healthy process does not grandfather an untested software stack.

Evaluate economics per accepted result, not per generated token. Include failed runs, retries, long-prefill queueing, idle reserve, checkpoint storage, networking, operational labor, and recovery capacity. Quantization wins only if its capacity benefit survives quality and protocol gates.

Use a non-Ascend control correctly

A non-Ascend accelerator can validate client behavior, evaluation fixtures, idempotency, rollback orchestration, and some checkpoint-level expectations. It cannot validate CANN kernels, HCCL topology, vLLM Ascend quantization, A2/A3 memory behavior, ModelSlim artifacts, DSA context parallelism, or the project issues described above.

Build a separate NVIDIA control

Use a rented GPU only for the evidence it can produce: rehearse the client, parser, labeled evaluation, streaming, cancellation, idempotency, and rollback harness. Keep its image, checkpoint format, backend, topology, and measurements in a separate receipt. Do not transfer its throughput, memory, long-context, or quantization result to Atlas A2 or A3.

Check current isolated GPU availability 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 RunPod GPU is a separate control path and cannot validate an Ascend NPU, CANN, HCCL, ModelSlim, or vLLM Ascend result. Verify the live accelerator SKU, count, interconnect, isolation, storage, and price before use.

If you need an evidence-backed NVIDIA deployment rather than only a harness control, the NVFP4 SGLang guide owns that route. The AMD ROCm SGLang guide provides a third distinct hardware contract. Neither is an Ascend fallback with the same flags; each requires its own artifact, runtime, and acceptance receipt.

Frequently asked questions

Is GLM-5.2 production-ready on vLLM Ascend?

The current pinned support matrix marks it experimental, so this guide does not call it production-ready by default. The project publishes detailed deployment recipes, but a production decision requires the exact artifact, topology, context, parser, repeated quality, memory, recovery, and workload gates to pass.

Which vLLM Ascend version should I use?

Start from stable v0.23.0 and its aligned dependency family: upstream vLLM 0.23.0, CANN 9.1.0, PyTorch 2.10.0, torch_npu 2.10.0.post4, and Triton Ascend 3.2.2. Resolve the image tag to a digest. Also pin the current tutorial because topology wording was corrected after the release commit.

Can W4A8C8 fit on one Atlas 800 A3 node?

Its observed 376.994-GiB safetensors floor is 39.53% of a corrected A3 node’s 1,024-decimal-GB aggregate, and the current tutorial provides a 16-NPU single-node recipe. That is not a full process-fit proof. Measure actual per-rank peak memory, KV cache, graphs, workspaces, fragmentation, concurrency, and reserve.

Can W4A8C8 fit on one Atlas 800 A2 node?

The current tutorial says no and names two A2 nodes, 16 NPUs total, as the minimum W4 configuration. Do not treat the aggregate W4 file floor as proof of a supported one-node placement; rank layout and runtime allocation matter.

Should accuracy-sensitive deployments use W8A8?

W8A8 is the recommendation in open issue #14378 for accuracy-sensitive production, but it is not a drop-in replacement. Its observed artifact is 720.728 GiB, the detailed tutorial scenarios use W4, and an A2 W8 tool-delivery report remains open. Recalculate fit and rerun every gate.

Does GLM-5.2 support one million tokens on A3?

The tutorial provides three A3 DCP recipes with a 1,024,000 command cap, while the config’s native position field is 1,048,576 and a tuning table says 1,040,000. The support matrix still says experimental/200K. Use 1,024,000 only as scenario-specific A3 evidence, not a blanket promise, and validate the real workload near the cap.

Can A2 use the one-million-token recipe?

Not on the checked evidence. The v0.23.0 release explicitly says the 1M deployment was validated only on Atlas 800 A3 and that A2 was not validated. An A2 service should use its documented scenario cap and local tests.

Can DCP and Sparse Flash Attention C8 be enabled together?

Not as a recommended v0.23.0 route. The project documents known issues when DCP and enable_sparse_sfa_c8 are combined. The 1M recipes keep SFA C8 off, and P/D deployments must keep DCP state symmetric across both sides.

Is this a hardware benchmark?

No. GLM52.ai used no NPU or GPU and made no model call. The page audits pinned documents, public file manifests, issue states, and deterministic arithmetic. All runtime, quality, and performance claims remain work the operator must measure on the exact target.

Sources and method

Z.AI’s pinned Ascend deployment entry names vLLM Ascend, SGLang, and xLLM as GLM-5.2 NPU framework paths. The pinned GLM-5.2 FP8 model card also names Ascend NPU frameworks. These establish a direct GLM-5.2/Ascend link; they do not replace each framework’s exact artifact and launch contract.

The deployment contract comes from the v0.23.0 tutorial, the current corrected tutorial, the release support matrix, the current support matrix, and the v0.23.0 release. The three ModelScope pages supplied public file manifests; issues #14378, #12405, and #12851 supplied bounded project reports. The fixed per-round Z.AI release check and Zhipu research check were discovery inputs, not launch-command evidence.

The committed evidence packet stores the observed URL, byte count, and SHA-256 for 17 source responses. Its deterministic script calculates artifact totals, reductions, A3 file-floor shares, eight topology rows, and differences among the 200,000, 1,024,000, 1,040,000, and 1,048,576 context values. The public receipt is byte-identical to the committed result.

No checkpoint shard was downloaded, no container was started, and no Atlas NPU, GPU, serving endpoint, grader, GLM, or MiniMax model was used. ModelScope master manifests can change, so the audit freezes only the observed response and deterministic per-file digest. Open issues are not GLM52.ai reproductions. The broad local deployment guide remains the place to choose among workstation experiments, accelerator clusters, and managed access; this page owns only the Ascend vLLM deployment and promotion decision.

About the editorial role

Evan Brooks

AI Infrastructure Editor

Evan Brooks serves as GLM52.ai’s disclosed editorial pen name for infrastructure, deployment, and training guides. The role examines checkpoint size, memory math, provider limits, implementation evidence, and operational risk. The GLM52.ai Editorial Team produces and fact-checks every article under this byline.

The GLM52.ai Editorial Team accepts responsibility for this article. Read our editorial policy or request a correction.

An AI image tool created this portrait. It does not depict a real individual.