[gilby]

What this changes

The routed experts' grouped prompt GEMM (experts_mma.metal), bit-equal to the decode row kernels over the same rows; registered with the kernel contract.

Main's shared files change only by one-line hooks; this part's records, suites and limits go into the family's own files (dsv41_metal_records.zig, metal_dsv41_main.zig, metal_dsv41_limits.zig).

Part 4 of 18 of the stack for #1676; stacks on dsv41-metal-pr/03-mxfp4-experts (part 3, #1707).

Receipt

• Environment, with the TensorFold commit, MLX or PyTorch version, machine and GPU, checkpoint and revision: TensorFold 16f5bc1 on main 2761c24 (native Zig 0.17.0; no MLX or PyTorch); Apple M3 Ultra (60-core GPU), 96 GB, macOS, for the kernel and device tests; checkpoint deepseek-ai/DeepSeek-V4.1-Flash-1017.
• Exactness, from tools/bench_concurrent.py --alone --serial or token_sha against "draft": false: n/a: kernels only; the kernel contract checks each launch geometry's bits against the others and against float64.
• Decode speed before and after, from tools/bench_openai.py: measured on the PR that turns serving on.
• Prompt speed before and after: the cold first request's ttft_s from tools/bench_cache.py --require-cold on a long prompt, or "n/a" with the reason when the change cannot reach prompt processing: measured on the PR that turns serving on.
• Tests run, with pass, fail and skip counts: zig build test tf-kernel-contract -Dcpu=apple_m1: exit 0, 583/583 steps, 0 fail; kernel contract, tf-kernel-contract --only dsv41 (Metal): SUMMARY 17 kernels: 17 pass gates 1-4, 0 fail, 0 known findings; 28 controls: 28 red as planted, 0 missed; 0 limit problems; python3 tools/zig/lean_check.py: 424 problems, the same count as main. Zig's summary counts only the test binaries it ran in that invocation, so the step count is the comparable figure.
• Not run, and why: CUDA: no CUDA code changes; Metal on M1, M2, M4 and M5: one M3 Ultra only (the contract's limits check covers the M1 to M5 pipeline limits).

Checklist

• Every token still goes through the lane rounds. No serial path, and nothing that needs drafts off.
• Drafted output equals "draft": false, a resumed prompt equals a fresh one, and concurrent equals solo.
• No precision traded for speed. If the bits change, the description says which sums change and why.
• A new or changed GPU kernel is registered with the kernel contract (docs/kernel-contract.md); each backend's SUMMARY line is in the receipt.
• Prompt processing is no slower than the last release.
• The description says which platforms I ran, Metal M1 to M5 and CUDA, and which I could not.
• New tests fail before the change, pass after it, and skip cleanly without their dependency.
• Comments and docstrings are one line. No measurements or history in the source.
• No personal data, machine names, internal hosts or local paths. No AI attribution lines.

[ashhart]

Thanks @gilby. With #1705-#1707 landing, we've reached parts 4 to 11, so please rebase them onto main in order. What we read here is the 29 Oct stack: each kernel part is under the contract with its own records and planted controls (17 to 59 kernels, 28 to 116 controls, every SUMMARY clean on your M3 Ultra), and Kimi's files are untouched past part 3. Two items from our 31 Oct list fall in this range and aren't in these versions yet: glue_tmp.metal's 16 kernels (#1710) and fused.metal's 3 (#1714) need their records and controls, with the unused g_actq, g_swiglu and g_join gone; and #1715 adds test-dsv41-metal to zig build test, which should be its own step. Once the rebased parts are up, we'll run tf-kernel-contract --only dsv41 on our Macs and land them in order.

[ashhart]

Thanks @gilby for the quick rebase. Parts 4 to 6 apply cleanly on current main once #1706 and #1707 are in. Lean is unchanged, Kimi's files are untouched, and the shared files change only by hooks. #1708 and #1709 are ready, and we'll land them in order after #1706 and #1707.

On #1710, thanks for deleting g_actq, g_swiglu and g_join and adding the 14 launch records. One thing is left from our list. The suite runs float64 cases and controls for five of glue_tmp.metal's kernels (rmsnorm, rope, scatter, embed and hc mean, 15 controls), but g_fp4pack, g_fp4rt, g_pool2, g_cand, g_hcmix, g_hcpre and g_hcpost have no case. Their planted faults are in the source, but nothing runs them, so nothing shows them red, and glue.zig launches all seven. Could each get its float64 case and controls? If #1711's registered glue replaces some before serving, deleting those from glue_tmp.metal works too; just say which part replaces them.

[ashhart]

A correction to our notes on #1711 to #1714, @gilby: each part carries the ones before it, so #1711 and later can only land after #1710. We are landing #1708 and #1709 now, after the dsv41 contract on our M3 Ultra, with one changelog line crediting you for both. #1711 to #1714 follow as soon as #1710 has cases for the seven glue_tmp.metal kernels (or drops the ones a later part replaces).

[ashhart]

Thank you @gilby. This is merged into main with your commits under your own name, so you're listed as a TensorFold contributor. It ships in the next release, credited to you in the changelog and the release notes.

[ashhart]

Thanks @gilby! The grouped prompt GEMM for DeepSeek V4.1's routed experts on Metal, under the kernel contract and bit-equal to the decode rows, is in 1.2.1: https://github.com/ashhart/TensorFold/releases/tag/v1.2.1