B200 Kernel Roofline Triage

E — Executable steps (Execution)

Once the skill is activated, the agent must follow this procedure:

1. Collect the minimal fact set
   • The operator formula, shapes, dtypes, batch, and whether inputs/outputs are reused.
   • The current implementation path (CUDA/Triton/TIRx/CUTLASS/framework op), the timing methodology, warmup, and whether communication is included.
   • The B200 model/power limit/clocks, the compile target, and a profiler summary.
   • Done criterion: you can write a one-line estimate of "useful FLOPs" and a one-line estimate of "HBM bytes".
2. Compute at least one roofline accounting
   • AI_HBM = useful_FLOPs / HBM_bytes.
   • Prefer the measured bandwidth on the user's machine and the same-dtype peak; without them, only order-of-magnitude inference is possible — label the assumptions explicitly.
   • Done criterion: an initial memory-bound / compute-bound / near-ridge call.
3. Check whether the implementation contradicts the initial call
   • memory-bound: check repeated reads/writes, intermediate tensors spilled to HBM, uncoalesced accesses, an overly wide dtype, and insufficient request concurrency.
   • compute-bound: check Tensor Core instructions, tile utilization, TMA/compute/store overlap, warp roles, tail tiles, and small shapes.
   • Neither fits: check launch latency, synchronization, CPU submission, communication, power/frequency, and occupancy resource pressure.
4. Build the evidence matrix
   • For each candidate bottleneck write "supporting evidence / counter-evidence / measurement needed".
   • Done criterion: at least 3 candidates listed, and they must not all be the same class of micro-optimization.
5. Design the minimal falsifiable experiment
   • Change only one factor at a time, e.g. disable fusion, switch to a contiguous layout, increase the pipeline depth, use a fixed shape, lock the clocks.
   • Stopping rule: if the experiment result contradicts the hypothesis, go back to step 3; do not keep stacking the same class of optimization.
6. Output the optimization order
   • P0: correctness and timing credibility; P1: the roof-determined primary bottleneck; P2: secondary scheduling/resource issues; P3: fine-tuning.

Required outputs

1. Conclusion: the current choice/diagnosis, never a vague "we may need to look at everything".
2. Evidence or assumptions: which items come from user data and which are assumptions pending verification.
3. Contract/table/timeline: the auditable intermediate artifacts corresponding to this skill.
4. Minimal validation: a correctness test, a boundary test, and one falsifiable experiment.
5. Risks and fallback: the alternative path when hardware, version, or resource requirements are not met.

B — Boundaries (Boundary) ★

Do not use when

• The user only asks about B200 memory capacity, price, or rack specs, with no operator or performance question.
• With no shape, dtype, timing, or dataflow information at all, do not assert a bottleneck outright.

Failure modes

• Treating the theoretical peak as a directly achievable promise.
• Looking only at occupancy while ignoring that explicit pipelining can already hide the latency; or conversely, looking only at pipelining while ignoring that resources prevent residency in the first place.
• Substituting a single profiler percentage for end-to-end evidence.

Limitations

• Roofline has limited explanatory power for irregular accesses, short kernels, dependency chains, and cross-GPU communication; latency and communication models must be added when necessary.

Related skills

• depends-on: none
• contrasts-with: b200-gemm-optimization-ladder
• composes-with: b200-layout-contract-auditor, b200-tma-pipeline-designer, b200-warp-specialized-debugger

Audit info

• Validation passed: V1 ✓ / V2 ✓ / V3 ✓
• Test definitions: 6 (3 should_trigger / 2 should_not_trigger / 1 edge_case)
• Hardware validation: not performed; must be verified on a target B200
• Distilled: 2026-06-25