What problem does it solve? Triton-based int4 (W4A16) and fp8 blockscale quantized fused-MoE kernels on AMD MI300X (gfx942) hit a performance ceiling around 1.1x from body-level tuning because the int4 unpack loop is latency-bound at 15-20% HBM utilization, leaving large speedups unreachable without a full kernel rewrite. ## Core Features & Use Cases - Triton-to-FlyDSL kernel rewrite: Maps quantized grouped-GEMM math onto existing FlyDSL compile_* MFMA primitives (moe_gemm_2stage, moe_blockscale_2stage) instead of writing kernels from scratch, achieving 3.6-6.2x over the Triton golden. - Exact numerics handling: Folds the GPTQ zero-point (zp=8) into weights so symmetric FlyDSL int4 matches GPTQ no-zp math, with a split correction term for per-group zero-points. - Memory contract enforcement: Mandates [M, hidden] stage-2 output via in-kernel accumulate to prevent the +896 MiB transient that OOMs e2e serving despite isolated wins. - Use Case: A hot fused_moe_kernel_gptq_awq kernel in a Kimi-K2.6 vLLM deployment is identified as the bottleneck; this skill rewrites it in candidate.py as a compiled FlyDSL kernel, validates parity (cosine ~0.999994), and benchmarks same-session speedup across decode and prefill regimes. ## Quick Start Ask the agent to rewrite the hot int4 W4A16 Triton fused-MoE kernel in candidate.py into a FlyDSL kernel and validate correctness and same-session speedup on gfx942.
