docs(ocrbench): the mlx-metal rows, and the arms behind them - #339
Merged
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.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.pysays 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:637cc0ff1570is the same artifact as this ladder's mlx-cudanvfp4 / nvfp4 towerrow — those two rows are one checkpoint on two backends, which answers the question the doc raised about the 0.875.The arms are committed
Under
bench-runs/ocrbench/with a.gitignorenegation, so every table re-renders from the repo alone — verified by re-rendering from the committed copies. Dataset rows are deliberately not committed:--categoriesreads 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_summarizers144,test_store_audit9,test_extbench8 — all OK.🤖 Generated with Claude Code