Metal half of the v0.33.0 fold: golden recalibration for the 27fec909 MLX pin + measured mlx-metal-0-33-0 profile (preflight PASS)

[glennneuber]

Closes the Metal half of the v0.33.0 fold's acceptance criteria (the open checkboxes in docs/maxusai/tasks/upstream-sync-2026-08-26.md), on the native build 0.33.0-maxusai-21cfe88e (llama.cpp b10488, MLX 27fec909) built and validated on 10.8.0.3 today.

Commit 1 — test(mlxrunner): golden recalibration for the 27fec909 MLX pin

Running the fold's native gate surfaced TestVisionGoldenParity failures on gemma4:26b-nvfp4 and 31b-nvfp4 (12b passed). Root-caused, not patched over:

• Signature: aggregates within 0.01–0.2% of golden, all row norms pass, exactly one sampled element per model ~0.01 over the 0.15+5%|g| bound (max deltas 0.19 / 0.16).
• Window: zero commits under x/mlxrunner/model/ since the 2026-08-11 calibration; the thrash-check commit eliminated by mechanism (CUDA-only, runner-subprocess-only). Last variable: libmlx (adf21dea → 27fec909, TASK: merge upstream/main 6bba484f (v0.32.15+3) — parser-deadlock fix, metadata cache, MLX/llama bumps #208).
• Refutation that sharpened it: a freshly regenerated mlx-vlm reference moved away from our runner on the failing element — but the reference matmuls dequantized bf16 while our runner runs fused nvfp4, the known arithmetic gap already ≤0.14 at calibration.
• The control that decides it: the same Go code on gemma4:26b-mlx-bf16 against its own regenerated golden measures ≤0.059 per element — as close to the reference as the reference is to itself across MLX versions (≤0.0625). Port structure proven; the pin bump changed fused-nvfp4 Metal kernel rounding, growing the quantization gap to ≤0.19 on the deepest towers.

Fix: goldens regenerated per the test header's documented procedure (12b came out byte-identical — its reference never moved), per-element bound raised to 0.20+5%|g| with the observation recorded in the comment, and the bf16 control golden committed so the discriminating experiment is repeatable.

Commit 2 — preflight: the mlx-metal-0-33-0 profile, measured

The #208 payload move requires a new profile per ADR 0011 (never a widened pattern over two payloads). Measured fresh against the build-under-test on :11437 with measure_ladder.py, rows rendered from its --out JSON (ADR 0012 rule 8 — no hand transcription):

• All four arches reproduce their mlx-metal-0-32-14 ladders exactly — gemma4/gemma4_unified flat at 1102 (prefix 19), qwen35/qwen35moe [68, 146, 578, 2306, 5186] (prefix 13). The payload move is inert for token accounting, as PR preflight: measured apple-silicon-mlx baseline for 0.32.14 / b10434 #166 found for the llama.cpp half.
• First full preflight: VERDICT PASS — 14 PASS / 12 SKIP (all skips native-serve by design or deliberate omissions), think probes valid-JSON on all four arches; result committed as preflight/runs/preflight-mlx-metal-0330-first.json.
• test_verdicts.py green (50 tests — the new rows are inside the gate).
• BINARIES.md: adds the 0.32.14-maxusai-c82b0464 rollback row (last pre-0.33.0 deploy, preflight-PASSED 2026-08-22) and the 0.33.0-maxusai-21cfe88e provenance row; both archived at ~/.ollama/binaries/ with checksums.
• Task doc: criterion 3 (native layer — TestDFlash* all pass with real MLX) and criterion 4 (Metal half) checkboxes close.

Native gate summary on 0.33.0-maxusai-21cfe88e

Gate	Result
go test ./x/mlxrunner/ -p 1 (native)	ok
TestDFlash* (draft-cache settling, real MLX)	6/6 PASS
Vision goldens 12b/26b/31b + bf16 control	PASS (post-recalibration)
test_verdicts.py	50 tests OK
go test ./llm/ -run TestImageTokensForSize	ok
Full mlx-metal preflight	VERDICT PASS

🤖 Generated with Claude Code

[glennneuber]

Reviewing as consolidator. Regenerating a golden is the one operation that can launder a regression — a recalibrated reference passes its own test by construction — so the only question that matters is whether the movement was explained before the numbers were replaced. It was, and the discriminating control is the right one.

The bf16 control is what makes this a diagnosis rather than a goalpost move:

the same Go code on gemma4:26b-mlx-bf16 against its own regenerated golden measures ≤0.059 per element — as close to the reference as the reference is to itself across MLX versions (≤0.0625)

That separates the two hypotheses cleanly. If the port had drifted, bf16 would drift too, because it runs the same Go path. It does not — so the port is intact and the movement is in fused-nvfp4 Metal kernel rounding, which only the quantized towers traverse. Committing that control golden so the discriminating experiment is repeatable is the part I would have asked for.

Three other things done in the right order:

• 12b came out byte-identical. A recalibration where one of three models does not move is far more credible than one where all three do — it bounds the change rather than blessing everything.
• The refutation is recorded, not buried. A freshly regenerated mlx-vlm reference moving away from the runner looks like confirmation of a port bug until you notice the reference dequantizes bf16 while the runner runs fused nvfp4. Writing down the misleading intermediate result is what stops the next person stopping there.
• The window was closed by inspection first — zero commits under x/mlxrunner/model/ since calibration, thrash-check eliminated by mechanism (CUDA-only, subprocess-only) — leaving libmlx as the last variable rather than the first guess.

One thing I would state explicitly in the test comment, since the bound moved: 0.15+5%|g| → 0.20+5%|g| is a loosening, and loosened bounds do not tighten again on their own. Worth a line naming what would justify tightening it back (a pin whose fused-nvfp4 kernels round closer, or a reference generated through the same fused path), so the next reader knows 0.20 is a measured accommodation of a known arithmetic gap and not a comfort margin.

On the profile half

Requiring a new mlx-metal-0-33-0 profile rather than widening a pattern over two payloads is exactly ADR 0011, and it is the opposite call from #218/#219 for the right reason: those two are lineage profiles keyed on a moving -dynres stamp; this one is a measured baseline. A guard I just added in #219 asserts the baseline-pinned profiles are not swept into the lineage widening, so these two changes agree by construction.

All four arches reproducing their mlx-metal-0-32-14 ladders exactly — gemma4 flat 1102 at prefix 19, qwen35/qwen35moe [68, 146, 578, 2306, 5186] at prefix 13 — is the strongest available statement that the payload move is inert for token accounting, and it matches what the CUDA side measured independently. Rendering from measure_ladder.py --out rather than transcribing keeps ADR 0012 rule 8 intact on the one file where a typo is invisible.

Committing the preflight run JSON alongside the VERDICT PASS is good practice — a verdict without its artifact is a claim.