refactor(preflight): platform names a (backend, runtime) pair, and mlx-cuda exists

[glennneuber]

The platform field held three naming schemes in four values: cuda/rocm named the backend, apple-silicon named the hardware, and apple-silicon-mlx folded the runtime into the same field.

That's not cosmetic. It's why a missing CUDA-side MLX profile read as a category error rather than a gap — apple-silicon-mlx makes MLX look like an Apple concept, when the build ships mlx_cuda_v13 for Linux and Windows (cmake/local.cmake).

Platform is now backend × runtime

The MLX runtime prefixes its backend, matching the payload directories the build produces:

backend	llama.cpp	MLX
metal	metal	mlx-metal — mlx_metal_v4
cuda	cuda	mlx-cuda — mlx_cuda_v13
rocm	rocm	— no MLX ROCm backend upstream
cpu	cpu	— no mlx_cpu target is built

Renames: apple-silicon-metal → metal, apple-silicon-mlx → mlx-metal, apple-silicon-mlx-0-32-14 → mlx-metal-0-32-14, apple-silicon-cpu → cpu. Old --platform values are accepted as deprecated aliases and print what they resolved to, so nothing in flight breaks.

mlx-cuda now exists — declared, not claimed

Never measured, and until now it had no profile at all. Its three arches carry status = "unmeasured" with reasons naming the known packaging fault: the payload ships with no ELF RPATH and libquadmath unbundled, so it loads only where the host already provides CUDA, cuDNN, NCCL and libquadmath. preflight exits 4 rather than implying a pass.

A bug the rename exposed

--platform's choices was a hardcoded list, so the new names were rejected by argparse before resolve_profile — the single place that owns this — ever ran. Choices are now derived from the expectations file plus the aliases, so the two can't drift again.

Verification

verdict gate            34/34  (it caught a missing `reason` on the new
                                unmeasured blocks and was right to)
--platform mlx-metal    resolves, 10 PASS / 0 FAIL on this host
--platform apple-silicon-mlx  -> "deprecated; using 'mlx-metal'", resolves to
                                 mlx-metal-0-32-14, 10 PASS
--platform mlx-cuda     exit 4, status = unmeasured ×3

Historical campaign docs keep the old names — they describe runs that used them.

🤖 Generated with Claude Code

[glennneuber]

Reviewing as consolidator. The taxonomy is right and worth landing — platform genuinely held three naming schemes in four values, and deriving --platform's choices from the expectations file plus aliases (rather than a hardcoded list that shadowed resolve_profile) is the correct fix for a bug that could otherwise recur on the next rename. Deprecated aliases that print what they resolved to means nothing in flight breaks.

Two corrections, both in your favour, plus data.

1. The unmeasured reason for mlx-cuda is out of date

The blocks cite "no ELF RPATH and libquadmath unbundled, so it loads only where the host already provides CUDA, cuDNN, NCCL and libquadmath". That was fixed and is on main:

cmake/mlx/CMakeLists.txt:38   set(CMAKE_BUILD_RPATH "$ORIGIN")      # ELF spelling
cmake/mlx/CMakeLists.txt:39   set(CMAKE_INSTALL_RPATH "$ORIGIN")
cmake/mlx/CMakeLists.txt:109  MLX_INCLUDE_REGEXES ... gfortran quadmath

And the shipped payload carries it — maxusai/ollama:0.32.14-rc0-dynres-mlxfix:

/usr/lib/ollama/mlx_cuda_v13/libquadmath.so.0
/usr/lib/ollama/mlx_cuda_v13/libquadmath.so.0.0.0

Worth correcting in place, because that text is the thing a future reader will use to decide whether the platform is worth measuring, and it currently says "don't bother".

(A caution from my own record on this: an earlier round of that investigation published "no RPATH" findings that were false negatives — readelf is absent from the runtime image and returned nothing, which I read as "no RPATH present". Anything asserting RPATH absence should say what tool produced the evidence.)

2. mlx-cuda is no longer unmeasured — I measured it today

Full vision suite against maxusai/ollama:0.32.14-rc0-dynres-mlxfix on :11495, gemma4:31b-nvfp4, through run_engine_compare.sh with a cold restart per cell.

Think-off, n=3 — bit-identical across all three repeats:

metric	mlx-cuda (today)	mlx-metal (2026-08-08)
scene bbox IoU	0.962	0.964
boxes / labels / colors	6/6 · 6/6 · 6/6	6/6 · 6/6 · 6/6
serial	✅	✅
invoice items · qty+price · total	5/5 · 5/5 · ✅	5/5 · 5/5 · ✅
name_bbox hits	4	4
fine text 22/16/12/9/7	4/4/4/3/3	4/4/4/2/1
multi-image	✅ all Qs + bbox	✅ all Qs + bbox
contract_followed	7/7/7 of 8	—
gen / prefill tok/s	28 / 434	50 / 519

Scene IoU differs by 0.002, inside ADR 0012's ±0.01 noise floor. Every exact-match cell is identical. The runtime behaves the same on both backends.

3. But keep it guarded — I found a crash

Under think-on, the 12th consecutive cell (finetext) aborted the runner:

mlx runner aborted: mlx: cudaGraphAddDependencies(graph_, from_nodes_.data(),
  to_nodes_.data(), nullptr, from_nodes_.size()) failed: invalid argument
  at build/mlx_cuda_v13/_deps/mlx-c-src/mlx/c/transforms.cpp:15

Runner.prefill -> mlx.Eval -> panic
  -> (during unwind) cacheSession.close -> mlx.AsyncEval -> panic again

The same test under think-off passes (json_valid=true, eval 263, prompt_eval 1173) at the same num_ctx 16384, so window size is not the trigger. The nested panic in prefix-cache teardown points at cache state interacting with CUDA graph capture — hypothesis, not conclusion; I have not reproduced it in isolation. The other 11 think-on cells all returned valid JSON.

So I'd suggest mlx-cuda land as measured for think-off, with think-on carrying a stated known-defect rather than either unmeasured or a clean bill.

4. What I deliberately am NOT offering

The five-geometry token ladder. I have strong indirect evidence it is flat 1102 exactly as mlx-metal records — a bare probe gave prompt_eval_count 1127 on a 25-token prompt — but ADR 0011 rule 4 exists precisely to stop me pasting the mlx-metal row across, and indirect evidence is not the B8 prefix measurement. It needs measuring properly.

Which is where these all converge: #168 generates the [expect.…] row instead of transcribing it, #171 fixes the docker logs --since window that #168's budget read depends on (zoneless UTC stamp → ten-hour window on this host), and #172 creates the profile to put the row in. I have the server. If you land the rename, I'll run measure_ladder.py against :11495 and post the generated block for the mlx-cuda.gemma4 row.