"A number you did not predict is a number you cannot be surprised by. The lab's first rule is to make surprise possible."
The Protocol
Every measured number in this quest came from one small program, silicon_lab.py, written for the quest and run on four of the household's Macs on one day — the base M3 in the Air, the M3 Max in the 2023 MacBook Pro, the M3 Ultra in the office Studio, the M2 Ultra in the music Studio. It does five things in a fixed order, and the order is the protocol. Stamp: before anything runs, record the machine by role alias, the chip as MLX names it, the memory and the recommended working set, the macOS build, the MLX and mlx-lm versions, and the UTC time — a number without these is a rumour. Count the bytes: open the checkpoint's safetensors headers and add up what a decode step actually reads, by the physics track's rules: skip the vision tower, skip the embedding table unless it is tied to the output head, count routed experts at k of E. The config file says what the model is; the headers say what is on disk. Predict: divide the chip's spec bandwidth by those bytes and print the ceiling before loading the model. Warm up: generate eight tokens and throw them away, so the first-forward page-touching from the journey track is not in the timing. Measure: a fixed prompt of about 209 tokens, 200 greedy tokens out, batch one, and record prefill rate, time to first token, decode rate and peak memory, with the prediction beside them.
Why the Prediction Comes First
The first office ladder was wrong, and the prediction is how it was caught. That run counted every byte on disk as bytes read per token: 0.63 GB for the 0.8B instead of 0.42, 5.95 for the 9B instead of 4.47, 20.39 for the mixture instead of 1.66. The decode rates it measured were fine; the effective bandwidth it derived from them was not — 1,815 GB/s for the mixture, on a chip whose bus carries 819. A number above the ceiling is not a fast machine, it is a wrong count, and the only reason that line stood out on a screen of plausible-looking rates was that the ceiling had been printed next to it. Run 1 was discarded; the byte rules above were written; the physics track's expert lesson carries the confession. Without a prediction, the wrong number would have been the result.
What a Measurement Record Contains
One line per run, JSON, appended to a file the machine keeps. The lab's records carry the stamp, the byte accounting (total, vision, embedding, experts, tied, per-token), the quantization as the config states it, the prompt and generation token counts, the four rates, the peak memory, and the prediction with the effective bandwidth beside it. Every table in this quest is built from those lines by scripts you can run on the same files, and the measurements companion the quest keeps is the human-readable index of them. The Mac card you have been filling is the same idea by hand: alias, date, build, versions, model, bits, bytes per token, prediction, measurement — and the gap. The table below predicts from the vendor's 819 GB/s; the physics track's version of the same rows predicted from the 638 GB/s a kernel actually streamed on office, which is why its fractions read higher (22% and 74% at the ends) — same measurements, two honest denominators, and the card should say which one it used.
| Office, 2026-09-15, mlx 0.32.2 | Bytes per token | Predicted ceiling (spec 819 GB/s) | Measured decode | Fraction of spec ceiling | Evidence |
|---|---|---|---|---|---|
| Qwen3.5-0.8B-4bit | 0.42 GB | 1,932 tok/s | 338.2 | 18% | measured |
| Qwen3.5-9B-4bit | 4.47 GB | 183 | 95.1 | 52% | measured |
| Qwen3.5-27B-4bit | 14.42 GB | 56.8 | 32.6 | 57% | measured |
| Qwen3.5-35B-A3B-4bit (run 1, wrong count) | 20.39 GB | 40.2 | 89.0 | 221% — impossible | measured, discarded |
| Qwen3.5-35B-A3B-4bit (corrected) | 1.66 GB | 494 | 89.1 | 18% | measured |