Skip to content

Does LongStraw Prove GLM-5.2 Works at 2M Tokens?

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

Conceptual editorial diagram of a long token stream passing through resident prefix state, 32 accelerator modules, response replay, and gradient finalization for the GLM-5.2 LongStraw audit

This is a conceptual training-systems illustration, not a photograph or dashboard from the external H20 run. The measured public-checkout result appears later as a separate data graphic.

The phrase “GLM-5.2 ran at 2M tokens” compresses several different claims. It can mean an inference API accepted a request, a model produced coherent answers beyond its trained window, a forward and backward path fit in memory, or a complete reinforcement-learning update closed across every rank. Those outcomes are not interchangeable.

The LongStraw paper and its newer public repository now support a stronger claim than the paper’s first abstract alone: the project records an exact 2,097,152-token GLM-5.2 policy rollout followed by a response-only GRPO update on 32 H20 GPUs. However, the released GLM-5.2 checkpoint still declares a native 1,048,576-token window, the 2M path uses an explicit YaRN override, and the repository says a fresh clone is review-only.

We checked those boundaries against official GLM sources, the paper, the exact repository commit, its sanitized receipts, and a disposable Docker fresh-clone test. The result is useful—but narrower than a “GLM-5.2 now supports 2M context” headline.

  1. Read the claim in four layers
  2. Put the updates on one timeline
  3. Separate native 1M from experimental 2M
  4. Inspect the exact-2M receipt
  5. Understand the LongStraw memory method
  6. Locate the gradient-evidence ceiling
  7. Review our Docker result
  8. Interpret the two timing numbers
  9. See what is publicly reproducible
  10. Choose a supported or experimental path
  11. Resolve common 2M questions
  12. Check sources and method

Start with a claim ladder. Each row needs different evidence.

Claim Current evidence Verdict
Released GLM-5.2 has a native 1M window Z.ai model material and official config.json Verified official specification
LongStraw executed GLM-5.2 beyond 2M positions Paper v2 reports 2.1M across all 78 layers on 32 H20 GPUs Publisher-reported execution result
An exact-2M rollout fed a response-only optimizer update July 23 sanitized repository receipt records two backwards and one step Stronger later publisher receipt, not independent reproduction
GLM-5.2 now has supported 2M inference and stable 2M answer quality No official API update, native metadata change, or shared-method quality benchmark Not established

Z.ai’s GLM-5.2 release describes a solid 1M context and explains the IndexShare work used to make that window practical. The official Hugging Face configuration independently exposes max_position_embeddings: 1048576. Those two sources define the model’s native boundary.

The LongStraw result asks another question: can an architecture-aware RL system carry an extremely long prompt through policy scoring, short response replay, distributed gradient closure, and an update without retaining the conventional full-sequence training graph? Its exact-2M receipt says yes for one external transaction. It does not measure whether a user should send a two-million-token document to a production endpoint.

The project changed after the current paper version, so a single undated summary is misleading.

Date Event What changed
June 17, 2026 GLM-5.2 release material documents 1M context Establishes the native model contract
July 16 LongStraw arXiv v1 is submitted Introduces the fixed-budget long-context RL system
July 20 arXiv v2 reports 2.1M GLM execution Still limits its conclusion to execution capacity rather than complete training correctness
July 23 Repository receipt dates an exact-2M online transaction Adds a real policy rollout, two backwards, and one optimizer step
July 24 Commit 12ce733 records training-readiness status Adds 32K gradient comparison and clearer public-release blockers

This distinction resolves an apparent contradiction. The paper abstract says distributed forward and gradient composition paths remained incomplete. The repository’s later exact-2M validation update says the external run subsequently observed global context-parallel DSA and Megatron gradient finalization. Both statements can be historically accurate because they describe different cutoffs.

The later result deserves attention, but it is a project-published update rather than a new paper revision or independent lab reproduction. A careful headline should say “LongStraw’s exact-2M receipt,” not “GLM-5.2 officially doubles context.”

Native 1M and experimental 2M are different contracts

Section titled “Native 1M and experimental 2M are different contracts”

The exact-2M run did not silently reveal unused native capacity. It changed the position configuration. The repository’s checked-in payload contains this core:

{
"max_position_embeddings": 2097168,
"rope_parameters": {
"rope_type": "yarn",
"factor": 2.0000152587890625,
"original_max_position_embeddings": 1048576,
"truncate": true
}
}

The override raises capacity slightly above 2,097,152 so the exact prompt fits. The extension ratio is exactly:

2,097,152 / 1,048,576 = 2.0000×

The project’s status file calls this opt-in and experimental. Without its environment boundary, checkpoint defaults remain unchanged.

Capacity, training, and quality therefore form three gates:

  1. Capacity: the system can address and execute positions beyond the native window.
  2. Training: gradients and an optimizer transaction can use that extended path.
  3. Quality: a trained checkpoint retains facts, follows instructions, reasons, and resists distraction across those positions.

LongStraw’s later receipt advances the first two gates for one run. It does not close the third. Copying the JSON into an inference server cannot substitute for long-position training and a controlled quality suite.

What the exact-2M receipt actually records

Section titled “What the exact-2M receipt actually records”

The sanitized online_grpo_2m.json is more specific than a marketing chart.

Receipt field Recorded value
Prompt 2,097,152 tokens
Model path GLM-5.2, all 78 decoder layers
Cluster 4 nodes, 32 H20 GPUs
Training topology TP1 / CP32 / EP32 / PP1
Rollout topology TP8 / PP4
Trainable update rank-8 policy LoRA, group size 2
Backward and step 2 backwards, 1 optimizer step
Trace inventory 64 rank files, 25,536 events
Reported numerical failures 0 NaN, 0 Inf, 0 execution errors

Context parallelism splits the prompt into 65,536 tokens per rank:

2,097,152 / 32 = 65,536

The transaction used a DAPO math row with ground truth 4. Two selected completions received rewards -1 and +1, then accumulated into one update. That is more informative than a memory-only allocation probe because a reward-bearing rollout crossed into training.

The receipt is still bounded. Its source_state is external_run_not_source_bound. The public repository does not include the full prompt, raw traces, checkpoint paths, immutable runtime, authorization, or a manifest tied to commit 12ce733. Its 146-file external artifact is represented by hashes, not distributed content. A reader can inspect internal consistency but cannot independently reconstruct the transaction.

LongStraw moves the training graph, not the API limit

Section titled “LongStraw moves the training graph, not the API limit”

Conventional GRPO can score several responses from one long prompt while retaining or recomputing an expensive full-sequence autograd graph. LongStraw separates the shared prefix from each short trainable branch:

capture prompt once without autograd
→ retain model-specific MLA/DSA state
→ restore the prompt boundary
→ replay one short response under autograd
→ accumulate its LoRA gradients
→ pop response state and replay the next branch
→ finalize distributed gradients once
→ optimizer step

For GLM-5.2, the resident state includes compressed MLA key/value pages and DSA index-key pages. Global sparse selection matters because each CP rank initially sees only its local prompt shard; candidates must be gathered, merged, selected, and materialized consistently for response replay.

This is an RL post-training memory and execution design. It trades replay time and orchestration complexity for a smaller live training graph. It does not modify Z.ai’s request validation, provider quotas, hosted KV-cache policy, or API service-level contract. For normal inference choices, the GLM-5.2 API provider guide and local deployment guide remain the relevant paths.

The later gradient_parity_32k.json compares conventional full-sequence and response-only gradients for two 32K cases.

Case Global cosine Relative L2 Optimizer steps
ratio-1 0.999933603 0.0117068 0 in both paths
active clipping 0.999933588 0.0116293 0 in both paths

Both cases match parameter sets and hashes, report no missing shards, and meet the project’s acceptance contract. They also retain 435,870 and 434,559 element-level zero-mask differences. The project explains that many outliers have negligible absolute scale, but reporting the differences is more useful than rounding cosine similarity to “identical.”

Three boundaries remain:

  • parity was measured at 32K, not exact 2M;
  • the planned 64K repeat was not run;
  • optimizer-delta parity was not measured because the comparison paths prohibited optimizer steps.

The exact-2M transaction and the 32K parity test answer complementary questions. One shows that the full extended transaction completed; the other gives a detailed numerical comparison at a smaller length. Neither alone proves end-to-end 2M training equivalence.

Our fresh-clone Docker audit found six release failures

Section titled “Our fresh-clone Docker audit found six release failures”

We cloned commit 12ce733, pinned python:3.12-slim by digest, and ran the public CPU path inside a disposable container. The repository’s documented requirements/test-cpu.txt was not sufficient: pytest collection needed safetensors and numpy. Its release-tree check also required two workflow files absent from the commit.

After adding those diagnostic dependencies plus Git and GNU Make inside the container only, compilation and shell checks passed. The complete pytest suite finished:

1,395 passed
6 failed
2 skipped
35.25 seconds

All six final failures depend on .github/workflows/release.yml, .github/workflows/cpu-contracts.yml, or both. One skip needs optional PyArrow; the other needs a real compiled GPU kernel environment. The runtime-lock checker returned zero schema errors but 36 blockers, starting with release_state is review_only.

Sanitized LongStraw Docker audit summary showing 1,395 passing CPU tests, six failures caused by missing release workflow files, two skips, and 36 review-only runtime blockers

This graphic is generated from our sanitized container log. It is not a screenshot of the external GPU run. Download the reader-facing audit JSON for the exact counts and boundaries.

A 99.57% pass rate among non-skipped tests is encouraging, but it is not an overall correctness score. Tests cover different contracts and the six release failures are deliberate fail-closed checks. The honest result is “many code contracts execute; the advertised fresh-clone gate is not green,” which matches the project’s public-release warning.

The Docker bridge first reproduced this host’s known DNS/fake-IP failure. We used the documented host-network exception only for a trusted, outbound-only container with no listener or published port. No dependency, service, model weight, or runtime was installed on the host.

The timing numbers are cache evidence, not throughput

Section titled “The timing numbers are cache evidence, not throughput”

The receipt records 1,867.58 seconds for the first exact-2M candidate and 30.798 seconds for a second candidate on the cached prefix:

first candidate = 31 minutes 7.58 seconds
timing ratio = 1,867.58 / 30.798 = 60.64×

That ratio demonstrates why prefix residency matters. It is not a 60.64× model speedup. The two paths have different cache state, the receipt exposes no controlled warm/cold distribution, and end-to-end training includes capture, replay, communication, backward, and optimizer phases beyond one sampled candidate.

The decode audit also inspected 16 bounded exact-2M outputs. Ten stopped normally, six hit the 16-token cap, one showed obvious degeneration, and one echoed a target marker. Zero Unicode replacement characters argue against deterministic encoding collapse immediately past 1M. Sixteen short samples do not measure retrieval, instruction following, reasoning, or long-horizon agent quality.

Use the result to design a benchmark, not to skip one. A quality claim needs frozen prompts with evidence at early, middle, late, and beyond-1M positions; distractors; exact token counts; multiple seeds; a native-window control; and task-level scoring.

The public checkout exposes useful levels with different meanings:

  1. Inspect receipts and local contracts. Parse the sanitized JSON, compile the code, and run most CPU tests. Our audit shows the current dependency and workflow gaps.
  2. Construct a deterministic 2M payload. The repository can build 2,097,152-token Python request data. Its own reproduction guide says this does not contact a service, capture a prefix, run forward/backward, or update weights.
  3. Generate deployment plans and prerequisite reports. These validate topology, ownership, configuration identity, and fail-closed gates—not GPU execution.
  4. Attempt the external path only with missing inputs restored. The project lists a digest-pinned CUDA 13 runtime, authorization, model snapshot, dataset fixtures, 32 H20 GPUs, and source-bound raw evidence among the absent requirements.

Before treating the method as independently reproduced, ask for a public commit tied to immutable runtime and artifacts, a successful fresh-clone gate, a 64K parity repeat, optimizer-delta comparison, and trained 2M quality results. Those requests do not negate the receipt; they convert a promising project report into a portable scientific result.

Choose the supported or experimental path deliberately

Section titled “Choose the supported or experimental path deliberately”
Your actual job Safer current decision
Call GLM-5.2 through a hosted API Budget against the provider’s documented 1M window; reject or reduce larger requests
Self-host the released checkpoint for inference Keep native metadata first; treat any RoPE extension as a separate experiment with quality regression tests
Study long-context RL systems Use LongStraw’s architecture and receipts as a concrete design reference, then reproduce each gate on a source-bound stack
Claim production-quality 2M answers Wait for trained-checkpoint quality evidence under a shared, repeatable harness

If a million-token session is the real problem, first check whether retrieval, compaction, prompt caching, or state separation can reduce it. Our prompt-caching guide covers the supported inference-side economics; the benchmark hub shows how to separate publisher and independent results.

Questions about LongStraw and GLM-5.2 at 2M

Section titled “Questions about LongStraw and GLM-5.2 at 2M”

Does GLM-5.2 now accept 2M tokens through Z.ai?

Section titled “Does GLM-5.2 now accept 2M tokens through Z.ai?”

No official source checked for this audit changes the hosted model contract to 2M. Z.ai and the released checkpoint document 1,048,576 tokens. A research stack’s opt-in YaRN capacity does not modify a provider endpoint.

Is the exact-2M receipt useless without independent reproduction?

Section titled “Is the exact-2M receipt useless without independent reproduction?”

No. It records a detailed topology, prompt length, reward-bearing rollout, two backwards, gradient finalization, one step, trace counts, timings, hashes, and limitations. That is meaningful publisher evidence. Its confidence ceiling is lower than a public source-bound rerun because key raw artifacts and runtime inputs remain external.

Can the YaRN JSON safely double another checkpoint?

Section titled “Can the YaRN JSON safely double another checkpoint?”

No general conclusion follows. Position scaling interacts with training, attention, kernels, serving, and evaluation. Even for GLM-5.2, the project treats quality at new positions as a training target. Test capacity and quality separately and retain the native configuration for rollback.

Did your Docker test verify the 32-H20 result?

Section titled “Did your Docker test verify the 32-H20 result?”

No. It verified the public checkout’s CPU contracts, dependency declarations, release assets, receipt structure, and runtime-lock state. GLM52.ai did not possess the external cluster or raw artifact needed to replay the exact-2M transaction.

Sources and repository state were checked July 27, 2026. Our Docker audit pinned commit 12ce7333373515b9d15226e9a290130dbd8e9b40 and the recorded Python image digest. We did not call a 2M hosted endpoint, run the GLM-5.2 weights, reproduce the external H20 transaction, or score long-context answer quality. AI HOT’s fingerprint was unchanged, so this was a proactive primary-source topic rather than a feed-derived story.