Pull requests / #2349

#2349 moe_mm_parity: the default tile that did not exist, and --v3's v1 arg…

open · @demetree · 0 comentários · No GitHub

AMD / HIPModels & quants

Descrição

…ument list

Two stale defaults, both of which kept the test from covering what the engine ships.

The default tile was TM 16 TN 64 TK 16, but the v1 kernel set only instantiates TK 64: the default run died at pipeline creation on any GPU (measured on an M1 Max: "mtl: no function mm_gu_42_16_64_16_2"). TK is now 64, which both the v1 and the v2 sets instantiate, so the default run and --v2 both work; the engine's v2 tile for Q2_0 (16,64,16,2) stays reachable with --tile.

--v3 bound the v1 kernels' argument list ({W, x, H, stok, tiles, ma}) to the v3 kernels: tiles was read as the sorted-token buffer and MmArgs as raw int2 pairs, so every stride, n_embd and expert id was garbage. On the M1 Max that is a deterministic GPU command-buffer error in the GEMM pass; with the right arguments the v3 kernels run, and a separate M1 limit shows (≥40 threadgroups of mm_gu3 fault, 35 pass, data-independent) that the engine does not hit: gu_v3 = dn_v3 = coop_k4, which is false on the M1. v3 now binds {W, XS, HS, tiles, ma} as the engine does, fills XS for v3 too (v3 is v2's gather plus the register-operand GEMMs), and binds HS - not H - to down3 with DSG simdgroups.

Measured on an M1 Max (macOS 26.6.2, Q2_0, T 256, 64 experts): default (v1) PASS, rel L2 2.53e-06 vs the fp16-operand reference and 2.37e-04 vs exact; --v2 PASS, 4.42e-06 and 2.37e-04, also with the engine's tile (16,64,16,2).

Leaves alone: no kernel, engine or other test change.

## Title
<!-- If Applicable, reference the GitHub issue -->
Issue: Resolves # 

## Summary
<!-- Quick Summary of changes -->

## What changed
<!-- Specifics on files changed, and what changes were made there -->

## Extra Notes
<!-- Any extra notes, delete if there are none -->

No site

Links install, modelos, releases.