NoCap-Test evidence · think2earn systems explainer · no sealed ΔT%
Source code ↗

Learn the systems path · code-adjacent

B32 systems

Microbatch 32 × accum 16 · fixed 524,288 tokens/update · throughput, not a new algorithm

B32×accum16 is a batching choice on the claim recipe. Same tokens per optimizer update as the older B16 path. Larger microbatch, fewer accumulation steps. Banked systems evidence: ~6% faster core step-time (matched systems_v1). Not a new optimizer. Not Ortho/NS. Not split-QKV.

systems path 524,288 tok/update ~6% step-time (banked) claim-stack ingredient

NUMBERS_CANON RECIPE_CARD GLOSSARY · B32×accum16 COMPREHENSIVE_REPORT

Problem 00 · scope systems path

Systems vs algorithm

A stranger often reads “B32” as a new training method. It is not. Ortho/NS lives on Muon. Timing-cheap split lives on architecture. B32×accum16 only changes how tokens are packed into one optimizer update.

Predict · Does B32 train on more tokens per update?

No. Tokens/update stay 524,288. Only the factors change (microbatch ↑, accum ↓). Same product → fair comparison of step wallclock.

Definition

One optimizer update sees a fixed token count. Microbatch size × accumulation steps × sequence length = that count. Call that product the effective batch in tokens (not a new algorithm).

Claim pin Tokens per update

tokens/update = microbatch × accum × seq
32 × 16 × 1024 = 524,288
(B16 path: 16 × 32 × 1024 = same 524,288)

Recipe pin: see RECIPE_CARD and NUMBERS_CANON. Horizon stays 4768 updates.

Problem 01 · fixed budget same tokens

What stays constant?

The fair comparison locks tokens per update. You do not “train on more data per step” by moving to B32. You change how those tokens are packed on the GPU.

Visual · One update = one fixed token block Our commentary
ONE OPTIMIZER UPDATE 524,288 tokens · seq 1024 · locked B16 and B32 fill this same block. Only packing changes.

Figure · Token budget is the invariant. Step-time is what the systems path tries to move.

Problem 02 · reshape B16 → B32

Same product, different factors

Older path: microbatch 16 × accum 32. Claim path: microbatch 32 × accum 16. Product identical. Fewer, larger microbatches → different GPU occupancy and step wallclock.

Teach beats · packing Auto / Step / Reset
524,288 tokens/update · locked B16 PATH · microbatch 16 × accum 32 accum ×32 · microbatch 16 32 thin forward/backward passes → one update B32 PATH · microbatch 32 × accum 16 accum ×16 · microbatch 32 16 thicker passes → same 524,288 tokens → usually better step wallclock

Lock the product

Effective tokens/update must match, or the “faster step” comparison is confounded.

16 × 32 × 1024 = 32 × 16 × 1024 = 524,288

Beat 1 · Product locked. One optimizer update always sees 524,288 tokens — microbatch × accum × seq length.

microbatch —
accum steps —
fwd/bwd passes —
tokens/update 524,288
Step through product → factors → throughput

Keyboard (focus controls): Space or → step · A auto · R reset · tab beats 1–3

Beats: product → factors → throughput. Caption + readouts sync to each beat (microbatch, accum, passes, tokens/update); step-time is schematic (bank ≠ seal).

Problem 03 · banked gain ~6% step-time

What was measured?

Matched campaign screen systems_v1 compared B32 vs B16 with tokens/update fixed. Result banked into the recipe: ~6% faster core step-time. That is component evidence. It is not the sealed multi-seed first-passage ΔT% on the report.

Visual · Step-time bar (schematic) Our commentary
CORE STEP-TIME · SAME TOKENS/UPDATE B16 reference path B32 ~6% shorter · systems_v1 ≈0.94× Bank ≠ seal. Full first-cross % lives on the report vs F1_seal.

Figure · Illustrates the banked systems delta. Sources: GLOSSARY, CAMPAIGN_OVERVIEW, COMPREHENSIVE_REPORT component bank.

Claim boundary. B32×accum16 is a systems path (microbatch × accumulation, tokens/update fixed) with matched campaign step-time evidence — not a paper novelty claim and not Muon Ortho. Bank ≠ seal: systems component evidence is not the sealed under-baseline %. Do not read ~6% step-time as the sealed ≈8.3% mean ΔT%. Sealed wall-clock is Muon B32 + timing-cheap split-QKV vs F1_seal on the report / NUMBERS_CANON. Optimizer attribution: Keller Jordan Muon · ecosystem: Modded-NanoGPT.
Problem 04 · claim stack ingredient, not solo

Where B32 sits

Kill → bank → seal. Plain Muon compose failed or lost under the seal. Systems B32 and timing-cheap split-QKV cleared promote criteria as components. Only then: three-seed candidate seals.

1 · Optimizer

Keller Jordan Muon

Ortho/NS on matrices. Muon explained.

2 · Systems

B32 × accum16

This page. Throughput packing.

3 · Architecture

Timing-cheap split-QKV

Banked mechanism · ≠ Ortho.

Causal spine: failed finals → fair clock → Muon compose misses → bank systems + cheap split → Tier A keeps defaults → claim-stack 3/3 under sealed F1. Detail: kill → bank → 3/3.

Systems_v1 also killed NS3 and z-loss 1e-4 on the same path family. Defaults that stayed: NS 5, z-loss 0.