Does LongStraw Prove GLM-5.2 Works at 2M Tokens?
Independent research — not an official Z.ai publication.Identity and provider disclosure
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.
Follow this exact-2M evidence audit
Section titled “Follow this exact-2M evidence audit”- Read the claim in four layers
- Put the updates on one timeline
- Separate native 1M from experimental 2M
- Inspect the exact-2M receipt
- Understand the LongStraw memory method
- Locate the gradient-evidence ceiling
- Review our Docker result
- Interpret the two timing numbers
- See what is publicly reproducible
- Choose a supported or experimental path
- Resolve common 2M questions
- Check sources and method
Read the 2M claim in four layers
Section titled “Read the 2M claim in four layers”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.
A five-date timeline changes the verdict
Section titled “A five-date timeline changes the verdict”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:
- Capacity: the system can address and execute positions beyond the native window.
- Training: gradients and an optimizer transaction can use that extended path.
- 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,536The 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 stepFor 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 gradient evidence stops at 32K
Section titled “The gradient evidence stops at 32K”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 passed6 failed2 skipped35.25 secondsAll 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.
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 secondstiming 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.
What a researcher can reproduce today
Section titled “What a researcher can reproduce today”The public checkout exposes useful levels with different meanings:
- 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.
- 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.
- Generate deployment plans and prerequisite reports. These validate topology, ownership, configuration identity, and fail-closed gates—not GPU execution.
- 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.
LongStraw sources and our audit method
Section titled “LongStraw sources and our audit method”- Z.ai: GLM-5.2 built for long-horizon tasks — native 1M positioning, IndexShare, and long-context system background;
- Z.ai GLM-5.2 developer guide — current supported model specification;
- official GLM-5.2 model card and
config.json— checkpoint identity and native position limit; - LongStraw arXiv record and paper PDF — paper-v2 architecture, 2.1M execution result, and stated correctness boundary;
- exact-2M validation update, online receipt, and 32K gradient receipt — July 23–24 repository update;
- reproduction levels and public status — runnable versus review-only boundaries.
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.
