| Files | Last commit | Last update |
|---|---|---|
修复 ops-transformer 接口文档扫描问题（错别字/术语及MD格式，214处） Co-authored-by: liujing987913<liujing407@h-partners.com> # message auto-generated for no-merge-commit merge: !15468 merge master into master 修复 ops-transformer 接口文档扫描问题（错别字/术语及MD格式，214处） Created-by: liujing987913 Commit-by: liujing987913 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> - 背景：大模型扫描发现 ops-transformer 接口文档问题 214 处 - 修改分类： - 文本替换 145 处：多字/中文多字 101、同音字 25、术语拼写 19、形近字 1、字母顺序 1、代码括号 3 - MD 结构修复 69 处：MD012 连续空行 / MD022 标题 / MD031 代码围栏 / MD032 列表 / MD058 表格 / MD028 引用 / MD010 tab→空格 - 涉及文件：docs 目录下 146 个接口文档 md（含 torchapi 接口文档） - 验证：git diff 确认为纯文本替换 + 纯结构操作，无内容/代码误改；已人工复核 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> https://gitcode.com/cann/ops-transformer/issues/7211 <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 本次 PR 更新了 ops-transformer 接口文档 146 个 md 文件，修正错别字/多字/术语 145 处、MD 结构 69 处，详见 diff。 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!15468 | 6 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 | |
删除dispatch/combine_setup/teardown aclnn接口，graph文件 Co-authored-by: jiangxiuhan1<jiangxiuhan@huawei.com> # message auto-generated for no-merge-commit merge: !12568 merge issue into master 删除dispatch/combine_setup/teardown aclnn接口，graph文件 Created-by: jiangxiuhan1 Commit-by: jiangxiuhan1 Merged-by: cann-robot Description: ## 描述 moe_distribute_dispatch_setup,moe_distribute_dispatch_teardown,moe_distribute_combine_setup,moe_distribute_combine_teardown算子经评审日落，删除相关算子aclnn接口，graph文件。 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/6943 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [x] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!12568 | 13 days ago | |
[cleancode]整仓替换OP_LOGE_WITH_INVALID_ATTR、OP_LOGE_WITH_INVALID_ATTR_SIZE等废弃宏 Co-authored-by: mutex_lock<chenyifan66@h-partners.com> # message auto-generated for no-merge-commit merge: !15263 merge replace_obs_api into master [cleancode]整仓替换OP_LOGE_WITH_INVALID_ATTR、OP_LOGE_WITH_INVALID_ATTR_SIZE等废弃宏 Created-by: mutex_lock Commit-by: mutex_lock Merged-by: cann-robot Description: ## 描述 整仓替换 op_common/log/log.h 中已废弃的日志宏，迁移到文档推荐的新宏，避免后续日落删除导致编译失败。 ### 背景与原因 OP_LOGE_WITH_INVALID_ATTR / ATTR_SIZE / INPUT_FORMAT / INPUT_DTYPE 等接口已在 opbase 文档中标记废弃，并给出替代宏。仓内（含 mc2、moe、ffn、experimental）仍有大量调用，需统一切换。 ### 改动方法 仅做宏名替换，调用参数签名一致，不改校验逻辑： | 废弃宏 | 替代宏 | 约计次数 | |--------|--------|----------| | OP_LOGE_WITH_INVALID_ATTR | OP_LOGE_FOR_INVALID_VALUE | 230 | | OP_LOGE_WITH_INVALID_ATTR_SIZE | OP_LOGE_FOR_INVALID_LISTSIZE | 8 | | OP_LOGE_WITH_INVALID_INPUT_FORMAT | OP_LOGE_FOR_INVALID_FORMAT | 13 | | OP_LOGE_WITH_INVALID_INPUT_DTYPE | OP_LOGE_FOR_INVALID_DTYPE | 1 | 共修改 60 个文件，252 处；错误码/日志文案随新宏切换（如 ATTR→VALUE：EZ0002→EZ0024），属预期行为。 ### 涉及范围 - mc2/、moe/、ffn/、experimental/ 等 Host / OPAPI 侧调用点 - 均依赖同一 log/log.h（third_party/opbase/include/op_common/log/log.h） ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/7092 ## 测试 - [x] 相关算子 Host / OPAPI UT（按需抽测） - [x] 二级冒烟 / 算子泛化（如有流水要求再补） - [x] 静态核对：旧宏在业务源码中无残留；新宏均在 log.h 中有定义；参数个数未变 ## 文档更新 无业务文档更新；依据 third_party/opbase 既有废弃说明完成迁移。 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [x] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!15263 | 5 days ago | |
feat: 960dt 非量化场景适配APACE新模板 Co-authored-by: dengyidan<dengyidan@huawei.com> # message auto-generated for no-merge-commit merge: !14503 merge mmrs_A5_apace into master feat: 960dt 非量化场景适配APACE新模板 Created-by: dyd-dmy Commit-by: dengyidan Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 为 MatmulReduceScatterV2 的 960dt 非量化场景接入 APACE 模板，复用已有 MX 量化通路的融合调度，实现非量化与 MX 量化共用计算、同步及通信流程。 主要修改如下： 1. 新增非量化 APACE 计算实现：基于 Blaze Basic BlockMmad 支持 FP16、BF16输入数据类型，支持 x2 转置和非转置、以及与输出同类型的 bias的输入组合。 2. 统一融合调度：非量化与 MX 量化共用头块组、尾块组调度和 HCCL ReduceScatter 流水，计算层分别保留对应的 Matmul 实现。APACE 使用 AIC-only 核类型。 3. 复用现有 Tiling：非量化沿用 MatmulV3 Tiling 和原有 TilingData，按各 rank 当前通信块合成的逻辑 M 生成计算切分；复用通信块对齐调整，减少跨 rank 行段的拆块。 4. 完善边界处理：Kernel 对跨 rank 的非连续输入分段计算；Host 校验分块覆盖范围、尾轮调度、片上缓冲区容量、单次通信量及包含尾块的总通信次数。 5. 保持平台与接口兼容：对外接口不变，APACE 仅在 960dt 满足条件的非量化和 MX 场景启用，当前使用 AICPU 通信；950、PerTensor、PerBlock及其他非 APACE 场景沿用原有通路。 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> https://gitcode.com/cann/ops-transformer/issues/6732 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 1. 本地测试已通过。 2. 冒烟测试已通过。 3. 补充并调整 Tiling UT，覆盖 960dt 非量化 APACE 分支选择、小/大 shape、不同核数，以及包含尾块的通信次数边界。 4. 增加 950 非量化和量化原有通路的回归用例，覆盖 AICPU、CCU、PeerOnly及通信量边界。 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 不涉及 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!14503 | 5 days ago | |
feat: mc2 算子 golden 迁移到 transformer 仓 Co-authored-by: qzzzy1<qiziyu2@huawei.com> # message auto-generated for no-merge-commit merge: !10590 merge master into master feat: mc2 算子 golden 迁移到 transformer 仓 Created-by: qzzzy1 Commit-by: qzzzy1 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!10590 | 2 months 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 | |
feat: allto_all_matmul&matmul_allto_all 960dt支持CCU通信 Co-authored-by: tongzy1242<tongzeyun@huawei.com> # message auto-generated for no-merge-commit merge: !15055 merge feat/alltoallmatmul-960dt-ccu-v2 into master feat: allto_all_matmul&matmul_allto_all 960dt支持CCU通信 Created-by: tongzy1242 Commit-by: tongzy1242 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 960dt芯片支持mma2a&a2amm算子ccu通信引擎 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> [#7146](https://gitcode.com/cann/ops-transformer/issues/7146) ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 二级冒烟 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!15055 | 9 days ago | |
change alg table for comm select. Co-authored-by: qq_43844249<fanglin17@huawei.com> # message auto-generated for no-merge-commit merge: !13287 merge change-alg into master change alg table for comm select. Created-by: qq_43844249 Commit-by: qq_43844249 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> # 代码检视报告 # 代码检视报告 **项目名称**：ops-transformer（分支 change-alg） **检视模块**：commit 8c367dd76 "add alg table for comm select."（24 个文件，+1276/-93） **检视规则**：C++ 安全编码规范（cpp-secure.md，47 条） **检视人**：CANNBot（Turing Team 规则引擎） **检视日期**：2026-10-30 > 提交范围说明：MC2 通信算法表与选择器（AllGather/AllToAll/ReduceScatter × Matmul 融合算子）、拓扑装配接口重构、group 属性判空加固、UT mocker 适配；另含 tests/test_config.yaml 关闭 grouped_mat_mul_all_reduce 的 UT（CI 配置项，非 C++ 代码，不在本规则检视范围）。 --- ## 🔍 检视概览 | 统计项 | 数值 | | ---- | ---- | | 发现问题总数 | 1 个 | | 已修复问题 | 1 个（ISSUE-001，MEDIUM） | | 开放问题 | 0 个 | | 误报排除数量 | 4 个 | **核心结论**：算法表/选择器/拓扑装配框架整体防御良好（溢出钳位、null 检查、位宽防越界、兜底回退齐备）。唯一确认的 MEDIUM 级问题（group 属性指针未判空）已修复并入本提交并复验通过，无开放问题。 --- ## ✅ 已修复问题 ### 问题ID：ISSUE-001 | 严重级别：MEDIUM（中等）| 状态：已修复并复验 #### 🔬 假设检验过程 **代码段**：SetMc2Hcomm() 中 group 属性获取与新调用链 **假设**：H0: 该代码段是安全的 | 证据序号 | 证据类型 | 规范ID | 证据描述 | 分值增量 | 累计自信值 | |---------|---------|--------|---------|---------|-----------| | 1 | 规范违反 | 10.1 | group 为 GetAttrPointer<char> 返回的裸指针，未判空即绑定到 const std::string& 形参（隐式 std::string(nullptr) 构造，UB） | +40% | 40% | | 2 | 上下文防御缺失 | 11.1 / 4.1 | 函数作用域内无判空防御；OP_LOGI(..., "group=%s", group) 同样无保护 | +30% | 70% | **结论**：自信值 **70%** > 60%，**推翻原假设 H0**，该代码段存在风险。 **关联红线条款**：cpp-secure 10.1（禁止从空指针创建 std::string，高）、11.1（LOG API 禁止传入空指针，高）、4.1（外部输入合法性校验，高） **代码路径**（修复后）： - mc2/matmul_reduce_scatter_v2/op_host/op_tiling/arch35/matmul_reduce_scatter_v2_tiling.cpp:116-117 - mc2/matmul_reduce_scatter_v2/op_host/op_tiling/arch35/quant_bmm_reduce_scatter_tiling.cpp:595-596 #### 修复内容（已并入提交） cpp auto group = context_->GetAttrs()->GetAttrPointer<char>(index++); OP_TILING_CHECK(group == nullptr || std::strlen(group) == 0, OP_LOGE_WITH_INVALID_INPUT(opName_, "group"), return ge::GRAPH_FAILED); #### 修复复验结论 - 宏用法：三参 OP_TILING_CHECK(cond, log, expr) 与 mc2/common/utils/mc2_log.h:109 一致；OP_LOGE_WITH_INVALID_INPUT 与两文件既有用法一致 - 校验位置：位于 group 获取之后、全部下游使用点（Mc2CcTilingConfig 构造、SelectReduceScatterAlgoName 的 std::string 绑定、OP_LOGI %s）之前，提前返回无副作用 - 依赖完备：<cstring> 已包含；return ge::GRAPH_FAILED 匹配返回类型 - 格式合规：行长 110 ≤ .clang-format ColumnLimit: 120，无 Tab/行尾空白，无 BOM - 范式一致：与 arch22 路径 matmul_reduce_scatter_v2_aiv_mode_tiling.cpp:500 既有防御写法一致 --- ## ✅ 误报排除记录（假设检验未通过项） | 排除项 | 排除依据 | | ---- | ---- | | args_.kValue / EVEN_ALIGN 除零（all_gather_quant_bmm_tiling.cpp:610） | EVEN_ALIGN 为文件内 constexpr uint64_t = 2 编译期常量，规则 2.3 常量排除 | | inferredInfo_.tileM 传入 uint32_t 形参缩窄 | 实际类型即 uint32_t（matmul_allto_all_util_tiling.h:141），完全匹配 | | 新增 OP_LOGI/LOGD 格式串类型与数量不匹配 | 逐条核对：%llu↔uint64_t、%u↔uint32_t、%x↔uint32_t、topoFlags 显式 cast ull，占位符与参数数量一致 | | dlerror() 传入 %s 可能为 NULL（mc2_hcom_topo_info.cpp:125） | dlopen 失败分支内，POSIX 保证返回非空错误串 | --- ## 🌟 亮点（合规正面样例） - CalcCommDataBytes（mc2_comm_algo_selector.cpp:17-30）：三因子乘法逐步溢出检查并钳位 UINT64_MAX，符合 2.2 - 位图区宽防御：static_assert 锁枚举值域 + 运行时越界告警截断（mc2_hcom_topo_info.h:37-42、selector CalcTopoFlags），符合 3.3 - 选择器硬过滤 + 兜底表项回退设计，任一装配失败均安全退化为默认算法，符合 4.1 失败安全原则 - 单例不 dlclose 的理由、L0 层号不可假设字面值等约束均有注释留痕，可审计性良好 --- ## 报告生成时间 2026-10-30 ## 报告状态 已完成检视：ISSUE-001 已修复并复验通过，无开放问题，本提交可合入。 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [x] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!13287 | 16 days ago |