Menu
评估 Ascend NPU 上 Triton 算子性能。使用 msprof/msprof op 采集性能数据，诊断 Memory-Bound/Compute-Bound 瓶颈，测量硬件利用率，生成性能报告。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Kubernetes 集群健康检查与安全修复 — 诊断问题，用户确认后执行修复
排查并优化 Ascend C 算子性能。当用户开发、审查或优化 Ascend C kernel 算子时使用，或当用户提及 Ascend C 性能优化、算子优化、tiling、流水、搬运、 内存优化、NPU/昇腾等关键词时触发。
多语言安全代码审查 (Security Code Review)。对 Python、C++、Shell、Markdown 文件进行系统性安全漏洞检测与修复指导。覆盖 OWASP Top 10、CWE Top 25、CERT 安全编码标准。当用户提及以下内容时，务必使用此技能：安全审查、安全代码审查、security review、code review 中的安全检查、漏洞扫描、安全合规检查（CWE/CERT/OWASP）、编写安全代码、检查代码安全性、推理服务安全审计、多模态 Token 安全校验、JSON 嵌套深度攻击防护。即使用户没有明确说'安全审查'，只要涉及代码安全性评估、漏洞检测、安全最佳实践，都应触发此技能。
昇腾NPU CANN Toolkit+Kernels+NNAL安装部署技能。支持从官网下载run包安装和从Docker镜像提取两种方式，覆盖驱动检查、包下载、安装、环境变量配置与验证全流程。当用户需要安装CANN全套组件或指定版本CANN到自定义路径时调用。
根据设计文档生成 AscendC 算子完整代码实现并完成框架适配。TRIGGER when: 设计文档已完成，需要生成 op_host/op_kernel 代码、注册到 PyTorch 框架、编译测试。关键词：代码生成、op_host、op_kernel、tiling、kernel、框架适配、算子注册。
完成AscendC算子设计 - 帮助用户完成算子的架构设计、接口定义和性能规划。当用户提到算子设计、算子开发、tiling策略、内存规划、AscendC kernel设计、两级tiling、核间切分、核内切分时，使用此skill。
| name | triton-operator-performance-eval |
| description | 评估 Ascend NPU 上 Triton 算子性能。使用 msprof/msprof op 采集性能数据，诊断 Memory-Bound/Compute-Bound 瓶颈，测量硬件利用率，生成性能报告。 |
只相信 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 负责。
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 编译时间。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 编译。
正确做法：
msprof op 的 Task Duration 作为 kernel 性能基准