What problem does it solve? Tuning kernels inside a live vLLM serving stack fails in non-obvious ways: config filenames depend on a device name that torch reports as empty, shipped configs rarely match MI355 hardware, and there is no signal that a tuned config was actually loaded. This Skill captures the real shapes a model issues, tunes the right kernels, deploys configs where vLLM looks, and proves engagement from the server log. ## Core Features & Use Cases - Shape capture from real traffic: Rank GEMM shapes by call count using HIPBLASLT_LOG_MASK and AITER_LOG_TUNED_CONFIG logs instead of tuning generated sweeps. - Two tuning surfaces: Tune dense GEMM through the aiter gradlib tuner and fused MoE through vLLM's benchmark_moe.py with its M-bucketed Triton config format. - Deployment and verification: Deploy via VLLM_TUNED_CONFIG_FOLDER and confirm from startup logs that vLLM loaded the tuned config rather than falling back to defaults. - Use Case: On an MI355 serving a MoE model, capture the issued shapes, tune the top fused-MoE configs, drop them into a folder pointed to by VLLM_TUNED_CONFIG_FOLDER, and A/B serving throughput by toggling the variable. ## Quick Start Use the tuning-in-vllm skill to capture the GEMM shapes my vLLM server issues on my MI300X, tune the fused-MoE configs, and verify from the startup log that the tuned config was loaded.