bug(mlx): nax capability warning false-positives on non-Neural-Accelerator hardware (fires on every CI build)

[Pushkinist]

Found by the CI run of #249 itself — a case that cannot be reproduced on the dev machine.

Problem

The build-time nax capability probe fires its loud warning on GitHub's macos-14 runner:

warning: rmlx-mlx@0.3.0: MLX at /opt/homebrew/opt/mlx (mlx 0.31.2, mlx-c 0.6.0_2)
  ships no steel_gemm_fused_nax kernels in lib/mlx.metallib.
warning:   Those are the Neural-Accelerator GEMM path. Without them GPU matmul throughput
  measured ~3.8x lower and prefill 2.2-3.7x slower on Neural-Accelerator-class hardware…

Two things are wrong there:

1. False positive. The Neural Accelerator is M5-only; macos-14 runners are M1. The kernels are legitimately absent and their absence costs that machine nothing. We now emit an alarming warning on every CI build, twice (clippy + build).
2. The message contradicts itself (hard rule 7). The runner is on 0.31.2 — our pinned "good" pair — yet the warning says "ships no … kernels" and then "rMLX pins the validated pair mlx 0.31.2 + mlx-c 0.6.0_2, whose metallib ships them." Both cannot be true. On that bottle, they aren't.

What this reveals (worth folding into #216's thesis)

The pin does not guarantee the kernels — the bottle does. brew 0.31.2 on this M5 dev box ships 145 distinct nax kernels; brew 0.31.2 on the M1 CI runner ships 0. So bottle contents vary by runner arch/OS/toolchain, which strengthens the "bottling/toolchain regression, not an MLX regression" conclusion (see the kept depends_on xcode: ["15.0", :build] note) — but it means "pin 0.31.2 ⇒ fast GEMM" is only true for this machine's bottle.

Fix directions

Gate the loud warning on hardware that actually has a Neural Accelerator (M5-class) — on anything else the kernels are irrelevant and their absence should be silent (or at most a one-line informational note). Detect the host capability rather than inferring from version/bottle: the probe already answers "are the kernels present?"; it needs a companion "does this machine want them?".

Keep the current behaviour where it matters: on NA-class hardware, missing kernels stay loud.

Also fix the self-contradiction — the "whose metallib ships them" clause must not assert a property of a bottle we didn't inspect.

Test

• Simulate/assert: NA-class host + kernels missing → loud warning (today's behaviour, keep).
• Non-NA host + kernels missing → silent (or a brief note), and no contradictory "the pin ships them" clause.
• Kernels present → silent either way (already true).
• CI must build clean without the alarm.
• Warn-not-fail preserved in all cases (a public user on any layout must build).

Related: #216 (the pin + probe), #248.

[Pushkinist]

Three corrections to this issue — the premise I filed it on was wrong.

1. "The Neural Accelerator is M5-only" is FALSE. It is M5-family + A19 Pro:

chip	GPU Neural Accelerator
M1 / M2 / M3 / M4	No
M5 (Oct 2025)	Yes — 10-core GPU
M5 Pro / M5 Max (Mar 2026)	Yes — up to 20 / 40-core GPU
M5 Ultra	Unknown (unannounced)
A19 Pro (iPhone 17 Pro)	Yes — NAs in each of 6 GPU cores

On macOS it is M5-family only, which is what matters for the bottle — so the fix direction survives. But the GPU Neural Accelerator is also not the Neural Engine (ANE); Apple's own wording keeps them separate ("the 16-core Neural Engine … complementing the Neural Accelerators in the CPU and GPU"). Any hardware gate must detect the GPU NA, not the ANE — every Mac since M1 has an ANE, so gating on that would make the check useless.

2. My "this strengthens the bottling/toolchain regression conclusion (see the depends_on xcode: ["15.0", :build] note)" is WRONG. Both bottles were built with Xcode 26.4 — the Xcode note is a red herring. The real cause is a deployment-target gate (MACOSX_DEPLOYMENT_TARGET=26.0 vs MLX ≥0.32.0's >= 26.2 requirement; see #216). The CI observation is orthogonal, not corroborating.

3. The CI M1 finding is expected, not evidence of anything. From the #249 log, verbatim:

Pouring mlx--0.31.2.arm64_sonoma.bottle.tar.gz

arm64_sonoma, not arm64_tahoe. That builder cannot satisfy MLX_METAL_VERSION >= 400 / MACOS_SDK_VERSION >= 26.2 (needs Metal 4 / Xcode 26), so arm64_sonoma has never shipped nax at any version — and an M1 has no NA, so it costs that machine nothing. Same version, different bottle.

What survives — and it's the substance of this issue:

• The false positive is real: we alarm on every CI build about kernels that machine neither has nor needs.
• The self-contradiction is real: build.rs asserts "rMLX pins the validated pair … whose metallib ships them" — a property of a bottle it never inspected. True on arm64_tahoe, false on arm64_sonoma, which is exactly where it printed. Hard rule 7.
• "Pin 0.31.2 ⇒ kernels present" is false in general. The bottle determines it, not the version. That reframes the fix: the loud warning must gate on GPU-NA-class hardware, and the message must not assert what the pin ships.

Note for the design: MLX already refuses nax at runtime when the kernels are absent (#2982), and upstream added a configure-time warning (4367c73, PR #3824, Jul 10) — after 0.32.0 was tagged, so that bottle build never printed it. Our probe is filling a real gap; it just needs the hardware predicate.