ascend-moe-optimizer-trace-analyzer

star 920

在用户提供 Chrome/Perfetto trace.json、或排查 Ascend 上 MoE/FusedDeepMoe 等算子性能时使用。按 phase、category、core group、tid 统计耗时、overlap、bubble,输出 CSV、Markdown 报告与确定性诊断;可选外部 LLM 扩写分析。默认 phase 映射面向 UMDK FusedDeepMoe,其它 trace 需替换或扩展 config/phase_map.yaml。

openJiuwen-ai By openJiuwen-ai schedule Updated 5/19/2026

name: ascend-moe-optimizer-trace-analyzer description: 在用户提供 Chrome/Perfetto trace.json、或排查 Ascend 上 MoE/FusedDeepMoe 等算子性能时使用。按 phase、category、core group、tid 统计耗时、overlap、bubble,输出 CSV、Markdown 报告与确定性诊断;可选外部 LLM 扩写分析。默认 phase 映射面向 UMDK FusedDeepMoe,其它 trace 需替换或扩展 config/phase_map.yaml。

Ascend MoE 性能 Trace 分析

分析 Chrome/Perfetto 风格的 trace.json,把原始 trace event 转换为结构化统计表、图表和 Markdown 报告,用于替代人工在 Perfetto 中做第一轮耗时分布和瓶颈定位。本 skill 的内置名称为 ascend-moe-optimizer-trace-analyzer;当前目录为 ascend-moe-optimizer-trace-analyzer

何时使用

  • 用户需要分析 算子或 runtime 打点 导出的 Chrome/Perfetto trace.json,关注 phase 分布、category、Ascend core group、线程 tid、overlap、bubble
  • 调优 Ascend 上 MoE / FusedDeepMoe(如 fused_deep_moe 或需沿用本仓库默认 config/phase_map.yaml 的场景。
  • 需要 确定性自动诊断,或可选的 --llm-analysis 二次解读。

脚本位置

  • 用户安装后的 skill 根目录:<ASCEND_MOE_OPTIMIZER_SKILL> = ~/.jiuwenswarm/agent/workspace/skills/ascend-moe-optimizer-trace-analyzer
  • 入口:<ASCEND_MOE_OPTIMIZER_SKILL>/app.py
  • 从本仓库资源运行时,将上述路径换为 jiuwenswarm/resources/agent/workspace/skills/ascend-moe-optimizer-trace-analyzer(相对仓库根目录)。

执行命令前请先 cd<ASCEND_MOE_OPTIMIZER_SKILL>,或使用下文绝对路径形式的 python3 .../app.py

能力概览

本 skill 面向的核心对象是 trace.json,不是某一个固定算子。它本身负责:

  • 解析 trace 中的完整区间事件。
  • 将原始 trace name 映射为可稳定统计的 phase。
  • 按 phase、category、core group、tid、raw name 聚合耗时。
  • 计算 phase overlap 和外层阶段 bubble。
  • 生成统计图、文字化统计摘要和 Markdown 报告。
  • 生成稳定、可复现的自动诊断。
  • 可选调用外部 LLM,把统计上下文扩写成专家分析段落。

当前仓库默认携带的 config/phase_map.yaml 和部分诊断规则来自 UMDK FusedDeepMoe trace 的实践经验。因此,默认配置对 FusedDeepMoe 最友好;如果要分析其他来源的 trace,应替换或扩展 phase/category 映射配置,并逐步沉淀对应领域的诊断规则。

Agent 执行原则

执行本 skill 时,agent 不应把文档中的示例路径当成固定输入。应先从用户请求或当前工作区中确认以下上下文,并把它们替换到命令中:

  • TRACE_JSON:必需,用户要分析的 trace 文件。
  • OUTPUT_DIR:必需或由 agent 选择,建议按本次任务命名,例如 output/<case_name>
  • PHASE_MAP:可选,phase/category 映射配置。若用户指定算子或已有对应配置,应使用对应配置;否则使用默认 config/phase_map.yaml
  • SOURCE_ROOT:可选,算子源码工程目录,例如某个 UMDK 工程。当前 CLI 尚未消费该参数,但 agent 可以用它阅读源码、理解打点语义和辅助维护 phase map。
  • OPERATOR:可选,用户指定的算子名,例如 fused_deep_moe。当前 CLI 尚未消费该参数,但 agent 应用它选择或维护对应的 phase/category 规则和诊断上下文。

如果用户只提供 trace.json,按 trace-only 模式分析。如果用户同时提供源码目录和算子名,agent 应先阅读相关源码打点,再决定是否需要补充或调整 PHASE_MAP

执行命令

<ASCEND_MOE_OPTIMIZER_SKILL> 目录下执行(以下 <ASCEND_MOE_OPTIMIZER_SKILL> 含义见「脚本位置」):

基础命令模板:

cd <ASCEND_MOE_OPTIMIZER_SKILL>
python3 app.py \
  --trace <TRACE_JSON> \
  --phase-map <PHASE_MAP> \
  --output-dir <OUTPUT_DIR>

常用参数:

  • --trace PATH:输入 trace JSON,必填。
  • --phase-map PATH:phase/category 映射配置,默认 config/phase_map.yaml
  • --output-dir DIR:输出目录,默认 output
  • --top-n 20:控制 report.md 中各表展示的行数。
  • --llm-analysis:启用 LLM Analysis 章节。
  • --llm-command "<cmd>":外部 LLM 命令,命令从 stdin 读取 prompt,并把分析文本写到 stdout。
  • --llm-timeout 120:LLM 命令超时时间,单位秒。

如果使用默认 phase map,可以省略 --phase-map

cd <ASCEND_MOE_OPTIMIZER_SKILL>
python3 app.py \
  --trace <TRACE_JSON> \
  --output-dir <OUTPUT_DIR>

如果本机安装了 matplotlib,运行时会默认生成统计分析总图 analysis_charts.png,并嵌入 report.md。未安装时会跳过图表,其他输出不受影响。

LLM 命令也可以用环境变量配置:

export TRACE_ANALYSIS_LLM_CMD="<your-llm-cli>"
cd <ASCEND_MOE_OPTIMIZER_SKILL>
python3 app.py \
  --trace <TRACE_JSON> \
  --phase-map <PHASE_MAP> \
  --output-dir <OUTPUT_DIR> \
  --llm-analysis

如果未启用 --llm-analysis,仍会生成 llm_prompt.md,方便后续手动交给 Codex 或其他模型复核。

输入要求

支持两种 trace 文件外层格式:

  • { "traceEvents": [...] }
  • 直接以事件数组 [...] 作为文件内容

支持的事件类型:

  • ph == "X":完整区间事件,直接使用 ts + dur 得到结束时间。
  • ph == "B" / "E":按 (pid, tid, name) 栈式配对为完整区间。

每个可分析事件至少应包含:

  • name:事件名称。
  • ts:开始时间或 B/E 时间戳。
  • dur:仅 X 事件需要。
  • pid / tid:进程和线程维度,建议保留。
  • args:可选,若包含 core_type/core_id/rank_id/extra_id/event_id 等字段,报告会一并保留。

不匹配 --phase-map 的事件当前不会进入 phase 统计表。分析非默认 trace 时,最重要的适配工作就是维护一份能覆盖目标 trace name 的 phase mapping。

分析时会同时保留:

  • name:原始 trace name。
  • normalized_name:去掉 [extra:x] #seq 后的归一化名称,便于把同一类事件合并统计。

Phase 和 Category

本 skill 通过 --phase-map 指定的 YAML 配置把原始 trace name 映射到稳定 phase。配置包含两类信息:

  • phases:phase 到正则 pattern 列表的映射。
  • phase_categories:phase 到 category 的归因。

正则命中多个 phase 时,优先选择 pattern 字符串最长的更具体规则。

默认 category 包括:

  • container
  • wait
  • sync
  • compute
  • epilogue
  • communication
  • quant
  • init
  • cleanup
  • other

对于 UMDK FusedDeepMoe,默认配置已经覆盖 processingdispatch_gmm1gmm2_combine 及其子阶段。对于其他 trace,可以保留这套统计框架,只替换 phase/category 映射。

Core Group

本 skill 会尽量为每个已映射事件补充:

  • core_type
  • core_group
  • core_kind
  • core_id

当前内置的核组解释来自 UMDK 1C2V trace:

  • type0 -> cube
  • type1 -> vector_recv
  • type2 -> vector_send

如果 trace event args 中没有 core_type/core_id,本 skill 会尝试从 tid 推断,例如 type1_core003 -> vector_recv/core_id=3

对于其他来源的 trace,如果没有这类 core_type 约定,事件会落到 unknown 核组。后续若要支持更多硬件或 runtime,可以把 core group 规则从当前内置逻辑中抽成配置。

指标口径

  • total_us:同类事件时长直接求和,会重复累计并行 tid/core。
  • union_us:同类事件时间区间并集长度,更接近 wall time 覆盖。
  • ratio_to_total_wall = union_us / trace_wall_time
  • ratio_to_core_group_wall = union_us / 当前 core_group 的 union_us,用于判断某类耗时在该核组内部的覆盖比例。
  • ratio_to_core_group_wall 是覆盖率,不是互斥占比;不同 category/phase 可以在同一时间重叠,因此同一核组下的百分比不要求加和为 100%。
  • overlap_summary.csv 的 overlap 基于 phase 区间并集两两求交,避免逐事件重复累计。
  • bubble_summary.csv 表示外层阶段中未被已知子阶段覆盖的时间空洞。这是“未归因时间”,不一定代表硬件空闲。

输出文件

  • phase_instances.csv:每个已映射区间事件,包含 phase/category/name/core_group/core_id/timing。
  • phase_summary.csv:按 phase 聚合。
  • category_summary.csv:按 category 聚合。
  • core_group_summary.csv:按 core group 聚合。
  • phase_core_group_summary.csv:按 (core_group, phase) 聚合。
  • category_core_group_summary.csv:按 (core_group, category) 聚合。
  • name_summary.csv:按原始 trace name 聚合。
  • phase_tid_summary.csv:按 (phase, pid, tid) 聚合,用于看单线程或单核长尾。
  • overlap_summary.csv:phase 两两 overlap。
  • bubble_summary.csv:外层阶段内部 bubble。
  • summary.json:整体概览。
  • diagnosis.json:确定性自动诊断结果。
  • statistical_summary.md:确定性统计摘要,文字化说明图表和关键统计信号。
  • llm_prompt.md:交给 LLM 的完整统计上下文,总是生成。
  • llm_analysis_meta.json:LLM 调用状态、命令和错误信息,总是生成。
  • llm_analysis.md:启用 LLM 且命令成功时生成。
  • report.md:可读报告,包含 Overview、Visualizations、Statistical Highlights、Automatic Diagnosis、可选 LLM Analysis 和各类汇总表。
  • analysis_charts.png:安装 matplotlib 时默认生成。单图包含 core group wall 覆盖、非 container category 的 total_us 饼图和 top phase。完整 trace 时间线建议继续使用 Perfetto UI 查看。

诊断策略

报告优先回答:

  1. 哪些 phase 覆盖 wall time 最多。
  2. 耗时类型更偏 wait、sync、compute、epilogue、communication 还是 quant。
  3. 耗时主要落在哪些 core group 或 tid。
  4. 关键 phase 之间的 overlap 是否不足。
  5. 外层阶段内部是否存在明显未归因 bubble。
  6. top raw names 中哪些原始事件应优先回查。

当前确定性诊断仍包含一部分 UMDK FusedDeepMoe 经验规则,例如 dispatch_gmm1gmm2_combine 的 overlap 判断。分析其他 trace 时,这些规则可能只具备参考价值;通用统计表和图表仍然是主要输出。

依赖和验证

默认运行只使用 Python 标准库,不需要安装第三方包。

可选能力:

  • matplotlib:用于自动生成 analysis_charts.png
  • 外部 LLM CLI:用于 --llm-analysis,协议是 stdin 输入 prompt、stdout 输出分析文本。

基础验证:

cd <ASCEND_MOE_OPTIMIZER_SKILL>
python3 app.py --trace <TRACE_JSON> --phase-map <PHASE_MAP> --output-dir <OUTPUT_DIR> --top-n 20

当前限制

  • 默认只分析单个 trace 文件,不做多 trace 对比。
  • 当前没有显式 --profile 机制;不同 trace 来源主要通过 --phase-map 适配。
  • 未映射到 phase 的事件会被过滤,通用 fallback 统计仍有改进空间。
  • core group 规则目前仍以内置 UMDK 1C2V 约定为主,尚未完全配置化。
  • 部分自动诊断规则仍偏 FusedDeepMoe,需要继续拆分为通用规则和领域规则。
  • LLM Analysis 是可选外部命令,不内置具体模型、API key 或网络调用。
Install via CLI
npx skills add https://github.com/openJiuwen-ai/jiuwenswarm --skill ascend-moe-optimizer-trace-analyzer
Repository Details
star Stars 920
call_split Forks 180
navigation Branch main
article Path SKILL.md
More from Creator
openJiuwen-ai
openJiuwen-ai Explore all skills →