GLM-5.2 on AMD GPUs: Solving 5 of 6 IMO 2026 Problems

Three engineering layers came together: kernel-level GPU fixes, a protocol-normalizing proxy, and a six-role solver pipeline built for long-horizon mathematical reasoning.

The International Mathematical Olympiad (IMO) is a six-problem benchmark of mathematical creativity and rigor. In July 2026, One Mount evaluated whether GLM-5.2 could sustain this level of reasoning when deployed on AMD MI355X hardware.

Final outcome: five problems solved at full marks (7/7). The sixth problem (P3) was not solved by GLM-5.2; its direct attempt scored 2/7. Combined score: 35/42.

01Model Serving on AMD GPUs

Running GLM-5.2-FP8 on MI355X required more than launching inference. A silent numerics issue in the underlying kernel path had to be identified and fixed.

GLM-5.2 and FP8 Deployment

GLM-5.2 is a sparse MoE model with DeepSeek Sparse Attention behavior and long-context reasoning characteristics. The deployed variant was zai-org/GLM-5.2-FP8, configured at tensor-parallel size 8 on a single MI355X node.

FP8 lowered memory cost significantly compared with BF16, allowing a practical single-node deployment for sustained long reasoning sessions.

--dsa-prefill-backend tilelang
--dsa-decode-backend tilelang
--chunked-prefill-size 131072
--watchdog-timeout 1200
--reasoning-parser glm45
--tool-call-parser glm47
--attn-cp-size 8 --enable-prefill-cp --cp-strategy interleave
--enable-dsa-cache-layer-split

gfx950 Block-FP8 Accuracy Failure

On MI350X/MI355X (gfx950, ROCm 7.2), the team observed a silent correctness issue: short prompts seemed acceptable, but compositional reasoning degraded severely. Layer-wise error accumulation across 78 layers made mathematical tasks unstable.

Root cause was traced to illegal-type FMA behavior in the gemm_a8w8_blockscale_bpreshuffle path after an LLVM coercion pass removal in ROCm 7.2.

02Harness Layer Enhancement

GLM-5.2 needed a durable protocol bridge to run reliably behind Codex and Claude Desktop during multi-hour solver sessions.

Nexus Composer as Control Plane

The team built Nexus Composer (forked from CC Switch, implemented with Tauri) to bridge: Anthropic Messages, OpenAI Responses, and OpenAI Chat Completions. It handles:

• Protocol conversion — bidirectional translation across Anthropic and OpenAI surfaces for desktop agents.
• Provider switching — fast switching between custom GLM endpoints and official providers.
• Operational telemetry — duration, token usage, latency, costs, and request correlation IDs.
• Config management — managed Claude and Codex local config and auth files from one control panel.

Reasoning Stream Normalization

The most difficult part was normalizing GLM-5.2 long reasoning streams. The proxy had to correctly handle reasoning-only chunks, legacy untyped deltas, and trailing empty tails after terminal chunks. Without this, sessions stalled under long-running workloads.

Over three days of iteration, stream finalization and buffering logic was hardened enough to keep hour-scale reasoning sessions stable across both desktop clients.

03IMO Problem-Solving Workflow

Desktop apps acted strictly as orchestrators. A background Python process performed direct model API calls to bypass desktop token-output limits.

Orchestrator + Direct API Pattern

The desktop layer launched and monitored a durable Python process. The process called GLM-5.2 directly with high token ceilings ( max_tokens=256000 ) and large reasoning budgets, avoiding SDK response limits.

Every problem ran in strict isolation with no access to prior runs, no internet research, and no external mathematical source material.

Six-role algorithm

Integrity and Provenance

Verifier and classifier contexts remained isolated from target outcomes. The orchestrator did not inject mathematical hints. Artifacts were checksummed (SHA-256), and P6 transcripts were audited for internet activity with zero web access events.

04Results

Five of six problems were solved at full marks. P3 was partially solved (2/7) without a complete rigorous proof.

Problem-by-problem highlights

05What This Means

This outcome was not only a model-quality result. It was a systems result across three layers: numerics correctness, transport reliability, and workflow rigor.

Without kernel-level fixes, long-chain reasoning quality collapsed. Without stream normalization, sessions failed under duration pressure. Without verification discipline, proofs could not be trusted.

P3 remains the boundary case: the model found a plausible final expression but did not produce the full proof required for IMO-grade acceptance. That boundary is exactly where future capability and engineering work should concentrate.