What problem does it solve? Deciding which operators should be fused into a single kernel—and whether the fusion is worth doing—requires structural rules and benefit estimation before any kernel is written. This Skill judges fusion-unit boundaries and pre-evaluates expected gains from model code plus profiling execution traces, so engineering time is not spent on fusions that cannot pay off. ## Core Features & Use Cases - Boundary determination: Applies construction rules (function boundaries as candidate groups, attention-family operators as hard anchors, Cube-first wrapping of Vec operators, iterative re-fusion, MatMul-family partitioning for MLP/MoE) to decide where a fusion unit starts and ends. - Benefit pre-evaluation: Classifies chains as MTE-saturated, vector-saturated, or vector-constrained using memory_bound and pipe utilization ratios, then applies bandwidth lower bounds, region share, ceiling method, floor-first, and Amdahl checks to produce go/no-go verdicts. - Gated deliverable: Produces a mandatory fusion_scope.md table validated column-by-column by scripts/check_fusion_scope.py, with theory columns computed by scripts/theory_columns.py and device peaks measured by scripts/perf_probe.py. - Use Case: Given kernel_details.csv and op_summary CSVs from a DiT model profile, ask whether the norm/rope chain after attention can be fused into one kernel and receive a boundary proposal plus a quantified benefit range or a rejection reason. ## Quick Start Ask the assistant to analyze whether the operators in your profiled execution sequence can be fused into one kernel and whether the fusion is worth implementing.
