PyPTO泳道图实战：如何用可视化工具找到算子性能瓶颈-平芜编程栈

PyPTO泳道图实战：如何用可视化工具找到算子性能瓶颈

【免费下载链接】pyptoPyPTO（发音: pai p-t-o）：Parallel Tensor/Tile Operation编程范式。项目地址: https://gitcode.com/cann/pypto

PyPTO（Parallel Tensor/Tile Operation）是面向 NPU 算子的编程范式，而泳道图正是它性能调优中最趁手的一把“照妖镜”：把算子计算图的真实调度与执行过程画成每个核一条泳道的色条图，任务执行顺序、耗时分布和空闲空隙一目了然，无需深入了解硬件细节即可快速定位算子性能瓶颈。本文带你完整走一遍泳道图实战流程：采集 → 查看 → 找瓶颈 → 调参优化。

🧭 什么是泳道图？

泳道图是一种时序可视化图，把“每个核”映射成一条横向泳道：

每条横向泳道对应一个 AI Core（Cube 核 AIC / Vector 核 AIV）；
泳道内的色块代表一个被调度的任务，色块长度直接对应任务耗时；
泳道之间的黑色间隔（俗称“气泡”）是空闲期，往往就是性能瓶颈的信号。

相关术语可参考官方名词解释。

📸 三步采集泳道图数据

当前支持两种并列的采集方式，可单独开启，也可同时开启：

方式一：图执行阶段采集（新手推荐）

在@pypto.frontend.jit装饰器入参中配置调试开关，即可启动性能数据采集：

@pypto.frontend.jit( debug_options={"runtime_debug_mode": 1} )

然后执行用例：

python3 examples/02_intermediate/operators/softmax/softmax.py

采集结果输出到当前工作目录output/output_<时间戳>下，核心文件为merged_swimlane.json。

方式二：AI CPU/AI Core 联合采集

如果怀疑首任务启动慢、调度等待等问题，可通过环境变量开启：

export DUMP_DEVICE_PERF=true

执行完用例、数据落盘后，运行 analyze 命令查看 AI CPU/AI Core 数据汇总表：

python tools/scripts/machine_perf_trace.py analyze output/output_<时间戳>/machine_trace_perf_data_0.json

输出目录关键文件速查

文件	用途
`merged_swimlane.json`	IDE 可视化综合泳道图
`machine_runtime_operator_trace*.json`	AI CPU / AI Core 泳道图（联合时序）
`machine_trace_perf_data*.json`	Machine 组件原始 Profiling 数据
`tilefwk_L1_prof_data_*.json`	Machine 组件 L1 层级 Profiling 数据

👀 两种打开泳道图的方式

方式一：PyPTO Toolkit 插件打开（推荐）

在 IDE 中右键单击 JSON 文件，选择**“使用PyPTO Toolkit打开”**，即可看到泳道图界面：

带色块的部分就是泳道，观察任务耗时分布和空闲空隙（气泡），就能分析出可能的性能瓶颈。

方式二：终端查看 AI Core 关键指标

想快速掌握AI Core 端到端耗时和AI Core 利用率，直接查看终端输出的 Perf 信息即可：

开启联合采集后，还能在同一时间轴上观察 AI CPU 调度与 AI Core 执行的协同关系：

💡 也可以直接用脚本 tools/profiling/draw_swim_lane.py 从 Profiling 数据生成泳道图，或用批处理工具 tools/gen_swimlane.sh 一次处理多个输出目录。

🔍 从泳道图找性能瓶颈：4 个典型信号

打开泳道图后，重点盯以下 4 类“异常形态”：

信号 1：泳道空隙多 → Stitch 配置偏小

stitch_function_max_num决定一次能同时调度多少个 root function。配置过小时，每个任务都要同步，调度开销大，泳道图上空隙密布。官方案例中该值为 1 时端到端耗时 1590us，增大到 128 后泳道明显紧凑、耗时降到 803us：

信号 2：子图间出现 GM 搬运 → 归约轴被切分

sum/max 等 reduce 运算尽量不要沿归约轴切分，否则多个子图的输出还要进另一个子图做归约，产生额外全局内存搬运和调度开销：

信号 3：并行核数少 → TileShape 偏大

某段泳道只用到不到一半的核，说明任务切得太粗，可尝试减小该处 Operation 的 TileShape。

信号 4：调度开销占比高 → 子图过小

子图耗时很短但调度开销占比高，说明切分过碎，可尝试增大 TileShape，或使用广度方向合图接口合并同构子图。

🛠️ 瓶颈定位后的调优抓手

识别出瓶颈后，结合以下手段迭代优化（Man-In-The-Loop 闭环：采集 → 观察 → 调参 → 复验）：

Stitch 调优：内存允许前提下逐步增大stitch_function_max_num，在并行收益与调度开销间找平衡；
TileShape 调优：Matmul 可从[128,128],[64,256],[256,256]等推荐组合起步，Vector 运算用set_vec_tile_shapes配置；
合图调优：深度方向与广度方向合图，减少子图调度开销；
调度策略调优：上下游依赖简单、L2 命中率重要时，可尝试 L2 亲和调度（device_sched_mode=1）。

若泳道图数据采集或展示异常（未生成文件、文件为空等），直接查阅故障排查指南：📖 docs/zh/tutorials/appendix/faq/swimlane-issue.md