Skip to content
C.W.K.
Stream
Lesson 06 of 06 · published

Reading Someone Else's Benchmark

~15 min · lab, benchmarks, checklist, ceiling, evidence, measured

Level 0Spec-Sheet Skimmer
0 XP0/91 lessons0/19 achievements
0/100 XP to next level100 XP to go0% complete
"A benchmark you did not run is a claim with a table attached. Read it the way the lab reads its own numbers: find the stage, count the bytes, divide by the bandwidth, and see what is left over."

The Checklist

Every number in a table someone else published needs seven questions before it can go on your card. Which stage? Prefill ("pp", "prompt processing", "TTFT") scales with compute; decode ("tg", "eval rate", "tokens per second") scales with bandwidth. A table that does not say is not a table. How many bytes per token? Model parameters times bits per weight, minus what decode does not read — and "Q4" is 4.5 bits with its scales, not 4. At what context? The curve lesson showed decode falling 15–39% across a window; a rate with no context length is a rate at the top of a curve. What batch? The physics track's batch lesson: aggregate tokens per second across many streams can be seven times the single-stream number on the same bytes. Which runtime, which version? The journey track measured a 5× gap between two paths on the same bytes; a benchmark without a commit or version is a benchmark of an unknown program. Was anything speculating? The Ollama lesson: a rate above the ceiling means more than one token per pass, and the log says so if you look. Is the spec column right? The community table below lists the M3 Ultra at 800 GB/s where Apple says 819 and mixes two commits across chip generations; even a good table has rows you must correct before dividing.

The Checker

The code block turns any decode claim into two fractions: of the vendor's bandwidth ceiling, and — for chips this quest streamed — of the bandwidth a kernel actually pulled. Above 100% of the first is impossible at one token per pass. Above 100% of the second, on a machine you have measured, is either speculation or a wrong byte count. Below 15% of the first on a model larger than 4B is a busy machine, no warm-up, or the wrong stage. Everything between is a measurement of a runtime, to be compared only with other runtimes at the same bytes and context.

SpecimenChipGB/tokenClaimed tok/sOf spec ceilingOf measuredVerdictEvidence
llama.cpp #4167, M2 Ultra 76c, 7B F16 TGM2 Ultra13.4841.069%75%plausible — and the M2 > M3 Ultra ordering the lab foundvendor table, checked
llama.cpp #4167, M3 Ultra 80c, 7B F16 TGM3 Ultra13.4839.865%84%plausiblechecked
llama.cpp #4167, M3 Max 40c, 7B F16 TGM3 Max13.4825.185%86%plausible — the Max's 87% fit againchecked
llama.cpp #4167, M3 10c, 7B Q8_0 TGM37.1612.388%91%plausible — the Air's 89% fit againchecked
llama.cpp #4167, M3 Ultra, 7B F16 PPM3 Ultra13.481,5382,532%not a decode number: prefillchecked
a neighbour quest on this site, as it read on 2026-09-15: 70B INT4M3 Ultra39.795461%591%impossible at one token per pass — reported to the family and repaired by its own session the same daychecked
this quest's ladder, Qwen3.5-27B 4-bitM3 Ultra14.4232.657%74%plausiblemeasured
Ollama's MLX engine, 27B NVFP4 (journey track)M3 Ultra14.4550.689%114%above the measured stream: speculation — confirmed in the logmeasured

Three Specimens Worth Learning From

The community table is the best public Apple-silicon benchmark there is, and read with the checklist it reproduces this quest: the base and Max chips near 90% of spec, the Ultras in the 60s and 70s, the M2 Ultra ahead of the M3 Ultra on decode and behind on prefill. Its rows for the newest chips carry a different commit, its M3 Ultra bandwidth is the M2's, and its Q4_0 rows sit at 45% of ceiling because a 3.8 GB token is where the fixed cost bites — all readable once you know what to look for. The neighbour quest on this site stated, in a lesson about hardware reality, that an M3 Ultra decodes a 70B at 4 bits around 95 tokens per second. Forty gigabytes a token against 819 GB/s is a ceiling near 20; the claim needed 4.6 buses. It was a wrong model — 95 is what the community table measures for a 7B on Ultra chips, filed under the wrong size — and it was reported to the family as a cross-quest contradiction rather than repaired here, which is this quest's rule for findings outside its own files; that quest's own session repaired it the same day, and its lesson now carries the correction with a dated note. Apple's own M5 claims, which the quest carries as vendor claims, sort cleanly by the first question: "up to 4x faster LLM prompt processing" is a prefill claim about the new GPU accelerators, and the "19–27% performance boost … thanks to its greater memory bandwidth" for decode is the physics track's formula in the vendor's own words — 153 over 120 GB/s is 1.275. A vendor that labels its stages is telling you which division to do; do it.

Code

benchmark_check.py — a claimed decode rate as a fraction of two ceilings·python
#!/usr/bin/env python3
"""Read someone else's benchmark with the physics track: for a claimed decode rate,
compute bytes per token from the model and its bits, the bandwidth ceiling for the
chip, and the fraction of the ceiling the claim needs. Above 100% with one token
per pass is not a fast machine; it is a wrong number, a wrong stage, a wrong
byte count, or speculation. Standard library only."""

CHIPS = {"M3 Ultra": 819, "M2 Ultra": 800, "M3 Max": 400, "M3": 100, "M5 Max": 614, "M1 Max": 400}   # vendor GB/s; M5 Max per the discussion table
MEASURED = {"M3 Ultra": 638, "M2 Ultra": 740, "M3 Max": 391, "M3": 97}                            # this quest's stream.py, GB/s (T4)


def bytes_per_token(params_b: float, bits: float) -> float:
    return params_b * 1e9 * bits / 8


def check(label, chip, params_b, bits, claimed_tps, stage="decode", note=""):
    bpt = bytes_per_token(params_b, bits)
    ceiling = CHIPS[chip] * 1e9 / bpt                                   # first filter: the vendor number
    frac = claimed_tps / ceiling
    meas = MEASURED.get(chip)
    frac_m = claimed_tps / (meas * 1e9 / bpt) if meas else None          # second filter: what a kernel actually pulled here
    if stage != "decode":
        verdict = "not a decode number — compare against prefill, not bandwidth"
    elif frac > 1:
        verdict = "impossible at one token per pass"
    elif frac_m and frac_m > 1:
        verdict = "above what this chip streamed for us — more than one token per pass, or a wrong byte count"
    else:
        verdict = "plausible" if frac > 0.15 else "plausible, low — fixed term or a small model"
    print(f"{label:46} {chip:9} {bpt/1e9:6.2f} GB/tok  spec ceiling {ceiling:7.1f}  claimed {claimed_tps:7.1f} = {frac*100:4.0f}%"
          + (f" ({frac_m*100:4.0f}% of measured)" if frac_m else "" ) + f"  -> {verdict}{note}")


# Specimen 1: llama.cpp discussion #4167 (Llama 2 7B, 6.74B params; F16 = 16 bits, Q8_0 ≈ 8.5, Q4_0 ≈ 4.5), commit 8e672ef
check("#4167 M2 Ultra 76c, F16 TG",     "M2 Ultra", 6.74, 16,  41.02)
check("#4167 M3 Ultra 80c, F16 TG",     "M3 Ultra", 6.74, 16,  39.78)
check("#4167 M3 Max 40c, F16 TG",       "M3 Max",   6.74, 16,  25.09)
check("#4167 M3 10c, Q8_0 TG",          "M3",       6.74, 8.5, 12.27)
check("#4167 M2 Ultra 76c, Q4_0 TG",    "M2 Ultra", 6.74, 4.5, 94.27)
check("#4167 M3 Ultra 80c, F16 PP",     "M3 Ultra", 6.74, 16, 1538.34, stage="prefill")
# Specimen 2: a neighbour quest on this site — "M3 Ultra decodes a 70B INT4 around 95 tok/s"
check("neighbour quest: 70B INT4 on M3 Ultra",       "M3 Ultra", 70.6, 4.5, 95.0)
# Specimen 3: this quest's own ladder, for scale
check("this quest: Qwen3.5-27B 4-bit on M3 Ultra",   "M3 Ultra", 25.6, 4.5, 32.6, note="  (14.42 GB/tok by header, 74% of the measured-bandwidth ceiling)")
# Specimen 4: Ollama's MLX engine on office, the previous track
check("Ollama MLX engine, 27B NVFP4 on M3 Ultra",    "M3 Ultra", 25.6, 4.5, 50.6, note="  -> and it was: MTP speculation, 2.3 tokens per pass")

# #4167 M2 Ultra 76c, F16 TG      13.48 GB/tok  spec ceiling  59.3  claimed   41.0 =  69% ( 75% of measured)  -> plausible
# #4167 M3 Ultra 80c, F16 TG      13.48 GB/tok  spec ceiling  60.8  claimed   39.8 =  65% ( 84% of measured)  -> plausible
# #4167 M3 Max 40c, F16 TG        13.48 GB/tok  spec ceiling  29.7  claimed   25.1 =  85% ( 86% of measured)  -> plausible
# #4167 M3 10c, Q8_0 TG            7.16 GB/tok  spec ceiling  14.0  claimed   12.3 =  88% ( 91% of measured)  -> plausible
# #4167 M2 Ultra 76c, Q4_0 TG      3.79 GB/tok  spec ceiling 211.0  claimed   94.3 =  45% ( 48% of measured)  -> plausible
# #4167 M3 Ultra 80c, F16 PP      13.48 GB/tok  spec ceiling  60.8  claimed 1538.3 = 2532%                    -> not a decode number
# neighbour quest: 70B INT4       39.71 GB/tok  spec ceiling  20.6  claimed   95.0 = 461% (591% of measured)  -> impossible at one token per pass
# this quest: Qwen3.5-27B 4-bit   14.40 GB/tok  spec ceiling  56.9  claimed   32.6 =  57% ( 74% of measured)  -> plausible
# Ollama MLX engine, 27B NVFP4    14.40 GB/tok  spec ceiling  56.9  claimed   50.6 =  89% (114% of measured)  -> above what this chip streamed for us

External links

Exercise

Take three decode numbers you have seen quoted for a Mac — a forum post, a vendor page, a lesson on this site — and run each through benchmark_check.py with the bytes per token you derive yourself. Put the three fractions on your card with a one-word verdict each. Then write the seven questions on the back of the card, because you will need them again next month.
Hint
The most common failure is not an impossible number but an unlabeled one: no context length, no quantization, no stage. Mark those 'unlabeled', not 'wrong', and do not compare them with anything. The second most common is a Q4 counted as 4.0 bits — it is 4.5 or more with scales, and the difference is 12% of the ceiling.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.