What problem does it solve? Tuned GEMM configs in aiter often fail silently: CSV rows keyed to the wrong gfx/cu_num never match, tuners run on shapes the engine never dispatches, and wrappers can drop the tuned kernelName so the deployed kernel is not the one measured. This Skill provides the measured workflow to tune aiter ops and prove the tuned config actually engages in production. ## Core Features & Use Cases - Engagement verification: Use AITER_LOG_TUNED_CONFIG to harvest the exact (M,N,K) shapes the serving engine dispatches, then confirm tuned rows bind with is tuned on cu_num hits before measuring. - Cross-backend tuning: Run gradlib's gemm_tuner.py for dense bf16 or the per-op quantized tuners (fp8/int8/fp4/MoE) that race hipblaslt, triton, flydsl, ck/cktile, and asm candidates per shape. - Correct deployment: Write tuned CSVs into the installed package's configs/model_configs directory rather than the regenerated /tmp cache, and gate on the aiter >= v0.1.15 kernelName-dispatch fix. - Use Case: While serving an FP8 model on sglang with MI300X, harvest the dispatched GEMM shapes from the baseline log, tune exactly those rows, verify the production wrapper reproduces the tuner's recorded latency, and only then run the e2e A/B. ## Quick Start Ask the agent to tune the aiter GEMM configs for my sglang serving workload on this MI300X box and verify the tuned rows actually engage at runtime.
