Skip to content

docs: the MLX pin move and the vision encoder (#312) — CUDA measurement, two causes, quant_dims.py - #316

Merged
glennneuber merged 2 commits into
mainfrom
docs/mlx-pin-encoder-312
Sep 18, 2026
Merged

glennneuber merged 2 commits into
mainfrom
docs/mlx-pin-encoder-312

Conversation

@glennneuber

@glennneuber glennneuber commented Sep 18, 2026 •

Copy link
Copy Markdown

The record of #312 on the CUDA side, and the rule it leaves behind.

Task doc (tasks/upstream-sync-0.34.1.md, new section "The MLX pin move and the vision encoder"): TestVisionGoldenParity at both ends of 2b95b4a5 → 8a7ba949 on MLX-CUDA, two runs per cell, every repeat to the digit. 12b and 26b identical across the fold; 31b moved slightly. Two causes, one per backend:

  • Metal-only, a fix: Fix fp quantized matmul corruption when the quantized dim is not a multiple of 32 ml-explore/mlx#3912 (fp_qmm_t read past K when K % 32 == 16). gemma4's vision mlp.down_proj has K = 4304 in 26b and 31b; 12b has no such shape. The CUDA kernel never had the defect: 26b reads 0.0469 at both ends, which the fixed Metal kernel (0.0508) now agrees with. No campaign on this host is affected.
  • Shared Go code, small: the fold's global-scale f32(f32(m × 2688) / 2688) round trip, one f32 ulp off for 17 of 31b's 191 vision global scales and exact for both of 12b's. A two-line control on the current fold reproduces the old 31b line to the digit. Inside the test's bounds; whether to keep the raw multiplier on the wrapper-applied paths is the maintainer's call.

Plus the recipe for running x/mlxrunner tests against the CUDA payload outside the image (the include symlink MLX needs for CCCL), which is what made the old side a 90-second run instead of a rebuild.

Rule for the next fold: list the pin range's commits and check every kernel fix's selection condition against the served models' quantized dims. Enforced by the new vision-suite/quant_dims.py (reads safetensors headers from the store, lists each quantized weight's K, flags K % 32 != 0; 8 offline tests), and a learnings-log entry with the cost.

Against the store today:

### gemma4:31b-nvfp4: 602 quantized weights, 27 with K % 32 != 0, 0 undetermined
### gemma4:26b-nvfp4: 455 quantized weights, 27 with K % 32 != 0, 0 undetermined
### gemma4:12b-nvfp4: 332 quantized weights, 0 with K % 32 != 0, 0 undetermined

Discussion: #312 (my two comments there carry the measurement and the reconciliation against the Metal session's prediction table).

🤖 Generated with Claude Code

glennneuber and others added 2 commits September 18, 2026 20:41
…nt, two causes, the rule for the next fold

CUDA at both ends of 2b95b4a → 8a7ba94: 12b and 26b identical to the digit, 31b moved slightly.
26b's Metal move is ml-explore/mlx#3912 (Metal-only fix for fp_qmm_t reading past K when K % 32 == 16;
gemma4's mlp.down_proj has K = 4304). 31b's move on both backends is the fold's global-scale
×2688/÷2688 round trip, demonstrated by a two-line control that reproduces the old line to the digit.
Rule: check kernel fixes in the pin range against served models' quantized dims. Plus the recipe for
running x/mlxrunner tests against the CUDA payload outside the image.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…nd flags K % 32 != 0; learnings-log entry for #312

The shape half of the pin-move rule recorded in the 0.34.1 task doc: at each MLX pin move, read the range's
kernel fixes' selection conditions against the quantized tensor dims the fork serves. Against the store it
reports gemma4 31b and 26b nvfp4 with 27 unaligned weights each (mlp.down_proj, K = 4304) and 12b with none,
which is the #312 split. Reads safetensors headers only; 8 offline tests on a synthetic store.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@glennneuber
glennneuber merged commit fd74486 into main Sep 18, 2026
1 check passed
@glennneuber
glennneuber deleted the docs/mlx-pin-encoder-312 branch September 18, 2026 11:45
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