调度追踪分析：基于 Trace 工具剖析 AI 芯片瓶颈路径与 PE 利用率

关键词：AI芯片调度分析、Trace工具、性能瓶颈、PE阵列利用率、任务图追踪、指令调度、Tile调度可视化、异构算力调度、性能调优、芯片编译器分析

摘要：
在 AI 芯片落地部署过程中，模型的实际执行性能往往远低于理论值，主要受限于调度不合理、PE资源利用率低、DMA带宽瓶颈等问题。本文结合主流芯片平台的 Trace 调度追踪工具，系统讲解调度图生成、瓶颈链识别、Tile搬运流追踪、PE阵列活跃度分析等工程方法，帮助研发人员高效定位执行链路中的性能瓶颈，形成可落地的调优策略。全流程基于真实项目调试场景，聚焦可解释性、工程实效与跨平台可移植性，面向 AI 芯片部署一线工程团队提供系统支持。

PE阵列利用率低：部分算子 Tile 大小不匹配，导致 PE 空转严重。
DMA带宽瓶颈：Tile 数据搬运顺序不当，导致算子等待数据。
计算-通信重叠度低：指令调度未能有效实现流水并行。
资源冲突与上下文切换成本高：多模型或多子图并发调度时频繁抢占，任务切换无序。

这些问题大多数隐藏在底层执行链路中，传统 profiling 工具很难提供结构化、时间轴上的洞察。因此，Trace 工具应运而生，它能够可视化整个调度路径、量化资源占用情况、精确定位瓶颈源头。

1.2 Trace 工具在芯片调优中的作用

Trace 工具是一类低侵入、时间轴可视化的执行轨迹采集系统，核心价值包括：

调度路径还原：识别实际运行时图的执行顺序、计算与搬运的流水关系。
资源利用监测：监控 PE、DMA、SRAM 的利用率、空闲时间与并发状态。
调度异常追踪：精确定位调度失败、任务挂起、指令依赖未满足等问题。
性能对比分析：多次运行的 Trace 数据可量化不同调度策略下的吞吐对比。

Trace 工具不仅用于性能优化，还可与编译器输出、Runtime 日志联合分析，构建闭环的调度分析体系。

1.3 主流平台支持的 Trace 机制

平台名称	Trace 工具	特性与机制
寒武纪 MLU	`profiler_trace.json` + `CambriconTrace` 工具	细粒度 PE 调度记录，支持 Timeline 展示与 Event 区分
地平线 BPU	`HBProfiler` + `HorizonTraceViewer`	提供 AI 算子执行、DMA 调度、Buffer 占用的完整视图
华为 Ascend	`Msprof` + `MindInsight`	提供 HCCL、TBE、任务调度等多级视图，支持异构多芯片协同追踪
NVIDIA Jetson	`Nsight Systems` + `Nsight Compute`	支持 CUDA kernel 执行、TensorCore 利用率分析，兼容 PTX Trace

各平台 Trace 工具均具备一定的结构化数据格式、时间戳体系与图结构标注能力，工程中应结合模型编译路径适配使用。

第2章：Trace工具生成原理与典型数据结构

2.1 执行轨迹采集机制：中断嵌入 / Runtime Hook

Trace 工具的底层依赖硬件协助与软件插桩机制，常见采集路径：

硬件中断打点：芯片在 PE/DMA 指令投递或完成后触发中断，写入环形缓冲区（Trace Buffer）。
Runtime Hook 函数：在 Runtime 层对模型执行的关键路径插入记录函数，如 TraceStart(OpId)、TraceEnd(OpId)。
系统计时模块同步：确保所有事件统一参考系统时间戳，便于跨模块时间轴对齐。

这一机制需保证低开销，常常采用异步写入与压缩格式输出以避免干扰主执行流。

2.2 Trace 数据结构设计：Event、Timestamp、Scope、Tag

Trace 工具的原始数据可表示为时间轴上的事件序列，每一条 Trace 通常包含：

字段	含义
`EventId`	本次记录事件的唯一标识
`TimestampStart` / `End`	任务的开始与结束时刻
`OpName`	算子或数据搬运名称
`DeviceId` / `PEId`	设备与处理单元编号
`Scope`	所属任务类型（算子执行、DMA、调度器调度等）
`Tag`	用户标注的阶段标识，如“Forward”、“PostProcess”

这些数据在可视化工具中映射为 Gantt 图、热力图、时间线或流水图，便于调度路径分析。

2.3 多线程 / 多PE / 多通道 Trace 协同格式解析

在多核 / 多任务并发的芯片环境中，Trace 工具需支持多维追踪与聚合展示：

线程级 Trace：支持每个 PE 核、DMA 通道分别记录，形成 N 路 Trace Stream。
事件对齐与跨流分析：采用全局同步时钟对齐多个 Trace Stream，重建调度图。
Trace 合并机制：分析时将多流数据归一为统一调度序列，便于 Gantt 图呈现。

如华为 Ascend 的 Trace 可同时展示 AI Core、CPU、TBE、HCCL 不同模块的协同执行链，支持跨芯片并行任务的Trace组合。

第3章：任务调度图的构建与执行流还原

3.1 调度图中的基本构件：节点与边的语义

在调度追踪分析中，我们可以将整个执行流程抽象为一张有向任务图（Task Graph），其核心组成包括：

节点（Node）

计算节点：代表一个调度执行的算子 Tile，如 Conv2D_Tile_3_5。
DMA 传输节点：表示张量从外部 DRAM→SRAM，或 SRAM→PE 输入/输出的搬运行为。
同步节点：代表显式的调度屏障，例如 Barrier_Wait, PE_Sync，常用于子图间切换或流水同步。

边（Edge）

数据依赖边：如一个 Tile 的输出被另一个 Tile 的输入所依赖。
控制依赖边：例如 DMA_Load 必须先于 PE_Compute 执行，即使数据上无直接显式依赖。
时间依赖边：表示调度器在不同任务之间强制引入的执行时序，比如 Subgraph_0_End → Subgraph_1_Start。

这些边的构建需结合 Trace 的时间戳与 OpId 信息，才能准确建图。

3.2 执行流重建方法与工具流程

执行流重建目标是从碎片化的 Trace 数据中重建出完整的 Tile → DMA → PE → WriteBack 的顺序链，典型流程如下：

具体工具路径（以寒武纪为例）：

cnpy-parse：解析 .profiler_trace.json 为结构化事件流
cnpy-analyze：生成 task_dag.dot 的调度图
graphviz：渲染任务调度图
event_id_matching.py：事件 ID 级别回溯依赖链

3.3 工程案例：模型子图调度路径还原

以一个典型的图像分类模型 ResNet-18 为例：

子图划分：每一组卷积 + 激活 + 下采样划为一个子图
Trace中发现 Conv_Block_3_2 → DMA_WB_3_2 → Conv_Block_4_0 存在较大时间间隔
调度图分析发现 DMA_WB_3_2 的输出与 Conv_Block_4_0 所需数据不匹配 → 发生了 数据 Tile 重排

通过调度图重建，我们可以追踪数据搬运路径是否重叠、计算是否连续，从而定性瓶颈是否出在调度空洞、Tile排布策略，或资源冲突上。

第4章：PE利用率分析与计算空洞识别方法

4.1 PE 活跃周期统计方法

每个 PE（Processing Element）在芯片内部被用于执行 Tile 级指令。我们可以统计 PE 在调度周期内的活跃状态时间段（Busy Slot）与空闲周期（Idle Slot），方法如下：

按照 Trace 中 Scope == PE 的事件进行时间段聚合
对每个 PE 编号做 busy_time = ∑(end_time - start_time)
计算 PE 利用率：
Utilization = busy_time / total_window_duration

例如，一个 PE 在 200ms 的执行窗口中累计工作了 120ms，则其利用率为 60%。

4.2 调度密度图与空间分布可视化

结合 PE 坐标和时间戳，可以生成类似以下的二维热力图：

Y轴：PE 编号（或阵列位置）
X轴：时间轴（ms）
颜色：活跃程度（热度）

时间(ms)	PE0	PE1	PE2	PE3
0~50	█		█
50~100	█	█		█
100~150			█	█
150~200	█	█

通过分析颜色分布，我们能识别：

哪些 Tile 排布导致 PE 长时间空闲
哪些 PE 被重复使用，负载集中
哪些时间片没有发生有效并行

4.3 实战问题：卷积类 Tile 分布不均分析

实际部署中，某项目使用了 Winograd 优化后的卷积，Trace 分析发现：

前 16 个 PE 使用率为 95%
后 48 个 PE 使用率不到 40%
Tile 编排中存在显著负载倾斜

进一步调度图分析发现：

调度策略为“深度优先分配”
某些 Channel 数无法均匀切割
Tile 与 PE 编号未对齐，导致 DMA 分发瓶颈

优化建议：

修改编译器策略为“宽度优先 + LoadBalance Shuffle”
Tile 编号按 PE mapping 优化以减少 DMA 分支路径
引入 Task-Level Round Robin 调度规则

第5章：DMA搬运瓶颈追踪与带宽利用评估

5.1 Tile 加载调度表的结构与解析路径

在 AI 芯片的调度系统中，每一个计算任务对应一个或多个 Tile 的加载、处理与回写流程。DMA（Direct Memory Access）负责将外部存储的数据搬运到片内 SRAM 或 PE 阵列中，是连接算子与数据路径的关键桥梁。

调度系统通常维护一张 Tile→DMA 映射表，包含字段如下：

字段	说明
Tile_ID	当前搬运的张量片块标识
Start_Addr	DRAM 中 Tile 的起始地址
End_Addr	DRAM 中 Tile 的终止地址
SRAM_Addr	SRAM 中的目标存储位置
Start_Cycle	搬运计划开始时间
DMA_Channel	分配的 DMA 通道编号
Dependency	当前搬运任务的控制依赖

在 Trace 分析中，可基于此调度表比对 Trace 中的搬运行为，找出搬运计划与实际执行的错位点。

5.2 Trace中识别搬运冲突与执行顺序异常

以下是从 Trace 中识别瓶颈的典型模式：

顺序异常：Trace 中 DMA_Load_4 早于 DMA_Load_3 结束，违反原始调度顺序，可能是调度器未处理好 Tile 分配顺序或出现抢占行为。
带宽冲突：多个 DMA Channel 在相邻周期内搬运超大张量，导致总带宽饱和或 SRAM 写入拥塞。
搬运阻塞：DMA 搬运任务被挂起超过 N ms，可能是目标 SRAM 被占用或 PE 阵列未释放上一次计算结果。

Trace 示例（伪数据）：

[1020ms] DMA_CH0 Start Tile_12
[1021ms] DMA_CH1 Start Tile_13
[1022ms] DMA_CH0 Wait (SRAM full)
[1024ms] DMA_CH1 Done Tile_13
[1025ms] DMA_CH0 Resume Tile_12

通过上述分析，可以推断出：

SRAM 争抢导致搬运冲突
调度顺序未优化 → 应避免同时调度大 Tile 到多个通道

5.3 多 DMA 通道下的路径冲突与避障调度

若芯片拥有多个 DMA 控制器（如双通道 DMA 或 Tile 维度多路加载），合理的路径选择至关重要：

典型问题场景	对应调度问题
两个大 Tile 分配给同一 DMA Channel	通道饱和，DMA 串行瓶颈
SRAM 地址映射冲突	同一区域被多个 Tile 写入
多核 PE 使用相同 SRAM Buffer	Tile 结果搬运/加载互斥

调度器中可引入以下避障策略：

通道级负载感知调度：动态查看每个 DMA 通道剩余队列长度，避免长队列通道继续分配大 Tile。
Tile 地址随机化映射：减少 SRAM 地址重叠率，尤其在 Batch 模式下进行 Tile 间隔映射。
预调度窗机制（Lookahead Window）：为未来 N 个 Tile 创建调度预测，并模拟 SRAM 写入拥塞风险，提前调整搬运顺序。

第6章：计算-搬运重叠优化与调度器改进建议

6.1 Trace辅助下的流水重叠度分析

AI 芯片的运行效率依赖于计算（PE）与数据搬运（DMA）的高效配合。有效的流水线应满足：

DMA_Load(Tile_n) → PE_Compute(Tile_n) → DMA_WriteBack(Tile_n)
            ↘                             ↗
           DMA_Load(Tile_n+1)           DMA_WriteBack(Tile_n+1)

Trace 分析中，我们可提取以下指标：

DMA→PE 启动间隔（Load-to-Compute Latency）
Compute→WB 间隔（Compute-to-Write Latency）
PE-Active vs DMA-Active 的时间重叠百分比

重叠度计算公式：

Overlap_Ratio = (Total_Overlap_Time between DMA and PE) / Total_Execution_Window

典型芯片优化目标为 60~80%。

6.2 双 Buffer 使用效率分析

双缓冲设计（Double Buffering）是常见的流水优化手段，其原理为：

Buffer_A 被 PE 读取时，Buffer_B 被 DMA 写入下一 Tile
完成后两者切换，实现计算与搬运并行

Trace 中识别双缓冲是否生效的典型模式：

如果 DMA Load 和 PE Compute 经常交替但不重叠 → Buffer 被阻塞或调度失效
若 DMA_Load_A 与 PE_Compute_B 无交叉 → 实际只使用了单 Buffer

改进措施：

在调度表中插入 Buffer 状态字段
调度器中添加 Buffer 空转检测逻辑，避免提前切换失败

6.3 调度器调优策略建议

参数	优化方向	说明
Tile 大小	动态调整 Tile 的维度划分	过小 → 调度频繁，DMA 调用多；过大 → 缓冲溢出
Tile 优先级	加入计算密集/通信密集标记	优先执行 DMA 轻负载 Tile，提高并发率
预取窗口	扩大 Lookahead Scope	提前启动搬运任务，减少搬运等待周期
调度策略选择	从贪婪→负载均衡/分布式路径	防止 DMA 冲突、带宽爆发

第7章：真实项目案例解析：Trace调试路径与性能演化

7.1 项目背景：YOLOv5 部署至边缘 NPU 平台

该项目源于一家物流分拣设备制造商，需求为在边缘端（无GPU）实时运行 YOLOv5 实现动态货物检测。选用的芯片平台为一颗国产 8TOPS NPU，支持 INT8 推理、具备多路 DMA、双PE阵列、Trace 调度分析模块。

初始模型为 PyTorch 版 YOLOv5s，转 ONNX 后通过芯片厂商提供的编译器转为 IR 格式并部署。

7.2 初次部署 Trace 分析结果：调度瓶颈显现

通过导出的 Trace 日志文件（JSON + 二进制 Timeline），我们发现如下典型问题：

指标项	表现情况
PE 利用率	47.3%，部分阶段出现空闲周期堆叠
DMA 带宽利用率	平均 28%，存在大量搬运间隔
Tile 调度间隙	最大达 32 cycles，流水断层严重
Token 分布密度图	中间层激活 Tile 大小过于离散

调度链条示意（部分）：

[Load Tile_13] --> idle (20 cycles) --> [Compute Tile_13]
[Load Tile_14] --> PE wait (15 cycles) --> [Compute Tile_14]

根因分析：

IR 图未启用双缓冲策略 → PE 等待搬运完成
Tile 粒度未按 Anchor 层聚合 → 计算浪费
默认调度器采用深度优先调度 → 串行化明显

7.3 调度策略调整与性能对比

基于上述 Trace 分析结果，我们优化了以下策略：

优化项	原始策略	新策略
Tile 映射	均分通道	Anchor 区域优先划分
调度顺序	静态排序	Lookahead 预调度 + 优先级排序
Buffer 管理	单 Buffer	PE 启用双 Buffer 循环结构
DMA 通道复用策略	固定绑定	动态复用 + 冲突规避

优化前后指标对比：

指标项	优化前	优化后
PE 利用率	47.3%	82.6%
平均推理延迟	143ms	84ms
系统功耗	4.7W	3.9W
FPS（640×480）	6.9 FPS	11.3 FPS

7.4 Trace工具在问题复现与版本回归中的作用

在后续的多版本编译器/调度器升级过程中，Trace 成为验证性能回退/异常定位的重要手段：

版本回退定位：在某次升级后 FPS 降为 9.2，Trace 快速定位出 PE0 执行任务异常中断，源于调度表生成逻辑错位。
资源复用失效排查：一次切换至多模型调度框架后，Trace 显示 DMA0 被多个模型 Tile 同时分配，发生 SRAM 写入冲突。
模型迭代对比：YOLOv5n vs v5s 的 PE 利用率对比 → 推动模型结构微调方向。

结论：Trace 工具不仅是调试利器，更是性能演进与优化闭环中的关键支撑。

第8章：工程总结与调度追踪机制未来演进方向

8.1 Trace 工具的标准化与 Runtime 深度集成

目前多数芯片厂商提供 Trace 接口为非标准格式，建议未来形成如下机制：

统一 Trace 格式（如 JSON+protobuf），支持跨平台比较
与 Runtime 深度绑定，支持 trace_start() / trace_dump() API 接口
提供跨平台 Trace Viewer 工具，如 Timeline + Op Heatmap

8.2 构建可视化调度分析平台

当前调度路径分析多依赖文本 + 波形日志，建议构建可视化平台：

图形化展示算子调度图与 PE/DMA 时间线
提供热点识别（Tile 冲突、搬运拥堵、指令稀疏）
支持多版本 Trace 差异分析，输出变化项报告

开源工具推荐：

Chrome Trace Viewer (部分支持)
Custom Dashboard（建议基于 Streamlit + D3.js）

8.3 向自动调度优化的演进：Trace × AutoTuner × CostModel

Trace 的最终价值是与 自动调度器/编译器优化器融合：

模块	作用
Trace	收集真实运行信息（Tile拥塞、PE冲突）
Cost Model	构建调度成本函数：延迟、能耗、重叠度
AutoTuner	基于Trace反馈调整Tile划分、调度顺序等参数

未来推荐流程：

IR Graph → Trace Simulate → Trace Feedback → Cost Evaluation → Scheduler Refinement → IR Update

这将实现真正闭环的 AI 芯片调度优化体系，从“人工经验调度”迈向“自动感知调优”。

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注人工智能领域。
个人主页：观熵
个人邮箱：privatexxxx@163.com
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
具身智能：具身智能
国产 NPU × Android 推理优化：本专栏系统解析 Android 平台国产 AI 芯片实战路径，涵盖 NPU×NNAPI 接入、异构调度、模型缓存、推理精度、动态加载与多模型并发等关键技术，聚焦工程可落地的推理优化策略，适用于边缘 AI 开发者与系统架构师。
DeepSeek国内各行业私有化部署系列：国产大模型私有化部署解决方案
智能终端Ai探索与创新实践：深入探索智能终端系统的硬件生态和前沿 AI 能力的深度融合！本专栏聚焦 Transformer、大模型、多模态等最新 AI 技术在智能终端的应用，结合丰富的实战案例和性能优化策略，助力智能终端开发者掌握国产旗舰 AI 引擎的核心技术，解锁创新应用场景。
企业级 SaaS 架构与工程实战全流程：系统性掌握从零构建、架构演进、业务模型、部署运维、安全治理到产品商业化的全流程实战能力
GitHub开源项目实战：分享GitHub上优秀开源项目，探讨实战应用与优化策略。
大模型高阶优化技术专题
AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理的完整全流程
Agentic AI架构实战全流程：一站式掌握 Agentic AI 架构构建核心路径：从协议到调度，从推理到执行，完整复刻企业级多智能体系统落地方案！
云原生应用托管与大模型融合实战指南
智能数据挖掘工程实践
Kubernetes × AI工程实战
TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统
大模型运营专家的Prompt修炼之路：本专栏聚焦开发 / 测试人员的实际转型路径，基于 OpenAI、DeepSeek、抖音等真实资料，拆解从入门到专业落地的关键主题，涵盖 Prompt 编写范式、结构输出控制、模型行为评估、系统接入与 DevOps 管理。每一篇都不讲概念空话，只做实战经验沉淀，让你一步步成为真正的模型运营专家。