Does GLM-5.2 Compile in vLLM? A Pinned Support Audit

Evan Brooks

AI Infrastructure Editor

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

How we research and review · Report a correction

Disclosed editorial pen name · AI-generated portrait

An accepted mode 3 flag is not a compilation receipt

At the three source snapshots audited here, the vLLM model class used for GLM-5.2 has no @support_torch_compile marker. The stable and issue snapshots also contain the warning that an unsupported model will fall back to eager mode. Reject that warning at startup. Do not add the decorator locally and infer success from a healthy process, loaded weights, or accepted requests.

Original editorial diagram. It explains the activation decision; it is not a vLLM screenshot, startup log, graph trace, model run, GPU benchmark, or proof that GLM-5.2 compiled successfully.

Short answer: do not treat GLM-5.2 as a compiled vLLM profile on the pinned v0.28.0 tag, the source named in the current bug report, or the checked main snapshot. All three contain the GLM-compatible model class, but none marks it as supporting vLLM’s torch.compile path. A requested compile mode can therefore become eager execution instead of the optimization you intended.

That distinction matters operationally. A server can start, load the checkpoint, return correct-looking text, and pass HTTP health checks while the performance experiment has never entered its treatment arm. You would then be comparing eager against eager, attributing unrelated variance to compilation, and perhaps paying for a fleet sized from a false result.

Our machine-readable support audit hashes 21 official or upstream source receipts. It made zero model calls, downloaded zero model-weight bytes, imported vLLM zero times, used zero GPUs, started zero serving processes, and ran zero containers. It proves what the pinned source declares and what the open report says. It cannot prove compiled performance, output parity, GPU compatibility, or a future fix.

In this guide

1. Read the pinned verdict
2. Separate three source snapshots
3. Understand what mode 3 requests
4. Detect silent eager fallback
5. Do not add the decorator locally
6. Treat runner changes as a separate variable
7. Apply the fail-closed activation gate
8. Capture an installed-source receipt
9. Build an eager-versus-compiled parity plan
10. Wait for a merged pinned fix
11. Rent only after static gates pass
12. Frequently asked questions
13. Bottom line
14. Sources and method

Read the pinned verdict

The compile decision has four independent gates. Do not collapse them into a single --compilation-config flag.

Gate	Pinned evidence on August 29, 2026	Required decision
Model eligibility	The audited GLM model class lacks @support_torch_compile in all three snapshots	Reject a performance test until a pinned upstream source declares support
Activation	Stable and issue-snapshot config contains the unsupported-model warning and eager fallback	Fail startup on the warning; require a positive, nonzero compile receipt
Correctness	No local model execution was performed; the reporter encountered full-graph failures after force-enabling	Require eager-versus-compiled output, tool, context, and failure-path parity
Performance	No GPU benchmark was run and no deployable fix was found	Measure only after eligibility, activation, and correctness pass

The current safe state is therefore hold, not “unsupported forever.” Keep a known-good, unmodified eager runtime. Watch for an upstream change with tests, pin the exact merged commit or containing release, and repeat the source audit before spending on a performance canary.

This page owns compile activation. The sequence-parallel MoE audit owns TP/DP/EP topology and its one-token state-guard boundary. The offline-batch guide owns JSONL validation and reconciliation. The local deployment guide owns hardware fit and checkpoint staging. Passing any of those contracts does not prove compilation.

Separate three source snapshots

“Current vLLM” is not a reproducible input. This audit separates three exact source identities:

Snapshot	Immutable revision	Model class compile marker	Runner boundary
vLLM v0.28.0	2cf0a6915ce544dc493a0990f2ea38d81601128a	Absent	GLM does not default to the later V2 runner path checked here
Issue environment	4a6a3272e8d75518efe0a6f9393eb504f3ed2ee0	Absent	GLM defaults to that V2 runner path
Checked main	cacc429f62c3738c9c95093e9bd410e96103221a	Absent	Checked only for the model-class marker

The stable tag is a release boundary. The second revision is the commit named by the reporter in vLLM issue #54197. The third is a main-branch snapshot captured after the issue was opened. None may stand in for a wheel whose code you have not hashed.

GLM-5.2 itself is also pinned. The audited Hugging Face configuration names GlmMoeDsaForCausalLM, 78 hidden layers, 256 routed experts, eight active experts per token, and an index top-k of 2,048. Those facts identify the model contract; they do not imply that every runner optimization supports it.

The official GLM-5.2 vLLM recipe provides a serving starting point, but the pinned recipe does not explicitly add compilation mode 3. Do not turn a generic framework default into a model-specific support promise.

Understand what mode 3 requests

At the issue snapshot, vLLM’s CompilationMode maps numeric mode 3 to VLLM_COMPILE, and the V1 configuration defaults to that mode. The compilation wrapper source invokes torch.compile with fullgraph=True in the audited path.

Those are request semantics, not completion semantics. Think of the control plane as four steps:

1. the configuration asks for vLLM compilation;
2. model eligibility determines whether that request can be applied;
3. the process emits an activation or fallback receipt;
4. the compiled graph must still pass semantic parity.

Only step one is proved by the numeric value. A configuration parser accepting {"mode": 3} says that the field and enum are valid. It does not say the selected model class was decorated, a graph was captured, compilation consumed nonzero time, generated artifacts were used, or output remained correct.

This is the same experimental-design problem as a feature flag that is accepted by an API but ignored by the implementation. Admission is not activation. Record both separately.

Detect silent eager fallback

The stable and issue-snapshot vLLM configuration files both contain the unsupported-compile warning. The relevant behavior is explicit: a model that does not support torch.compile can fall back to eager execution. “Silent” in this guide means the experiment can be silently invalid to an operator who records only the requested flag and process health; it does not mean vLLM necessarily emits no warning.

Make the warning fatal in the deployment harness. Also require positive evidence, because absence of a warning is not enough. Logging may change, filters may suppress a line, or a wrapper may bypass the check. A credible activation receipt should bind:

• the checkpoint repository and immutable revision;
• the wheel or image digest and installed source hashes;
• the exact runner and compilation configuration;
• the startup log from the same process;
• a positive compilation event or nonzero duration;
• the graph/artifact identity if the pinned vLLM version exposes one;
• the CUDA, driver, PyTorch, Triton, GPU, topology, and kernel environment.

Do not use latency alone as the activation signal. A warm eager run may be faster than a cold compiled run; batching, cache state, prefix reuse, request shape, or an unrelated runner change can dominate. Performance becomes meaningful only after the treatment is positively identified.

Here is a minimal log gate. Adapt the positive receipt pattern to the exact pinned version rather than copying a phrase from a different release:

Reject fallback and require positive compilation evidence

from pathlib import Path
import re

log = Path("startup.log").read_text(errors="replace")
unsupported = "does not support torch.compile" in log.lower()
durations = [float(value) for value in re.findall(
    r"(?:compil(?:e|ation)[^\n]{0,80}?)(\d+(?:\.\d+)?)\s*(?:s|seconds)",
    log,
    flags=re.IGNORECASE,
)]

if unsupported:
    raise SystemExit("reject: unsupported model fell back to eager")
if not durations or max(durations) <= 0:
    raise SystemExit("reject: no positive compilation receipt")
print({"activation": "candidate", "max_compile_seconds": max(durations)})

The printed candidate is deliberately not passed: semantic parity is still outstanding.

Do not add the decorator locally

The tempting workaround is a one-line decorator edit. Do not treat it as one line of risk. The decorator opts a model implementation into a full-graph contract. Every Python-side decision, context carrier, custom operation, dynamic shape, device query, workspace allocator, and graph boundary under that model path becomes relevant.

Issue #54197 reports that manually adding @support_torch_compile exposed full-graph failures at a platform device-capability call and at a ContextVar.get workspace path. The reporter also describes a separate V1 override failure involving a Triton wrapper on A100. These are reporter observations, not results reproduced by GLM52.ai.

The static source does support the mechanism check. The pinned fused_q_cutedsl.py contains a platform capability decision, and the pinned workspace.py contains the context-variable workspace lane named in the report. Source alignment makes the report technically inspectable; it does not prove every environment will fail the same way.

A local decorator patch also creates a provenance fork. Even if it starts on one GPU type, it may bypass upstream feature guards, lack tests, diverge from future releases, and turn a support question into an unreviewed compiler integration. Keep the unmodified eager image as the control and rollback.

Treat runner changes as a separate variable

The audit found a runner-routing change between v0.28.0 and the issue snapshot: the stable source does not default this GLM path to the checked V2 runner, whereas the later issue snapshot does. That is a separate intervention from compilation.

Do not compare “old stable eager” with “new main compiled” and assign the whole delta to torch.compile. That changes at least the vLLM revision, runner, compiler eligibility, and potentially kernels or defaults. A useful experiment holds every admissible variable still:

Arm	Source	Runner	Compile state	Purpose
Control	Pinned fixed revision	Pinned explicit runner	Explicit eager	Known-good semantic and performance baseline
Parity treatment	Same revision	Same runner	Positively compiled	Detect output and failure-path drift
Performance treatment	Same as parity	Same as parity	Same compiled receipt	Measure only after parity passes

If the future fix exists only in a source revision that also changes runner behavior, first qualify that revision in explicit eager mode against the old control. Then compare eager and compiled within the new revision. This nested design costs more runs but prevents causal fiction.

Topology remains another controlled input. The 78-layer sparse MoE model can exercise different code under TP, DP, EP, graph, batch, and sequence shapes. Use the production topology in the final canary, but reduce the debugging matrix to one named change at a time.

Apply the fail-closed activation gate

The public receipt includes four deterministic policy fixtures. They are not model results; they test whether the admission rule rejects ambiguous states.

Fixture	Unsupported warning	Compile seconds	Parity	Decision
Reported GLM-5.2 fallback	Yes	0	No	Reject: unsupported-model warning
Quiet no-op	No	0	No	Reject: no positive compile receipt
Compiled without parity	No	38.2	No	Hold: compiled output parity not proved
Compiled and parity checked	No	38.2	Yes	Eligible for a bounded performance canary

The 38.2-second value is a synthetic gate input, not a GLM-5.2 measurement or expected startup time. Its purpose is to prove that “positive activation but no parity” remains a hold.

Implement the same state machine in CI or the deployment controller:

warning present                    -> REJECT
warning absent, compile receipt 0  -> REJECT
positive compile, parity missing   -> HOLD
positive compile, parity passed    -> CANARY-ELIGIBLE

Fail closed when a log is truncated, the process identity is ambiguous, a source hash differs, the expected positive receipt is absent, or the parity corpus is incomplete. Do not retry into an unknown state and do not relabel a hold as a performance result.

Capture an installed-source receipt

Package version text alone is insufficient. A wheel can be rebuilt, patched, or installed from a commit while retaining a familiar version. Hash the source that will actually execute without importing vLLM or initializing CUDA:

Hash the installed vLLM compiler contract without importing vLLM

from hashlib import sha256
from importlib.metadata import distribution, version
from pathlib import Path

dist = distribution("vllm")
files = [
    "vllm/models/deepseek_v32/nvidia/model.py",
    "vllm/config/vllm.py",
    "vllm/config/compilation.py",
    "vllm/compilation/decorators.py",
    "vllm/compilation/wrapper.py",
]

print("vllm", version("vllm"))
for relative in files:
    path = Path(dist.locate_file(relative)).resolve()
    data = path.read_bytes()
    print(relative, len(data), sha256(data).hexdigest())

Archive the output with the wheel hash, container digest, image build recipe, checkpoint revision, and sanitized launch configuration. Compare it with the immutable source you reviewed. A mismatch is not automatically malicious or wrong, but it creates a new, unaudited input and blocks reuse of this verdict.

Then inspect the installed model class itself. Confirm which class the architecture resolves to and whether the support decorator is truly present in that pinned version. Do not use text search alone to prove activation: an import can exist without decorating the selected class, and a decorator can be present while graph capture later fails. The source marker is the eligibility receipt, not the execution receipt.

This receipt also makes rollback honest. “Return to v0.28.0” is ambiguous if the original wheel was locally rebuilt. Return to the exact known-good image digest and its archived source hashes.

Build an eager-versus-compiled parity plan

Compilation is not ready for performance testing until it preserves the application contract. Build the parity corpus before provisioning the canary. Use deterministic or tightly bounded sampling and store sanitized request, token, parser, and acceptance receipts.

At minimum, include:

1. short plain-text tasks with exact or rubric-scored answers;
2. reasoning-on and reasoning-off template paths used in production;
3. single and multi-turn tool calls, including invalid arguments and denied functions;
4. long-context prompts near named operating points, not only tiny warmups;
5. concurrent batches and the actual TP/DP/EP topology;
6. cancellation, timeout, OOM, malformed input, and worker-restart paths;
7. streaming chunk reconstruction and non-streaming response parity;
8. sparse-expert and indexer shapes representative of live traffic.

Compare more than decoded strings. Record finish reasons, token IDs where permitted, tool names and JSON arguments, usage counts, refusal or policy outcomes, timeouts, server errors, and application acceptance. For stochastic tasks, define tolerances before seeing the results and compare distributions over repeated seeds or a task-level success metric.

Keep correctness and speed as separate reports. A 10% latency improvement does not compensate for one invalid tool call, an empty final answer, or a failure path that hangs instead of terminating. Conversely, output parity does not prove a performance win.

After parity passes, run warmup outside the measurement window, hold request mix and concurrency fixed, and capture prefill latency, inter-token latency, end-to-end latency, throughput, GPU memory, compilation time, cache behavior, and error rate. Segment by prompt and output length; a blended average can hide a regression in the expensive tail.

Wait for a merged pinned fix

At the audit time, issue #54197 was open with two comments. A follow-up says a root cause was verified and one point was ready for a pull request, but an exact GitHub search found no pull request directly referencing the issue. A comment about a future PR is not a deployable diff.

Before changing the verdict:

• find the actual pull request and review every changed file;
• require tests that cover GlmMoeDsaForCausalLM, the supported runner, and relevant GPU/backend combinations;
• check whether the decorator is accompanied by graph-break or custom-op work, rather than being the only change;
• confirm the PR merged and record the merge commit;
• identify the first release tag that contains that commit;
• repeat the installed-source and startup-receipt audit;
• run the parity plan before any performance claim.

Recheck the vLLM torch.compile design document against the containing release. Compiler architecture and log vocabulary can change. This guide’s gate is stable—prove eligibility, activation, parity, then performance—but exact evidence fields must follow the pinned implementation.

Do not adopt an arbitrary main-branch snapshot just because the marker appears. Main may contain unrelated runner and kernel changes. If an urgent source pin is justified, build it immutably, review the diff from the known-good base, add your own regression suite, and keep the control deployment immediately available.

Rent only after static gates pass

Everything through source eligibility, provenance capture, log-policy testing, and parity-corpus design can be completed without renting a GPU. Provision only after a merged pinned source declares support and your harness can distinguish compiled execution from eager fallback.

Write down the GPU model and count, HBM, interconnect, driver, CUDA, PyTorch, Triton, vLLM image digest, checkpoint revision, storage, egress, maximum spend, test duration, deletion plan, parity gates, performance metrics, and rollback before creating anything. Availability labels alone do not prove the required topology or software contract.

Run a bounded GLM-5.2 compile canary after support lands

Rent only after the upstream support change is merged and pinned, the installed source is hashed, fallback is fatal, the parity corpus is frozen, and a spend ceiling plus immediate rollback are written. Create and delete only the resources belonging to the bounded canary.

Check current 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 rental does not prove that GLM-5.2 supports vLLM torch.compile, that mode 3 activated, that the selected GPU, HBM, interconnect, driver, CUDA, PyTorch, Triton, runtime, checkpoint, storage, egress, price, security, and deletion match this guide, or that outputs remain correct. Verify the live SKU, exact source pins, activation receipt, parity results, terms, and rollback before use.

If those gates are not ready, keep the eager control. A rented cluster cannot repair an unsupported source contract, and more benchmark repetitions cannot turn an eager-versus-eager comparison into compiler evidence.

Frequently asked questions

Does vLLM mode 3 mean GLM-5.2 is compiled?

No. In the pinned configuration, mode 3 requests VLLM_COMPILE. The selected model must also be eligible, startup must produce a positive compile receipt, and outputs must pass parity. The audited GLM model class lacks the eligibility marker in all three snapshots.

Is the eager fallback a correctness bug?

Not necessarily. Eager execution may return correct output, and fallback can be a deliberate compatibility behavior. It is a serious experimental and capacity-planning problem when an operator believes compilation activated and uses the result as a compiled benchmark.

Can I ignore the warning if latency looks good?

No. Latency cannot establish which path ran. Cache state, batching, runner changes, request mix, and warmup can all change timing. Reject the warning and require a positive same-process activation receipt.

Can I add @support_torch_compile to the model class?

Not as a production shortcut. The current report says that force-enabling then encountered full-graph failures. A decorator is an opt-in to a larger compiler contract, not proof that every operation under the model path is traceable and correct.

Does issue #54197 prove my A100 or H200 will fail?

No. It supplies an attributed environment and failure report. The source audit confirms that named mechanisms and the missing marker exist, but GLM52.ai did not reproduce the run. Test the eventual fix on your exact hardware and topology.

Is vLLM v0.28.0 safe for ordinary eager serving?

This audit does not certify general serving correctness. It only says the pinned model class is not marked for the compiled path and the stable config contains the fallback warning. Use the official recipe and the separate model, topology, output, and failure-path acceptance tests for ordinary serving.

What counts as a positive compilation receipt?

Use evidence emitted by the exact pinned implementation: an explicit compiled path acknowledgement, nonzero compilation activity, and—where available—a graph or artifact identity tied to the process. Define the expected evidence before the run. Absence of the warning alone is not positive proof.

When can I publish a speedup number?

After a merged pinned fix, installed-source verification, positive activation receipt, full semantic parity, and a controlled same-revision eager-versus- compiled benchmark. Report hardware, software, topology, request distribution, warmup, repetitions, error rate, and uncertainty with the number.

Bottom line

For the source pinned on August 29, 2026, GLM-5.2 should be treated as not admitted to vLLM’s torch.compile path. Mode 3 is a request, not proof. Fail startup on the unsupported-model warning, require nonzero positive activation evidence, and keep the exact eager image as the control and rollback.

Do not locally add the support decorator and call the experiment complete. Wait for a reviewable merged fix, pin its containing source or release, qualify runner changes in eager mode, pass output and failure-path parity, and only then run a bounded performance canary. That sequence turns a configuration hope into an auditable compiler decision.

Sources and method

Primary model identity comes from the pinned GLM-5.2-FP8 configuration, the official vLLM recipe, and the Z.AI GLM-5.2 release. The mandatory Zhipu AI research index was also fetched as a first-party discovery check; it is not used to prove compiler support.

Compiler eligibility and fallback behavior were checked in the vLLM v0.28.0 tree, the issue environment tree, and the checked main tree. Issue state, environment, and failure observations come from issue #54197 and its public comments. Reporter claims remain attributed reporter evidence.

The deterministic collector fetched 21 public sources and recorded final URLs, byte counts, HTTP status, and SHA-256 hashes. The calculator verifies the three model-class marker checks, runner boundary, warning paths, mode-3 enum, full-graph wrapper, issue state, four fail-closed fixtures, overlap audit, and zero-runtime boundary. The public JSON receipt is byte-identical to the archived result.

One exact Google query—GLM-5.2 vLLM torch.compile—was attempted through the budgeted SerpAPI client. The request returned an HTTP error, was recorded as failed, and was not retried or replaced with another engine. It did not change the topic, wording, overlap decision, or claims, which remain grounded in the pinned primary source and local content registry.

No model, weight, vLLM import, GPU, serving process, upstream test, or container was used. Recheck the issue, actual merged diff, release containment, installed source, and official documentation before rollout because upstream status and implementation can change after the audit date.

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.