Skip to content

docs(ocrbench): the mlx-metal rows, and the arms behind them - #339

Merged
glennneuber merged 1 commit into
mainfrom
docs/ocrbench-metal-rows
Sep 19, 2026
Merged

glennneuber merged 1 commit into
mainfrom
docs/ocrbench-metal-rows

Conversation

@glennneuber

Copy link
Copy Markdown

Fills the section #323 left for the Metal session, under its protocol exactly — rows 0–200, THINK=false, NUM_CTX=8192, NUM_PREDICT=512, /api/generate, one model at a time, cold server per run, two runs per arm.

arm correct / scored accuracy
nvfp4 / nvfp4 tower 175 / 200 0.875
mxfp8 / 8-bit tower (local) 173 / 200 0.865
bf16 169 / 200 0.845

Accuracy falls monotonically as precision rises, every arm reproduced its accuracy exactly across two cold runs with zero items changing verdict, and the mlx-cuda rows show the same ordering independently.

nvfp4 beats bf16, 6 items to 0, exact McNemar p = 0.031 — the only pair here that clears the test. Stated with both caveats it needs: three pairwise tests were run, so Bonferroni (≈0.09) puts it back above 0.05, and rows 0–200 are OCRBench's text-recognition half, not the benchmark.

Which artifacts — this is the load-bearing part

store_audit.py says all seven quantised gemma4 MLX tags on this host have diverged from the registry, so every arm is named by manifest digest and run against a preserved tag a pull can't overwrite:

  • 637cc0ff1570 is the same artifact as this ladder's mlx-cuda nvfp4 / nvfp4 tower row — those two rows are one checkpoint on two backends, which answers the question the doc raised about the 0.875.
  • The mxfp8 row is not comparable across backends. The local copy differs from the registry's bf16-tower one by 579 of 1247 layers (language 411, vision 162). It's a local artifact, and the doc says so rather than lining the numbers up.

The arms are committed

Under bench-runs/ocrbench/ with a .gitignore negation, so every table re-renders from the repo alone — verified by re-rendering from the committed copies. Dataset rows are deliberately not committed: --categories reads extbench's local cache, and this repo shouldn't redistribute the benchmark's content.

Also records the 1000-item kernel A/B behind ADR 0037 (835 vs 833, p = 0.804).

test_summarizers 144, test_store_audit 9, test_extbench 8 — all OK.

🤖 Generated with Claude Code

Fills the section this ladder left for the Metal session, under its own
protocol exactly: rows 0-200, THINK=false, NUM_CTX=8192, NUM_PREDICT=512,
SLEEP=1, /api/generate, one model at a time, cold server per run, two runs per
arm. Build 0.34.0-maxusai-8a7ba949 (= 0.34.1-dynres-0-g8a7ba94, ADR 0032).

  nvfp4 / nvfp4 tower          175/200  0.875
  mxfp8 / 8-bit tower (local)  173/200  0.865
  bf16                         169/200  0.845

Accuracy falls monotonically as precision rises, every arm reproduced its
accuracy exactly across two cold runs with zero items changing verdict, and
mlx-cuda shows the same ordering independently. Timing is not ordered by
precision either: bf16 is fastest per item, mxfp8 slowest.

nvfp4 beats bf16 6 items to 0, exact McNemar p = 0.031 — the only pair in this
section that clears the test, and stated with both caveats: three pairwise
tests were run, so Bonferroni puts it back above 0.05, and rows 0-200 are
OCRBench's text-recognition half, not the benchmark.

Which artifacts, because store_audit.py says all SEVEN quantised gemma4 MLX
tags here have diverged from the registry. Every arm is named by its local
manifest digest and run against a preserved tag a pull cannot overwrite.
637cc0ff1570 is the same artifact as this ladder's mlx-cuda nvfp4 row, so
those two rows are one checkpoint on two backends. The mxfp8 row is NOT: the
local copy differs from the registry's bf16-tower one by 579 of 1247 layers
(language 411, vision 162), so it is a local artifact and the doc says it must
not be read across backends.

Also records the 1000-item kernel A/B behind ADR 0037 (835 vs 833, p = 0.804).

The arms are committed under bench-runs/ocrbench/ with a .gitignore negation,
so every table here re-renders from the repo alone — verified by rendering
from the committed copies. Dataset rows are deliberately NOT committed:
--categories reads extbench's local row cache, and this repo does not
redistribute the benchmark's content.

test_summarizers 144, test_store_audit 9, test_extbench 8, all OK.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@glennneuber
glennneuber merged commit 54b5612 into main Sep 19, 2026
1 check passed
@glennneuber
glennneuber deleted the docs/ocrbench-metal-rows branch September 19, 2026 11:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant