GLM-5.2 SGLang DSA Indexer Fusion: Speed and Memory

Evan Brooks

AI Infrastructure Editor

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

How we research and review · Report a correction

Disclosed editorial pen name · AI-generated portrait

The deployment verdict

For a pinned SGLang v0.5.18 CUDA deployment of GLM-5.2 with its normal interleaved RoPE, leave DSA indexer fusion on only as a measured candidate. Compare it with an otherwise identical process started with SGLANG_DISABLE_DSA_INDEXER_FUSION=1. Promote the fused path only if output parity, low- and high-concurrency service metrics, total HBM, usable KV capacity, CUDA-graph stream count, and restart rollback all pass. Do not use this recommendation for ROCm/NPU, NeoX-style indexers, an unpinned build, or an adapter that targets the DSA indexer.

Original editorial illustration: the small tiles represent a fragmented indexer prologue, the four larger modules represent fused work, and the lower route represents a rehearsed rollback. It is not an SGLang profiler trace, memory capture, or benchmark result.

SGLang’s DSA indexer fusion is easy to misunderstand because it is not a prominent server flag that an operator normally turns on. In the eligible GLM-5.2 CUDA path, the runtime constructs a fused indexer by default. The visible control is the negative one: an environment variable that disables fusion and restores the split path.

That default makes the optimization operationally important. The upstream evidence reports meaningful decode gains, but the change also has a repair history involving CUDA graph streams, a closed but unmerged report of a large capacity loss, a RoPE-style accuracy boundary, and a pinned source edge for indexer-targeted LoRA. “Fewer kernels” is therefore a hypothesis to test, not a reason to skip a control.

This guide pins SGLang v0.5.18 at commit 71de97b264b04dcd514cf904003028aefe9775c8 and GLM-5.2-FP8 revision ba978f7d347eaf65d22f1a86833408afdb953541. The machine-readable audit receipt hashes twenty-one public artifacts and reproduces the percentages below. We made zero model calls, zero local GPU runs, and zero local upstream-test runs. Every upstream performance or accuracy row remains labeled as a publisher or PR-author result.

In this guide

1. Understand what the fusion changes
2. Pin the release before comparing
3. Check whether the path is active
4. Read the throughput evidence correctly
5. Reconcile the memory evidence
6. Follow the CUDA graph repair history
7. Separate GLM accuracy from the NeoX regression
8. Audit the v0.5.18 indexer-LoRA edge
9. Build a one-change A/B canary
10. Measure memory and capacity live
11. Validate output before promoting
12. Roll back with one environment variable
13. Rent only after the experiment is fixed
14. Troubleshoot ambiguous results
15. Frequently asked questions
16. Sources and method

Understand what the fusion changes

GLM-5.2 uses DeepSeek Sparse Attention (DSA). Before sparse attention can read selected positions, the indexer prepares query and key representations, calculates head-gate values, quantizes the index query, and writes the index-key cache. Small operations in that prologue can become expensive during decode because they repeat across many layers and tokens.

SGLang pull request #27705 changes that prologue in four ways:

1. The index-key projection and head-gate projection become one BF16 matrix multiplication instead of two.
2. Query RoPE, optional Hadamard handling, FP8 quantization, and head-gate scaling move into one fused query kernel.
3. Key normalization, RoPE, optional Hadamard handling, FP8 quantization, and the index-cache write move into one fused key kernel.
4. The key and query sides can overlap instead of leaving the cache store on the critical path.

The v0.5.15 release notes summarize the result as an indexer prologue reduced from 12 kernels to 4. That is a 66.67% kernel-count reduction, but it is not a 66.67% latency claim. Kernel launch overhead, GEMM efficiency, overlap, graph capture, allocator state, batch shape, and the rest of the model still determine end-to-end performance.

The fused projection is especially concrete for the pinned checkpoint. Its config declares a 6,144-wide hidden state, a 128-dimensional index key, 32 index heads, and 78 decoder layers. The fused matrix therefore produces 160 rows per layer:

Pinned GLM-5.2 fused projection shape

fused output rows = index_head_dim + index_n_heads
                  = 128 + 32
                  = 160

per-layer matrix = [160, 6144] in BF16

This is an indexer-prologue optimization. It does not replace expert parallelism, MTP, KV-cache policy, or DSA cache ownership. Use the expert-parallelism guide for expert placement, the MTP guide for draft decoding, and the LayerSplit guide for PD-prefill cache sharding.

Pin the release before comparing

The optimization landed just after v0.5.14, then received two important fixes before v0.5.15. A version string or main checkout without a commit is too coarse for a useful A/B.

SGLang boundary	Pinned commit	Fusion state	Operational meaning
v0.5.14	49e384ce…	Absent	Clean pre-feature source control, but also older in every other way
v0.5.15	f63458b5…	Present; eligible GLM path defaults on	First stable tag with the fusion plus early stream and RoPE gates
v0.5.18	71de97b2…	Present; eligible GLM path defaults on	Current audit target and recommended comparison baseline

Do not use v0.5.14 as the production “off” arm. It changes far more than one feature. The clean control is the same v0.5.18 build, same image digest, same checkpoint revision, and same launch arguments, with only the disable environment variable changed.

Record provenance without importing the full CUDA runtime:

Record the exact candidate provenance

python - <<'PY'
from importlib.metadata import version
print("sglang", version("sglang"))
PY

python - <<'PY'
import json
from pathlib import Path

config = json.loads(Path("/models/GLM-5.2-FP8/config.json").read_text())
for key in (
    "model_type",
    "num_hidden_layers",
    "hidden_size",
    "index_head_dim",
    "index_n_heads",
    "index_topk",
    "indexer_rope_interleave",
):
    print(key, config.get(key))
PY

The second block assumes a locally pinned config path. If the model is loaded from a mutable cache reference, record the resolved Hugging Face commit as well. A package version plus a model name is not enough to reconstruct a canary months later.

Check whether the path is active

The pinned v0.5.18 dsa_indexer.py constructs the fused path when three source conditions are true:

Pinned fusion eligibility

CUDA platform
AND SGLANG_DISABLE_DSA_INDEXER_FUSION is false
AND the indexer is not NeoX-style RoPE

The pinned environment declaration sets the disable flag to false. GLM-5.2’s config declares interleaved RoPE, not NeoX style. The ordinary GLM-5.2 CUDA arm therefore enters fusion by default.

Platform and workload	Disable value	Pinned result	Use in this canary
CUDA, GLM-5.2 interleaved RoPE	0 or unset	Fusion on	Candidate
CUDA, same GLM-5.2 process	1	Split path	Control
ROCm or NPU	Either	This CUDA fusion is ineligible	Different implementation; do not transfer results
CUDA, NeoX-style indexer	0	Fusion gated off	Different model boundary
CUDA, adapter targets DSA indexer	Either	v0.5.18 source edge	Exclude pending a dedicated fix and test

An environment snapshot should record the variable without dumping unrelated secrets:

Record only the fusion control

python - <<'PY'
import os

raw = os.getenv("SGLANG_DISABLE_DSA_INDEXER_FUSION")
print("SGLANG_DISABLE_DSA_INDEXER_FUSION", raw if raw is not None else "<unset>")
PY

Do this in both arms. A typo such as setting the variable only in an interactive shell while the service manager starts a clean environment can make both arms identical.

Read the throughput evidence correctly

The upstream performance evidence is encouraging but narrow. Pull request #27705 reports two B300 decode cells:

Reported cell	Fusion off	Fusion on	Reproduced change
Batch 1, zero-context decode	97.72 tok/s	107.77 tok/s	+10.284486%
Batch 128 decode	3,212.05 tok/s	3,418.63 tok/s	+6.431407%

The v0.5.15 release note separately rounds the batch-one improvement to about 8%. Those values belong to the upstream author and release environment. This audit did not run a B300, load the checkpoint, or reproduce either result.

The shape of the evidence still teaches two useful lessons. First, the gain is larger in the low-batch cell where launch and prologue overhead are easier to see. Second, a high-batch win remains possible but is smaller. A canary that tests only saturated throughput can miss the latency-sensitive reason the feature exists; a canary that tests only one request can miss scheduling, memory, and capacity costs.

Use at least these workload cells:

Cell	Why it exists	Minimum outputs
Decode batch 1, short context	Exposes per-token prologue cost	inter-token latency, output tok/s, GPU utilization
Decode batch 1, long context	Adds index-cache pressure	inter-token latency, HBM, cache capacity
Moderate steady concurrency	Represents normal service mix	p50/p95 latency, accepted output tok/s, queue time
Near capacity	Finds allocator or cache cliffs	admission failures, preemptions, HBM, usable tokens
EAGLE/MTP graph arm if used	Covers the repaired stream ordering	graph streams, verify cost, acceptance length

Do not compare raw output tokens per second when one arm produces shorter, truncated, repeated, or malformed completions. Throughput becomes meaningful only after both arms pass the same output contract.

Reconcile the memory evidence

The memory story contains a valuable unresolved mismatch. The fused loader places the index-key and head-gate projections into one BF16 parameter. For the pinned FP8 checkpoint, idealized tensor payload arithmetic gives:

Projection payload only, per rank

fused = 78 × 6144 × (128 + 32) × 2 bytes
      = 146.25 MiB

split  = 78 × 6144 × (128 × 1 byte + 32 × 2 bytes)
       = 87.75 MiB

payload delta = 58.50 MiB

This simplified calculation intentionally excludes block scales, alignment, allocator reserve, compiled kernels, CUDA graphs, workspaces, KV and index caches, MTP state, and every other model tensor. It tells us the scale of the obvious FP8-to-BF16 projection payload. It does not predict process HBM.

SGLang pull request #29564, which was closed without merge, reports a very different runtime observation for GLM-5.2-NVFP4 with MTP. The author measured roughly 19–20 GB more target memory per rank with fusion and less room for KV cache:

Reported hardware / TP	KV capacity off	KV capacity on	Reproduced change
B300 / TP4	1.90M tokens	1.52M	−20.000000%
GB300 / TP4	2.04M	1.66M	−18.627451%
B300 / TP2	582K	199K	−65.807560%
GB300 / TP2	736K	353K	−52.038043%

The static 58.5 MiB FP8 projection delta cannot by itself explain a 19–20 GB runtime delta. The report also uses an NVFP4 checkpoint whose indexer loading details differ from the FP8 arithmetic above. The correct conclusion is not “fusion weights cost 20 GB.” It is: a large upstream runtime observation exists, its allocation source is unresolved here, and capacity must be measured on the exact candidate.

Preserve these as separate facts:

• Verified arithmetic: idealized pinned FP8 projection payload changes by 58.5 MiB per rank.
• Reported observation: one closed, unmerged NVFP4/MTP experiment saw a 19–20 GB target-memory shift and large capacity changes.
• Not established: which graph, workspace, allocator, compilation, buffer, checkpoint, or other state accounts for the remainder.

If memory is the primary decision, the off arm is not optional. It is the instrument that turns an unexplained report into a deployment-specific answer.

Follow the CUDA graph repair history

The initial fusion did not simply move from “off” to “on.” With GLM-5.2-NVFP4, TP4, EAGLE speculative decoding, and CUDA graph capture, the fused dual-stream issue order created about 22 graph streams instead of two.

Pull request #30018 temporarily turned fusion off by default. Then pull request #30025 reordered the second overlap stage: enqueue the main-stream fused query work before the alternate-stream fused key/cache work. The author reports that graph capture could then reuse one alternate stream, reducing the captured graph from 22 streams to 2.

The same ten-run comparison reports:

Reported arm	Per-step verify cost
Pre-fix fused head	11.817 ms
Fusion off	12.167 ms
Reordered fusion	11.833 ms

The reordered result is 2.74513% lower than the fusion-off cell and effectively even with the original fused cost, while the stream count falls by 90.91%. These are upstream profiler and benchmark results, not a local Nsight capture.

This history matters even on v0.5.18, which contains the fix. Graph behavior depends on the exact feature combination and runtime. If production uses MTP speculative decoding, add a graph-profile cell; do not assume plain autoregressive throughput covers it. Record the SGLang commit, PyTorch/CUDA versions, graph mode, draft settings, maximum running requests, and captured stream count.

Separate GLM accuracy from the NeoX regression

Soon after fusion landed, a scheduled DeepSeek-V3.2 test showed an accuracy regression. That model uses NeoX-style RoPE pairing. The fused kernels had been written for the interleaved/GPT-J-style pairing used by GLM-5.x.

Pull request #30088 documents the regression, while merged pull request #30111 root-causes it and adds the current not is_neox_style eligibility gate. At the pinned v0.5.18 source, NeoX-style indexers stay on the split path.

That history should not be converted into “fusion harms GLM-5.2 accuracy.” The pinned GLM-5.2 config declares interleaved RoPE, so the broken NeoX pairing is outside its fused path. A later, closed and unmerged PR #30342 includes a GLM-5.2-NVFP4 TP4/EP4 control: mean GSM8K 0.943 for the current-main fused path and 0.945 with fusion off. Its author interprets this as no material GLM movement.

That is still reporter evidence. A two-thousandths aggregate gap does not prove your outputs are identical, and GSM8K alone does not cover tool calls, long context, multilingual prompts, structured output, or your service protocol. The practical boundary is:

• Do not transfer a NeoX root cause to the interleaved GLM path.
• Do not transfer a small upstream GLM aggregate difference into a universal parity guarantee.
• Compare exact responses and task acceptance under the same decoding seeds or deterministic settings before comparing speed.

Audit the v0.5.18 indexer-LoRA edge

The pinned source contains a separate reason to exclude indexer-targeted LoRA from this canary. When LoRA target modules intersect DSA_INDEXER_LORA_NAMES, the v0.5.18 LoRA manager tries to import a module-level helper named _use_dsa_indexer_fusion from dsa_indexer.py. The intended next step is a friendly error telling the operator to disable fusion.

However, PR #30111 removed that module-level helper while switching eligibility to self.use_dsa_indexer_fusion. The symbol is absent from the pinned indexer file. The static audit therefore finds:

Pinned v0.5.18 source question	Result
LoRA manager imports _use_dsa_indexer_fusion in the indexer-target branch	Yes
DSA indexer defines that module-level symbol	No
This task captured a live traceback	No
Setting the environment flag can recreate a missing Python symbol	No

This is a source-proven unresolved import edge, not a runtime reproduction. It means the intended “disable fusion for indexer LoRA” message can itself be blocked before it executes. Do not infer that every LoRA adapter fails: the specific branch requires a target that intersects the DSA indexer names.

For v0.5.18, keep indexer-targeted adapters outside the fusion experiment. If that adapter is the workload, pin a known fix or audited patch, add a startup test that reaches the exact target-module branch, and then run correctness and performance controls. Do not describe SGLANG_DISABLE_DSA_INDEXER_FUSION=1 as a complete workaround for this exact missing-symbol path.

Build a one-change A/B canary

The candidate and control must differ by one environment value. Do not compare different SGLang releases, checkpoint formats, GPU types, graph modes, or parallel topologies and call the difference “fusion.”

Candidate: eligible fusion-on process

env SGLANG_DISABLE_DSA_INDEXER_FUSION=0 \
  python -m sglang.launch_server \
  --model-path /models/GLM-5.2-FP8 \
  --tp-size 8 \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --host 127.0.0.1 \
  --port 30001

Control: identical process with fusion disabled

env SGLANG_DISABLE_DSA_INDEXER_FUSION=1 \
  python -m sglang.launch_server \
  --model-path /models/GLM-5.2-FP8 \
  --tp-size 8 \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --host 127.0.0.1 \
  --port 30002

Those snippets illustrate the one-change contract; they are not a universal topology recommendation. Use the topology that the pinned checkpoint, GPUs, fabric, and service already validated. Do not run both full checkpoints on the same GPUs at once if that changes allocator or thermal behavior. Sequential runs should use the same warmup, prompt order, cache policy, and measurement window.

Freeze these dimensions:

A/B invariants

SGLang package + source commit
container image digest and CUDA/PyTorch stack
checkpoint files + resolved revision
TP / DP / EP / PP layout and node placement
MTP/EAGLE and CUDA-graph settings
attention, cache, parser, and quantization settings
prompt corpus, seeds, temperatures, and output caps
warmup count, measurement order, concurrency schedule
GPU clocks/power policy and background workload

Run the order more than once—off/on and on/off—when setup time permits. A single sequential order can confound fusion with cache warmth, JIT compilation, clock state, or a neighboring workload.

Measure memory and capacity live

Do not record only nvidia-smi after startup. The unmerged memory report is about how target memory changes usable KV capacity, so the test needs both whole-process and allocator-specific observations.

For each arm, capture:

• HBM before load, after weight load, after graph capture, after warmup, and at steady state.
• SGLang’s reported static memory fraction, KV pool bytes, and estimated token capacity.
• CUDA graph pool or workspace allocations where the runtime exposes them.
• Maximum admitted requests and tokens before preemption or rejection.
• Cache hit/miss behavior under the same prompt order.
• Any difference in compiled-kernel or graph-capture count.

A useful result table keeps phase and scope explicit:

Phase	Fusion off	Fusion on	Difference	Evidence source
Weight load HBM	—	—	—	process/GPU telemetry
Post-graph HBM	—	—	—	process/GPU telemetry
KV pool bytes	—	—	—	SGLang log or metric
Estimated KV tokens	—	—	—	same runtime revision
Max admitted fixed-shape requests	—	—	—	controlled load

If the live delta is small, say that the upstream 19–20 GB cell did not reproduce on the named stack. If it is large, profile allocation phases before assigning a cause. Either result is more useful than repeating the unmerged PR as a universal fact.

Validate output before promoting

Kernel fusion changes operation grouping, storage, and FP8 preparation. Even when an upstream aggregate score is stable, production acceptance should be checked at the response level.

Build a fixed corpus that represents the service:

• short and long plain-text completions;
• code generation with executable tests;
• JSON or schema-constrained output;
• tool calls with exact function name and argument validation;
• reasoning-on and reasoning-off requests if both are served;
• Chinese and English prompts if both matter;
• prompts near the indexer’s 2,048 top-k boundary and the service’s long-context limits;
• MTP/EAGLE requests if the deployment uses speculative decoding.

Compare more than exact bytes when sampling is nondeterministic. Use a layered grader:

1. Protocol status, finish reason, and token accounting match the contract.
2. Structured outputs parse and validate.
3. Tool names and arguments pass allowlisted schemas.
4. Code passes the same tests.
5. Deterministic prompts match exactly when deterministic settings are expected.
6. Nondeterministic outputs meet task-specific acceptance thresholds with no new repetition, truncation, or malformed-text pattern.

Keep correctness and performance gates separate. A candidate fails if it is faster but loses accepted tasks. It also fails if output is correct but the capacity drop breaks the service budget. A useful promotion rule might be:

Example promotion contract

zero protocol or structured-output regressions
zero deterministic mismatches on the fixed corpus
no statistically material accepted-task regression
p95 inter-token latency improves or stays inside budget
usable KV capacity stays above the traffic forecast plus reserve
captured graph stream count remains bounded in the MTP arm
one-variable restart rollback completes inside the recovery objective

Roll back with one environment variable

The rollback is a process restart, not a hot toggle. The environment value is read when the indexer is constructed, so changing a parent shell after the server has started does not change that server.

Rollback control

export SGLANG_DISABLE_DSA_INDEXER_FUSION=1
# Restart the same pinned service through its normal supervisor.

Before promotion, rehearse the complete path:

1. Drain or redirect traffic according to the service plan.
2. Restart the exact image and checkpoint with the disable value set to 1.
3. Confirm the service manager passed the variable to the process.
4. Run a short output and health canary.
5. Confirm memory, cache capacity, and graph behavior returned to the recorded control range.
6. Restore traffic and preserve the incident evidence.

Do not delete the off-arm configuration after a successful experiment. Keep it as a versioned, tested rollback until the next runtime upgrade has its own A/B. An upgrade from v0.5.18 changes the evidence boundary and should not inherit this result silently.

Rent only after the experiment is fixed

A rented GPU cluster can be a useful isolated canary when it reproduces the required GPU architecture, count, topology, image, and checkpoint. It is not evidence by itself. B300 and GB300 measurements cannot be transferred to an H200 listing, and a nominal GPU name does not specify NVLink, inter-node fabric, storage bandwidth, or available HBM after provider overhead.

Run the fusion-on/off canary on isolated GPUs

Rent only after fixing the two launch environments, checkpoint revision, topology, prompt corpus, measurement phases, failure thresholds, cost ceiling, and cleanup plan. Archive sanitized logs and metrics, then remove only the task-owned cluster resources. A fast rented result does not override a failed output, memory, or rollback gate.

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. A rental does not verify SGLang v0.5.18, GLM-5.2 checkpoint compatibility, B300/GB300 equivalence, NVLink or RDMA topology, indexer fusion, memory capacity, CUDA graph behavior, output parity, or performance. Verify the live SKU, topology, HBM, storage, egress, image digest, price, and teardown policy before use.

For broader checkpoint choices, start with the GLM-5.2 NVFP4 SGLang guide or the local deployment guide. This page answers only the indexer-fusion decision inside a compatible deployment.

Troubleshoot ambiguous results

Both arms have identical speed and memory

First verify that the environment reached the service process. Then confirm the model actually uses the DSA indexer, the platform is CUDA, the runtime is the pinned build, and the test does not use a NeoX-style indexer that v0.5.18 gates off. Identical results may be valid at a workload where the indexer prologue is not limiting, but prove activation before drawing that conclusion.

Fusion is faster but usable KV capacity falls sharply

Keep the candidate unpromoted. Compare phase-by-phase HBM, graph pools, workspace allocation, cache-pool bytes, and admission capacity. Repeat after reversing run order. The upstream memory report establishes a reason to measure, not the allocation cause. Prefer the split path if the capacity loss violates the service reserve even when per-token speed improves.

EAGLE creates many graph streams

Confirm the SGLang commit includes PR #30025 and that no downstream patch reordered the same main/alternate stream sequence. Record graph mode, draft steps, top-k, draft tokens, concurrency, CUDA/PyTorch versions, and a profiler capture. Disable fusion for the immediate control; do not improvise a partial stream patch during a production incident.

An indexer-targeted LoRA fails before the friendly message

Check whether the traceback names _use_dsa_indexer_fusion. The pinned v0.5.18 source imports that removed helper in the indexer-target branch. The disable environment value does not restore a missing symbol. Use a separately audited fix or avoid that adapter/runtime combination; do not broaden a local patch into an untested production release.

Output differs but aggregate accuracy looks similar

Find which acceptance layer changed: protocol, parsing, tool arguments, deterministic content, executable tests, or semantic grading. An aggregate GSM8K mean cannot authorize changes in a tool-using or structured-output service. Treat unexpected deterministic drift as a failure until explained.

The candidate wins only after the first run

Separate cold compilation and graph capture from steady state. Use identical warmups, reverse arm order, and report cold and warm results independently. Do not hide startup cost inside a steady-state throughput number if restarts or autoscaling matter to the service.

Frequently asked questions

Is DSA indexer fusion on by default for GLM-5.2 in SGLang v0.5.18?

Yes for the pinned eligible CUDA path with GLM-5.2’s interleaved RoPE and an unset or false disable flag. The source also requires a non-NeoX indexer. This answer does not apply to ROCm/NPU or a different SGLang revision.

Which variable disables GLM-5.2 DSA indexer fusion?

Set SGLANG_DISABLE_DSA_INDEXER_FUSION=1 before starting the server. Restart the process; it is not a hot runtime switch. Keep every other candidate/control dimension fixed.

Does fusion make GLM-5.2 about 10% faster?

One upstream B300 batch-one cell changes from 97.72 to 107.77 tokens per second, a reproduced 10.284486% increase. The v0.5.15 release notes summarize about 8%, and the upstream batch-128 cell is 6.431407%. None is a guarantee for another GPU, topology, context, graph, or request mix.

Does fusion use 20 GB more GPU memory?

Not as a universal conclusion. A closed, unmerged NVFP4/MTP PR reports about 19–20 GB more target memory in named B300/GB300 cells. The idealized extra FP8 projection payload calculated here is only 58.5 MiB per rank, so the large runtime observation requires live allocation-phase reconciliation.

Is the DeepSeek-V3.2 accuracy regression a GLM-5.2 regression?

No. It was root-caused to applying interleaved fused RoPE handling to a NeoX-style model. v0.5.18 gates NeoX indexers out. GLM-5.2 uses interleaved RoPE, but still needs workload-specific output parity before promotion.

Can I use indexer-targeted LoRA if I disable fusion?

Do not rely on that alone in pinned v0.5.18. The LoRA manager’s indexer-target branch imports a helper that is absent from the pinned indexer module, so it can fail before reaching its intended disable-fusion message. Audit a fix and run the exact startup branch first.

Is fewer kernels always better?

No. Fewer launches can reduce overhead and enable overlap, but the total result also depends on matrix efficiency, graph capture, memory pools, workspaces, cache capacity, batch shape, and correctness. The 12-to-4 change justifies an A/B; it does not decide it.

Sources and method

The feature and release boundary comes from SGLang v0.5.15, v0.5.18, and PR #27705. The graph history uses PR #30018 and PR #30025. The RoPE boundary uses PR #30088, PR #30111, and the explicitly unmerged PR #30342. The memory observation comes from the explicitly unmerged PR #29564.

The pinned model facts come from the GLM-5.2-FP8 config and model card. Z.ai’s official GLM-5.2 release page and Zhipu AI’s research index were checked as required first-party discovery entries; they do not prove the SGLang runtime claims.

The deterministic audit hashes twenty-one public artifacts, calculates the two throughput changes, the four reported capacity changes, the 12-to-4 kernel and 22-to-2 stream reductions, and the pinned FP8 projection payload. It also checks that the v0.5.18 LoRA manager imports a module-level symbol absent from the pinned indexer source. Re-run the committed calculator with:

node docs/evidence/glm-5-2-sglang-dsa-indexer-fusion-2026-08-24/calculate.mjs

The exact output is mirrored in the public machine-readable receipt. No checkpoint was downloaded, no model was called, no GPU test ran locally, and no upstream reporter measurement is presented as an independent GLM52.ai benchmark. The added value is a bounded decision: a pinned default-on CUDA path, a same-build disable control, explicit memory and graph uncertainties, an indexer-LoRA exclusion, and measurable promotion and rollback gates.

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.