What problem does it solve? At decode time, grouped-GEMM MoE stage-1 (gate+up) kernels re-read the same low-precision expert weight from HBM once per sort-block, because token sorting pads each expert to a fixed block granularity. This redundant weight traffic dominates stage-1 latency when many experts hold two or more sort-blocks. ## Core Features & Use Cases - Pair-fusion mechanism: Builds a device-side, CUDA-graph-safe leader-block descriptor that merges two adjacent same-expert sort-blocks into one 2B-row compute tile, so the expert weight is loaded once and reused across both halves. - Validated applicability gates: Requires a tile_m=64 baseline, a substantial pairable-block fraction, and evidence that repeated-weight traffic is latency-relevant, with explicit instructions to report pair_count_fraction and paired_block_fraction. - Correctness and measurement discipline: Mandates odd-tail store masking, a runtime-signature gate (_am2_bmap plus one _blkmap_kernel dispatch), joint config sweeps, and honest segment timing that includes the descriptor producer kernel. - Use Case: On gfx950/MI355X with FlyDSL 0.2.2 running fp8-act/fp4-weight grouped-MoE decode, applying this recipe reduced the honest stage-1 segment median from 192.706 us to 174.498 us (1.104x) while passing parity. ## Quick Start Ask the agent to apply the FlyDSL decode MoE stage-1 block-pairing recipe to the grouped-GEMM gate/up kernel and validate it with a same-session paired versus unpaired A/B benchmark including parity checks.
