CANN 多流推理调试指南：kernel_details.csv 字段查法与物理并行验证

CANN 多流推理调试指南kernel_details.csv 字段查法与物理并行验证【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer多流multi-stream优化是 CANN 上 LLM 推理提速的关键手段但Stream ID 切对了并不等于物理并行成立。本指南以kernel_details.csv的字段查法为主线讲解如何用 profiling 明细精准定位跨流候选、验证 overlap 真伪、诊断 cube/vector 长尾与主副流争核并给出可直接运行的 pandas 取数方法与仓库内真实多流实现佐证。读完你将掌握一套设计期取数 → 落地后复盘 → 分诊问题的完整调试方法论。为什么必须从 kernel_details.csv 精准取数多流分析和调试的所有结论都建立在 profiling 数据之上。torchair.scope.npu_stream_switch给副流贴的只是逻辑标签GE 图模式编译期仍会基于数据依赖拓扑重排算子可能把 block 内的小算子Cast/Reshape/Swish/Sigmoid等挪到主流也可能把 block 外被副流输出间接依赖的轻量预计算典型如silu(z) Swish(Cast(z))拉到主流提前下发。因此源码层级 ≠ 物理层级任何副流已落到 side stream的结论都不能直接当作方案成立必须回到kernel_details.csv用Stream IDStart Time(us)Duration(us)验证物理布局。完整规则见技能主文档 SKILL.md。多流技能包model-infer-multi-stream把这项工作沉淀为两条纪律只取必要的几条 op、几个字段不把整份kernel_details.csv或 per-op 明细灌进上下文先print(df.columns)确认列名不要猜列名。什么时候需要下探到算子明细确认某个算子的具体细节时才从 profiling 明细下钻典型触发场景包括校验Stream ID/Task ID是否符合方案设计排查 shape 是否引入额外TransData/BroadcastTo/MemSet判断Block Dim/Mix Block Dim是否导致主副流争核检查aic_*_ratio/aiv_*_ratio是否显示 cube / vector 长尾定位等待或拖尾是否来自某个具体算子。注意不要一上来就抓某个局部热点函数。多流分析遵循先整网后局部的原则——先回答整网主路径和模块间并行性再进入模块内算子下钻算子明细属于第二层之后的工作。两套字段集设计期 vs 落地复盘跨流候选的设计和落地复盘必须使用不同字段集不能混用。仅看设计字段集会漏掉Start Time(us)从而无法判断 overlap 是真是假——两段时间线的Start Time(us)重叠程度才是 overlap 是否成立的唯一证据。排查目标推荐字段跨流候选设计dim 阈值、Stream 配对、填 resource_hintStream ID, Task ID, Name, Input Shapes, Output Shapes, Duration(us), Wait Time(us)跨流候选post-mortem验证 overlap 是否真成立必查Stream ID, Name, Start Time(us), Duration(us), Wait Time(us), Input Shapes—— 用Start Time(us)Duration(us)重建甘特图按 timeline-overlap-check.md 算overlap_pct多流后 cube 是否打满Name, Duration(us), aicore_time(us), aic_mac_ratio, aic_mte2_ratio, cube_utilization(%)Vector 长尾 / 搬运瓶颈Name, Duration(us), aiv_time(us), aiv_vec_ratio, aiv_mte2_ratio, aiv_mte3_ratio控核场景下 Block DimName, Duration(us), Block Dim, Mix Block Dim, Accelerator Core其中aic_mac_ratioMAC 单元利用率、aic_mte2_ratiocube 侧搬运单元 MTE2 利用率反映 cube 侧是否打满aiv_vec_ratio、aiv_mte2_ratio、aiv_mte3_ratio反映 vector 侧计算与两级搬运的占用情况。设计期字段集主要用于判断dim 阈值怎么定、Stream 怎么配对、resource_hint 填什么post-mortem 字段集则专门回答切流后到底有没有并行。怎么取数pandas 按行按列精准读取直接从kernel_details.csv读需要的几行几列即可。例如用 pandasimport pandas as pd df pd.read_csv(kernel_details.csv) print(list(df.columns)) # 先看有哪些列避免猜列名 cols [Stream ID, Name, Start Time(us), Duration(us)] print(df.loc[df[Name].str.contains(xxx, naFalse), cols]) # 按算子名/索引取需要的几行 print(df.iloc[row_index_list][cols]) # 或按行号取关键约束只取必要的几条 op、几个字段别把整张表灌进上下文先print(df.columns)确认列名不要猜overlap 只能在同一次采集内用Start Time(us)计算不同采集的Start Time(us)基准不同、不可比。Duration(us)在不同采集之间通常稳定除非 shape 变化跨采集对比 wall / 并行度应使用性能分析报告同口径指标对比物理布局则用源码 方案差异而不是直接比时间戳。用 Start Time Duration 重建甘特图判定真/假并行拿到 post-mortem 字段集后按 timeline-overlap-check.md 的 5 步重建甘特图选窗口副流时间窗 方案切到副流的那段 ops主流 dominator 时间窗 方案假设副流能躲在它背后跑的主流 op常见为 conv1d / matmul / FA取字段只下钻每个 op 的(Stream ID, Start Time, Duration)算两组区间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)判定真并行overlap_pct ≥ 0.5至少 50% 的副流时间藏在主流 dominator 后面部分并行0.05 overlap_pct 0.5说明 op 集合划分要再调让副流更长 / 让 dominator 更长 / 换 dominator假并行serialoverlap_pct ≤ 0.05Stream ID 切对了但物理串行——主流大概率被某个 GE 拉过来的 precompute 卡住。找 barrier op仅假并行时把主流上的 op 按Start Time(us)排序找到主流上第一个输入来自副流的 op X多半是Cast/Reshape/ 小算子检查 X 是否排在主流 dominator 之前若是X 就是 barrier。解法是派生新编排候选在with npu_stream_switch(...)块内显式写出f(T)的预计算而不是依赖 GE 自动放置。结论记录只需关键摘要不贴整张 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 内。设计期就预判 GE auto-reorder 风险假并行的根因——GE 把消费副流输出的轻量 precompute 拉到主流形成 barrier——在设计阶段就能预判不必等到测出来才发现。按 ge-reorder-design-check.md 的清单逐条过不允许留空副流的输出有哪些下游消费者在主流列出tensor 名 → 消费者这些消费者里有没有 cheap precomputeCast/Reshape/Swish/Sigmoid/Mul例如silu(z) Swish(Cast(z))GE 会把这些 precompute 提前下发到哪条流设计期先推断落地后用Stream IDStart Time验证这些 precompute 会不会排在主流 FIFO 顺序的 dominator 之前形成 barrier应对是否在副流with npu_stream_switch(...)块内显式预计算这些 op把它们 pin 在副流上如果第 2、4 条命中而第 5 条没处理这个候选大概率落成假并行。注意本清单只适用于 Ascend IR / GE 图模式npu_stream_switch路径npugraph_ex / aclgraph 是显式 stream没有 GE 自动重排但要关注跨流 tensor 生命周期record_stream。判争核用 Block Dim 加和不要用算子类型二元推断判断主 / 副流是否争 cube 时用kernel_details.csv的Block Dim加和 vs 设备核数ai_core_cnt不要用算子类型是 MatMul / Vector二元推断——MatMul 也可能blk1只占很少核。控核场景下还需满足两条副流算子Block Dim不超过配置值主 / 副Block Dim加和不超过设备核数。若出现主 / 副流 cube 利用率叠加高于单流但 wall 没降属于资源争抢应换资源对偶性更好的集合划分——让一边偏 cube、一边偏 vector / memory。Block Dim/Mix Block Dim字段在 Ascend PyTorch Profiler 结果的kernel_details.csv中可直接确认核使用情况Mix Block Dim对应混合 cube/vector 算子。仓库实战多流 控核场景下的字段验证闭环本仓库多个模型已落地多流实现可作为取数验证的对照样本MoE 共享专家双流代表实现见 modeling_deepseek.py、modeling_glm.py把共享专家放到副流与 gating、dispatch、路由专家计算重叠decode阶段 shape 稳定、收益稳定落下来。案例细节见 moe-shared-expert-dual-stream.md。最小切流形态if self.n_shared_experts 0: enable_multi_streams self.enable_multi_streams and not is_prefill with npu_stream_switch(enable_multi_streams, 11): hidden_states_share self.shared_experts( hidden_states.view(-1, hidden_states.shape[-1]) )Indexer / Prolog 多流indexer.py把 Q 路径与权重投影路径拆到不同流通过record_stream/record_event/wait_event/wait_tensor显式表达跨流依赖。从 indexer.py 的源码结构可以看到完整的切流 → 记录 event → 等待 → 汇合模式这类实现正是验证Stream ID落点与overlap_pct的最佳素材。多流 控核联动代表实现见 modeling_longcat_flash.pyAttention 路径与 MoE 路径拆流后再用limit_core_num(True, aic_num1, aiv_num1)分核让两流时长更接近。案例细节见 longcat-flash-multi-stream-limit-core.md。该场景下必须用Block Dim/Mix Block Dim字段确认两条流各自的核占用未超配置。这些案例共同印证了一个调试流程改造一处 → profiling 取数 → 看物理布局 → 再改下一处或回滚关注算子 / 模块是否真落在目标流上、cube / vector 的利用率与占核情况而不是只看 wall time 变化。多流性能问题的五类分诊拿到kernel_details.csv字段后按 SKILL.md 的五类问题分开排查不要混在一起依赖 / 同步错误查事件记录、等待顺序、跨流汇合点、共享状态写入次序典型现象是读到未完成结果、死等、结果偶发错误精度 / 功能异常先对比优化前基线再按prefill/decode → 模块 → 算子缩小范围性能无收益——必须按 3a → 3b → 3c 顺序排查不允许跳过3a 副流根本没真跑现象是副流 ops 的stream_id仍落在主流、或全退到sid13b 副流跑了但和主流串行假并行现象是 Stream ID 已分裂但候选模块 wall 与 baseline 持平、并行度 ≤ 1.05×。必须重建甘特图算overlap_pct≤ 0.05 即判假并行3c 真重叠overlap_pct ≥ 0.5但 wall 不变仅在 3a/3b 排除后才走这步看 shape 变化、task 数增加、host bound、带宽争抢、流间资源抢占、拖尾跨流 tensor 维度偏大时先查TransData/BroadcastTo/MemSet是否长尾图模式 / runtime 限制graph break、图模式 API 约束、stream 语义差异、运行时不支持aclgraph 生命周期错误短生命周期 tensor 是否跨流继续使用、是否遗漏record_stream()。常见现象对应的技术方向现象技术方向改造点之外的 TransData / BroadcastTo / MemSet wall 显著上升或单算子 max duration 5x可能触发 GE 全局重排或算子上提缩小副流、换集合划分或先做算子合并让分流单元更独立副流已落 side stream但 layer wall 几乎不变先算overlap_pct≤5% 是假并行把 GE 拉过来的 precompute 显式钉进 with-block0.05~0.5 是部分并行调 op 集合让副流更长 / 换 dominator≥0.5 才走资源争抢 / shape / host 假设主流出现新空洞 / 拖尾副流已提前结束同步点编排不对调整汇合点或让副流接力到下游非 dominator 算子主 / 副流 cube 利用率叠加高于单流但 wall 没降资源争抢换资源对偶性更好的集合划分让一边偏 cube、一边偏 vector / memory多流后某个原本未关注的 Cast / Reshape / DynamicQuant 位置变化隐含 data 依赖或新瓶颈被暴露把该算子显式纳入候选集重做集合划分选定方案前必须完成 Profile 双重验证Stream ID 落点检查副流算子确实落到目标 stream、没被 GE 挪回主流与overlap_pct 时间线验证方案成立要 ≥ 0.5方案无效要区分是 ≤ 0.05 的假并行还是 ≥ 0.5 的真并行但 wall 没降两者改进方向完全不同。Profile 至少跑 5 次丢掉前 2-3 次 cold-start 取中位数。关键约束速查不要把整份kernel_details.csv或 per-op 明细灌进上下文只取需要的几行几列先print(df.columns)确认列名不要猜判主 / 副是否争 cube 用Block Dim加和 vs 设备核数不要用算子类型二元推断overlap 只能在同一次采集内用Start Time(us)计算不同采集的Start Time(us)基准不同、不可比overlap 复盘是判断方案成败的核心证据必须自己做不能因为Stream ID 已切到副流就直接判通过判通过和判淘汰前都要算overlap_pct并把结论连同 barrier如有记下来不要把host overhead 吃掉收益当默认解释先证明 overlap 真实成立。延伸阅读多流技能总纲分析、实现、调试与验证完整规则SKILL.mdoverlap 时间线复盘完整算法与记录模板timeline-overlap-check.mdGE auto-reorder 设计期风险清单ge-reorder-design-check.md多流 / 控核 API 路由Ascend IR / npugraph_ex 两套路径api-routing.md多流案例库与快速选型表examples/README.md【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考