GLM-5.2 IndexShare: Validate Pipeline Stage Boundaries

Independent research — not an official Z.ai publication.Identity and provider disclosure

AI Infrastructure Editor

Editorial responsibility: GLM52.ai Editorial TeamPublished and editorially reviewed August 2, 2026

How we research and review Report a correction

Disclosed editorial pen name · AI-generated portrait

Eight GLM-5.2 IndexShare pipeline stages sized 14, 8, 8, 8, 8, 8, 8 and 16 layers start on full index-computing layers

Original editorial diagram reconstructed from the pinned checkpoint and Vime layout. It is not a Z.ai, Hugging Face, Vime or GPU product screen.

Use 14 / 8 / 8 / 8 / 8 / 8 / 8 / 16 for the pinned Vime GLM-5.2 PP8 profile. Those eight stages begin at global layers 1 / 15 / 23 / 31 / 39 / 47 / 55 / 63, and every start is a full index-computing layer. Do not divide 78 layers into a merely balanced-looking layout without checking the checkpoint’s indexer_types array.

The reason is local state, not aesthetic symmetry. An IndexShare shared layer reuses top-k indices from a preceding full layer. In the pinned Vime implementation, that per-microbatch holder does not cross a pipeline-parallel boundary. If a stage starts on a shared layer, its source full layer ran on the previous stage and the implementation fails closed.

This configuration preflight gives you the exact stage table, a copyable checker, a real Docker receipt and the limits of that evidence. It applies to the cited Vime/Megatron pipeline implementation. It does not mean every GLM-5.2 API, vLLM serving profile or future engine requires PP8.

Use the pinned PP8 split

The pinned Vime GLM-5.2 example publishes these pipeline controls:

--pipeline-model-parallel-size 8
--decoder-first-pipeline-num-layers 14
--decoder-last-pipeline-num-layers 16

With 78 transformer layers, the six middle stages receive eight layers each:

middle layers = 78 - 14 - 16 = 48
middle stages = 8 - 2 = 6
layers per middle stage = 48 / 6 = 8

That produces the complete layout:

Stage	Global layer range	Layer count	Start type	Boundary result
1	1–14	14	full at 1	pass
2	15–22	8	full at 15	pass
3	23–30	8	full at 23	pass
4	31–38	8	full at 31	pass
5	39–46	8	full at 39	pass
6	47–54	8	full at 47	pass
7	55–62	8	full at 55	pass
8	63–78	16	full at 63	pass

This is not a recommendation to copy the rest of the 256-GPU launcher without review. It is a verified answer to one smaller question: does each published pipeline stage begin where its local IndexShare state can be initialized?

Trace the index that cannot cross a stage

The IndexCache paper names two layer roles: a Full layer runs the sparse-attention indexer, while a Shared layer reuses the nearest Full layer’s selected top-k positions. GLM-5.2 stores that distinction directly in its checkpoint configuration.

The pinned Vime GLM-5.2 provider keeps the selected indices in a holder attached to the current microbatch. A shared layer looks up the full layer that produced its indices. That holder supports reuse and activation recomputation inside one stage, but Vime does not send it across the PP boundary.

Consider stage 3 in our explicit near-uniform negative control. It starts at layer 21, which is shared. Its source is full layer 19. Layer 19 belongs to stage 2, so stage 3 cannot find the required entry in its local holder:

stage 2: layers 11–20  → contains full layer 19
stage 3: layers 21–30  → starts at shared layer 21
required source: layer 19 on the previous stage
result: reject before distributed execution

A stage may end on a shared layer. What matters in this implementation is that the next stage starts on a full layer. That next full layer computes a fresh top-k set before its local shared layers try to reuse it.

Derive full and shared layers from the checkpoint

Our probe pins the official config at revision b4734de4…. It observed:

Checkpoint field	Pinned value	Deployment meaning
`num_hidden_layers`	78	Every stage count must sum to 78
`index_topk`	2,048	Each full indexer selects this many positions
`index_topk_freq`	4	Index computation follows a four-layer cadence after the initial full layers
`index_skip_topk_offset`	3	The first three layers compute their own indices
`indexer_types`	21 full, 57 shared	This array is the final source of truth for boundary validation

The full layers are:

1, 2, 3, 7, 11, 15, 19, 23, 27, 31, 35,
39, 43, 47, 51, 55, 59, 63, 67, 71, 75

Read indexer_types instead of hard-coding this list in a long-lived tool. A future checkpoint revision can change architecture fields even if the model repository name stays the same. Pin the model revision, keep the exact config hash in your run manifest, and regenerate the schedule when either changes.

The site’s broader GLM-5.2 architecture overview explains where IndexShare sits beside sparse attention and MTP. This page stays narrow: it converts the published schedule into one launch invariant.

Reconstruct Vime’s eight-stage layout

The pinned Vime launcher defines the first and last stage overrides. The intermediate stage size follows from arithmetic, and cumulative sums produce the starts:

const layersPerStage = [14, 8, 8, 8, 8, 8, 8, 16];
let next = 1;

const starts = layersPerStage.map((count) => {
  const start = next;
  next += count;
  return start;
});

console.log(starts); // [1, 15, 23, 31, 39, 47, 55, 63]
console.log(next - 1); // 78

Do not describe our negative control as “the framework default.” We explicitly chose 10/10/10/10/10/10/9/9 because it is balanced, sums to 78, and exposes four invalid starts. A different framework may distribute a non-divisible layer count differently. Validate the actual array that your launcher will use.

Run a fail-closed split validator

Save the checkpoint config locally, then run this dependency-free Node script with your proposed stage counts. It checks the total, derives every start and rejects any stage that does not begin on a full entry:

import { readFile } from 'node:fs/promises';

const configPath = process.argv[2] ?? 'config.json';
const splitText = process.argv[3] ?? '14,8,8,8,8,8,8,16';
const config = JSON.parse(await readFile(configPath, 'utf8'));
const split = splitText.split(',').map(Number);

const fail = (message) => {
  console.error(`INVALID: ${message}`);
  process.exit(1);
};

if (!split.every((n) => Number.isInteger(n) && n > 0)) {
  fail('every stage count must be a positive integer');
}
if (split.reduce((a, b) => a + b, 0) !== config.num_hidden_layers) {
  fail(`stage counts must sum to ${config.num_hidden_layers}`);
}
if (config.indexer_types.length !== config.num_hidden_layers) {
  fail('indexer_types does not cover every hidden layer');
}

let start = 1;
for (const [index, count] of split.entries()) {
  const type = config.indexer_types[start - 1];
  if (type !== 'full') {
    let source = start - 1;
    while (source > 0 && config.indexer_types[source - 1] !== 'full') source--;
    fail(`stage ${index + 1} starts at shared layer ${start}; source is ${source}`);
  }
  console.log(`stage ${index + 1}: ${start}-${start + count - 1} (${type})`);
  start += count;
}

console.log('VALID: every stage starts on a full indexer layer');

Run it against the exact pinned file:

node check-indexshare-split.mjs config.json 14,8,8,8,8,8,8,16
node check-indexshare-split.mjs config.json 10,10,10,10,10,10,9,9

The first command should exit zero. The second should exit one at stage 3, which starts at shared layer 21 and depends on full layer 19. If either result changes, stop and inspect the config, script and engine revision instead of forcing the job to continue.

Inspect the pinned container receipt

Sanitized Docker receipt showing four pinned GLM-5.2 and Vime sources verified, the published PP8 layout accepted and two controls rejected

Actual rendering of the sanitized JSON receipt. It reports source-integrity and layout checks, not a model response or a GPU benchmark.

The August 2 probe used node@sha256:f32b81066cde10a75dbac96646099533316d94bac4150c55da1636e1f0ffdc46 with the repository mounted read-only. The ordinary Docker bridge reproduced the host’s documented DNS/fake-IP failure, so the final trusted, outbound-only container used the approved host-network exception. It opened no listener and published no port.

The final receipt records:

four HTTP 200 source fetches and four matching SHA-256 values;
21 full and 57 shared checkpoint layers;
the published stage sizes and eight full-layer starts;
four shared starts in the near-uniform negative control;
a second control whose stage counts total 77 instead of 78;
no credential, model-weight download, server startup, GPU run or throughput measurement.

Inspect the complete sanitized JSON receipt before adapting the checker. Source URLs, revisions, digests and every stage record remain in the file.

Separate indexer FLOPs from end-to-end speed

The official GLM-5.2 model card reports that IndexShare reduces per-token indexer FLOPs by 2.9× at a one-million-token context. It does not say the complete model trains or serves 2.9× faster. Attention kernels, experts, communication, pipeline bubbles, checkpoint I/O and speculative rollout still consume time.

The IndexCache paper reports removing 75% of indexer computations and measuring up to 1.82× prefill and 1.48× decode speedups on its 30B DSA experiment. Those are paper results under that setup. They are not our measurements and not a GLM-5.2 744B production guarantee.

Our checker removes one avoidable failure mode. It supplies no evidence about throughput, convergence, quality, memory, RDMA behavior or cost. Pair it with a small launch canary and engine-native metrics before reserving the full topology. The MTP speculative-decoding guide uses the same discipline: configuration acceptance precedes, but never replaces, workload measurement.

Make the layout a release gate

Run the checker before checkpoint conversion and before the scheduler allocates the full distributed job. A useful release gate records six values:

Gate input	Required record	Stop condition
Model source	repository plus immutable revision	branch-only reference
Config integrity	SHA-256 and 78 `indexer_types` entries	digest or length changes
Engine source	Vime/Megatron commit	unpinned package or source
Pipeline layout	exact per-stage layer array	count does not total 78
Boundary result	start, type and source for every stage	any start is not full
Hardware canary	smallest representative launch	assertion, OOM or communication failure

Do not silence the engine assertion or fabricate a cached index on the receiving stage. Cross-stage transfer would be an implementation feature with its own correctness and communication cost, not a configuration workaround. If a later Vime revision adds that feature, treat it as a new test matrix and update both the validator rule and pinned evidence.

Validate physical and virtual boundaries independently

The pinned provider receives an optional virtual-pipeline stage when it builds the transformer specification. Its guard computes the global offset for that specific stage, then tests the first local layer. In other words, a physical PP8 summary can look valid while a later interleaving change creates a smaller virtual stage that begins on shared.

Do not validate only the eight human-readable ranges in a design document. Export the layer counts that the framework materializes for every physical and virtual stage, calculate their global starts, and run the same full-layer rule over that final sequence. Preserve the emitted array in the job manifest. If the runtime cannot show you the derived ranges before allocating the cluster, add a dry configuration command or a small source-level test rather than inferring them from parallelism flags.

Keep checkpoint conversion and training as separate layouts

The Vime example converts the Hugging Face checkpoint with PP2, then trains with PP8. Those are two distinct stage plans. A reshardable checkpoint can move between them, but that does not make either boundary set valid by association. Run the validator once against the conversion arguments and again against the training arguments. Record both outcomes beside the exact engine commit.

This separation also makes a future failure easier to locate. A conversion assertion points to the conversion split; a later training assertion points to the training or virtual-stage split. One undifferentiated “PP validated” flag would hide that diagnostic value.

Decide whether this self-hosting path fits

The cited Vime example targets 32 nodes and 256 H100 GPUs. PP8 is only one dimension: its published training group also uses tensor parallelism 4 and context parallelism 8. Therefore, “pipeline parallel size 8” does not mean the complete profile fits on eight GPUs.

Do not transfer that training layout to SGLang inference cache sharding. The GLM-5.2 DSA cache LayerSplit audit uses context-parallel prefill ownership for a different reader job and keeps pipeline parallelism at one under its pinned compatibility boundary.

If you need model access rather than architecture work, compare the Coding Plan, metered API and self-hosting paths. An API removes pipeline-layout responsibility. Self-hosting preserves control but makes checkpoint storage, interconnect, topology, engine commits and canary evidence your responsibility. The local deployment guide estimates that broader resource boundary before you request capacity.

Audit the sources, method and limitations

Primary and implementation sources checked on August 2, 2026:

Z.ai’s GLM-5.2 release page and the official model card for the IndexShare design claim and model-family context;
the pinned GLM-5.2 config for the 78-entry full/shared schedule;
the pinned Vime example, launcher and provider source for the PP8 controls and cross-boundary assertion;
IndexCache: Accelerating Sparse Attention via Cross-Layer Index Reuse for the Full/Shared method and separately bounded 30B measurements.

The Docker probe verifies public source bytes and evaluates layouts with a small independent function. The positive layout comes from Vime; the two negative controls are ours. We did not obtain the hardware required to run the published 744B training profile. Re-run the checker whenever the checkpoint or engine revision changes, then perform a real canary on the intended cluster.

Answer IndexShare pipeline questions

Does PP8 mean GLM-5.2 needs only eight GPUs?

No. PP8 means eight pipeline stages. The cited Vime profile combines PP8 with TP4 and CP8 for a 256-GPU training group. Other deployment engines and quantizations have different topology requirements.

Why not divide 78 layers evenly across eight stages?

Because 78 is not divisible by eight, and balance alone does not preserve IndexShare state. Validate the actual stage-count array; every cumulative stage start must point to indexer_types[start - 1] === "full".

Can a pipeline stage end on a shared layer?

Yes in the pinned Vime implementation, provided that stage’s required full source appeared earlier inside the same stage and the next stage begins on a full layer. The published layout follows that rule.

Does this check apply to Z.ai API or Coding Plan access?

No. Those managed routes do not ask the caller to define Megatron pipeline stages. The check is for operators using the cited self-hosted Vime/Megatron path or adapting its IndexShare implementation.

Does a passing split prove the distributed job will run?

No. It proves a narrow metadata and boundary invariant. Checkpoint conversion, engine compatibility, GPU memory, expert groups, context parallelism, network transport and training stability still require a hardware canary.