资讯详情

整网模块拆解与候选编排派生:CANN NPU 多流优化分析阶段实战指南

📅 2026/9/18 2:24:00 | 华诺云谱 👁 阅读
整网模块拆解与候选编排派生:CANN NPU 多流优化分析阶段实战指南
整网模块拆解与候选编排派生CANN NPU 多流优化分析阶段实战指南【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer本文是 CANN 多流Multi-Stream优化方法论中「分析阶段」的技术指南核心解决一个问题如何把一个大模型推理网络拆成可判并行的模块与算子并为每个并行点派生多种多流编排候选。文章以 CANN 项目中的多流技术知识技能.agents/skills/model-infer-multi-stream为骨架结合仓库内 GLM-5、DeepSeek-V3.2-Exp 等模型的多流实现源码完整讲解模块拆解规则、模块/算子 DAG 建模、并行性三态判定、resource_hint资源标注、候选编排派生维度以及方向级分析产物的落盘模板。读完你可以独立完成一个模型的多流可行性分析并产出可被编排层直接消费的分析报告。一、整体框架两个拆解层级 一个派生阶段多流分析见 SKILL.md的完整主线固定为三步整网模块拆解先把整网拆成模块画单层模块 DAG判断模块与模块之间的候选并行关系算子级拆解再把每个候选模块拆成算子画模块内算子 DAG判断模块内的候选并行关系候选编排派生基于两层 DAG 和资源标签为每个并行点派生候选编排方案。也就是说分析在垂直方向上分两个层级模块级、算子级在水平方向上有一个派生阶段从并行点 → 候选编排。核心原则是先整网后局部先回答整网主路径和模块间并行性再进入模块内算子不要一上来就抓某个局部热点函数同时decoder layer 不能当作单个模块必须再往下拆一层。需要强调的边界是本文只讲技术规则——怎么拆、怎么判、怎么派生、怎么记账成文。产出如何进入 Dashboard / round / 状态机推进由调用方上层优化编排流程负责本技能不承担 Plan / round 编排职责。二、整网模块拆解规则1. 从一层完整 decoder layer 的执行路径出发第一步必须从整网 decoder layer 的执行路径出发而不是直接抓某个局部热点函数。动拆之前先看清三件事整网主路径从哪开始、到哪结束当前分析的是prefill还是decode阶段两者 shape 稳定性、并行收益完全不同整网里有哪些模块。2. 模块定义四条硬性条件一个节点要成为「模块」必须同时满足条件说明语义完整例如Attention Main Path、Router Path、Shared Expert、Dispatch、Expert Compute、Combine、KVCache Offload是一个可以独立命名、独立理解的功能单元输入输出明确能说清它的输入、输出以及是否写共享状态可独立讨论调度能单独判断「是否可能和别的模块并行」尺度合适不能只是局部 reshape / cast / view 或某个融合算子内部的小步骤也不能是整个 Decoder Layer——Decoder Layer 至少要再往下拆一层3. 优先沿五类边界拆拆模块不是凭感觉切函数而是优先沿着以下五类天然边界下刀子网络边界Attention/MoE/MLP/LM Head通信边界all_to_all/send/recv/all_gather/reduce_scatter状态边界KVCache update/offload/reload同步边界record_event / wait_event/wait_stream资源边界明显偏计算、偏通信、偏搬运memory movement的切换点。仓库中的 GLM-5 的 MoE 实现 就是按上述边界拆分的典型forward_shared_expert把共享专家Shared Expert单独拆出并放到独立 stream与_forward_gateRouter Path、moe_infer_dispatch_combineDispatch/Combine 通信路径解耦三者在hidden_states汇合点相遇。三、整网模块 DAG 规则1. 节点一个节点对应一个模块节点名要体现模块语义如router_path、shared_expert汇合点可以单独画成控制节点如merge_shared_router以显式表达同步语义节点不能是 Decoder Layer要再往下拆至少一到两级。2. 边类型四种依赖必须显式标注每条边必须标依赖类型这是后续判断并行性的关键依据依赖类型含义data后继直接消费前驱的输出state后继依赖前驱写完 cache / buffer / 共享状态event后继依赖前驱的事件、同步或 stream waitcollective_order通信顺序固定不能随意重排3. 共同输入不是依赖这是最容易犯的错误两个模块都用同一个输入如hidden_states同时进router_path和shared_expert时不要在它们之间画依赖边。正确做法是补一个共同上游节点让依赖关系变成「共同上游 → 各模块 → 汇合点」4. Mermaid 画法约定统一用flowchart LR还没决定流归属时用Main Path / Side Path / Comm Path表述只有代码里已明确是Stream0 / Stream1时才用流名做subgraph边画法--表示data或state依赖-.-表示event依赖如B -. wait .- M。四、模块级并行性判断三态判定对每一对模块必须落到三种状态之一不允许含糊判serial满足任一即必须串行存在data依赖存在共享可写状态冲突通信顺序固定不能插入collective_order其中一个只是另一个的内部步骤。判parallel_candidate须同时满足没有data依赖没有明确共享写冲突两者结果到后面的汇合点才相遇通信顺序没把它们绑成单链条。判parallel_pending_validation逻辑可并行待验证逻辑上可并行但以下问题尚未确认资源是否冲突、shape 是否太小、图模式 / runtime 是否有限制、是否引入额外 clone / buffer / host 开销。这三态判定是后面「候选编排」和「Plan 方案细节」的事实基础——只有parallel_candidate和parallel_pending_validation的并行点才有资格进入派生阶段。五、算子级拆解与 resource_hint 资源标注1. 算子拆解规则每个候选模块都要做算子拆解不允许只拆部分模块每个节点必须是单个算子或没必要再拆的算子组仍优先沿计算 / 通信 / 同步 / 状态边界拆模块内的共同输入、汇合点、同步点要单独标清每个模块产出三样东西模块内算子清单、算子级依赖清单、算子级 DAG。2. resource_hint 填写与字段查法resource_hint在生成模块清单和算子清单时同步填写对每个可并行点从 profiling 的kernel_details.csv读取算子行级资源信息回填。定位某模块 / 节点对应的算子行靠调用方提供的算子归属信息或源码对照确定具体字段查法和命令见 kernel-fields-lookup.md。推荐读取字段务必先print(df.columns)确认列名不要猜字段用途Name确认算子身份Stream ID/Task ID判断落流和下发顺序Input Shapes/Output Shapes判断跨流 tensor 尺寸和额外搬运风险Duration(us)判断主路径窗口和副路径耗时Accelerator Core判断 cube / vector / mix 类型Block Dim判断实际占用核数不用算子类型二元推断Mix Block Dim判断混合算子的另一侧核数aic_mac_ratio/aic_mte2_ratio判断 cube 计算 / 搬运占比aiv_vec_ratio/aiv_mte2_ratio判断 vector 计算 / 搬运占比resource_hint应写成可读摘要不贴 raw 表例如cube-heavy, blk20, dur35usvector/mem-heavy, aiv_mte2_ratio high, dur18uslight cube, blk1, can overlap with main matmul3. 资源标注的两条关键约束不要用算子类型推资源占用MatMul 也可能Block Dim1占很少核Vector 也可能占满核判断主副流是否争核用「主路径 dominator 算子 同时刻副路径候选算子的Block Dim加和」与设备核数比较设备核数从CANN 软件安装目录/arch-linux/data/platform_config/soc_version.ini读取。这与 SKILL 调试章节的结论一致判「主 / 副是否争 cube」用kernel_details.csv的Block Dim加和 vs 设备ai_core_cnt不要用「算子类型是 MatMul / Vector」的二元判断见 SKILL.md 3c 节。六、候选编排派生规则1. 每个并行点至少派生 2 种编排对每个可并行点至少给出 2 种不同编排。思考方式上有一个重要转变把共享同一输入、彼此无data依赖的模块 / 算子看成一个候选集合优先按集合划分思考分流而不是只从主流里挑一个「副流子集」。每个候选必须能看出五件事并配一张方案 DAG并行什么怎么分流在哪里汇合为什么可能有收益主要风险是什么。并行对象、流分组、汇合点、tag 粒度或跨阶段 overlap 不同就是不同的候选不要把多个变体塞进同一个方案。2. 常见派生维度派生维度取值变化示例算子粒度是否需要合并 / 拆分 / 重排算子集合划分哪些模块 / 算子同流串行哪些放到另一条流汇合点早汇合还是晚汇合流数量双流还是三流tag 粒度同一副流串行下发还是多个独立副流跨阶段 overlap仅本模块内还是跨层 / 跨阶段掩盖 dominator3. 实现强度不是候选变体实现强度C1 最小切流 → C2 切流 控核 → C3 切流 控核 手动同步是同一候选的复杂度递进不算不同候选。正确的推进方式是先用 C1 验证核心编排是否物理真并行再决定是否加控核、加手动同步点而改变并行对象 / 流分组 / 汇合点则属于另一个候选详见 SKILL「分析」一节。4. 与执行路径的关系派生候选时必须先定当前模型走的执行路径两条路径的 API 与约束不能混用见 api-routing.mdAscend IR / GE 图模式通过torchair.CompilerConfig()torchair.get_npu_backend()定界切流用torchair.scope.npu_stream_switch(stream_tag, ...)npugraph_ex / aclgraph切流用torch.npu.Stream()with torch.npu.stream(stream)或torch.npu.npugraph_ex.scope.npu_stream_switch(tag)这套 string-tag 接口。仓库源码正是按此双路径实现的DeepSeek-V3.2-Exp 的 modeling_deepseek.py 中enable_gegraph_and_multistream走npu_stream_switch(True, 22)npu_wait_tensorGE 路径enable_npugraphex_and_multistream走npu_stream_switch_npugraphrecord_event/wait_eventnpugraph_ex 路径同一份 shared expert 双流逻辑按执行模式分流实现。七、方向级分析产物模板analysis/direction.md上述拆解出的整套结果模块 / 算子 DAG 并行性判断就是多流方向的方向级分析产物。它的定位是一个模型一份被该方向派生出的所有候选 Plan 共享和引用在候选发现阶段产出从编排报告的「候选发现记录」链接出去建议落到analysis/multi-stream.md不要拷进每个 Plan 的方案细节——Plan 里只写自己的流分组 / GE 风险 / overlap_pct结构见 plan-detail-fragment.md。为保证跨 run、跨 agent 的结构一致必须固定按下面的骨架落盘1. 分析范围模型 / 网络阶段prefill/decode分析对象代码入口执行模式Ascend IR / GE 图模式或npugraph_ex / aclgraph2. 整网模块2.1 模块清单module_idmodule_namemodule_typeinputsoutputsside_effectresource_hint2.2 模块依赖清单fromtodependency_typereason2.3 模块 DAG3. 模块内算子为每个候选模块复制一组不要只写部分模块3.x module_name算子清单op_id / op_name / op_type / inputs / outputs / side_effect / resource_hint算子依赖清单from / to / dependency_type / reason算子 DAGmermaid4. 候选编排清单每个可并行点 ≥2 个候选每个候选给到「描述 DAG」这一层候选-N名方案描述并行什么 / 怎么分流 / 在哪汇合 / 可能收益 / 主要风险方案 DAGmermaid候选进入编排报告后各自成为一个 Plan更细的流分组、GE auto-reorder 风险、overlap_pct实测在该 Plan 的方案细节里按 plan-detail-fragment.md 展开不写在本产物里。八、最小示例MoE 路径的完整分析流程下面把整网中一段 MoE 路径整理成模块级骨架演示从拆解到派生的完整流程。模块清单module_idmodule_namemodule_typeinputsoutputsside_effectresource_hintrouter_pathRouter Pathcomputehidden_statesrouted_hidden_states无compute commshared_expertShared Expertcomputehidden_statesshared_hidden_states无computemerge_shared_routerMerge Shared Routercontrolrouted_hidden_states, shared_hidden_stateshidden_states无light compute依赖清单fromtodependency_typereasonrouter_pathmerge_shared_routerdatamerge 需要 routed_hidden_statesshared_expertmerge_shared_routerdatamerge 需要 shared_hidden_states注意router_path与shared_expert共享hidden_states输入但二者之间没有依赖边——共同输入不是依赖汇合点在merge_shared_router。模块 DAG候选编排shared_expert 旁路双流router_path与shared_expert共享hidden_states输入在merge_shared_router前汇合。该候选把shared_expert放到 Side Path用它掩盖router_path主路径窗口资源标签从kernel_details.csv的Block Dim/ pipeline ratio 补齐。主要风险是副流过重导致拖尾或汇合点过早导致主流空洞。九、仓库中的落地佐证从拆解到实现的闭环方向级分析的产出最终要落到代码。仓库内的多流案例库 examples/README.md 按「每次优化算一个案例」整理了与本拆解方法论一一对应的落地形态可作为分析时的快速选型参考优化模式先看案例再看源码MoE shared expert 双流moe-shared-expert-dual-stream.mdmodels/deepseek_v3_2_exp/models/modeling_deepseek.py、models/glm_5/models/modeling_glm.pyIndexer / Prolog 多流indexer-prolog-multi-stream.mdmodels/glm_5/models/indexer.pyKVCache offload 异步流kvcache-offload-async-stream.mdmodels/deepseek_v3_2_exp/models/offload_cache.pyPrefill micro-batch 双流prefill-microbatch-dual-stream.mdmodels/deepseek_r1/models/modeling_deepseek.py多流 控核longcat-flash-multi-stream-limit-core.mdmodels/longcat_flash/models/modeling_longcat_flash.py以 GLM-5 的共享专家双流实现为例modeling_glm.py源码严格遵循了本文的拆解语义forward_shared_expert先record_stream标记跨流 tensor 生命周期、record_event(npu_events, 0)记录入口事件然后在npu_stream_switch(self.enable_multi_streams, shared_expert_stream)的 with-block 内等待事件、执行共享专家前向、record_event(npu_events, 1)记录出口事件——这正是模块 DAG 中「共同输入 → Side Path → event 汇合」的代码级体现。对应的开关设计也符合 SKILL「开关必须可关闭」的核心原则多流能力通过配置项enable_multi_streams控制且通常叠加exe_mode选择执行路径。例如 GLM-5 decode 配置 中exe_mode: npugraph_ex搭配enable_multi_streams: True而 prefill 配置中enable_multi_streams: False——这印证了「多流分析必须区分 prefill / decode 阶段」的要求。十、分析阶段的常见误区把 decoder layer 当模块模块至少要再往下拆一层否则无法独立讨论调度把共同输入画成依赖边两个模块共享hidden_states不等于有data依赖应补共同上游节点用算子类型推资源占用MatMul 也可能Block Dim1判断争核必须用Block Dim加和 vs 设备核数把实现强度递进当新候选C1 → C2 → C3 是同一候选的复杂度阶梯改变并行对象 / 流分组 / 汇合点才是新候选每个并行点只给一个编排规则要求至少 2 种不同编排多试不同集合划分才能选出物理真并行且 wall 下降最大的方案。进一步阅读并行性判断与resource_hint之后方案的同步实现npu_stream_switch/npu_wait_tensor/ tagged event见 api-routing.md候选落 Plan 后的流分组、GE auto-reorder 风险与overlap_pct实测回填见 plan-detail-fragment.mdkernel_details.csv设计 / post-mortem 两套字段集见 kernel-fields-lookup.md。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。