tuning-ck

Run ckProfiler with positional arguments: op name, data type code, layout code, verification and timing flags, then M, N, K and strides. Enable verification (arg4=1) and timing (arg7=1), raise warm-up and iteration counts above defaults, and read the winning instance name to see the tile and pipeline that won.

Seven per-op tuner scripts under aiter's csrc directory race CK candidates and write config CSVs the runtime reads. Prefer the umbrella entry point aiter/utility/pretune.py, which auto-detects architecture, tags results, and rebuilds the inference library with winners.

Yes, CK's gemm_mx op is the only route to MXFP8 on gfx950 since the shipped aiter builds lack an MXFP8 operator. It uses its own positional argument list where arg2 selects the format (f4->f16, fp8->f16, fp8->bf16) and instances print ScaleBlockSize: 32.

The shipped input file untuned_fmoe.csv contains eleven rows specifying torch.float8_e4m3fnuz, the gfx942 FP8 dialect, which raises a KeyError on gfx950 and aborts the whole run. Filter those rows out with grep -v fnuz before tuning.

These tuners time on a single operand set with no cache-invalidation knob, so their reported microseconds are warm-cache and were measured up to 23% optimistic on one shape. Re-time every winner cold on an independent harness with rotated buffers before deploying.

Selection only chooses among pre-compiled instances; it cannot reach kernels that do not exist in the shipped library. For shapes needing new tile configurations, CK's tile_engine generates and compiles new instances, which this skill explicitly does not cover.