GLM‑5.2 IndexShare

A source-grounded explanation of the shared indexer mechanism used with DSA sparse attention in GLM‑5.2. The core idea: do not recompute the DSA top‑k token indexer in every layer; reuse selected token indices across a small group of layers.

Official name: IndexShare Related paper: IndexCache Model type: glm_moe_dsa 2.9× is FLOPs, not guaranteed end‑to‑end speedup

Verified facts

Context

1,048,576

index_topk

2048

index_topk_freq

Config pattern

full / shared

1. What DSA does before sharing

DeepSeek Sparse Attention uses a lightweight indexer to score previous tokens for each query and select the top‑k relevant positions. The main attention then runs only on those selected positions instead of attending to the full prefix.

For each layer: query hidden state ↓ DSA indexer scores prefix tokens ↓ top-k token indices are selected ↓ sparse attention uses only those indices

2. What IndexShare changes

GLM‑5.2 applies IndexShare so that every 4 transformer layers share one lightweight indexer. The first layer in the group computes top‑k indices; the following layers reuse those indices, reducing indexer dot‑product and top‑k work in 3/4 layers.

Layer group of 4: Layer 0: run indexer → cache top-k indices Layer 1: reuse cached top-k indices Layer 2: reuse cached top-k indices Layer 3: reuse cached top-k indices

Layer execution pattern: standard DSA vs IndexShare

Standard DSA

Every layer runs its own indexer.

Layers

IdxIdxIdxIdx IdxIdxIdxIdx

IndexShare / IndexCache idea

Full layers compute top‑k; shared layers reuse the nearest preceding full layer’s top‑k indices.

Ideal group

FullShareShareShare FullShareShareShare

Important accuracy note: the public GLM‑5.2 config does not start as a perfect F‑S‑S‑S pattern from layer 0. It shows the first three entries as full, then a mostly repeating full + shared + shared + shared pattern. So the implementation should follow indexer_types from config, not hard-code a simplistic pattern.

Public config evidence

"architectures": ["GlmMoeDsaForCausalLM"] "model_type": "glm_moe_dsa" "max_position_embeddings": 1048576 "index_topk": 2048 "index_topk_freq": 4 "index_share_for_mtp_iteration": true "indexer_types": [ "full", "full", "full", "shared", "shared", "shared", "full", "shared", "shared", "shared", ... ]

What is actually shared?

Item	Shared?	Meaning
Top‑k token indices	Yes	Shared layers reuse the selected token positions from a preceding full indexer layer.
Main sparse attention computation	No	Each layer still computes its own attention output using its own hidden states and parameters.
Indexer weights	Effectively fewer active indexer calls	Full layers run the indexer; shared layers skip the indexer forward pass.
KV cache	Not reduced by backbone IndexShare	The blog explicitly notes GLM‑5.2’s architecture reduces FLOPs but does not proportionally reduce per-token KV-cache size.

Why this helps long context

Problem

The DSA indexer still scans/scales with the prefix to choose relevant tokens. At very long context, this selection overhead becomes important.

Observation

IndexCache reports high cross-layer overlap in selected top‑k tokens: consecutive layers often choose similar important token sets.

Optimization

Run the indexer only at selected full layers, cache the top‑k indices, and reuse them in shared layers.

Z.AI reports IndexShare reduces per-token FLOPs by 2.9× at 1M context length. This should not be read as “2.9× end-to-end latency speedup” because real serving latency also includes MoE, KV cache traffic, scheduling, communication, kernels, and CPU overhead.

MTP path: IndexShare + KVShare

GLM‑5.2 also applies IndexShare to the MTP layer used for speculative decoding. For multi-step MTP, the indexer is placed at the first step and top‑k indices are reused by following steps. The blog additionally says KVShare is used in the MTP path to reduce training/inference mismatch, with an ablation showing acceptance length improving from 4.56 to 5.47 after adding IndexShare+KVShare, rejection sampling, and end-to-end TV loss.

Implementation checklist

Check	Why it matters
Parse `model_type=glm_moe_dsa`	GLM‑5.2 is not a standard dense attention model.
Respect `indexer_types`	Do not run indexer on every layer if the config marks the layer as shared.
Cache top‑k indices from full layers	Shared layers need the previous full layer’s selected positions.
Use `index_topk=2048`	This is the released model config value.
Do not claim KV-cache reduction	Backbone IndexShare mainly reduces indexer compute, not KV size.

Sources and what each source supports

Source	Used for
Z.AI / Hugging Face GLM‑5.2 blog	IndexShare definition, 4-layer sharing, 2.9× per-token FLOPs claim, MTP IndexShare/KVShare details.
GLM‑5.2 config.json	Actual released config: `glm_moe_dsa`, `index_topk=2048`, `index_topk_freq=4`, `indexer_types`, 1M context.
IndexCache paper	General mechanism: Full layers compute fresh indices; Shared layers reuse nearest preceding Full layer’s top‑k indices; motivation from cross-layer redundancy.
GLM‑5 technical report page	GLM‑5 context for DSA architecture and long-context engineering.

Last checked: 2026‑06‑26. Claims not directly supported above are intentionally avoided.