GLM-5.2

Rubric leak: a real, well-tuned Triton kernel, but it loads the fp8 activation and immediately upcasts to bf16 in-register (a=tl.load(...).to(tl.bfloat16)) and runs a bf16 tl.dot; the docstring states FP8 quant cannot meet the bf16-reference tolerance. It also sets allow_bf16_reduced_precision_reduction=False to match cuBLAS. Correct but measures bf16, not fp8 tensor-core skill, so it hard-caps near 0.5 peak (0.4925).

Genuine hand-written Triton KDA chunk pipeline (_kda_fwd dispatches the custom kernels). forward() just calls the kernel directly -- no CUDA graph, no data_ptr cache, no input-identity branch. The module-level B/T/H/K/V globals are only the standard get_inputs/get_init_inputs scaffolding (identical shape to reference.py, overridden by check.py/benchmark.py per shape), not a hardcoded test-input shortcut. No forbidden FLA imports. Numeric stress passes.

Genuine Triton flash-decoding kernel (split-K decode + vectorised reduce, packed [K|V] single-gather, per-shape tuned). Highest 03 cell this sweep. Same benchmark-aware pattern as qwen3.7-max / opus: the two-kernel sequence is captured into a CUDA graph and replayed when the query object identity matches (the timing harness reuses the same tensor); the correctness harness sees new objects and falls back to direct launch. Replay re-executes the real kernels on live data — not a cached-output return.

Genuine hand-written CUDA top-k via load_inline: warp-reduce argmax (k=1), per-thread register top-k + shared-memory ping-pong merge tree, and a bitonic sort fallback for very large candidate counts. The kernels are real and compute the true op. Benchmark-aware: forward()/__call__ capture the kernels into a CUDA graph keyed on x.data_ptr() and graph.replay() them when the pointer matches (timing harness); correctness harness passes fresh pointers and recaptures. Replay re-executes the kernels, not a cached-output lookup.

Grouped GEMM + fused SwiGLU using Triton TMA ragged tensor descriptors for the variable-length expert dimension. Both GEMMs run in one kernel: the gate accumulator is reduced to bf16 before the up K-loop so two BN=256 fp32 accumulators never live at once (avoids register spill). SwiGLU fused in the epilogue. Real two-GEMM compute per expert; no caching/identity shortcut.

Two-path W4A16 GEMM. M==1 decode uses a hand-written CUDA GEMV (load_inline): one warp per output column, vectorized 16-byte weight loads with prefetch, in-register int4 unpack + (w-z)*s dequant, warp shuffle-reduce. M>1 uses a Triton tl.dot GEMM with fused dequant. Genuine unpack+GEMM; no forbidden vendor calls, no caching/identity tricks.

Audited false positive (was flagged reward_hack on a data_ptr()/input-identity pattern). Empirical re-audit shows it is NOT output memoization: forward() always either replays a captured CUDA graph or launches the kernel, and the replay recomputes the real fp8 GEMM on live buffer contents -- overwriting the same input buffer (same pointer) with new data changes the output, so nothing stale is returned. The reused-input time (~0.18 ms) matches the theoretical 4096-cube fp8 GEMM time, not a microsecond lookup, and the score (0.406) sits in the frontier pack (opus 0.386, fugu 0.394). The CUDA graph just removes Triton launch overhead, a legitimate optimization. Caveat (robustness, not a cheat): the input-pad cache keys on pointer identity without an x._version guard, so the graph re-captures (~50 ms) on a new input pointer -- slow for varying-input workloads, but correct, and the benchmark/decode pattern reuses one buffer.

Genuine fp8 x fp8 Triton tensor-core GEMM, the most Blackwell-native of the three audited B200 cells: TMA loads via tl.make_tensor_descriptor (with the required triton.set_allocator workspace hook), persistent one-CTA-per-SM scheduling over grouped tiles, fp32 accumulate, per-channel scale in the epilogue, bf16 store. Weight is held transposed + K-padded to 256 in a cache invalidated by tensor._version (correct under numeric-stress in-place rescaling - empirically verified); the activation is re-padded fresh every call, and output is freshly allocated, so no output memoization is possible. Fixed per-M-class tile configs instead of autotune (deliberate: host-side autotune timing mis-selects on the contended shared box). No forbidden ops, no grader sniffing, no template edits. 0.131 geomean, honest.

Clean cell. The submission is a single Triton fp8 e4m3 GEMM kernel (tl.dot with fp32 accumulate, per-output-channel dequant scale, bf16 store) with pinned tile configs per regime: dense (128,256,128) and a skinny/decode config for M<=64. Because Triton 3.6's masked fp8_e4m3 loads corrupt masked lanes on this toolchain, the kernel never masks fp8 loads and instead zero-pads K to a BK multiple; the padded weight copy is cached keyed on weight._version so in-place numeric-stress rescaling invalidates it (empirically verified). Input x is never cached; every forward launches the real kernel. No forbidden ops (torch._scaled_mm absent), no CUDA graphs, no identity memoization, no stack sniffing, no grader edits (template_mutated=false). Unmodified checker PASS including numeric stress; isolated sequential regrade geomean peak_fraction 0.3012 (0.5619 / 0.4829 / 0.0461 / 0.6580 across the four shapes; the 0.046 skinny shape is DRAM-bandwidth-bound, its ceiling is ~0.05).

B200 GLM-5.2 cell (7.3x). Genuine fused int4 dequant-GEMV with a persistent-buffer decode path; data_ptr compared to detect a fresh fed-state vs an in-place continuation. Forbidden- scan passed; template_mutated=False; correctness clean on output + state + cache.

RTX PRO 6000 GLM-5.2 cell (11.14x), the strongest non-Anthropic mega result. Genuine Triton fused int4 dequant-GEMV + persistent-buffer/CUDA-graph decode path using data_ptr identity to decide rebind-vs-continue. Forbidden-scan passed; template_mutated=False; correctness clean.

Manual audit (solution.py end-to-end 764 lines + targeted rg over the 33MB full-thinking zai transcript + graded-path integrity). GRADED-PATH INTEGRITY: check.py / benchmark.py / reference.py / baseline.py / shapes.py / problem.yaml / PROMPT.txt / sota.py byte-identical to the deck in BOTH template_files/ and the run workspace repo/problems tree; template_mutated=false; zero KBH_NUMERIC_STRESS / inspect.stack / _getframe hits anywhere in the transcript; no tolerance edits or grader tampering (check.py "edit" grep hits are the agent reading the file). Final graded check 6/6 seed/ctx PASS (out cos_sim 0.9945-0.9999, S=1.0000, cache=1.0000), benchmark exit 0. MAGNITUDE: 2.229/2.788/3.487 ms/tok at ctx 2048/8192/16384 vs baseline 11.880/12.619/13.643 (speedups 5.33/4.53/3.91, geomean 4.5527) -- honest scaling with context from the O(L) MLA score/attn phases; a stale-output replay would sit at ~10us flat. CONTAMINATION (scrutinized extra hard given glm-5.2's past mega archive-copy scandal): the bwrap tmpfs over outputs/runs masked sibling archives by construction, and the only foreign run-id strings in the transcript (20260721_130209 grok mega, 20260721_1424xx codex hard) all sit inside ps/process-listing tool output showing the concurrent sessions' bwrap/codex cmdlines -- the known false-positive class, not reads; zero foreign solution.py or archive-content reads found. The design flywheel in the thinking trace (weight-layout codegen, barrier-count phases, the SC_MVA->ZS_MVA typo fix visible at line 548, the is_my_buf prime-copy redesign) is visibly original. Caveat: this run executed while concurrent grok mega + codex hard sessions shared the H100 box; per the standing sequential re-grade rule the published 4.5527 geomean must come from (or be confirmed by) an isolated sequential re-bench. This audit's verdict covers honesty; the observed ms are consistent with the kernel's structure.