Ascend Profiling Analysis Skill 设计深度解析
本文深度解析一个用于分析 Ascend NPU torch profiler 产出的 skill,涵盖其设计哲学、Pipeline 架构、昇腾核心知识体系和先验知识体系。
一、背景与动机
为什么需要 profiling 分析?
在昇腾 NPU 上运行 LLM 推理时,的性能调优需要回答几个关键问题:
- Step 时间去哪了? attention/FFN/MoE 各占多少?
- 瓶颈在哪? Cube 计算还是 Vector 内存搬运?
- EP/TP 负载均衡吗? 有没有 rank 掉队?
- 通信是否拖后腿? HCCL collective 是否慢于预期?
传统的分析手段面临几个问题:
| 工具 | 问题 |
|---|---|
| CANN Studio Timeline | 只能看时序,无法聚合统计 |
trace_view.json | 数据稀疏,难以关联到 kernel 语义 |
kernel_details.csv | 数据量级 GB,需要专门解析逻辑 |
设计目标
这个 skill 的核心目标:从原始 profiling 数据出发,产出带证据链的可追溯报告。
- 每一条诊断结论都必须能追溯到原始 CSV 的行号
- 支持跨 rank 对齐和异常检测
- 输出 Markdown / Excel / HTML 三种格式
二、设计哲学:证据链优先
核心理念
每个 claim 必须能追溯到原始 row。
| |
置信度分层
| 置信度 | 条件 | 处理方式 |
|---|---|---|
| high | 直接 row 证据 + 交叉验证一致 | 直接输出 |
| medium | 直接证据存在,但缺少一个佐证 | 标注后输出 |
| low | 模式可疑,但覆盖不完整 | 标注 limitation |
结构 Role vs 实现 Evidence
这是理解整个 skill 的关键:
- 结构 Role = Paper 术语,表示"这是什么功能块"(MLA、DSA、CSA)
- 实现 Evidence = Kernel 分类,表示"哪些 kernel 实现这个功能"
| |
关键洞察:同一个 kernel(如 FusedInferAttentionScore)可以服务多个 architecture。Family 由组合判断,非单个 kernel。
确定性优先
| |
- 层数 = 观测结果,非假设
- 不写死模型名
- 宁可低置信度输出,不输出不可追溯结论
三、Pipeline 架构
阶段划分
normalize → segment → classify → summarize → cross_rank → diagnostics → report
↓ ↓ ↓ ↓ ↓ ↓ ↓
原始CSV Step切分 Block分解 聚合统计 跨Rank对齐 诊断发现 报告生成
阶段可复用
| |
远端执行策略
Profiling 数据可能几十 GB,绝不能全量拉回本地。
| |
Artifact 契约
每个阶段的产出文件固定,其他阶段只依赖 manifest.json 校验。
segment_manifest.json # 切分段数、层数、hard_errors
classify_manifest.json # block 统计、companion_layers
summary_manifest.json # pipeline 覆盖率
四、昇腾核心知识体系
AICore vs AIVector 解耦架构
Atlas A2/A3 的关键架构特征:Cube 和 Vector 是两个独立的执行单元。
┌─────────────────────────────────────────────────────┐
│ NPU Die │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ AI Core │ │ AI Vector │ │
│ │ (Cube) │ │ (Vector) │ │
│ │ │ │ │ │
│ │ ┌────────┐ │ │ ┌────────┐ │ │
│ │ │ MAC │ │ │ │ ALU │ │ │
│ │ │(矩阵乘) │ │ │ │(向量运算)│ │ │
│ │ └────────┘ │ │ └────────┘ │ │
│ └──────────────┘ └──────────────┘ │
│ ↑ ↑ │
│ └────────┴────────────┘ │
│ 解耦执行,互不阻塞 │
└─────────────────────────────────────────────────┘
Pipeline 时间字段映射
kernel_details.csv 暴露了 11 个 pipeline 时间字段(单位 μs):
| Pipeline | Stage | CSV Column | 含义 |
|---|---|---|---|
| AIC | matmul | aic_mac_time | Cube 矩阵乘 |
| AIC | fixpipe | aic_fixpipe_time | 写回/量化 |
| AIC | mte1 | aic_mte1_time | GM → L0 |
| AIC | mte2 | aic_mte2_time | GM → L0A/B |
| AIC | scalar | aic_scalar_time | AIC 标量指令 |
| AIV | vec | aiv_vec_time | Vector ALU |
| AIV | mte2 | aiv_mte2_time | GM → UB |
| AIV | mte3 | aiv_mte3_time | UB → GM |
| AIV | scalar | aiv_scalar_time | AIV 标量指令 |
为什么 AIC mte2 ≠ AIV mte2
两者走的是完全不同的内存路径:
| |
如果一个算子受困于 AIV 的 GM→UB 压力,错误合并会被误诊断为 Cube 侧 mte2 问题。
op_type 分类体系
基于 Accelerator Core 列和 kernel name 的粗粒度分类:
| op_type | 触发条件 | 含义 |
|---|---|---|
aic | Core = AI_CORE | 纯 Cube 算子 |
aiv | Core = AI_VECTOR_CORE | 纯 Vector 算子 |
mix_cv | Core = MIX_AIC/MIX_AIV | Cube+Vector 同时运行(FlashAttention、GroupedMatmul) |
mix_comm_aiv | Core = COMMUNICATION 且 AIV > 0 | 通信+AIV 融合(DispatchFFNCombine) |
communication | Core = COMMUNICATION 且 AIV = 0 | 纯 HCCL 集合通信 |
aicpu | Core = AI_CPU | Host 侧算子 |
mix_comm_aiv 的设计意图:当 CANN 报告 DispatchFFNCombine 时,Accelerator Core = COMMUNICATION。但实际上有一半运行时在 AIV 上跑。我们检查非零 AIV 时间并重新标记,让报告能单独归因 AIV 负担。
五、Step / Layer / Block 分解
Step 切分
基于 selection/sampling kernel 定位 step boundary:
| |
Step 切分的结果:
Step 0: [head] → [layer_0, layer_1, ..., layer_N] → [tail]
↑ ↑ ↑
启动开销 主计算 采样/输出
每个 step 分解为四个时间桶:
| 时间桶 | 计算方式 | 含义 |
|---|---|---|
| head | step.start → layer[0].start | 启动/调度开销 |
| main | layer[0].start → layer[-1].end | 主计算 |
| tail | layer[-1].end → step.end | 后处理 |
| bubble | wall - busy | 设备空闲时间 |
Layer 切分
按 anchor(attention / MoE / matmul / block_head)构建 layer observations:
| |
关键设计:层数是观测结果,不是先验假设。观测到什么就是什么。
Block 分解
每个 layer 最多切分为 2 个 block:
| |
Block 边界由 row 中点 决定,而非时间中点:
| |
六、Bound 分类
11 个 pipeline 字段 → 5 个 family
| |
Dominant Core vs Bound Stage
| |
| |
七、Class 分组:Shape-strict Equality
设计原则
Shape 必须完全一样才可以。跨 DP 的话可能存在两个 step 一个 shape 为 (3, 4),另一个 shape 为 (4, 3),这种情况也视为两种不同的 step。
| |
Aggregate 计算策略
| |
八、先验知识体系
这是 skill 最核心的创新:通过 YAML 声明式地管理模型架构知识。
三层架构
┌─────────────────────────────────────────────────────────┐
│ Layer 3: model_architectures.yaml │
│ HF arch → (attention_family, ffn_family, block_pattern)│
│ 用于诊断异常,不驱动切分 │
├─────────────────────────────────────────────────────────┤
│ Layer 2: attention_families.yaml │
│ kernel category 组合 → paper-aligned family name │
│ CSA/HCA/DSA/MLA/linear/GQA_MHA │
├─────────────────────────────────────────────────────────┤
│ Layer 1: kernel_signatures.yaml │
│ profile kernel name → categories + roles │
│ 100+ 条映射,覆盖所有见过的 kernel │
└─────────────────────────────────────────────────────────┘
Attention Family 检测(7 种)
| |
关键洞察:Kernel Category 中性设计
| |
代码片段:categories_and_roles 结构
| |
代码片段:resolve_attention_family 决策流程
| |
KVComp Overlay
| |
扩展新 Kernel 的流程
| |
九、通信诊断
HCCL 两层事件
| Layer | 出现位置 | 代表含义 |
|---|---|---|
| Op-level | kernel_details.csv 的 COMMUNICATION 行 | 用户发起的集合通信 |
| Task-level | communication.json (level 1) | 集合内部的任务分解 |
Op-kind Taxonomy
| |
Notify Wait 诊断
| |
诊断发现类型
| |
十、报告结构
章节布局
- Executive Summary — 关键指标一览
- Capture And Segmentation — 采集和切分统计
- Macro Step Timeline — per-rank step 时长分位数
- Pipeline Coverage — AIC/AIV 各 stage 占比
- Step Class View — top step classes 按 wall 贡献排序
- Layer And Block View — block_kind 分解
- Operator View — top 算子 + HCCL 汇总
- Cross-Rank Anomaly — 跨 rank 异常
- Evidence Chain — 证据索引
HTML 报告特性
- 单文件零依赖
- Single-step Inspector(点击 step 查看详情)
- Bubble tracing axis
- 可缩放多流时间轴
- 46 字段算子卡(带 raw kernel_details row 追溯)
十一、Skill 的优势与限制
优势
- 证据链可追溯 — 每条结论都能追溯到原始 CSV 行
- Kernel category 中性 — 易于扩展新 kernel
- Paper 术语与实现解耦 —
csa/dsa/mlavskv_compressor/lightning_indexer - 远端执行 — 避免大文件传输
- 确定性切分 — 不依赖模糊匹配
限制
不读 HF config.json — 无法直接确认 model arch
- 原因:skill 只看到
ascend_pt/输出,无 config 访问权限 - 影响:
block_pattern_unexpected诊断无法自动关联到 HF arch
- 原因:skill 只看到
Shape 可能缺失 — acl-graph compile 会擦除
Input Shapes- 影响:GQA/MHA/MQA 细化可能失败,保持伞形
gqa_or_mha
- 影响:GQA/MHA/MQA 细化可能失败,保持伞形
HCA 检测是 heuristic — 缺少确认样本
- 误报可能:V3.2 + KV 压缩在非 CSA 层
Task-level 通信数据需要 level 1 profiling
- Level 0 只有 op-level,
Notify Wait等诊断不可用
- Level 0 只有 op-level,
可改进点
| 改进项 | 当前状态 | 目标 |
|---|---|---|
| YAML-driven matcher | Python 代码镜射 YAML | 直接读 YAML |
| Shape 缺失 graceful degradation | 直接失败 | 多级 fallback |
| 诊断规则 YAML 化 | Python 内联 | diagnosis_rules.yaml |
| HF config 集成 | 不可达 | serving 侧传递 config |
| 层结构指纹库 | 人工阅读 YAML | 自动匹配已知架构 |
十二、关键设计原则总结
层数 = 观测结果,非假设
- 不写死 24/27/36/40 层
不写死模型名 / 层数
- “layer_17” 只是个 hash,不是 “attention_layer_17”
宁可低置信度输出,不输出不可追溯结论
kernel category 中性
- 同一 kernel 可服务多个 architecture
Paper 术语与实现解耦
csa/dsa/mla是架构名kv_compressor/lightning_indexer是 kernel category
AIV mte2 与 AIC mte2 必须分开
- 两者走不同内存路径
Shape 缺失不合并
- 保守策略:宁可 under-cluster