metal : static-K32 tensor mul_mm for full-tile Q1_0 products (GGML_METAL_Q1_MM_K32=1)

[jasontitus]

Overview

On devices with tensor units (M5, A19), Q1_0 prompt processing runs on the tensor kernel_mul_mm, whose K extent is dynamic and whose loads and store are clamped for partial tiles. This adds an opt-in variant, GGML_METAL_Q1_MM_K32=1, for Q1_0 products made only of full tiles (M % 64, N % 128 and K % 32 all zero, all contiguous): a static K32 extent and no bounds handling. The same threads dequantize the same 16-weight chunks in the same K order with the same matmul2d; only the static extents and the whole-tile store differ. Any remainder keeps the whole product on the generic kernel. The kernel sits in the GGML_METAL_HAS_TENSOR branch of mul_mm.metal. Off by default.

Additional information

M5 Max, Bonsai 27B Q1_0, this branch, switch off vs on, three A-B-B-A quartets with 8 s cooldowns (tok/s, llama-bench):

Case	Off	On	Speedup [quartet range]
tg128 (control)	66.05	66.08	1.000 [0.998-1.003]
pp128	613.44	660.29	1.076 [1.076-1.077]
pp512	856.66	917.19	1.071 [1.070-1.071]

Correctness:

• test-backend-ops -o MUL_MAT: all pass with the switch off and on; the K32 kernel runs for two new full-tile cases (plain, and batched with broadcast).
• Full model, one 512-token prompt: logits at all 512 positions bitwise equal with the switch off and on on the M5. Bitwise equality depends on how the device compiler lowers the two kernels, so it is a measured property, not a guarantee on other devices.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES. Claude (Anthropic) helped with the implementation, testing, measurements and this description; I reviewed the change and own it.