triton-operator-performance-eval
About triton-operator-performance-eval
triton-operator-performance-eval is a skill for evaluating Triton operator performance on Ascend NPU. It guides performance analysts to use msprof for function-level comparisons and operator-level profiling, then diagnose bottlenecks rather than implement optimizations.
Key features
- 01Compare function-level performance with msprof
- 02Profile operator-level metrics with msprof op
- 03Classify bottlenecks using profiling data
- 04Specify metrics and evidence for performance reports
- 05Flag warm-up, JIT, and hardware-comparison pitfalls
Use cases
- 01Compare Triton and torch_npu on the same hardware
- 02Locate hotspots in multi-operator workloads
- 03Analyze kernel utilization and bottleneck types
- 04Check whether compilation or warm-up affected measurements
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/triton-operator-performance-evalin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/msprof-function-level.mdmsprof-op-level.mdperformance-data-analysis.mdDetails
From the project READMETriton 算子性能评估（Ascend NPU）
核心原则
只相信 msprof 数据，不凭直觉。
性能比（Ratio）定义：Ratio = torch_npu 耗时 / Triton 耗时。Ratio > 1.0 表示 Triton 更快，Ratio < 1.0 表示更慢。不是耗时的直接比值，而是耗时的倒数。目标通常为 Ratio ≥ 1.0x。
唯一可信采集方式：msprof（函数级）和 msprof op（算子级）。其他方式（time.time()、torch.npu.Event、do_bench等）因包含 Host 开销且精度不足，绝对不可用于性能评估。
| 命令 | 用途 | 典型场景 |
|---|---|---|
msprof --application="python x.py" | 函数级：多算子对比、全链路分析 | "哪个算子最慢？" |
msprof op --kernel-name=K python x.py | 算子级：硬件利用率、Bank Conflict | "这个 kernel 为什么慢？" |
决策：先 msprof 定位热点，再 msprof op 深度分析。
参考资源加载
| 任务 | 必须加载 | 不要加载 |
|---|---|---|
| 函数级性能对比 | msprof-function-level.md | msprof-op-level |
| 算子级硬件分析 | msprof-op-level.md, performance-data-analysis.md | msprof-function-level |
| 理解硬件术语 | ascend-terminology.md | — |
性能总结模板
完成评估后必须输出：
| 模块 | 内容 |
|---|---|
| 基本信息 | 算子名称、输入规模、硬件型号、测量方法 |
| 性能指标 | 执行耗时、内存带宽利用率、Cube/Vector 利用率、L2 Cache 命中率、Bank Conflict |
| 瓶颈诊断 | 瓶颈类型 + 判断依据 + CSV 数据证据 |
| 优化建议 | 按优先级排列，附预期收益 |
原则：所有结论必须有 Profiling 数据支撑。利用率 < 30% 标记为 重点关注。
瓶颈分类（仅用于诊断归类）
| 瓶颈 | 判断条件 | 详细优化手法 |
|---|---|---|
| Memory-Bound | AI < 硬件平衡点 | → 交给 performance-optim skill |
| Compute-Bound | AI > 硬件平衡点 | → 交给 performance-optim skill |
| Latency-Bound | 带宽和计算利用率均低 | → 交给 performance-optim skill |
边界：本 skill 负责诊断瓶颈类型并输出数据。优化手法由 triton-operator-performance-optim 负责。
反模式清单（NEVER）
- ❌ 使用非 msprof 方式计时（time.time/Event/do_bench 等）
- ❌ Triton(NPU) vs PyTorch(CPU) 对比 — 必须 同硬件 对比
- ❌ 不预热就采集（首次含编译开销）
- ❌ 只测一次就下结论 / 只测大 shape
- ❌ 采集时含打印或日志（I/O 干扰）
- ❌ 混淆
msprof和msprof op的用途
常见陷阱
| 陷阱 | 表现 | 正确做法 |
|---|---|---|
用 msprof op 做对比 | 只看单个 kernel | 对比用 msprof，深度分析用 msprof op |
--kernel-name 拼错 | 静默完成但无数据 | 确认名称与 Triton 函数定义一致 |
| 未区分编译和稳态 | 首次耗时异常高 | 至少 5 次预热后采集 |
| 忽略小 shape 性能 | 小 shape 差未发现 | 必须覆盖小/中/大 shape |
| 忽略 dtype 影响 | FP16/FP32 差异大 | 固定 dtype 对比，分别评估 |
| 函数级含 JIT 编译 | op_statistic 中 Triton avg 异常高（ms 级） | 对比用 msprof op 的 Task Duration，或函数级仅比较稳态调用 |
| Triton vs torch_npu Core Type 不同 | Triton=AI_VECTOR_CORE，torch_npu=MIX_AIC | 注意：MIX_AIC 不一定使用 Cube 引擎，需检查 aic_cube_ratio 是否为 NA；真正差距在 MTE2 指令粒度 |
函数级 msprof 的 JIT 编译陷阱（重要）
msprof 函数级采集会包含 JIT 编译时间。Triton kernel 首次调用每种 (shape, dtype, mode) 组合时触发编译，耗时可达数秒。op_statistic.csv 中的 Total Time 和 Avg Time 会将这些编译时间算入。
案例：Triton kernel 的 op_statistic 显示 Avg=17791 us，但 msprof op 的 Task Duration 仅 1362 us。差距完全来自 11 种 unique config 的 JIT 编译。
正确做法：
- 函数级对比仅看 稳态调用（忽略前 N 次或单独统计编译开销）
- 或直接用
msprof op的 Task Duration 作为 kernel 性能基准 - 对比 torch_npu 时注意 Core Type：torch_npu=MIX_AIC 可用 Cube 引擎，Triton=AI_VECTOR_CORE 不行