多流 overlap 时间线复盘【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills本页回答一个问题副流上的算子是不是真的和主流并行执行了这是判断多流方案在物理执行层面是否成立的唯一证据。背景为什么Stream ID 切对了不等于并行成立torchair.scope.npu_stream_switch给副流贴的是逻辑标签。GE 图模式编译期还会做几件事算子提前 / 延后下发基于数据依赖图的拓扑序而不是源码顺序。被动拉取副流上某个 tensor 被主流消费时GE 可能把消费前必须做的小预计算如Cast/Swish/Sigmoid自动 pin 到消费侧的流。流内 FIFO 排队同一 stream id 上的 op 严格按下发顺序串行执行。最常见的错位副流的输出T有一个轻量级 precomputef(T)例如silu(T) Swish(Cast(T))下游消费者在主流。GE 把f(T)拉到主流提前下发而主流被它占住、必须等副流的T就绪才能继续。结果是副流跑的时候主流 idle副流跑完后主流再串行做f(T)和原本想跑的 dominator。这种假并行在只看 Stream ID 的报告里看不出来必须看Start Time。何时必须做时间线复盘下面任意一种情况都必须算overlap_pct不能跳过切流改造后候选模块 wall 与改造前持平或仅微变 5%但 Stream ID 已经按设计切到副流。候选模块的并行度kernel_sum / wall≤ 1.05×。准备判某个方案无效之前——必须先排除假并行再下结论否则改进方向会判错。准备判某个方案成立之前——确认收益不是噪声、并行点确实在物理上落地了。输入从 profiling 的kernel_details.csv或等价的 per-op 明细取每个 op 的Stream ID/Start Time(us)/Duration(us)并按方案设计区分哪些 op 应该在副流、哪些是主流上被掩盖的 dominator。字段查法见kernel-fields-lookup.md。5 步重建甘特图Step 1选窗口按方案描述选两个 op 区间副流时间窗 方案切到副流的那段 ops。主流期望被掩盖的 dominator 时间窗 方案假设这段时间副流能躲在它背后跑的主流 op通常是方案里主路径 dominator那一项常见为 conv1d / matmul / FA。两个区间都要拿到每个 op 的Start Time(us)和Start Time(us) Duration(us)。Step 2取每个 op 的(Stream ID, Start Time, Duration)只下钻这几个字段的必要几条 op不要把整份明细灌进上下文。字段集和命令见kernel-fields-lookup.md的 post-mortem 字段集。Step 3算两组区间side_window [min(side_op.start), max(side_op.start side_op.duration)] main_window [main_dominator.start, main_dominator.start main_dominator.duration] overlap max(0, min(side_window.end, main_window.end) - max(side_window.start, main_window.start)) side_len side_window.end - side_window.start main_len main_window.end - main_window.start overlap_pct overlap / min(side_len, main_len)Step 4判定真并行overlap_pct ≥ 0.5至少 50% 的副流时间能藏在主流 dominator 后面。部分并行0.05 overlap_pct 0.5主副流有重叠但 dominator 没把副流完全吃下通常说明 op 集合划分要再调让副流更长 / 让 dominator 更长 / 换 dominator。假并行serialoverlap_pct ≤ 0.05Stream ID 切对了但物理串行——主流大概率被某个 GE 拉过来的 precompute 卡住。Step 5找 barrier op仅在判定为假并行时把主流 stream id 上的 op 按Start Time(us)排序。找到主流上第一个输入来自副流的 op X多半是Cast/Reshape/ 小算子。检查 X 在主流 FIFO 顺序里是否排在主流 dominator 之前。如果是X 就是 barrier主流 dominator 必须等 X 开始才能跑而 X 必须等副流输出就绪。解法派生一个新的编排候选把这个 op显式钉到副流——在with npu_stream_switch(...)块内显式写出f(T)的计算而不是依赖 GE 自动放置。设计期怎么提前预判见ge-reorder-design-check.md。怎么记录结论只记关键摘要不贴整张 op 表。例side_window [1615.25, 1634.75] us、main_dominator window [1638.00, 1660.75] usin_proj_qkv overlap0us / overlap_pct0%判为假并行barrier ops 55-56 (CastSwish, silu(z))被 GE 拉到主流 下一候选把 silu(z) 显式预计算钉在 with-block 内。该做、不该做✅ overlap 复盘是判断方案成败的核心证据必须自己做不能因为Stream ID 已切到副流就直接判通过。✅ 判通过和判淘汰前都要算overlap_pct并把结论连同 barrier如有记下来。❌ 不要把整份 per-op 明细贴进对话只下钻必要的几条 op。❌ 不要把host overhead 吃掉收益当默认解释先证明 overlap 真实成立。关键约束Start Time(us)在不同采集之间不可比基准时间不同overlap_pct只能在同一次采集内计算。Duration(us)在不同采集之间通常稳定除非 shape 变化。跨采集对比 wall / 并行度要用性能分析报告同口径指标对比物理布局用源码 方案差异而不是直接比时间戳。【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考