| Files | Last commit | Last update |
|---|---|---|
单jetty多对端 Co-authored-by: Yuyu-Li<liyuyu6@huawei.com> # message auto-generated for no-merge-commit merge: !13422 merge single_jetty into master 单jetty多对端 Created-by: Yuyu-Li Commit-by: Yuyu-Li Merged-by: cann-robot Description: ## 描述 训练DC算子支持单jetty多对端 > **检视对象**：git commit e56f8c20fb22ddcd72c57db1dcbb0e1d5cc7c723（单jetty多对端） > **提交说明**：为 MoE EP dispatch/combine 引入第二种通信算法 shared_jetty——32 个物理 Jetty（SQ=4096/CQ=64）经 multi-channel handle 服务所有对端 rank；ElasticBuffer 增加 comm_alg 参数；4 个 aclnn 算子签名插参 commAlg 并按 TilingKey 分流到全新 shared-jetty kernel 实现；torch extension 新增 1GiB 大页 context builder。变更 44 文件（+3091/-144，有效变更 2782 行）。 > **检视方式**：ascendc-code-review skill PR 检视流程（标准模式），阶段：代码概要 → API 预研（Ascend 950/A5 代际）→ 设计文档探测 → 检视计划 → 12 组逐条检视（红线/TOPK/安全/API/MC2 领域/风格/RegBase/性能/算子约定/通用规范/Python）+ 设计一致性 S1-S7/D8 → 行号校对（含 diff 范围红线校验，0 范围外）→ 报告组装。 # 代码检视报告 ## 检视概览 - 代码文件：commit e56f8c20fb22ddcd72c57db1dcbb0e1d5cc7c723「单jetty多对端」的 44 个变更文件（mc2/common 共享组件、mc2/moe_ep_combine(+epilogue)、mc2/moe_ep_dispatch(+epilogue)、torch_extension/、tests/） - 代码侧别：混合（Kernel + Tiling + Host/API + Python） - 检视文档：ascendc-api、ascendc-op-conventions、ascendc-perf、ascendc-red-line、ascendc-topk、cpp-general、cpp-secure、cpp-style、mc2-specific、python-secure、regbase-review-checks（共 11 个规则文档） - 总条例数：134（另含 cpp-style 19 条风格条款，不计入统计） - 设计文档来源：mc2/common/docs（torchapi_ElasticBuffer.md） - 检视时间：2026-10-20 22:41 ## 检视统计 | 状态 | 条例数 | 占比 | |------|------|------| | PASS | 132 | 98.5% | | FAIL（发现问题）| 1 | 0.7% | | SUSPICIOUS（需关注）| 1 | 0.7% | ## 设计一致性检查 - 文档来源：mc2/common/docs（torchapi_ElasticBuffer.md） - 总体评级：不一致 | 策略 | 维度 | 设计期望 | 实现实际 | 判定 | |------|------|---------|---------|------| | S1 | 架构匹配 | ElasticBuffer 作为分布式通信 buffer 管理器，内部按算子参数自动计算并申请 CCL buffer，向 aclnn MoE EP 算子提供 context | 实现延续该架构，shared_jetty 路径由 MoeSharedJettyContextBuilder 分配 1GiB 大页并注册 HCCL，from_blob 包装为 context tensor 传入 4 个 aclnn 算子 | ✅ | | S2 | 分支覆盖 | torchapi_ElasticBuffer.md 功能说明仅描述单一通信路径，无 comm_alg/通信算法分支描述 | 实现新增 fullmesh/shared_jetty 双算法分支（构造参数、窗口布局、kernel 实现全套分叉），文档未同步描述 shared_jetty 分支及其约束（至少 64 rank、仅 direct 拓扑） | ❌ | | S3 | API清单 | 文档 dispatch/combine 等接口原型与约束 | 既有接口签名语义不变，新增 comm_alg 为可选参数（默认 fullmesh 向后兼容），kernel API 未使用黑名单接口 | ✅ | | S4 | 数据流追踪 | dispatch 将 token 分发到对应专家卡，combine 将专家输出按原路由聚合回原序列 | shared_jetty 路径数据流与之一致（dispatch 路由统计、count 通知、payload URMA 写、notify；combine metadata 读取、按槽位回写、flag 通知），窗口布局由 host/kernel/Python 三侧同公式保证一致 | ✅ | | S5 | 参数语义 | 文档 __init__ 原型为 group/num_cpu_bytes/num_max_tokens_per_rank/hidden/num_topk/with_grad/explicitly_destroy 七参数，无 comm_alg | 实现在 Python/C++/pybind 三层新增 comm_alg 参数（fullmesh/shared_jetty），产品文档 __init__ 原型未包含该参数 | ❌ | | S6 | 伪代码映射 | 文档无伪代码章节 | 无伪代码可映射 | N/A | | S7 | 约束合规 | 所需 CCL 通信 buffer 由 ElasticBuffer 内部按算子参数自动计算并申请，无需手动配置 | shared_jetty 路径同样由内部按窗口布局公式自动计算并以 2MB 对齐 1GiB 大页申请，满足文档约束 | ✅ | | D8 | 文档格式 | | | ✅ | ### 设计一致性偏差（❌ 项详情） **S5**：__init__ 新增 comm_alg 参数未同步至产品文档函数原型 - 代码位置（校对后行号）：mc2/common/torch_extension/elastic_buffer.py:660 - 设计依据：torchapi_ElasticBuffer.md 函数原型（36-46 行）__init__ 原型无 comm_alg **S2**：shared_jetty 通信算法分支（含至少 64 rank、仅 direct 拓扑、32 jetty 资源约束）未在产品文档功能说明中描述 - 代码位置（校对后行号）：mc2/common/torch_extension/elastic_buffer.py:923 - 设计依据：torchapi_ElasticBuffer.md 功能说明（28-30 行）仅描述单一通信路径 ## 需关注（MED 置信度） ### [SEC-7.4] 对外结构体接口新增字段时必须在结构体最后添加 - **状态**：FAIL | **置信度**：MED - **问题描述**：本次 commit 在 4 个 TilingData Info 结构体（MoeEpDispatchEpilogueInfo/MoeEpDispatchInfo/ MoeEpCombineInfo/MoeEpCombineEpilogueInfo）的中间位置插入 commAlg 字段而非追加到结构体末尾。 其中 moe_ep_dispatch_epilogue_tiling.h 自身的注释明确记载该结构体是 host tiling 与 kernel 共用的裸内存 ABI，且 rankExpertHitCountOffsetReserved 占位字段存在的唯一目的就是保持 metadataRankOffsetsOffset 等字段在新旧 host/kernel 混用（非同一次构建）时偏移不变； 本次将 commAlg 插入到该占位字段之前，使 metadataRankOffsetsOffset/localRecvIndexOffset/ slotEndsOffset/slotRowIdsOffset 等字段整体后移 8 字节，破坏了注释所记载的混用兼容保证。 混用场景下 kernel 会按旧偏移读取新布局（或反之），metadataRankOffsetsOffset 被错读为 错误值，复现注释中描述的 recv_rank_offsets 错乱类问题。 - **代码文件**：mc2/moe_ep_dispatch_epilogue/op_kernel/moe_ep_dispatch_epilogue_tiling.h - **起始行号**：41 - **中止行号**：51 - **代码片段**： cpp // 占位，勿删：这个字段曾经死在 metadataRankOffsetsOffset 前面，删掉会把后者前移 8 字节。 // tiling 结构体是 host tiling 与 kernel 共用的裸内存 ABI，偏移一变，两侧只要不是同一次构建， // kernel 就会把 metadataRankOffsetsOffset 读成 0，offsets 被写到 recvSrcMetadata + 0， // 随后又被 metadata 行覆盖，表现为 recv_rank_offsets 恒为 torch.empty 的 [0, 0, 0]。 // 保留占位即可让新旧 host/kernel 混用时字段偏移不变。 uint32_t commAlg = 0; uint64_t rankExpertHitCountOffsetReserved = 0; uint64_t metadataRankOffsetsOffset = 0; // byte offset of the aligned tail in packed metadata uint64_t localRecvIndexOffset = 0; // byte offset of [num_tokens, top_k] local recv_x reverse index uint64_t slotEndsOffset = 0; // compact slot list ends, capacity entries uint64_t slotRowIdsOffset = 0; // metadata row ids grouped by slot, capacity entries - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 规范违反 | +40% | 4 个 TilingData 结构体均在中间插入新字段，违反"新增字段必须在结构体最后添加" | | 上下文防御缺失 | +30% | 结构体注释明确记载混用 ABI 兼容保证（保留占位使偏移不变），本次插入破坏该保证且无任何版本隔离/偏移校验机制 | | PR 归属 | +20% | commAlg 插入在本次 diff 变更范围内 | | 数据流风险 | +15% | 混用构建下 metadataRankOffsetsOffset 等字段错读 8 字节偏移，接收侧 metadata 布局错乱 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在 | -20% | mc2/moe_ep_dispatch_epilogue_tiling.h 同一头文件被 host tiling 与 kernel 同时包含，同仓同版本构建时偏移必然一致 | 自信值 = Σ正向 + Σ负向 = 85% ≥ 70% → 判定违规 - **修复建议**：将 commAlg 字段移到各 TilingData Info 结构体末尾（最后一个字段之后）追加， 保持既有字段偏移不变；或复用已有的 reserved/占位字段空间。若确需中间插入， 应同步更新结构体注释并确认部署上不存在新旧 host/kernel 混用场景。 ## 疑似（LOW 置信度） ### [MC2-17] HCCL API 参数动态查阅验证 - **状态**：SUSPICIOUS | **置信度**：LOW - **问题描述**：本次 commit 大量使用新 HCCL/HCOMM 扩展 API（HcclChannelAcquireWithConfig、 HcclChannelConfigSetInt/SetStr、HcclEngineCtxDestroy、MakeMultiChannelHandle、 Hcomm::MakeBatchHandle/WriteNbi/WriteWithNotifyNbi/BatchCommit/Drain/GetHandleRef）， 本规则要求检视时必须通过 /ascendc-docs-search 动态查阅官方文档验证参数与生命周期。 本次检视环境中无本地 ASC_DEVKIT 文档，在线文档站点（hiascend.com）对脚本抓取返回 JS/Cookie 拦截页，无法完成权威文档比对。参数一致性只能通过与仓内既有 fullmesh 生产实现（moe_ep_dispatch.h/moe_ep_combine.h 同族调用模式）对照佐证，属于未经 动态查询确认的潜在风险，需人工在具备文档环境时复核。 - **代码文件**：mc2/common/torch_extension/csrc/moe_shared_jetty_context.cpp - **起始行号**：288 - **中止行号**：304 - **代码片段**： cpp std::vector<ChannelHandle> channels(channelDescs_.size()); HcclChannelConfig config = nullptr; CheckHccl(HcclChannelConfigCreateFunc(&config), "HcclChannelConfigCreate"); const char* operation = "HcclChannelConfigSetInt"; auto ret = HcclChannelConfigSetIntFunc(config, HCCL_CHANNEL_CONFIG_TYPE_IS_SHARED_QUEUE, 1); if (ret == HCCL_SUCCESS) { operation = "HcclChannelConfigSetStr"; ret = HcclChannelConfigSetStrFunc(config, HCCL_CHANNEL_CONFIG_TYPE_SHARED_QUEUE_TAG, queueTag.c_str()); } if (ret == HCCL_SUCCESS) { operation = "HcclChannelAcquireWithConfig"; ret = HcclChannelAcquireWithConfigFunc(comm_, COMM_ENGINE, channelDescs_.data(), static_cast<uint32_t>(channelDescs_.size()), config, channels.data()); } auto destroyRet = HcclChannelConfigDestroyFunc(config); TORCH_CHECK(ret == HCCL_SUCCESS, operation, " failed, ret=", ret, ", config cleanup ret=", destroyRet); - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 领域关联 | +10% | 代码命中 HCCL 通信 API 领域触发特征，规则要求动态查阅验证 | | PR 归属 | +20% | 全部新增 HCCL 调用在 diff 变更范围内 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在 | -20% | 所有 HCCL 函数指针经 InitHcclSharedJettyFunctions 全量判空加载，调用返回值全部 CheckHccl/TORCH_CHECK 校验 | | 上游校验 | -15% | Hcomm kernel 侧调用模式与仓内 fullmesh 生产实现（moe_ep_dispatch.h:1165-1210、moe_ep_combine.h:281-317）逐模式一致 | 自信值 = Σ正向 + Σ负向 = -5% ≥ 70% → 未达违规阈值 - **修复建议**：在具备 CANN 文档环境处复核 HcclChannelAcquireWithConfig/MakeMultiChannelHandle 等 新 API 的参数约束与生命周期语义（特别是 AcquireSharedChannels 返回的 ChannelHandle 是否需要显式释放），确认与仓内既有用法一致。 ## 代码风格 > 来自 cpp-style 检视，不走假设检验，违反即 FAIL。不并入上方统计表。 | 条例 | 严重级别 | 问题描述 | 代码位置（校对后行号） | 修复建议 | |------|---------|---------|----------------------|---------| | STYLE-3.1 文件头注释包含版权声明（年份正确） | 中 | 新增文件 moe_ep_combine_shared_jetty.h 的版权年份为 2025，而同一次 commit 新增的其余 7 个文件均为 2026（该文件首次进入仓库于本 commit 2026-10），疑为复制旧文件头注释时未改年份，与同批新文件不一致。 | mc2/moe_ep_combine/op_kernel/moe_ep_combine_shared_jetty.h:1-14 | 将版权年份修正为 2026，与同批新增文件保持一致。 | ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/5359 ## 测试 二级冒烟，线下测试 ## 文档更新 NA ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [x] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!13422 | 9 days ago | |
单jetty多对端 Co-authored-by: Yuyu-Li<liyuyu6@huawei.com> # message auto-generated for no-merge-commit merge: !13422 merge single_jetty into master 单jetty多对端 Created-by: Yuyu-Li Commit-by: Yuyu-Li Merged-by: cann-robot Description: ## 描述 训练DC算子支持单jetty多对端 > **检视对象**：git commit e56f8c20fb22ddcd72c57db1dcbb0e1d5cc7c723（单jetty多对端） > **提交说明**：为 MoE EP dispatch/combine 引入第二种通信算法 shared_jetty——32 个物理 Jetty（SQ=4096/CQ=64）经 multi-channel handle 服务所有对端 rank；ElasticBuffer 增加 comm_alg 参数；4 个 aclnn 算子签名插参 commAlg 并按 TilingKey 分流到全新 shared-jetty kernel 实现；torch extension 新增 1GiB 大页 context builder。变更 44 文件（+3091/-144，有效变更 2782 行）。 > **检视方式**：ascendc-code-review skill PR 检视流程（标准模式），阶段：代码概要 → API 预研（Ascend 950/A5 代际）→ 设计文档探测 → 检视计划 → 12 组逐条检视（红线/TOPK/安全/API/MC2 领域/风格/RegBase/性能/算子约定/通用规范/Python）+ 设计一致性 S1-S7/D8 → 行号校对（含 diff 范围红线校验，0 范围外）→ 报告组装。 # 代码检视报告 ## 检视概览 - 代码文件：commit e56f8c20fb22ddcd72c57db1dcbb0e1d5cc7c723「单jetty多对端」的 44 个变更文件（mc2/common 共享组件、mc2/moe_ep_combine(+epilogue)、mc2/moe_ep_dispatch(+epilogue)、torch_extension/、tests/） - 代码侧别：混合（Kernel + Tiling + Host/API + Python） - 检视文档：ascendc-api、ascendc-op-conventions、ascendc-perf、ascendc-red-line、ascendc-topk、cpp-general、cpp-secure、cpp-style、mc2-specific、python-secure、regbase-review-checks（共 11 个规则文档） - 总条例数：134（另含 cpp-style 19 条风格条款，不计入统计） - 设计文档来源：mc2/common/docs（torchapi_ElasticBuffer.md） - 检视时间：2026-10-20 22:41 ## 检视统计 | 状态 | 条例数 | 占比 | |------|------|------| | PASS | 132 | 98.5% | | FAIL（发现问题）| 1 | 0.7% | | SUSPICIOUS（需关注）| 1 | 0.7% | ## 设计一致性检查 - 文档来源：mc2/common/docs（torchapi_ElasticBuffer.md） - 总体评级：不一致 | 策略 | 维度 | 设计期望 | 实现实际 | 判定 | |------|------|---------|---------|------| | S1 | 架构匹配 | ElasticBuffer 作为分布式通信 buffer 管理器，内部按算子参数自动计算并申请 CCL buffer，向 aclnn MoE EP 算子提供 context | 实现延续该架构，shared_jetty 路径由 MoeSharedJettyContextBuilder 分配 1GiB 大页并注册 HCCL，from_blob 包装为 context tensor 传入 4 个 aclnn 算子 | ✅ | | S2 | 分支覆盖 | torchapi_ElasticBuffer.md 功能说明仅描述单一通信路径，无 comm_alg/通信算法分支描述 | 实现新增 fullmesh/shared_jetty 双算法分支（构造参数、窗口布局、kernel 实现全套分叉），文档未同步描述 shared_jetty 分支及其约束（至少 64 rank、仅 direct 拓扑） | ❌ | | S3 | API清单 | 文档 dispatch/combine 等接口原型与约束 | 既有接口签名语义不变，新增 comm_alg 为可选参数（默认 fullmesh 向后兼容），kernel API 未使用黑名单接口 | ✅ | | S4 | 数据流追踪 | dispatch 将 token 分发到对应专家卡，combine 将专家输出按原路由聚合回原序列 | shared_jetty 路径数据流与之一致（dispatch 路由统计、count 通知、payload URMA 写、notify；combine metadata 读取、按槽位回写、flag 通知），窗口布局由 host/kernel/Python 三侧同公式保证一致 | ✅ | | S5 | 参数语义 | 文档 __init__ 原型为 group/num_cpu_bytes/num_max_tokens_per_rank/hidden/num_topk/with_grad/explicitly_destroy 七参数，无 comm_alg | 实现在 Python/C++/pybind 三层新增 comm_alg 参数（fullmesh/shared_jetty），产品文档 __init__ 原型未包含该参数 | ❌ | | S6 | 伪代码映射 | 文档无伪代码章节 | 无伪代码可映射 | N/A | | S7 | 约束合规 | 所需 CCL 通信 buffer 由 ElasticBuffer 内部按算子参数自动计算并申请，无需手动配置 | shared_jetty 路径同样由内部按窗口布局公式自动计算并以 2MB 对齐 1GiB 大页申请，满足文档约束 | ✅ | | D8 | 文档格式 | | | ✅ | ### 设计一致性偏差（❌ 项详情） **S5**：__init__ 新增 comm_alg 参数未同步至产品文档函数原型 - 代码位置（校对后行号）：mc2/common/torch_extension/elastic_buffer.py:660 - 设计依据：torchapi_ElasticBuffer.md 函数原型（36-46 行）__init__ 原型无 comm_alg **S2**：shared_jetty 通信算法分支（含至少 64 rank、仅 direct 拓扑、32 jetty 资源约束）未在产品文档功能说明中描述 - 代码位置（校对后行号）：mc2/common/torch_extension/elastic_buffer.py:923 - 设计依据：torchapi_ElasticBuffer.md 功能说明（28-30 行）仅描述单一通信路径 ## 需关注（MED 置信度） ### [SEC-7.4] 对外结构体接口新增字段时必须在结构体最后添加 - **状态**：FAIL | **置信度**：MED - **问题描述**：本次 commit 在 4 个 TilingData Info 结构体（MoeEpDispatchEpilogueInfo/MoeEpDispatchInfo/ MoeEpCombineInfo/MoeEpCombineEpilogueInfo）的中间位置插入 commAlg 字段而非追加到结构体末尾。 其中 moe_ep_dispatch_epilogue_tiling.h 自身的注释明确记载该结构体是 host tiling 与 kernel 共用的裸内存 ABI，且 rankExpertHitCountOffsetReserved 占位字段存在的唯一目的就是保持 metadataRankOffsetsOffset 等字段在新旧 host/kernel 混用（非同一次构建）时偏移不变； 本次将 commAlg 插入到该占位字段之前，使 metadataRankOffsetsOffset/localRecvIndexOffset/ slotEndsOffset/slotRowIdsOffset 等字段整体后移 8 字节，破坏了注释所记载的混用兼容保证。 混用场景下 kernel 会按旧偏移读取新布局（或反之），metadataRankOffsetsOffset 被错读为 错误值，复现注释中描述的 recv_rank_offsets 错乱类问题。 - **代码文件**：mc2/moe_ep_dispatch_epilogue/op_kernel/moe_ep_dispatch_epilogue_tiling.h - **起始行号**：41 - **中止行号**：51 - **代码片段**： cpp // 占位，勿删：这个字段曾经死在 metadataRankOffsetsOffset 前面，删掉会把后者前移 8 字节。 // tiling 结构体是 host tiling 与 kernel 共用的裸内存 ABI，偏移一变，两侧只要不是同一次构建， // kernel 就会把 metadataRankOffsetsOffset 读成 0，offsets 被写到 recvSrcMetadata + 0， // 随后又被 metadata 行覆盖，表现为 recv_rank_offsets 恒为 torch.empty 的 [0, 0, 0]。 // 保留占位即可让新旧 host/kernel 混用时字段偏移不变。 uint32_t commAlg = 0; uint64_t rankExpertHitCountOffsetReserved = 0; uint64_t metadataRankOffsetsOffset = 0; // byte offset of the aligned tail in packed metadata uint64_t localRecvIndexOffset = 0; // byte offset of [num_tokens, top_k] local recv_x reverse index uint64_t slotEndsOffset = 0; // compact slot list ends, capacity entries uint64_t slotRowIdsOffset = 0; // metadata row ids grouped by slot, capacity entries - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 规范违反 | +40% | 4 个 TilingData 结构体均在中间插入新字段，违反"新增字段必须在结构体最后添加" | | 上下文防御缺失 | +30% | 结构体注释明确记载混用 ABI 兼容保证（保留占位使偏移不变），本次插入破坏该保证且无任何版本隔离/偏移校验机制 | | PR 归属 | +20% | commAlg 插入在本次 diff 变更范围内 | | 数据流风险 | +15% | 混用构建下 metadataRankOffsetsOffset 等字段错读 8 字节偏移，接收侧 metadata 布局错乱 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在 | -20% | mc2/moe_ep_dispatch_epilogue_tiling.h 同一头文件被 host tiling 与 kernel 同时包含，同仓同版本构建时偏移必然一致 | 自信值 = Σ正向 + Σ负向 = 85% ≥ 70% → 判定违规 - **修复建议**：将 commAlg 字段移到各 TilingData Info 结构体末尾（最后一个字段之后）追加， 保持既有字段偏移不变；或复用已有的 reserved/占位字段空间。若确需中间插入， 应同步更新结构体注释并确认部署上不存在新旧 host/kernel 混用场景。 ## 疑似（LOW 置信度） ### [MC2-17] HCCL API 参数动态查阅验证 - **状态**：SUSPICIOUS | **置信度**：LOW - **问题描述**：本次 commit 大量使用新 HCCL/HCOMM 扩展 API（HcclChannelAcquireWithConfig、 HcclChannelConfigSetInt/SetStr、HcclEngineCtxDestroy、MakeMultiChannelHandle、 Hcomm::MakeBatchHandle/WriteNbi/WriteWithNotifyNbi/BatchCommit/Drain/GetHandleRef）， 本规则要求检视时必须通过 /ascendc-docs-search 动态查阅官方文档验证参数与生命周期。 本次检视环境中无本地 ASC_DEVKIT 文档，在线文档站点（hiascend.com）对脚本抓取返回 JS/Cookie 拦截页，无法完成权威文档比对。参数一致性只能通过与仓内既有 fullmesh 生产实现（moe_ep_dispatch.h/moe_ep_combine.h 同族调用模式）对照佐证，属于未经 动态查询确认的潜在风险，需人工在具备文档环境时复核。 - **代码文件**：mc2/common/torch_extension/csrc/moe_shared_jetty_context.cpp - **起始行号**：288 - **中止行号**：304 - **代码片段**： cpp std::vector<ChannelHandle> channels(channelDescs_.size()); HcclChannelConfig config = nullptr; CheckHccl(HcclChannelConfigCreateFunc(&config), "HcclChannelConfigCreate"); const char* operation = "HcclChannelConfigSetInt"; auto ret = HcclChannelConfigSetIntFunc(config, HCCL_CHANNEL_CONFIG_TYPE_IS_SHARED_QUEUE, 1); if (ret == HCCL_SUCCESS) { operation = "HcclChannelConfigSetStr"; ret = HcclChannelConfigSetStrFunc(config, HCCL_CHANNEL_CONFIG_TYPE_SHARED_QUEUE_TAG, queueTag.c_str()); } if (ret == HCCL_SUCCESS) { operation = "HcclChannelAcquireWithConfig"; ret = HcclChannelAcquireWithConfigFunc(comm_, COMM_ENGINE, channelDescs_.data(), static_cast<uint32_t>(channelDescs_.size()), config, channels.data()); } auto destroyRet = HcclChannelConfigDestroyFunc(config); TORCH_CHECK(ret == HCCL_SUCCESS, operation, " failed, ret=", ret, ", config cleanup ret=", destroyRet); - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 领域关联 | +10% | 代码命中 HCCL 通信 API 领域触发特征，规则要求动态查阅验证 | | PR 归属 | +20% | 全部新增 HCCL 调用在 diff 变更范围内 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在 | -20% | 所有 HCCL 函数指针经 InitHcclSharedJettyFunctions 全量判空加载，调用返回值全部 CheckHccl/TORCH_CHECK 校验 | | 上游校验 | -15% | Hcomm kernel 侧调用模式与仓内 fullmesh 生产实现（moe_ep_dispatch.h:1165-1210、moe_ep_combine.h:281-317）逐模式一致 | 自信值 = Σ正向 + Σ负向 = -5% ≥ 70% → 未达违规阈值 - **修复建议**：在具备 CANN 文档环境处复核 HcclChannelAcquireWithConfig/MakeMultiChannelHandle 等 新 API 的参数约束与生命周期语义（特别是 AcquireSharedChannels 返回的 ChannelHandle 是否需要显式释放），确认与仓内既有用法一致。 ## 代码风格 > 来自 cpp-style 检视，不走假设检验，违反即 FAIL。不并入上方统计表。 | 条例 | 严重级别 | 问题描述 | 代码位置（校对后行号） | 修复建议 | |------|---------|---------|----------------------|---------| | STYLE-3.1 文件头注释包含版权声明（年份正确） | 中 | 新增文件 moe_ep_combine_shared_jetty.h 的版权年份为 2025，而同一次 commit 新增的其余 7 个文件均为 2026（该文件首次进入仓库于本 commit 2026-10），疑为复制旧文件头注释时未改年份，与同批新文件不一致。 | mc2/moe_ep_combine/op_kernel/moe_ep_combine_shared_jetty.h:1-14 | 将版权年份修正为 2026，与同批新增文件保持一致。 | ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/5359 ## 测试 二级冒烟，线下测试 ## 文档更新 NA ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [x] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!13422 | 9 days ago | |
单jetty多对端 Co-authored-by: Yuyu-Li<liyuyu6@huawei.com> # message auto-generated for no-merge-commit merge: !13422 merge single_jetty into master 单jetty多对端 Created-by: Yuyu-Li Commit-by: Yuyu-Li Merged-by: cann-robot Description: ## 描述 训练DC算子支持单jetty多对端 > **检视对象**：git commit e56f8c20fb22ddcd72c57db1dcbb0e1d5cc7c723（单jetty多对端） > **提交说明**：为 MoE EP dispatch/combine 引入第二种通信算法 shared_jetty——32 个物理 Jetty（SQ=4096/CQ=64）经 multi-channel handle 服务所有对端 rank；ElasticBuffer 增加 comm_alg 参数；4 个 aclnn 算子签名插参 commAlg 并按 TilingKey 分流到全新 shared-jetty kernel 实现；torch extension 新增 1GiB 大页 context builder。变更 44 文件（+3091/-144，有效变更 2782 行）。 > **检视方式**：ascendc-code-review skill PR 检视流程（标准模式），阶段：代码概要 → API 预研（Ascend 950/A5 代际）→ 设计文档探测 → 检视计划 → 12 组逐条检视（红线/TOPK/安全/API/MC2 领域/风格/RegBase/性能/算子约定/通用规范/Python）+ 设计一致性 S1-S7/D8 → 行号校对（含 diff 范围红线校验，0 范围外）→ 报告组装。 # 代码检视报告 ## 检视概览 - 代码文件：commit e56f8c20fb22ddcd72c57db1dcbb0e1d5cc7c723「单jetty多对端」的 44 个变更文件（mc2/common 共享组件、mc2/moe_ep_combine(+epilogue)、mc2/moe_ep_dispatch(+epilogue)、torch_extension/、tests/） - 代码侧别：混合（Kernel + Tiling + Host/API + Python） - 检视文档：ascendc-api、ascendc-op-conventions、ascendc-perf、ascendc-red-line、ascendc-topk、cpp-general、cpp-secure、cpp-style、mc2-specific、python-secure、regbase-review-checks（共 11 个规则文档） - 总条例数：134（另含 cpp-style 19 条风格条款，不计入统计） - 设计文档来源：mc2/common/docs（torchapi_ElasticBuffer.md） - 检视时间：2026-10-20 22:41 ## 检视统计 | 状态 | 条例数 | 占比 | |------|------|------| | PASS | 132 | 98.5% | | FAIL（发现问题）| 1 | 0.7% | | SUSPICIOUS（需关注）| 1 | 0.7% | ## 设计一致性检查 - 文档来源：mc2/common/docs（torchapi_ElasticBuffer.md） - 总体评级：不一致 | 策略 | 维度 | 设计期望 | 实现实际 | 判定 | |------|------|---------|---------|------| | S1 | 架构匹配 | ElasticBuffer 作为分布式通信 buffer 管理器，内部按算子参数自动计算并申请 CCL buffer，向 aclnn MoE EP 算子提供 context | 实现延续该架构，shared_jetty 路径由 MoeSharedJettyContextBuilder 分配 1GiB 大页并注册 HCCL，from_blob 包装为 context tensor 传入 4 个 aclnn 算子 | ✅ | | S2 | 分支覆盖 | torchapi_ElasticBuffer.md 功能说明仅描述单一通信路径，无 comm_alg/通信算法分支描述 | 实现新增 fullmesh/shared_jetty 双算法分支（构造参数、窗口布局、kernel 实现全套分叉），文档未同步描述 shared_jetty 分支及其约束（至少 64 rank、仅 direct 拓扑） | ❌ | | S3 | API清单 | 文档 dispatch/combine 等接口原型与约束 | 既有接口签名语义不变，新增 comm_alg 为可选参数（默认 fullmesh 向后兼容），kernel API 未使用黑名单接口 | ✅ | | S4 | 数据流追踪 | dispatch 将 token 分发到对应专家卡，combine 将专家输出按原路由聚合回原序列 | shared_jetty 路径数据流与之一致（dispatch 路由统计、count 通知、payload URMA 写、notify；combine metadata 读取、按槽位回写、flag 通知），窗口布局由 host/kernel/Python 三侧同公式保证一致 | ✅ | | S5 | 参数语义 | 文档 __init__ 原型为 group/num_cpu_bytes/num_max_tokens_per_rank/hidden/num_topk/with_grad/explicitly_destroy 七参数，无 comm_alg | 实现在 Python/C++/pybind 三层新增 comm_alg 参数（fullmesh/shared_jetty），产品文档 __init__ 原型未包含该参数 | ❌ | | S6 | 伪代码映射 | 文档无伪代码章节 | 无伪代码可映射 | N/A | | S7 | 约束合规 | 所需 CCL 通信 buffer 由 ElasticBuffer 内部按算子参数自动计算并申请，无需手动配置 | shared_jetty 路径同样由内部按窗口布局公式自动计算并以 2MB 对齐 1GiB 大页申请，满足文档约束 | ✅ | | D8 | 文档格式 | | | ✅ | ### 设计一致性偏差（❌ 项详情） **S5**：__init__ 新增 comm_alg 参数未同步至产品文档函数原型 - 代码位置（校对后行号）：mc2/common/torch_extension/elastic_buffer.py:660 - 设计依据：torchapi_ElasticBuffer.md 函数原型（36-46 行）__init__ 原型无 comm_alg **S2**：shared_jetty 通信算法分支（含至少 64 rank、仅 direct 拓扑、32 jetty 资源约束）未在产品文档功能说明中描述 - 代码位置（校对后行号）：mc2/common/torch_extension/elastic_buffer.py:923 - 设计依据：torchapi_ElasticBuffer.md 功能说明（28-30 行）仅描述单一通信路径 ## 需关注（MED 置信度） ### [SEC-7.4] 对外结构体接口新增字段时必须在结构体最后添加 - **状态**：FAIL | **置信度**：MED - **问题描述**：本次 commit 在 4 个 TilingData Info 结构体（MoeEpDispatchEpilogueInfo/MoeEpDispatchInfo/ MoeEpCombineInfo/MoeEpCombineEpilogueInfo）的中间位置插入 commAlg 字段而非追加到结构体末尾。 其中 moe_ep_dispatch_epilogue_tiling.h 自身的注释明确记载该结构体是 host tiling 与 kernel 共用的裸内存 ABI，且 rankExpertHitCountOffsetReserved 占位字段存在的唯一目的就是保持 metadataRankOffsetsOffset 等字段在新旧 host/kernel 混用（非同一次构建）时偏移不变； 本次将 commAlg 插入到该占位字段之前，使 metadataRankOffsetsOffset/localRecvIndexOffset/ slotEndsOffset/slotRowIdsOffset 等字段整体后移 8 字节，破坏了注释所记载的混用兼容保证。 混用场景下 kernel 会按旧偏移读取新布局（或反之），metadataRankOffsetsOffset 被错读为 错误值，复现注释中描述的 recv_rank_offsets 错乱类问题。 - **代码文件**：mc2/moe_ep_dispatch_epilogue/op_kernel/moe_ep_dispatch_epilogue_tiling.h - **起始行号**：41 - **中止行号**：51 - **代码片段**： cpp // 占位，勿删：这个字段曾经死在 metadataRankOffsetsOffset 前面，删掉会把后者前移 8 字节。 // tiling 结构体是 host tiling 与 kernel 共用的裸内存 ABI，偏移一变，两侧只要不是同一次构建， // kernel 就会把 metadataRankOffsetsOffset 读成 0，offsets 被写到 recvSrcMetadata + 0， // 随后又被 metadata 行覆盖，表现为 recv_rank_offsets 恒为 torch.empty 的 [0, 0, 0]。 // 保留占位即可让新旧 host/kernel 混用时字段偏移不变。 uint32_t commAlg = 0; uint64_t rankExpertHitCountOffsetReserved = 0; uint64_t metadataRankOffsetsOffset = 0; // byte offset of the aligned tail in packed metadata uint64_t localRecvIndexOffset = 0; // byte offset of [num_tokens, top_k] local recv_x reverse index uint64_t slotEndsOffset = 0; // compact slot list ends, capacity entries uint64_t slotRowIdsOffset = 0; // metadata row ids grouped by slot, capacity entries - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 规范违反 | +40% | 4 个 TilingData 结构体均在中间插入新字段，违反"新增字段必须在结构体最后添加" | | 上下文防御缺失 | +30% | 结构体注释明确记载混用 ABI 兼容保证（保留占位使偏移不变），本次插入破坏该保证且无任何版本隔离/偏移校验机制 | | PR 归属 | +20% | commAlg 插入在本次 diff 变更范围内 | | 数据流风险 | +15% | 混用构建下 metadataRankOffsetsOffset 等字段错读 8 字节偏移，接收侧 metadata 布局错乱 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在 | -20% | mc2/moe_ep_dispatch_epilogue_tiling.h 同一头文件被 host tiling 与 kernel 同时包含，同仓同版本构建时偏移必然一致 | 自信值 = Σ正向 + Σ负向 = 85% ≥ 70% → 判定违规 - **修复建议**：将 commAlg 字段移到各 TilingData Info 结构体末尾（最后一个字段之后）追加， 保持既有字段偏移不变；或复用已有的 reserved/占位字段空间。若确需中间插入， 应同步更新结构体注释并确认部署上不存在新旧 host/kernel 混用场景。 ## 疑似（LOW 置信度） ### [MC2-17] HCCL API 参数动态查阅验证 - **状态**：SUSPICIOUS | **置信度**：LOW - **问题描述**：本次 commit 大量使用新 HCCL/HCOMM 扩展 API（HcclChannelAcquireWithConfig、 HcclChannelConfigSetInt/SetStr、HcclEngineCtxDestroy、MakeMultiChannelHandle、 Hcomm::MakeBatchHandle/WriteNbi/WriteWithNotifyNbi/BatchCommit/Drain/GetHandleRef）， 本规则要求检视时必须通过 /ascendc-docs-search 动态查阅官方文档验证参数与生命周期。 本次检视环境中无本地 ASC_DEVKIT 文档，在线文档站点（hiascend.com）对脚本抓取返回 JS/Cookie 拦截页，无法完成权威文档比对。参数一致性只能通过与仓内既有 fullmesh 生产实现（moe_ep_dispatch.h/moe_ep_combine.h 同族调用模式）对照佐证，属于未经 动态查询确认的潜在风险，需人工在具备文档环境时复核。 - **代码文件**：mc2/common/torch_extension/csrc/moe_shared_jetty_context.cpp - **起始行号**：288 - **中止行号**：304 - **代码片段**： cpp std::vector<ChannelHandle> channels(channelDescs_.size()); HcclChannelConfig config = nullptr; CheckHccl(HcclChannelConfigCreateFunc(&config), "HcclChannelConfigCreate"); const char* operation = "HcclChannelConfigSetInt"; auto ret = HcclChannelConfigSetIntFunc(config, HCCL_CHANNEL_CONFIG_TYPE_IS_SHARED_QUEUE, 1); if (ret == HCCL_SUCCESS) { operation = "HcclChannelConfigSetStr"; ret = HcclChannelConfigSetStrFunc(config, HCCL_CHANNEL_CONFIG_TYPE_SHARED_QUEUE_TAG, queueTag.c_str()); } if (ret == HCCL_SUCCESS) { operation = "HcclChannelAcquireWithConfig"; ret = HcclChannelAcquireWithConfigFunc(comm_, COMM_ENGINE, channelDescs_.data(), static_cast<uint32_t>(channelDescs_.size()), config, channels.data()); } auto destroyRet = HcclChannelConfigDestroyFunc(config); TORCH_CHECK(ret == HCCL_SUCCESS, operation, " failed, ret=", ret, ", config cleanup ret=", destroyRet); - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 领域关联 | +10% | 代码命中 HCCL 通信 API 领域触发特征，规则要求动态查阅验证 | | PR 归属 | +20% | 全部新增 HCCL 调用在 diff 变更范围内 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在 | -20% | 所有 HCCL 函数指针经 InitHcclSharedJettyFunctions 全量判空加载，调用返回值全部 CheckHccl/TORCH_CHECK 校验 | | 上游校验 | -15% | Hcomm kernel 侧调用模式与仓内 fullmesh 生产实现（moe_ep_dispatch.h:1165-1210、moe_ep_combine.h:281-317）逐模式一致 | 自信值 = Σ正向 + Σ负向 = -5% ≥ 70% → 未达违规阈值 - **修复建议**：在具备 CANN 文档环境处复核 HcclChannelAcquireWithConfig/MakeMultiChannelHandle 等 新 API 的参数约束与生命周期语义（特别是 AcquireSharedChannels 返回的 ChannelHandle 是否需要显式释放），确认与仓内既有用法一致。 ## 代码风格 > 来自 cpp-style 检视，不走假设检验，违反即 FAIL。不并入上方统计表。 | 条例 | 严重级别 | 问题描述 | 代码位置（校对后行号） | 修复建议 | |------|---------|---------|----------------------|---------| | STYLE-3.1 文件头注释包含版权声明（年份正确） | 中 | 新增文件 moe_ep_combine_shared_jetty.h 的版权年份为 2025，而同一次 commit 新增的其余 7 个文件均为 2026（该文件首次进入仓库于本 commit 2026-10），疑为复制旧文件头注释时未改年份，与同批新文件不一致。 | mc2/moe_ep_combine/op_kernel/moe_ep_combine_shared_jetty.h:1-14 | 将版权年份修正为 2026，与同批新增文件保持一致。 | ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/5359 ## 测试 二级冒烟，线下测试 ## 文档更新 NA ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [x] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!13422 | 9 days ago | |
提升mc2算子ut覆盖率 Co-authored-by: mutex_lock<chenyifan66@h-partners.com> # message auto-generated for no-merge-commit merge: !14690 merge ut_cov into master 提升mc2算子ut覆盖率 Created-by: mutex_lock Commit-by: mutex_lock Merged-by: cann-robot Description: ## 描述 提升部分 mc2 算子 UT 行覆盖率（分支 ut_cov）：补齐 moe_ep_* 脚手架、增补 distribute/dispatch/combine 相关用例，并清理无效 arch22 quant tiling UT。 主要改动： 1. **新建 UT**：为 moe_ep_combine、moe_ep_combine_epilogue、moe_ep_dispatch、moe_ep_dispatch_epilogue 新增完整 tests/ut（op_api / op_host / arch35 tiling、CMake）。 2. **增补用例**：all_gather_matmul_v2（api + arch35 tiling）、moe_distribute_combine_v3（arch35 tiling）、moe_distribute_combine_setup（tiling）、moe_distribute_dispatch_setup / teardown（infershape）、moe_distribute_dispatch_v2（arch22/arch35 tiling）。 3. **清理**：删除 quant_all_reduce / quant_reduce_scatter 的 arch22 tiling UT。 ### 覆盖率提升算子列表 | 算子 | 变更前 LINE% | 变更后 LINE% | 变更前 STATUS | 变更后 STATUS | |------|-------------:|-------------:|:-------------:|:-------------:| | all_gather_matmul_v2 | 88.6% | 90.0% | BELOW | OK | | moe_distribute_combine_setup | 88.0% | 88.3% | BELOW | BELOW | | moe_distribute_combine_v3 | 84.4% | 90.0% | BELOW | OK | | moe_distribute_dispatch_setup | 80.5% | 91.9% | BELOW | OK | | moe_distribute_dispatch_teardown | 84.6% | 97.8% | BELOW | OK | | moe_distribute_dispatch_v2 | 88.8% | 91.3% | BELOW | OK | | moe_ep_combine | N/A | 93.3% | NO_DATA | OK | | moe_ep_combine_epilogue | N/A | 93.7% | NO_DATA | OK | | moe_ep_dispatch | N/A | 91.6% | NO_DATA | OK | | moe_ep_dispatch_epilogue | N/A | 92.6% | NO_DATA | OK | 说明：moe_distribute_combine_setup 略有抬升但仍未达 90%；quant_* 仅删无效 arch22 用例，行覆盖率相对基线无变化。 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/3647 ## 测试 - bash scripts/ci/ut_make.sh "$(pwd)"（本分支涉及算子 host 多 SoC + api）全绿 ## 文档更新 无 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [x] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!14690 | 17 days ago | |
fix(pre-commit): 全仓OAT合规整改——许可证/版权头存量修复与豁免策略对齐 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !13363 merge fix_3 into master fix(pre-commit): 全仓OAT合规整改——许可证/版权头存量修复与豁免策略对齐 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: 关联Issue https://gitcode.com/cann/ops-transformer/issues/5885 ## 描述 全仓 OAT 合规整改（ pre-commit run oat-check --all-files 从 200 条问题清零）： **1. OAT.xml 豁免策略对齐**（仅新增 6 行 filteritem，零删除）： - experimental/.*：孵化目录豁免 license/copyright/binary 三类检查（含 swiglu_gated_mlp 等第三方 Apache-2.0 双版权贡献代码，策略上不归管） - *.jpg：文档图片豁免二进制拦截（与已有 *.png 一致） - LICENSE：许可证正文本身，豁免许可证头检查 - Third_Party_Open_Source_Software_Notice：第三方声明文件，豁免版权头检查 **2. 文件头修复（167 个源文件）**： - 旧版许可证头（redistribute it and/or modify. 句式，2026-03 入库、04-03 OAT 上线前时间差遗留）→ 标准 CANN V2 头 - 变体错别字：Copyend (c)、You can not use、in in compliance、free software; 分号、CANN 1.0 许可证等 - 无头文件补标准头（如 golden.py、executor_aclnnMoeFusedTopk.py） - 版权年保留各文件原有年份；CRLF/混合行尾文件逐字节保持原行尾，diff 仅头部 **3. 历史遗留原因**：存量问题多经网页端合并（不触发本地钩子）或 OAT 上线前入库积累。 ## 验证 - pre-commit run oat-check --all-files：9 个批次全部 0 issue，Passed - git pc HEAD~1 + 显式 pre-commit run --files 复核收敛，第 2 笔为 clang-format/ruff/end-of-files 自动修复 - py/sh 语法、OAT.xml XML 合法性校验通过 基线 master：d9d81a50a See merge request: cann/ops-transformer!13363 | 1 month ago |