GLM-5.2 SGLang Weight Cache Daemon: Compatibility Audit

Evan Brooks

AI Infrastructure Editor

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

How we research and review · Report a correction

Disclosed editorial pen name · AI-generated portrait

The compatibility verdict

Treat SGLang Weight Cache Daemon as a narrow GLM-5.2 lab pilot, not a production-ready fast-recovery feature. Pin SGLang v0.5.18, run one standalone daemon set and one client, use plain tensor parallelism, disable MTP and every speculative algorithm, and choose either unquantized BF16 or the official 128×128 block-FP8 checkpoint. The source allowlist makes those two artifacts eligible to test; it does not prove GLM-5.2 parity or restart speed. Keep DP, EP, multiple independent instances, and coordinated multi-node failover out of the first pilot because their shard identity or lifecycle work remains on the open roadmap.

Original editorial illustration: resident weights stay on the left, the restarted client crosses a compatibility fingerprint in the center, and locked branches show configurations that need more evidence. It makes no speed claim.

SGLang’s Weight Cache Daemon (WCD) keeps post-processed model weights in a persistent GPU process. A new engine maps those tensors through CUDA IPC rather than reading, deserializing, sharding, and post-processing the checkpoint again. That architecture directly targets one expensive part of restarting a model as large as GLM-5.2.

The attraction is real, but the compatibility boundary is narrower than the headline. The launch publication measures Ling-2.6-1T FP8, not GLM-5.2. The registered WCD tests use Qwen3-0.6B. Separate GLM-5.2 tests exercise TP8, DP8, and MTP, but none combines the model with WCD. Current source also omits DP, EP, and node rank from the cache identity and rejects every speculative algorithm before launch.

This audit pins SGLang v0.5.18 at commit 71de97b264b04dcd514cf904003028aefe9775c8, the official GLM-5.2-FP8 revision ba978f7d347eaf65d22f1a86833408afdb953541, and nineteen public source receipts. Its machine-readable evidence reproduces the quantization matrix, socket-rank examples, test-coverage gap, and publisher-number boundary. We made zero model calls and zero GPU runs.

In this guide

1. Make the decision before copying a command
2. Understand what stays resident
3. Keep the Ling measurements with Ling
4. Audit the official GLM-5.2 FP8 artifact
5. Read the quantization allowlist literally
6. Map fingerprint and socket identity
7. Remove MTP, DP, and EP from the first pilot
8. Reconcile publication and source behavior
9. Build a two-path parity harness
10. Measure every restart stage separately
11. Inject failure before promotion
12. Rent only after fixing the experiment
13. Troubleshoot failed pilots
14. Frequently asked questions
15. Sources and method

Make the decision before copying a command

WCD is useful only when repeated weight loading is a material part of a service event you actually need to shorten. It does not preserve KV cache, requests, the scheduler, distributed process groups, graph capture, kernel warm-up, HTTP state, or an application’s retry contract. Mapping weights quickly can still leave a long interval before the first correct response.

Classify the event first:

Event	Can resident weights help?	What remains outside WCD
Engine process restart on the same healthy GPUs	Potentially, if a standalone daemon survives	Distributed init, graph capture, kernels, KV allocation, server readiness, request recovery
Engine-spawned daemon exits with the engine	No persistent cache survives	A full disk load is required on the next start
Daemon process dies	Existing clients terminate to avoid invalid pointers	Daemon recovery and cache adoption are roadmap work
GPU reset, node loss, or power loss	No resident GPU memory survives	Checkpoint reload, orchestration, traffic recovery, and state reconstruction
Model revision, dtype, TP/PP layout, or environment changes	Cache fingerprint should reject reuse	A compatible daemon must be loaded again
Rolling config change unrelated to model state	Maybe, if the fingerprint and client contract remain identical	Application and serving-state correctness still need validation

If the operational objective is node-loss recovery, WCD Phase 1 is not the answer. If the objective is to restart one engine process on healthy GPUs while the exact model state remains valid, a controlled pilot can answer whether weight mapping removes enough time to matter.

Use this go/no-go sequence:

1. Profile a normal disk start and split it into named phases.
2. Confirm weight loading is large enough to justify another persistent process and failure dependency.
3. Confirm the exact checkpoint and launch graph are source-eligible.
4. Establish disk-versus-IPC tensor and output parity before timing.
5. Prove failure behavior and rollback while traffic is isolated.
6. Compare the whole service-ready event, not just the fastest substage.

A null result is valuable. If graph capture, distributed init, storage caching, or application recovery dominates, leave WCD off and improve the real bottleneck. Do not keep a resident daemon merely because a microstage became fast.

Understand what stays resident

The standalone daemon performs the expensive path once: it loads checkpoint files, applies tensor and pipeline sharding, runs supported post-load transforms, and retains the resulting parameters and buffers in GPU memory. It exports IPC handles over a Unix socket. A client initializes the model structure on the meta device, maps the exported tensors, and avoids a second physical weight copy.

This is zero-copy sharing, not a second GPU cache tier. The daemon owns the physical allocation; the client points at it. That saves duplicate weight memory, but it also creates a lifetime dependency. Pinned ipc_loader.py starts a liveness watchdog. If the daemon disappears, the client terminates because continuing with dangling mapped pointers could crash or produce wrong data. Fail-loud behavior protects correctness; it is not transparent failover.

The three public modes have different consequences:

Mode	What it does	Restart consequence
off	Normal checkpoint loading	Known control and mandatory rollback path
daemon	Engine launches a co-terminal daemon	First start is slower and the daemon does not survive that engine’s restart
client	Engine connects to a pre-existing standalone daemon	Candidate fast-map path, if every compatibility and parity gate passes

The daemon mode name is easy to misread. Pinned server_args.py states that an engine-spawned daemon does not persist across restarts. The standalone process launched with python -m sglang.srt.weight_cache.daemon must be operationally independent, then the engine uses client mode. The default readiness timeout is 1,800 seconds, which is a wait ceiling rather than a performance promise.

Do not set --load-format ipc_cache. It is an internal dispatch format selected when WCD is enabled, and pinned source rejects setting it directly. Keep the ordinary disk launch command as a reviewed rollback artifact instead of trying to simulate WCD through internal flags.

Keep the Ling measurements with Ling

The first-party launch publication reports a compelling result for its system: approximately 495 seconds to 0.63 seconds for weight loading, a stated roughly 785× improvement, and total startup from 8.8 minutes to 0.528 minutes. The model is Ling-2.6-1T FP8 on eight H20-3e GPUs with weights on its described NVMe storage path.

Those numbers are neither a GLM-5.2 benchmark nor a universal WCD constant. At least these variables change the result:

• checkpoint file count, tensor names, size, layout, and filesystem cache;
• storage bandwidth, metadata latency, shared-filesystem contention, and NUMA;
• TP and PP degree, rank placement, device topology, and distributed startup;
• quantization method, post-load transforms, repacking, and kernel version;
• accelerator, driver, CUDA, Torch, allocator, and IPC implementation;
• graph shapes, kernel warm-up, KV allocation, tokenizer, and server startup;
• whether the measured event is weight mapping, engine readiness, health-check success, or first correct application response.

Even the publication’s reported ratio needs its label. 495 / 0.63 is about 785.714, while the article rounds it to roughly 785×. That arithmetic verifies the internal presentation; it does not create a forecast. The same source reports about a 94% total-startup reduction for its measured system. GLM52.ai did not reproduce either result.

Set the baseline to “unknown until measured.” Record WCD-off and WCD-client samples on the same node, same revision, same storage state, same process layout, and same readiness definition. Report medians, tails, dispersion, and every excluded failure. A single warm restart is not a service-level result.

Audit the official GLM-5.2 FP8 artifact

The official GLM-5.2-FP8 manifest gives WCD a plausible test candidate. At the pinned Hugging Face revision, the config.json declares the GlmMoeDsaForCausalLM architecture, 78 hidden layers, 256 routed experts, eight selected experts per token, one MTP layer, and this quantization block:

Pinned GLM-5.2-FP8 quantization fields

{
  "quant_method": "fp8",
  "fmt": "e4m3",
  "activation_scheme": "dynamic",
  "weight_block_size": [128, 128]
}

That last field is decisive because current WCD source allowlists FP8 only when weight_block_size exists. It rules the official artifact into a source-level pilot candidate. It does not establish that every GLM-specific module, post-processing attribute, shared storage, DSA path, or MoE tensor maps correctly.

The pinned model.safetensors.index.json contains 118,629 tensor names across 141 shard files and publishes exactly 755,617,140,416 tensor bytes: 703.723301 GiB. The model API reports 753,375,793,584 parameters, of which 751,226,191,872 are F8_E4M3, or 99.7147%. These are manifest facts, not measured HBM allocation. Runtime buffers, scales, allocator behavior, graphs, communication workspaces, KV cache, and reserve sit outside the tensor-index total.

The size explains why avoiding a repeated disk path may matter. It also raises the cost of a mistake: an incorrect tensor mapping can make a server look ready while producing bad output. Treat size as motivation for stronger parity, not permission to relax it.

Read the quantization allowlist literally

Pinned protocol.py contains a small allowlist, not an open-ended capability claim. Unquantized weights pass. FP8 passes only when it is block-wise. Every absent method hard-errors because post-load metadata, transposition, packing, or new tensor attributes may not be reconstructible in the meta-initialized client.

GLM-5.2 candidate	Pinned allowlist	What the result means
BF16, unquantized	Eligible	Source permits an experiment; the roughly 1.5 TB checkpoint still needs a valid topology and parity run
Official zai-org/GLM-5.2-FP8	Eligible because block size is 128×128	Best first candidate, but no combined GLM-5.2 WCD test was observed
Per-tensor FP8	Hard error	Current source says its post-load transpose cannot be reproduced safely
NVIDIA GLM-5.2 NVFP4	Hard error	nvfp4 is absent from the allowlist; use the dedicated NVFP4 guide without WCD
AMD GLM-5.2 MXFP4	Hard error	mxfp4 is absent; use the ROCm guide and keep WCD off

“Eligible” is intentionally weaker than “supported for production.” Registered WCD tests use Qwen/Qwen3-0.6B at TP1 and TP2. The manual WCD harness is generic. The pinned GLM-5.2-FP8 test file separately exercises TP8, TP8+DP8, and TP8+DP8+MTP, but never sets a weight-cache mode. We observed zero combined GLM-5.2 plus WCD tests in this source set.

Do not expand the allowlist locally to make a preferred artifact start. The hard error exists to prevent silent wrong numerics. Adding a method requires a full parity artifact: final names, shapes, dtypes, strides, bytes, storage relationships, module metadata, short quality checks, and failure semantics.

Map fingerprint and socket identity

WCD compares a CacheConfig before handing a client its tensors. The pinned fingerprint has fourteen fields:

Identity group	Present fields	Missing identity relevant to deployment
Model	model_path, model_arch, revision	Resolved artifact equivalence is not inferred; exact values matter
TP and PP	tp_size, tp_rank, pp_size, pp_rank	These ranks are represented
DP and EP	dp_size, ep_size	dp_rank and ep_rank are absent
Quantization	quant_method, quant_config_hash, dtype	An allowlist pass still needs model parity
Environment	device_capability, torch_version	Driver, image digest, kernels, and full dependency graph are not one field
Node and instance	none	node_rank, physical GPU identity, protocol version, and instance namespace are absent

The open roadmap issue #33522 explicitly calls for ep_rank, dp_rank, and node_rank. It also proposes a namespace based on physical GPU identity plus configuration. Those are future tasks in the observed issue, not capabilities to infer from the presence of ep_size or dp_size.

The default socket path is /tmp/sglang_weight_cache_rank{global_rank}.sock, with:

global_rank = tp_size × pp_rank + tp_rank

For TP8/PP1, the paths end in ranks 0–7. For TP8/PP2, they end in 0–15. Two independent TP4 instances on the same default runtime namespace both request ranks 0–3. The deterministic receipt reproduces all four collisions. Current launcher code does not supply a general daemon namespace flag, so the first pilot should run one task-owned daemon set only. Do not use --force around an uncertain existing socket: it can remove a valid task’s state.

Model path identity can also surprise an operator. A local symlink, mounted path, and Hugging Face repository string can refer to the same bytes but produce different fingerprint text. Use the exact same model path, revision, TP/PP layout, dtype, quantization config, device capability, and Torch version for daemon and client. A mismatch is a stop signal, not a reason to weaken the fingerprint.

Remove MTP, DP, and EP from the first pilot

GLM-5.2 deployment recipes often use features that the first WCD pilot must omit. This is why copying a high-throughput production command into a WCD experiment is unsafe.

MTP and speculative decoding are a hard conflict. GLM-5.2 ships an MTP layer and SGLang’s cookbook recommends EAGLE variants for some profiles. Pinned ServerArgs rejects any non-null --speculative-algorithm when WCD is on because the daemon does not export draft-model weights. The dedicated GLM-5.2 MTP guide remains valid for an ordinary launch; it is not composable with this WCD revision.

DP is not established by a size field. The roadmap says multiple DP ranks on a GPU should eventually map one daemon and explicitly tracks dp_rank keying. Until that contract and a combined test land, a TP8+DP8 GLM test elsewhere in the tree does not prove WCD DP behavior.

EP needs rank-specific expert shard identity. GLM-5.2 has 256 routed experts, and large serving layouts commonly use expert parallelism. Current WCD fingerprint records ep_size but not ep_rank; the roadmap says expert shards differ and must be keyed by rank. Use the expert-parallelism guide to size a normal deployment, but keep EP out of the initial WCD claim.

Multi-node launch is not coordinated failover. Phase 1 includes a basic multi-node TP/PP launcher. The same roadmap still lists cross-node daemon coordination, primary/secondary lifecycle, failover, discovery, and node rank identity as unfinished. A command that starts across nodes is not evidence that the service recovers coherently when one daemon or node disappears.

The narrow candidate is therefore: one isolated TP8 GLM-5.2-FP8 experiment, one standalone daemon set, one client, one node if suitable hardware is available, no DP, no EP, no PP unless separately justified, and no speculative flags. If the actual production graph requires excluded features, record WCD as blocked rather than testing a topology that cannot answer the production question.

Reconcile publication and source behavior

The launch publication and pinned client source disagree about one failure path. The publication says a config mismatch in client mode falls back to disk. The pinned IpcModelLoader says disk fallback is allowed only when the Unix socket file is genuinely absent. Other failures are hard errors:

Condition	Pinned client result	Operational interpretation
Socket path does not exist	Disk fallback	Cache is absent; record the miss so a slow path is not mistaken for success
Socket exists but connection is refused	Hard error	A stale or crashed daemon must be repaired explicitly
CacheConfig differs	Hard error	Do not disk-load beside a potentially incompatible resident allocation
Protocol or tensor transfer fails	Hard error	Stop rather than serve partially mapped or ambiguous state
Any cache failure in engine-spawned daemon mode	Hard error	A second disk copy could exhaust GPU memory
Serving daemon dies after mapping	Client terminates	Mapped pointers cannot be trusted after owner loss

This is source-versus-publication drift, not proof that either behavior will remain forever. Pin the exact runtime and assert each path in the pilot. Alert on fallback separately from cache hit. Otherwise an operator can celebrate a healthy server that quietly took the ordinary disk path.

The source also checks device capability and Torch version. That reduces one class of cross-environment mismatch, but it does not replace image and driver pinning. Record container digest, SGLang commit, CUDA, driver, Torch, kernel libraries, allocator, model revision, launch flags, device UUIDs, and filesystem mounts in the test receipt.

Build a two-path parity harness

Correctness comes before latency. Construct two engines from the same immutable artifact: control A loads normally with WCD off; candidate B maps the standalone daemon. Change no other performance variable.

The daemon and client scaffold below shows the shape of the candidate, not a copy-paste production recipe. It deliberately omits speculative, DP, and EP flags. Replace the environment placeholders with pinned, reviewed values and keep the ordinary WCD-off command beside it.

Narrow TP-only candidate scaffold

MODEL_ID="zai-org/GLM-5.2-FP8"
MODEL_REVISION="ba978f7d347eaf65d22f1a86833408afdb953541"

python -m sglang.srt.weight_cache.daemon \
  --model-path "$MODEL_ID" \
  --revision "$MODEL_REVISION" \
  --tp-size 8 \
  --dtype auto \
  --trust-remote-code

python -m sglang.launch_server \
  --model-path "$MODEL_ID" \
  --revision "$MODEL_REVISION" \
  --tp-size 8 \
  --weight-cache-mode client \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --trust-remote-code

The two paths need structural comparison before requests:

1. Enumerate every parameter and buffer after all post-load transforms.
2. Compare name, shape, dtype, stride, device, byte hash, and persistence.
3. Verify tied or shared storage relationships and parameter-to-buffer changes.
4. Capture quantization scales, packed layouts, and whitelisted module attributes required by the forward path.
5. Fail if either side has an unmatched tensor or attribute. Sampling a few layers is insufficient for a 78-layer MoE checkpoint.

Then run a fixed protocol and quality suite. At minimum include deterministic short prompts, reasoning on and off, glm45 reasoning separation, glm47 tool calls, streaming deltas, cancellation, stop behavior, long-context samples, and a quality set such as GSM8K. Compare token IDs and log probabilities when the kernel path permits determinism; otherwise define a statistically justified quality tolerance before seeing the candidate result.

Store hashes and summarized results, not sensitive prompts or credentials. Never archive a real API key, model-access token, cookie, full customer request, or unrestricted runtime dump. WCD is local model infrastructure; it does not need a hosted GLM call to establish parity.

Measure every restart stage separately

After parity passes, instrument the restart timeline. Use monotonic timestamps and a shared event schema so the control and candidate can be joined without hand-edited logs.

Stage	Start and stop definition	Why it stays separate
Daemon cold load	Process start to all reviewed ready files	First load still pays disk, sharding, and post-processing
Client IPC mapping	Client model-load start to all tensors mapped	Closest analogue to the launch post’s weight-load number
Distributed initialization	Rendezvous start to all ranks ready	Can dominate multi-rank recovery independently of weights
Graph and kernel work	Capture/warm-up start to completion	WCD Phase 1 does not preserve graphs or every compiled kernel
KV allocation	Allocation start to usable cache	Weight sharing does not restore KV state
HTTP readiness	Server start to successful health result	A port open is not necessarily model ready
Semantic readiness	Restart trigger to first correct fixture response	Best end-to-end service metric for the pilot
Traffic recovery	Restart trigger to normal error, queue, and latency budgets	Includes application routing and retry behavior

Run enough paired repetitions to report median, p90 or p95, range, and failures. Control filesystem cache state deliberately: a cold storage read and a warm OS page cache answer different questions. Record whether the daemon was already resident, whether graphs or kernels were warm, and whether another workload shared storage or GPUs.

The primary outcome should match the incident being improved. If users care about the first correct response, optimizing only “weights mapped” is a partial result. Publish both the substage and the end-to-end event, and keep any Ling publisher number in a separate, labeled row.

Set stop conditions before timing: parity difference, unexpected disk fallback, socket collision, daemon liveness loss, HBM reserve breach, stale ready file, wrong rank attachment, health success with fixture failure, or rollback failure. Excluded runs should remain visible in the receipt rather than disappearing from the latency distribution.

Inject failure before promotion

Fast happy-path mapping is insufficient for production. Exercise the exact branches the source exposes:

1. Absent socket: move only the task-owned socket out of the test namespace and confirm client mode records an explicit disk fallback.
2. Stale socket: leave a socket file with no serving daemon and confirm a hard error rather than an accidental disk success.
3. Fingerprint mismatch: change one controlled field, such as revision or TP size, and assert a hard error at the pinned version.
4. Protocol interruption: terminate the connection during transfer and confirm no partially mapped server reaches readiness.
5. Daemon death: after a client maps weights, stop only the task-owned daemon and confirm the client terminates and traffic fails over according to the application contract.
6. Client restart: restart the engine while leaving the daemon healthy; this is the event WCD is intended to improve.
7. Disk rollback: turn WCD off and prove the pinned ordinary launch returns to semantic readiness without stale sockets or cache-only assumptions.
8. Host and process cleanup: confirm only task-owned PIDs, ready files, sockets, ports, containers, and temporary paths were removed.

Promote only when each outcome is deterministic and observable. A cache hit, miss, mismatch, fallback, and hard error need distinct telemetry. The observed roadmap still lists a status command, Prometheus metrics, protocol versioning, runtime-directory permissions, peer credential checks, memory limits, eviction, systemd/Kubernetes recipes, and richer CI as open work. Supply local controls or keep the pilot isolated until the upstream operational surface matures.

Rent only after fixing the experiment

A rented accelerator node can isolate the parity and recovery control after the model revision, topology, image, commands, metrics, and teardown contract are fixed. Choose the exact eight-GPU shape, local storage, driver, container support, IPC behavior, and interconnect required by the experiment. A product page that says “H200” does not prove same-node IPC, storage performance, or the ability to keep a daemon alive across your engine restart workflow.

Build an isolated TP-only recovery pilot

Use a rental only after writing the WCD-off control, standalone-daemon candidate, parity checks, failure matrix, and stop conditions. Keep one task-owned daemon set, pin every artifact, export sanitized evidence, and destroy only the resources created for the pilot. Do not transfer a result across checkpoint revisions, quantization methods, GPU types, storage paths, runtime releases, or TP/DP/EP graphs.

Check current multi-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. Renting GPUs does not establish SGLang Weight Cache compatibility, CUDA IPC behavior, socket isolation, GLM-5.2 tensor or output parity, restart speed, or production failover. Verify the live GPU count, same-node topology, storage, image, driver, IPC permissions, price, egress, and teardown controls before use.

Budget the complete experiment: checkpoint storage and download, daemon cold load, repeated control and candidate starts, quality runs, failure injection, idle resident weights, log retention, and rollback capacity. A lower mapping time does not justify a persistent GPU allocation unless the end-to-end service benefit exceeds that cost and the new failure dependency is acceptable.

Troubleshoot failed pilots

The client rejects speculative decoding

This is expected at the pinned source. Remove every --speculative-algorithm, EAGLE, and MTP-related launch flag, or turn WCD off. Do not patch around the validation: draft-model weights are not exported by the daemon.

Official FP8 still reports unsupported quantization

Verify the exact model revision and inspect the resolved quantization config. The eligible artifact needs quant_method: fp8 and a non-null weight_block_size; this audit observed [128, 128]. A provider-converted, per-tensor, or differently packaged FP8 checkpoint may not meet that condition. Do not force an allowlist match by changing labels.

The socket exists but the engine will not attach

Treat connection refusal as a hard failure. Confirm the socket and daemon belong to this experiment, then compare model path, architecture, revision, TP/PP sizes and ranks, DP/EP sizes, quantization hash, dtype, device capability, and Torch version. Never delete or overwrite an uncertain /tmp socket shared with another process.

A second TP instance attaches to the wrong daemon

Stop the pilot. Two default TP4 instances both derive rank paths 0–3. Current roadmap work proposes a physical-GPU and namespace key, but it is not present in the pinned default. Run one isolated daemon set; do not describe multi-instance sharing as verified from this audit.

The client becomes ready but output differs

Fail correctness immediately. Compare the full tensor and buffer manifest, strides, byte hashes, post-load attributes, tied storage, parser configuration, and exact environment. A quality or token difference is not an acceptable price for restart speed unless a separately designed approximate path has a documented safety case—which WCD zero-copy weight reuse does not require.

Mapping is fast but service recovery is still slow

Inspect distributed initialization, graph capture, kernel warm-up, KV allocation, tokenizer/server startup, health checks, application routing, and first semantic response. WCD Phase 1 targets weights. Optimize the measured dominant phase and retain WCD only if it improves the declared end-to-end goal.

The daemon dies and clients exit

That is the pinned fail-loud contract. CUDA IPC mappings depend on the memory owner. Route traffic away, restart through the reviewed disk path or reload a new daemon, and investigate the owner failure. Do not automatically restart in a loop without proving sockets, rank identity, and resource ownership.

Frequently asked questions

Does SGLang Weight Cache Daemon support GLM-5.2?

The pinned source makes unquantized BF16 and the official block-FP8 checkpoint eligible for a narrow test, but the inspected tests contain no combined GLM-5.2 WCD run. The evidence supports “lab candidate,” not “production support.”

Which GLM-5.2 checkpoint should I test first?

The official zai-org/GLM-5.2-FP8 revision is the practical first candidate because its [128, 128] block-FP8 config passes the source allowlist and its tensor payload is about half the BF16 artifact. Exact node fit, HBM reserve, and parity still have to be measured.

Can I keep GLM-5.2 MTP enabled?

No, not with WCD at pinned v0.5.18. ServerArgs rejects every speculative algorithm because draft weights are not exported. Use either ordinary GLM-5.2 MTP serving or the WCD pilot, not both.

Are DP and EP supported if their sizes are in CacheConfig?

Size fields alone are insufficient. Current cache identity lacks dp_rank and ep_rank, and the open roadmap lists both as required work. Do not infer production shard correctness from dp_size and ep_size.

Does WCD survive a node or GPU failure?

No. It preserves weights in a GPU process while that process and device remain healthy. GPU or node loss removes that resident state. Cross-node lifecycle and failover are separate roadmap work.

Does client mode fall back to disk on every cache problem?

Not in the pinned source. A genuinely absent socket can fall back. Connection refusal, config mismatch, protocol failure, or transfer failure hard-error. The launch publication describes broader mismatch fallback, so test the exact version and alert on each branch.

How fast will GLM-5.2 restart?

Unknown from public evidence inspected here. The roughly 495-to-0.63-second weight-load result belongs to Ling-2.6-1T FP8 on its published system. Measure GLM-5.2 weight mapping and first correct response on your pinned deployment.

Is WCD the same as KV or prompt caching?

No. It shares model weights across an engine restart. KV and prompt caches hold request-dependent attention state or reusable prefixes. WCD Phase 1 does not preserve in-flight context or eliminate prefill after a restart. See the prompt caching guide for that separate task.

Sources and method

The runtime was pinned from the SGLang v0.5.18 release and immutable commit 71de97b264b04dcd514cf904003028aefe9775c8. The audit reads pinned protocol.py, server_args.py, ipc_loader.py, and daemon.py.

Test coverage was separated using the registered WCD daemon test, protocol tests, and the independent GLM-5.2-FP8 test. The feature history comes from merged PR #27139, the open roadmap #33522, and the first-party launch publication.

GLM-5.2 facts come from the pinned official FP8 repository, config, tensor index, and SGLang’s pinned GLM-5.2 cookbook. The fixed per-round Z.AI release page and Zhipu research index were checked as discovery inputs, not WCD compatibility proof. The selected AI HOT item is attribution for the discovery route only.

The committed evidence packet hashes nineteen public responses, publishes five quantization rows, derives TP/PP socket paths and a two-instance collision, records the missing DP/EP/node rank fields, and preserves the Ling-number transfer warning. Its public JSON receipt is byte-identical to the committed result.

No model shard was downloaded. No container, model endpoint, grader, GLM, MiniMax, GPU, or NPU was used. This is a dated source-compatibility audit, not a runtime benchmark. Re-audit the implementation, docs, tests, and roadmap after any SGLang upgrade.

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.