菜单
评估 Ascend NPU 上 Triton 算子性能。使用 msprof/msprof op 采集性能数据，诊断 Memory-Bound/Compute-Bound 瓶颈，测量硬件利用率，生成性能报告。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 性能基准