| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
AlltoAllMatmulV2 comm_mode urma场景改成aiv_urma & AllGatherMatmulV3 UT 问题修复 Co-authored-by: MeiWenxuan<meiwenxuan@huawei.com> # message auto-generated for no-merge-commit merge: !11159 merge master into master AlltoAllMatmulV2 comm_mode urma场景改成aiv_urma & AllGatherMatmulV3 UT 问题修复 Created-by: MeiWenxuan Commit-by: MeiWenxuan Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> https://gitcode.com/cann/ops-transformer/issues/4713 https://gitcode.com/cann/ops-transformer/issues/4711 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11159 | 6 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
fix codecheck-warning Co-authored-by: qq_43844249<fanglin17@huawei.com> # message auto-generated for no-merge-commit merge: !11089 merge fix-warning into master fix codecheck-warning Created-by: qq_43844249 Commit-by: qq_43844249 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> # allto_all_matmul 算子代码检视报告 | 项目 | 内容 | | --- | --- | | 检视对象 | mc2/allto_all_matmul 算子（op_api、op_graph） | | 检视基线 | commit b283e2c5d（fix codecheck-warning） | | 参照标准 | 华为 C/C++ 编码规范（G.EXP.08/15/16/21、G.FUN.03）及编译告警 | | 上轮问题数 | 18 条 | | 本轮问题数 | **11 条**（7 条已修复闭环，11 条按评审决策保留原实现） | | 结论 | 无高风险问题；遗留 11 条均为接口/工具链结构性限制，建议走豁免流程闭环 | --- ## 一、问题清单汇总 | 序号 | 等级 | 位置 | 问题摘要 | 处置 | | --- | --- | --- | --- | --- | --- | | 1 | 一般 | allto_all_matmul_base.cpp:284 | reinterpret_cast 将 uint8_t 值转为指针 | 豁免 | | 2 | 一般 | allto_all_matmul_base.cpp:354 | reinterpret_cast 指针转 uintptr_t 取值 | 豁免 | | 3 | 一般 | allto_all_matmul_base.cpp:252 | const_cast 去除 group 的 const 属性 | 豁免 | | 4 | 一般 | allto_all_matmul_base.cpp:262 | const_cast 去除 commMode 的 const 属性 | 豁免 | | 5 | 一般 | allto_all_quant_matmul_base.cpp:546 | reinterpret_cast 将 uint8_t 值转为指针 | 豁免 | | 6 | 一般 | allto_all_quant_matmul_base.cpp:620 | reinterpret_cast 指针转 uintptr_t 取值 | 豁免 | | 7 | 一般 | allto_all_quant_matmul_base.cpp:518 | const_cast 去除 group 的 const 属性 | 豁免 | | 8 | 一般 | allto_all_quant_matmul_base.cpp:519 | const_cast 去除 commMode 的 const 属性 | 豁免 | | 9 | 一般 | fallback_allto_all_matmul.cpp:283 | EXEC_OPAPI_CMD 宏内部 reinterpret_cast（dlsym 转函数指针） | 豁免 | | 10 | 一般 | fallback_allto_all_matmul.cpp:293 | 同上（第二个调用点） | 豁免 | | 11 | 一般 | fallback_allto_all_matmul.cpp:282~301 | 宏内 lambda 返回 int（-1）赋值给 ge::graphStatus 触发截断告警 | 豁免 | --- ## 二、遗留问题详细分析 ### 2.1 G.EXP.15 禁止使用 reinterpret_cast（6 处） **类别一：通信模式 handle 传递（序号 1、2、5、6）** cpp // 一段式接口（写），如 allto_all_matmul_base.cpp:284 void *args = reinterpret_cast<void *>(static_cast<uint8_t>(commModeEnum)); NnopbaseSetUserHandle(*executor, args); // 二段式接口（读），如 allto_all_matmul_base.cpp:354 void *arg = NnopbaseGetUserHandle(executor); uintptr_t handleVal = reinterpret_cast<uintptr_t>(arg); uint8_t commMode = static_cast<uint8_t>(handleVal); - **根因**：NnopbaseSetUserHandle(void *executor, void *handle) / NnopbaseGetUserHandle 接口仅支持指针类型，两段式接口间需要传递通信模式枚举值（0~255），借用指针值本身承载小整数是 nnopbase handle 机制下的既定用法。 - **影响分析**：写入与读取对称（低字节承载、同为小端平台），值域 0~255 远小于指针空间，Nnopbase 不解引用该 handle，无越界与崩溃风险。 - **处置建议**：维持原实现，申请豁免。备选方案（如后续政策允许）：两侧改用 memcpy_s 按字节拷贝，可消除该告警且语义不变。 **类别二：EXEC_OPAPI_CMD 宏内 dlsym 地址转换（序号 9、10，宏体位于 common/include/fallback/fallback.h:404/487/514）** - **根因**：GetOpApiFuncAddr 通过 dlsym 返回 void*，C++ 标准不允许 static_cast 完成 void* 到函数指针的转换，reinterpret_cast 是 dlsym 场景的标准惯用法，且告警归属到使用方 fallback_allto_all_matmul.cpp。 - **影响分析**：动态符号地址转换的正确性由 dlsym 保证，无实际风险。 - **处置建议**：维持原实现，申请豁免。 ### 2.2 G.EXP.16 禁止使用 const_cast（4 处） cpp char *str_group = const_cast<char *>(group); char *str_commMode = const_cast<char *>(commMode); - **根因**：L0 Inner 接口 aclnnInnerAlltoAllMatmulGetWorkspaceSize(..., char *group, ..., char *commMode, ...) 的签名由工具链根据算子原型（string 类型属性）自动生成，op 仓无法修改为 const char *。 - **影响分析**：Inner 接口内部不修改字符串内容，且可能跨两段式接口持有该指针；若复制到栈缓冲区规避 const_cast，会造成悬垂指针，引入真实缺陷。 - **旁证**：全 mc2 目录同类写法共 99 处（如 matmul_allto_all、all_gather_matmul 等），为统一模式。 - **处置建议**：维持原实现，申请豁免。根治需工具链将 Inner 接口 string 属性参数签名改为 const char *。 ### 2.3 G.EXP.21 确保无符号类型计算不会溢出（1 处） - **位置**：EXEC_OPAPI_CMD 宏展开（fallback.h:509~524），告警归属 fallback_allto_all_matmul.cpp:282~301。 - **根因**：宏内 acl_call lambda 返回类型为 int，失败分支 return GRAPH_FAILED;（值 -1），随后 ret = acl_call(); 将 int 赋给 ge::graphStatus（底层为无符号类型），触发 int→unsigned 截断告警。 - **影响分析**：ret 实际取值仅 0（成功）或 -1（失败），回绕为 0xFFFFFFFF 后与失败语义一致，调用侧仅做 ret != ge::GRAPH_SUCCESS 判断，无溢出危害。 - **处置建议**：维持原实现，申请豁免。备选方案（如后续政策允许）：lambda 返回类型改为 ge::graphStatus 即可消除。 --- ## 三、已闭环问题（7 条，commit b283e2c5d） | 序号 | 规范条款 | 原位置 | 修复方式 | | --- | --- | --- | --- | | 1 | G.FUN.03 禁止函数有未使用的参数 | allto_all_quant_matmul_base.cpp:69 | CheckNotNull 删除未使用参数 biasOptional，同步调用点（现 459 行） | | 2 | G.FUN.03 禁止函数有未使用的参数 | allto_all_quant_matmul_base.cpp:187 | CheckScaleShape 删除未使用参数 x1，同步调用点（现 467 行） | | 3 | G.FUN.03 禁止函数有未使用的参数 | allto_all_quant_matmul_base.cpp | CheckAllDtypesValid 删除未使用参数 biasOptional，同步调用点（现 472 行） | | 4 | G.EXP.08 确保对象在使用之前已被初始化 | allto_all_quant_matmul_base.cpp:548 | 一段式接口写 handle 前补充 executor != nullptr 判空 | | 5 | 编译告警 -Wcomment | aclnn_allto_all_quant_matmul.h:2 | 删除文件头重复的 /** 行，消除嵌套注释 | | 6 | 编译告警 -Wunused-parameter | allto_all_quant_matmul_base.cpp:69 | 随序号 1 一并消除 | | 7 | 编译告警 -Wunused-parameter | allto_all_quant_matmul_base.cpp:187 | 随序号 2 一并消除 | 补充说明：非量化接口 allto_all_matmul_base.cpp 中同类判空（283、352 行）已同步加固；fallback.h 中 GET_OP_API_FUNC 宏（79 行）及 fallback_2stages.h 存在同类 reinterpret_cast，但未纳入本次扫描范围，暂不处理。 --- ## 四、风险评估与结论 1. 本轮 11 条遗留问题均为**结构性限制**（工具链生成接口签名、dlsym 标准用法、nnopbase handle 机制），修改收益低、引入缺陷风险高，维持原实现并走豁免流程是合理决策。 2. 无内存安全、并发、精度类高风险问题。 3. 建议：将本报告问题清单与豁免理由归档至扫描豁免清单，避免后续扫描重复提单；若工具链后续支持 const char * Inner 签名或 handle 值传递接口，可再评估根治方案。 --- *报告生成：CANNBot · 基线：b283e2c5d · 生成日期：2026-09-05* ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11089 | 16 小时前 | |
fix(allto_all_matmul_v2): 修复 group_sizes schema 非法默认值导致 import 失败 Co-authored-by: MeiWenxuan<meiwenxuan@huawei.com> # message auto-generated for no-merge-commit merge: !11203 merge master into master fix(allto_all_matmul_v2): 修复 group_sizes schema 非法默认值导致 import 失败 Created-by: MeiWenxuan Commit-by: MeiWenxuan Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> https://gitcode.com/cann/ops-transformer/issues/4713 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11203 | 5 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Co-authored-by: qzzzy1<qiziyu2@huawei.com> # message auto-generated for no-merge-commit merge: !11210 merge master into master MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Created-by: qzzzy1 Commit-by: qzzzy1 Merged-by: cann-robot Description: ## 描述 补充MoeDistributeDispatchSetup/Teardown RT2.0 infershape与inferdatatype ## 关联的Issue 4932 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [x] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11210 | 10 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
训练engram表直接映射 Co-authored-by: luozhonglin222<luozhonglin1@huawei.com> # message auto-generated for no-merge-commit merge: !11226 merge engram_new into master 训练engram表直接映射 Created-by: luozhonglin222 Commit-by: luozhonglin222 Merged-by: cann-robot Description: ## 描述 1.训练engram表直接映射 2.反向图模式修改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 ElasticBuffer.md ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： # PR #11226 代码检视报告 ## 检视概览 - **PR**: https://gitcode.com/cann/ops-transformer/pull/11226 - **组件**: ElasticBuffer（mc2/common/torch_extension 公共 torch_extension 组件） - **变更规模**: 3 个文件，+225/-204（3 个提交：训练engram表直接映射 / 反向图模式修改 / 锁页内存限制） - **代码侧别**: Host 侧（C++/ACL/HCCL + Python），无 Kernel 侧代码 - **检视文档**: cpp-secure.md、cpp-general.md、mc2-specific.md、python-secure.md、ascendc-topk.md - **总条例数**: 19 - **检视时间**: 2026-09-05 - **执行方式**: 子 Agent 不可用，全程串行执行（主流程完成概要/路由/逐条检视/行号校对） ## 检视统计 | 状态 | 条例数 | 占比 | |------|------|------| | PASS | 15 | 79% | | FAIL（发现问题） | 2 | 10% | | SUSPICIOUS（需关注） | 2 | 10% | ## 变更摘要 1. **训练模式零拷贝**（C++/Python）： with_grad=True 时 engram_write 不再拷贝，直接将调用方锁页内存经 aclrtHostRegisterV2(ACL_HOST_REG_MAPPED) 注册映射为 Engram storage 并注册到 HCCL 通信域；注册失败降级告警；Destroy 按注册归属条件化释放；Python 持 _engram_storage_ref 保证生命周期。 2. **反向 ctx 清零**（C++）：EngramFetchTrain 5 个 ctx 张量 at::empty → at::zeros，修复 numTokens==0 时反向 kernel 读垃圾计数死等的问题。 3. **图模式友好校验**（Python）：校验抽为 _check_engram_fetch_grad（if/raise 替代 torch._check），新增 hidden 128 对齐校验。 4. **死代码清理**：删除旧版成员 EngramFetchGrad、GetHostBufPtr、IsWithGrad 及 pybind 绑定（已 grep 验证无残留引用）。 5. **文档同步**：ElasticBuffer.md 更新训练模式零拷贝语义与锁页内存要求。 ## 发现问题（HIGH 置信度） 无 HIGH 置信度发现。 ## 需关注（MED 置信度） ### [cpp-secure 4.1] 外部输入合法性校验——重复 engram_write 仅校验地址，未校验大小一致性 - **问题描述**：训练模式下重复调用 engram_write 时，仅以指针相等判断与首次注册的一致性，未校验 storage.nbytes() 与首次注册窗口大小（externalBytes）一致。若调用方传入**同基址但更大**的 tensor（如先写 big[:10] 注册 10 行窗口，再写 big 共 20 行），C++ 地址校验通过、engramNumEntries_ 更新为 20，但 HCCL 通信域注册窗口仍为首次的 10 行字节数 → 远端 rank 按新 numEntries 通过 RDMA 读取越过注册窗口的内存 → 越界读取/未定义行为。 - **代码片段**（mc2/common/torch_extension/csrc/elastic_buffer.cpp 行 1365-1378）： cpp if (withGrad_) { TORCH_CHECK(storage.nbytes() > 0, "engram_write in with_grad mode requires non-empty storage, got ", storage.nbytes(), " bytes"); if (engramContextInitialized_) { TORCH_CHECK(engramHostBufPtr_ == storage.data_ptr(), "engram_write: engram storage is already initialized from a different address, expected " "ptr=", engramHostBufPtr_, ", got ptr=", storage.data_ptr()); } else { externalHostPtr = storage.data_ptr(); externalBytes = static_cast<int64_t>(storage.nbytes()); } } EnsureEngramContext(externalHostPtr, externalBytes); 配套风险行（行 1394）：engramNumEntries_ = storage.size(0);（每次写入都更新，但注册窗口仅首次生效）。 - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 规范违反 | +40% | cpp-secure 4.1：外部输入（storage 尺寸）作为内存注册/通信读取长度的依据，未做与已注册窗口的一致性校验 | | 上下文防御缺失 | +30% | 作用域内仅存在地址相等校验（cpp:1369），无 nbytes 比较；Python _engram_storage_ref 仅防 GC，不约束尺寸 | | PR 归属 | +20% | 地址校验分支与 externalBytes 采集均为本次 diff 新增（diff 行 211-218） | | 数据流风险 | +15% | externalBytes 仅首次采集，numEntries 每次更新，二者可解耦 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在（部分覆盖） | -10% | 文档约束"重复调用须传入同一 storage"，但文档语义为同一对象，未覆盖"同基址不同大小视图"场景，不构成有效防御 | 自信值 = 40+30+20+15-10 = **95% ≥ 70% → 判定违规**（考虑触发需"同基址扩容写入"这一非常规但完全合法的使用序列，落地严重级别为 MED） - **修复建议**：在 engramContextInitialized_ 分支同时校验 storage.nbytes() == 首次注册的 externalBytes（可新增成员 engramExternalBytes_ 记录），不一致时 TORCH_CHECK 报错；或在重复写入时禁止 numEntries × rowBytes 超出已注册窗口。 ### [cpp-secure 5.2] 资源泄露——外部注册成功后的异常路径无补偿释放 - **问题描述**：外部锁页内存 aclrtHostRegisterV2 成功（resources.externalRegistered = true）后，若同函数内后续 aclrtHostGetDevicePointer（cpp:492）或 HcclCommMemRegFunc（cpp:501）失败抛异常，externalRegistered 标志随栈销毁丢失，EnsureEngramContext 不会完成赋值 engramExternalRegisteredByUs_，调用方内存上的注册在进程生命周期内**永不解除**。对比同文件 MoeContextBuilder 明确实现了异常路径 RAII 回滚（cpp:762-766、822-834），EngramContextBuilder 新增的外部注册路径缺少同等保护。实际后果较轻（重试时 register 失败 → fallback 路径可用），但违反资源申请/释放匹配原则。 - **代码片段**（mc2/common/torch_extension/csrc/elastic_buffer.cpp 行 479-503）： cpp } else { // Map caller-owned storage memory directly (zero-copy): plain memory is supported aclError ar = aclrtHostRegisterV2(externalHostPtr, static_cast<uint64_t>(externalBytes), ACL_HOST_REG_MAPPED); resources.externalRegistered = (ar == ACL_SUCCESS); if (ar != ACL_SUCCESS) { ASCEND_LOGW("aclrtHostRegisterV2(%lld B) failed, ret=%d, fallback to existing registration", externalBytes, static_cast<int>(ar)); } } void *hostPtr = (externalHostPtr != nullptr) ? externalHostPtr : guard.hostPtr; void *devPtr = nullptr; aclError ar = aclrtHostGetDevicePointer(hostPtr, &devPtr, 0); TORCH_CHECK(ar == ACL_SUCCESS, "aclrtHostGetDevicePointer failed, ret=", ar, ", storage host memory cannot be mapped to device"); CommMem mem; mem.type = COMM_MEM_TYPE_DEVICE; mem.addr = devPtr; mem.size = static_cast<uint64_t>((externalHostPtr != nullptr) ? externalBytes : numCpuBytes); auto hcclRet = HcclCommMemRegFunc(commHandle, memBufferTag.c_str(), &mem, &resources.memHandle); TORCH_CHECK(hcclRet == HCCL_SUCCESS, "HcclCommMemReg(tag='", memBufferTag, "', size=", mem.size, ") failed, ret=", hcclRet); - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 规范违反 | +40% | cpp-secure 5.2：注册成功后两条 TORCH_CHECK 异常路径（cpp:492、cpp:501）无补偿 unregister | | 上下文防御缺失 | +30% | EngramContextBuilder 无 RAII/回滚；对照组 MoeContextBuilder 有（cpp:762-766 注释明确"防泄露"） | | PR 归属 | +20% | 外部注册分支为本次 diff 新增 | | 调用链风险 | +15% | HcclCommMemRegFunc 为网络类注册操作，存在窗口冲突/资源不足等现实失败可能 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在（间接） | -20% | 后续重试时 register 必然失败 → fallback 告警路径使功能可继续，泄漏后果被弱化为一次性注册残留 | 自信值 = 40+30+20+15-20 = **85% ≥ 70% → 判定违规**（泄漏量有限、有 fallback 兜底，落地严重级别 MED） - **修复建议**：将外部注册纳入异常安全保护——例如在 AllocateAndRegisterBuffer 内部 catch 后补偿 aclrtHostUnregister(externalHostPtr) 再 re-throw；或复用 HostBufferGuard 模式，为外部内存增加"仅 unregister 不 free"的 guard 变体。 ### [MC2-19] AlltoAllV 跨 rank 参数一致性——zeros 修改未论证跨 rank 场景 - **问题描述**：EngramFetchTrain 将 5 个 ctx 张量由 at::empty 改为 at::zeros，注释充分论证了**单 rank** 维度（numTokens==0 → 前向 kernel 早退 EngramFetchTrainArch35::Process 已验证存在 → 反向 kernel 无条件启动读垃圾计数 → 清零后走合法快速路径）。但未论证**跨 rank** 一致性：若部分 rank numTokens==0（ctx 全零、反向"send/recv 全跳过"）而其他 rank numTokens>0 且曾从零 token rank 的表拉取过数据（反向需向其发送梯度），反向交换的 send/recv 计数与 notify 协议在这些 rank 间是否仍然匹配，注释与文档均未说明。若协议要求两侧计数配对，将出现一侧跳过一侧等待的挂死或数据丢失。 - **代码片段**（mc2/common/torch_extension/csrc/elastic_buffer.cpp 行 1449-1458）： cpp // numTokens==0 时 forward kernel 直接早退（EngramFetchTrainArch35::Process），ctx 五个 // tensor 不会被 kernel 写入；而 EngramFetchGrad 侧无条件启动，若此处保持 at::empty， // grad 接收核将按垃圾 recvCounts 死等对端 notify 直至看门狗超时。 // 清零保证"零 token ⇒ 全零计数"是 kernel 可处理的合法一致输入（send/recv 全跳过、 // numRecv==0 走 WriteNumUniqueZero 快速路径） at::Tensor perm = at::zeros({numTokens}, intOpts); at::Tensor sendCounts = at::zeros({rankSize * SEND_COUNTS_ALIGN_FACTOR}, intOpts); // 32b对齐 at::Tensor recvCounts = at::zeros({rankSize}, intOpts); at::Tensor recvLocalEntry = at::zeros({maxR}, intOpts); at::Tensor numRecv = at::zeros({1}, intOpts); - **假设检验证据**： 正向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | PR 归属 | +20% | zeros 修改为本次 diff 新增 | | 数据流风险 | +15% | 各 rank ctx 独立产生，"部分 rank 全零"输入组合的跨 rank 匹配性未在注释/文档/UT 中论证 | | 上下文防御缺失 | +30% | 注释仅论证单 rank 合法性；未找到覆盖"混合 numTokens 场景"的反向 a2a 一致性证据 | | 领域关联 | +10% | MC2-19 红线：sendCounts/recvCounts 跨 rank 参数一致性 | 负向证据： | 证据类型 | 分值 | 证据描述 | |---------|------|---------| | 防御存在（部分） | -20% | kernel 侧存在 WriteNumUniqueZero（engram_fetch_grad_unique.h:225）等零计数快速路径，说明 kernel 对零输入有显式处理设计 | 自信值 = 20+15+30+10-20 = **55%**，跨 rank 协议细节无法从本地代码完全确认，按保守原则提请关注（未达 FAIL 线） - **修复建议**：请作者确认/补充说明：当通信域内部分 rank numTokens==0 而其他 rank >0 且其前向曾从零 token rank 的表拉取数据时，反向交换的 send/recv 计数与 notify 协议如何保持配对一致；建议补充对应 UT（混合 numTokens 场景）或在注释/文档中说明协议不依赖对端计数配对的依据。 See merge request: cann/ops-transformer!11226 | 11 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
engram推理修复sq队列溢出 Co-authored-by: wuchenhao<wuchenhao6@huawei.com> # message auto-generated for no-merge-commit merge: !11382 merge engram-ubg-1ch-v2 into master engram推理修复sq队列溢出 Created-by: wuchenhao123 Commit-by: wuchenhao Merged-by: cann-robot Description: ## 描述 修复urma batch接口使用sq队列溢出，记录任务cnt，在达到临界值调用drain清空队列 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/5023 ## 测试 本地验证 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [X] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： # 代码检视报告 **项目名称**：ops-transformer PR #11382 engram推理修复sq队列溢出 **检视模块**： - mc2/engram_fetch/op_kernel/arch35/engram_fetch_arch35.h - mc2/engram_fetch/op_kernel/engram_fetch_utils.h **检视人**：Turing Team **检视日期**：2026-09-07 ## 检视范围 本次检视针对 PR #11382 的变更内容，涉及 engram_fetch 算子 arch35 Kernel 侧的 SQ 队列溢出修复。 变更内容：URMA WQE 配置调整、新增 sqReadCount_ 成员变量追踪 SQ 深度、mid-stream Drain 机制、 通道切换时 sqReadCount_ 重置、FlushPreparedReads 重构。 ## 检视依据 - C++ 安全编码规范（cpp-secure.md） - C++ 通用编码规范（cpp-general.md） - Ascend C 高性能编程规范（ascendc-perf.md） --- ## 检视概览 | 统计项 | 数值 | | ---- | ---- | | 发现问题总数 | 3 个 | | 严重级（CRITICAL）问题 | 0 个 | | 中等级（MEDIUM）问题 | 1 个 | | 轻微级（LOW）问题 | 2 个 | | 误报数量 | 0 个 | **核心结论**：SQ 队列溢出修复逻辑整体正确，mid-stream Drain 机制和通道切换 sqReadCount_ 重置逻辑 符合预期。存在 1 处中等级防御性编码缺失（FlushPreparedReads 移除了空调用保护），2 处轻微级存疑问题 需评估。 --- ## 问题详情及修改建议 ### 问题ID：ISSUE-001 | 严重级别：MEDIUM（中等） #### 假设检验过程 **代码段**：FlushPreparedReads() 函数 **假设**：H0: 该代码段是安全的 | 证据序号 | 证据类型 | 规范ID | 证据描述 | 分值增量 | 累计自信值 | |---------|---------|--------|---------|---------|-----------| | 1 | 上下文防御缺失 | cpp-secure 1.2 | 移除了 if (preparedReadCount_ == 0U) { return; } 空调用保护，若未来新增调用点未做 guard，BatchCommit 将操作 stale handle，可能导致未定义行为 | +30% | 30% | | 2 | 函数调用链风险 | cpp-secure 1.2 | 同仓参考实现 moe_ep_combine.h:560 保留了此保护，且 FlushPreparedWrites 的 keepHandle 机制更完善，本 PR 反向移除保护属于防御性退化 | +25% | 55% | | 3 | 上下文防御缺失 | cpp-general 1.3 | 同时移除了 activeBatchHandle_ = {} 和 activeBatchChannel_ = 0 重置，FlushPreparedReads 后 activeBatchHandle_ 保留 stale 值 | +15% | 70% | **结论**：自信值 **70%** > 60%，**推翻原假设H0**，该代码段存在风险。 --- **关联规范条款**：cpp-secure 1.2（保证内存安全）、cpp-general 1.3（删除无效冗余代码） **代码路径**：mc2/engram_fetch/op_kernel/arch35/engram_fetch_arch35.h:358-363 **问题类型**：防御性编码缺失 / stale handle 风险 **问题描述**： FlushPreparedReads 移除了空调用保护 if (preparedReadCount_ == 0U) { return; }，同时移除了 activeBatchHandle_ = {} 和 activeBatchChannel_ = 0 的重置逻辑。 当前所有调用点的 guard 分析： 1. PrepareRead:344 — if (preparedReadCount_ == ENGRAM_BATCH_CAPACITY) → count=128 > 0，安全 2. RemoteFetchRank:406 — 在 if (needDrain) 块内，needDrain 要求 sqReadCount_+1 >= 32767， 至少执行过一次 PrepareRead，count >= 1，安全 3. RemoteFetchRank:412 — if (preparedReadCount_ > 0U) 显式 guard，安全 当前调用点均安全，但移除保护后： - 若未来新增调用点未做 guard，BatchCommit 将操作 stale/空 handle，行为未定义 - activeBatchHandle_ 不再重置，FlushPreparedReads 后成员变量保留 stale 值 - 同仓 moe_ep_combine.h:560 的 FlushPreparedWrites 保留了空调用保护，本 PR 与参考实现不一致 #### 修改建议 **修改前代码**： cpp __aicore__ inline void EngramFetchArch35::FlushPreparedReads() { int32_t ret = hcomm_.BatchCommit(activeBatchHandle_); ascendc_assert(ret == 0, "BatchCommit failed, ret=%d", ret); preparedReadCount_ = 0U; } **修改后代码**： cpp __aicore__ inline void EngramFetchArch35::FlushPreparedReads() { if (preparedReadCount_ == 0U) { return; } int32_t ret = hcomm_.BatchCommit(activeBatchHandle_); ascendc_assert(ret == 0, "BatchCommit failed, ret=%d", ret); preparedReadCount_ = 0U; } **修改说明**：恢复空调用保护，与同仓 moe_ep_combine.h:560 参考实现保持一致。虽然当前调用点 均有 guard，但该保护是防御性编码最佳实践，可防止未来修改引入 stale handle 操作风险。 activeBatchHandle_ 不重置可接受（PrepareRead 在 count==0 时会重新 MakeBatchHandle 覆盖）， 但空调用保护建议保留。 --- ### 问题ID：ISSUE-002 | 严重级别：LOW（轻微） #### 假设检验过程 **代码段**：RemoteFetchRank() 中 ascendc_assert 用于 Drain 返回值校验 **假设**：H0: 该代码段是安全的 | 证据序号 | 证据类型 | 规范ID | 证据描述 | 分值增量 | 累计自信值 | |---------|---------|--------|---------|---------|-----------| | 1 | 规范违反 | cpp-general 12.1 | ascendc_assert(drainRet == 0, ...) 使用断言校验运行时可能发生的错误（Drain 失败），违反"断言不能用于运行期错误处理" | +40% | 40% | | 2 | 上下文防御缺失 | — | Drain 失败后无恢复路径，直接 assert 终止 | +15% | 55% | **证据有效性校验**： - 排除项：ascendc_assert 是 Kernel 侧标准错误处理机制（同文件 line 353、361 均使用此模式）， Kernel 侧无异常机制，ascendc_assert 是约定俗成的错误处理方式 - 排除项：engram_fetch_grad_arch35.h:203-211 的 DrainChecked 使用重试机制，但本场景为 mid-stream Drain，重试意义有限 **结论**：自信值 **55%** < 60%，**不推翻原假设H0**。但作为存疑问题列出供评估。 --- **关联规范条款**：cpp-general 12.1（断言不能用于运行期错误处理） **代码路径**：mc2/engram_fetch/op_kernel/arch35/engram_fetch_arch35.h:408 **问题类型**：断言用于运行时错误处理（存疑） **问题描述**： cpp int32_t drainRet = hcomm_.Drain(static_cast<AscendC::ChannelHandle>(channelHandle)); ascendc_assert(drainRet == 0, "mid-stream Drain failed, ret=%d", drainRet); 使用 ascendc_assert 校验 Drain 返回值。规范 12.1 要求"断言不能用于校验程序在运行期间可能导致的 错误"。但 Kernel 侧无异常机制，ascendc_assert 是全文件统一模式（line 353 ReadNbi、line 361 BatchCommit 均如此），属于既有约定。此条为存疑问题，建议评估 Kernel 侧是否应有更完善的错误处理机制。 **修改建议**：暂不修改。遵循既有 Kernel 侧 ascendc_assert 模式。如需改进应全文件统一处理， 不在本 PR 范围内单独修改。 --- ### 问题ID：ISSUE-003 | 严重级别：LOW（轻微） #### 假设检验过程 **代码段**：RemoteFetchRank() 通道切换逻辑 **假设**：H0: 该代码段是安全的 | 证据序号 | 证据类型 | 规范ID | 证据描述 | 分值增量 | 累计自信值 | |---------|---------|--------|---------|---------|-----------| | 1 | 数据流追踪风险 | cpp-secure 1.2 | 通道切换时 sqReadCount_ = 0 但不 Drain 旧通道，若旧通道仍有在途 reads，跨批次回到该通道时 sqReadCount_ 不含在途计数 | +25% | 25% | | 2 | 上下文防御缺失 | — | 通道切换时不 FlushPreparedReads，依赖 RemoteFetchRank 末尾的 final flush 保证 preparedReadCount_ == 0 的隐式不变量 | +20% | 45% | **证据有效性校验**： - 排除项：RemoteFetchRank:412-414 末尾 if (preparedReadCount_ > 0U) { FlushPreparedReads(); } 保证函数返回时 preparedReadCount_ == 0，下次调用入口 PrepareRead 会在 count==0 时重新 MakeBatchHandle，不会复用旧通道 handle。排除"stale handle"风险。 - 排除项：用户确认 Drain 语义为防止单通道 SQ 溢出，换对端不需要 Drain（不同通道的 SQ 独立计数） - 未排除项：跨批次（Process while 循环）回到同一通道时，sqReadCount_ 从 0 开始，不含上一批次 在途 reads。若硬件无背压且单批次 reads 数接近 32767，理论上可能累积溢出。但实际场景中 indicesBatchSize_ 远小于 32767，风险极低。 **结论**：自信值 **45%** < 60%，**不推翻原假设H0**。作为存疑问题列出供评估。 --- **关联规范条款**：cpp-secure 1.2（保证内存安全） **代码路径**：mc2/engram_fetch/op_kernel/arch35/engram_fetch_arch35.h:386-389 **问题类型**：跨批次 SQ 计数准确性（存疑） **问题描述**： cpp if (activeChannelHandle_ != channelHandle) { sqReadCount_ = 0; } activeChannelHandle_ = channelHandle; Branch 2（totalBlocks < numRanks_，FetchByRank:430-437）中，一个核处理多个 rank， 跨批次（Process while 循环）回到同一通道时，sqReadCount_ 被重置为 0（因为中间切到过其他通道）， 不包含上一批次该通道的在途 reads 计数。needDrain 判定可能延迟，理论上存在 SQ 溢出风险。 实际风险评估： - 触发条件：totalBlocks < numRanks_ + numTokens >> indicesBatchSize_（多批次）+ 单通道单批次 reads 数接近 32767 - 实际场景中 indicesBatchSize_ 受 UB 容量限制，远小于 32767，风险极低 - 用户确认换对端不需要 Drain，不同通道 SQ 独立 **修改建议**：暂不修改。若未来场景变化（更大 indicesBatchSize 或更多 rank）， 可考虑在 RemoteFetchRank 末尾对当前通道做 Drain，确保跨批次安全。 --- ## 已验证无问题的代码段 ### 1. URMA WQE 配置变更（line 49-63） odr/fence 值调整属于传输语义配置，无逻辑错误。constexpr 常量定义符合规范。 ### 2. 成员变量初始化（line 125-127） activeChannelHandle_{0}、sqReadCount_{0} 均在声明时初始化，符合 cpp-secure 3.1。 ### 3. PrepareRead SQ 计数递增（line 354-355） ++preparedReadCount_ 和 ++sqReadCount_ 不会溢出： - preparedReadCount_ 在 ENGRAM_BATCH_CAPACITY(128) 时触发 FlushPreparedReads 重置 - sqReadCount_ 在 HCOMM_SQ_MAX_PENDING(32767) 时触发 Drain 重置 ### 4. needDrain 判定逻辑（line 399-410） sqReadCount_ + 1U >= HCOMM_SQ_MAX_PENDING： - isLast || needDrain 时使用 URMA_CQE_CFG（生成完成事件），正确 - needDrain 后 FlushPreparedReads + Drain + sqReadCount_=0，正确 - isLast 且 needDrain 同时为 true 时，Drain 后循环结束，final flush 因 count==0 跳过，正确 ### 5. HCOMM_SQ_MAX_PENDING 常量定义（engram_fetch_utils.h:46） constexpr uint32_t HCOMM_SQ_MAX_PENDING = 32767U，与 moe_ep_combine.h:78 一致， 命名清晰，符合 cpp-general 4.2。 ### 6. static_cast<AscendC::ChannelHandle>(channelHandle)（line 407） channelHandle 为 uint64_t，ChannelHandle 可从 uint64_t 转换。 同仓 moe_ep_combine.h:653 直接传 uint64_t，转换安全。 --- ## 检视结论 本次 PR #11382 "engram推理修复sq队列溢出" 变更经假设检验方法论检视，整体结论如下： ### 修复逻辑正确性验证 1. **sqReadCount_ 机制**：新增成员变量准确追踪单通道 SQ 深度，在 PrepareRead 中递增， 达到 HCOMM_SQ_MAX_PENDING(32767) 时触发 mid-stream Drain 并重置，机制正确。 2. **通道切换处理**：activeChannelHandle_ != channelHandle 时 sqReadCount_ 重置为 0， 符合"不同通道 SQ 独立计数"的硬件语义，逻辑正确。 3. **needDrain 判定**：sqReadCount_ + 1U >= HCOMM_SQ_MAX_PENDING 配合 isLast 条件， 确保达到阈值时使用 URMA_CQE_CFG 生成完成事件并 Drain，SQ 不会溢出。 4. **URMA WQE 配置**：odr/fence 值调整为传输语义配置，无逻辑错误。 ### 发现的问题 - **无严重级（CRITICAL）问题**：修复逻辑无功能错误，无 SQ 溢出风险。 - **1 个中等级问题**（ISSUE-001）：FlushPreparedReads 移除了空调用保护， 当前调用点均安全但防御性退化，建议恢复 if (preparedReadCount_ == 0U) { return; }。 - **2 个轻微级存疑问题**（ISSUE-002、ISSUE-003）：ascendc_assert 用于 Drain 返回值 （既有 Kernel 侧模式）、跨批次 SQ 计数准确性（实际风险极低），均建议暂不修改。 ### 总体判定 **通过（建议修复 ISSUE-001）**。SQ 队列溢出修复目标达成，核心逻辑经检验正确。 建议合入前恢复 FlushPreparedReads 空调用保护，与同仓 moe_ep_combine.h:560 保持一致。 --- ## 报告生成时间 2026-09-07 ## 报告状态 已完成检视，待评估验证 See merge request: cann/ops-transformer!11382 | 15 小时前 | |
fix compile warnings Co-authored-by: yezhuoxi<yezhuoxi@huawei.com> # message auto-generated for no-merge-commit merge: !11299 merge master into master fix compile warnings Created-by: yezhuoxi Commit-by: yezhuoxi Merged-by: cann-robot Description: ## 描述 清理cleancode告警 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/5022 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11299 | 1 天前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Co-authored-by: qzzzy1<qiziyu2@huawei.com> # message auto-generated for no-merge-commit merge: !11210 merge master into master MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Created-by: qzzzy1 Commit-by: qzzzy1 Merged-by: cann-robot Description: ## 描述 补充MoeDistributeDispatchSetup/Teardown RT2.0 infershape与inferdatatype ## 关联的Issue 4932 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [x] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11210 | 10 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
mc2: 清理CMake depends冗余算子依赖声明 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11261 merge fix_3 into master mc2: 清理CMake depends冗余算子依赖声明 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 描述 mc2 算子 CMake depends 整改（校验标准：源码 include 传递闭包 + v2/v3 及配套算子一体声明保留）： **1. depends 冗余删除（3 处，闭包零引用且单算子构建验证通过）** | 算子 | 删除项 | 说明 | |---|---|---| | moe_distribute_dispatch_setup | dispatch_v2/v3 | 传递闭包零引用 | | grouped_mat_mul_allto_allv | allto_allv_grouped_mat_mul | 闭包零引用（保留另两个真实依赖） | | mega_moe | apt行 dispatch_v2/v3 | 闭包零引用 | **2. License 头补齐（2 个文件）**：moe_ep_combine_epilogue / moe_ep_dispatch_epilogue 的 op_host/CMakeLists.txt 补充仓内标准 License 头（OAT 整改） **3. 保持原样（配套一体声明）**：combine v1/v3、combine_add_rms_norm 对 dispatch_v2/v3 的声明经闭包核实为传递依赖（经 combine_v2 头文件间接引用 dispatch_v2），不可删；engram_fetch_grad 与 moe_ep_*_epilogue 对主算子的声明按配套一体语义保留。 ## depends 声明机制说明 **主 depends（ <op>_depends）**，消费点三处： 1. op_add_depend_directory（cmake/func.cmake）：编译级联——把依赖算子的 op_host add_subdirectory 进编译（proto/tiling 注册、aclnn 生成头） 2. custom_build.cmake:1114：安装级联——把依赖算子的 op_kernel 打进自定义算子包 3. 主形态构建时的 kernel 源码级联拷贝 **变体 depends（<op>_a2/_a3/_apt_depends）**，消费点： - func.cmake:782：按变体名（如 moe_distribute_combine_v2_a2）动态拼变量名，把声明的算子源码目录拷贝到 build/binary/<soc>/src/ 下，供对应 soc 形态（A2/A3/apt）kernel 的相对路径 include 使用——**变体行是变体构建的源码级联声明，不是主行的重复** ## depends 声明的正确写法（新增算子时参考） **主 depends 应写**：本算子源码 include 传递闭包内的全部算子目录（不是仅直接引用——如 combine_v2 的头间接引用 dispatch_v2，依赖方也需声明）；配套使用的 v2/v3 需同时声明 **变体 depends（_a2/_a3/_apt）应写**：与主 depends 相同的算子集合——变体 kernel 编译时拷贝整个算子目录，源码引用与主形态一致，漏声明会导致对应 soc 构建时 src/ 下缺依赖算子目录而 file not found **不需要写入 depends 的**：examples/tests 中经 aclnnop/ 安装头调用其他算子 API 的关系（测试侧依赖，不属于算子构建依赖） **多 soc 引用不一致时**：主 depends 写全部引用的并集（消费点不区分 soc）；变体行推荐与主行保持一致（全量写法只多拷目录无副作用，精确写易漏间接 include 链） ## 验证 - 9 个涉及算子逐一单算子构建（每次 rm -rf build）：ascend950 下 8 个全部通过；mega_moe 失败与上游基线一致（utils/base/helpers.h 缺失 + OOM，非本改动引入） - A2/A3（ascend910b / ascend910_93）单算子包构建验证 dispatch_v2、combine_v2 通过 ## 冗余来源溯源（git 历史） quantize_functions.h 原位于 mc2/moe_distribute_dispatch_v2/op_kernel/ 下，setup/mega_moe 的 kernel 曾直接 include 它，depends 声明 dispatch_v2/v3 有真实依据。 **dc032f70f5（2026-08-27，megamoe issue闭环）** 将该文件挪至 mc2/common/op_kernel/，并同步把 setup/mega_moe 的源码 include 全部改向 common： diff -#include "../../moe_distribute_dispatch_v2/quantize_functions.h" +#include "../../common/quantize_functions.h" 该笔只改了源码 include、未同步清理 CMakeLists 的 _depends，setup 主行与 mega_moe apt 行的 dispatch_v2/v3 自此成为零引用的历史遗留，本 PR 清理的正是这批遗留。combine 系不受影响：combine_v2 仍引用 dispatch_v2 下未挪动的其他文件（如 moe_distribute_v2_constant.h），传递依赖依然成立，故其声明保留。 See merge request: cann/ops-transformer!11261 | 16 小时前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Co-authored-by: qzzzy1<qiziyu2@huawei.com> # message auto-generated for no-merge-commit merge: !11210 merge master into master MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Created-by: qzzzy1 Commit-by: qzzzy1 Merged-by: cann-robot Description: ## 描述 补充MoeDistributeDispatchSetup/Teardown RT2.0 infershape与inferdatatype ## 关联的Issue 4932 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [x] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11210 | 10 小时前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
fix(mega_moe): align activation validation and documentation Co-authored-by: zhujun116<zhujun116@huawei.com> # message auto-generated for no-merge-commit merge: !11390 merge master into master fix(mega_moe): align activation validation and documentation Created-by: OblivionZHU Commit-by: zhujun116 Merged-by: cann-robot Description: ## 描述 ## 修改内容 ### 代码整改 - 统一 Atlas A2/A3 和 Ascend 950PR/950DT 的 SiTUGLU 参数校验： - beta 必须为大于 0 的有限值。 - 显式配置的 linear_beta 必须为大于 0 的有限值。 - 修正现有 UT 中 SiTUGLU 的合法参数取值及相关注释，未新增测试用例。 - “Ascend 950PR/Ascend 950DT”说明整改。 ### 激活流程资料整改 - 将流程、公式和共享专家计算中泛指激活阶段的“SwiGLU”统一改为“Activation/激活”，避免与新增激活类型冲突。 - 补充 swiglu、swiglustep、swigluoai 和 situglu 的参数配套及取值约束。 - 明确不同产品上 SiTUGLU 的默认参数和必选规则。 - 修正 A8W4-FP 场景中的公式格式问题。 - 修正符号含义： - E_local 表示本 Rank 的路由 MoE 专家数。 - 新增 m_e 表示专家本次实际接收的 Token 数。 ### MXFP量化说明整改 - 明确 A8W8-FP 场景激活量化类型与 Dispatch 阶段一致，支持 FLOAT8_E5M2 或 FLOAT8_E4M3FN。 - 明确 A8W4-FP 场景 Dispatch 和激活量化均使用 FLOAT8_E4M3FN。 - 明确 A4W4-FP 场景： - Dispatch 阶段量化为 FLOAT4_E2M1。 - 第一层矩阵乘后的激活结果量化为 FLOAT8_E4M3FN。 - 第二层矩阵乘实际为 A8W4。 - 删除资料中对内部类型变量 SwigluQuantOutType 的直接描述，改为面向用户的量化行为说明。 - 保留 l1_weights_sf、l2_weights_sf 的“可选”属性，在参数说明中明确 MXFP 量化场景下必须输入。 ### 权重及TensorList约束整改 - 将 Ascend 950PR/950DT 路由专家相关维度统一为 local_moe_expert_num。 - 补充 l1_weights_sf、l2_weights_sf 在 Ascend 950PR/950DT 上的 TensorList 长度： - 逐专家布局长度为 local_moe_expert_num。 - 堆叠布局长度为 1。 - 明确权重及权重缩放因子的逐专家布局、堆叠布局及一致性要求。 - 补充 FP4 权重在 PyTorch 侧以 uint8 打包传入的说明： - 每个 uint8 打包两个 FLOAT4_E2M1 元素。 - 表格中的 shape 为物理载体的实际传入 shape。 - 通过 weight1_type、weight2_type 指定逻辑数据类型。 - 补充 A8W8-FP E4M3 权重的 FRACTAL_NZ 格式支持。 - 删除无对应实现的 A4W4-FP weight1 ND 格式说明，并明确： - A8W4-FP 的 weight1 使用 FORMAT_FRACTAL_NZ_C0_32。 - A4W4-FP 的 weight1 仅支持 FRACTAL_NZ。 - 两种场景的 weight2 使用 FORMAT_FRACTAL_NZ_C0_32。 - 共享专家权重格式需与对应路由专家权重一致。 - 将“普通MTE权重格式”等内部表述改为 A8W8-FP、A8W4-FP、A4W4-FP 等用户可理解的场景描述。 ### 通信及组网约束整改 - 将“通信域和组网约束”拆分为“通信域约束”和“组网约束”两个独立小节。 - 修正 Ascend 950PR/950DT 约束中混入 Atlas A2/A3 组网说明的问题。 - 删除 topo_type 和 topk_weights_type 中“当前暂不支持URMA通信方式”的过期说明。 - 明确 URMA 拓扑下暂不支持 swiglustep 和 swigluoai 激活算法。 - “Ascend 950PR/Ascend 950DT”说明整改。 ### 资料同步 以上修改已同步至： - mc2/mega_moe/README.md - torch_extension/cann_ops_transformer/docs/zh/mega_moe.md ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 以上修改已同步至： - mc2/mega_moe/README.md - torch_extension/cann_ops_transformer/docs/zh/mega_moe.md ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11390 | 10 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Co-authored-by: qzzzy1<qiziyu2@huawei.com> # message auto-generated for no-merge-commit merge: !11210 merge master into master MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Created-by: qzzzy1 Commit-by: qzzzy1 Merged-by: cann-robot Description: ## 描述 补充MoeDistributeDispatchSetup/Teardown RT2.0 infershape与inferdatatype ## 关联的Issue 4932 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [x] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11210 | 10 小时前 | |
MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Co-authored-by: qzzzy1<qiziyu2@huawei.com> # message auto-generated for no-merge-commit merge: !11210 merge master into master MoeDistributeDispatchSetup&MoeDistributeDispatchTeardown补充rt2.0注册和信息库实现 Created-by: qzzzy1 Commit-by: qzzzy1 Merged-by: cann-robot Description: ## 描述 补充MoeDistributeDispatchSetup/Teardown RT2.0 infershape与inferdatatype ## 关联的Issue 4932 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [x] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11210 | 10 小时前 | |
dispatch将专家权重判断提至moe发送循环外，消除可选topk weight引入的性能劣化 Co-authored-by: zhong-zixin<zhongzixin@huawei.com> # message auto-generated for no-merge-commit merge: !11394 merge fix_topkw_loop into master dispatch将专家权重判断提至moe发送循环外，消除可选topk weight引入的性能劣化 Created-by: zhong-zixin Commit-by: zhong-zixin Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 将 FillTriple / ProcessToken / TokenToExpert 中循环内的 (k < axisK_) && hasExpertScalesFlag_ 运行时判断外提：SendToMoeExpert 拆分为入口 + 循环体，按 hasExpertScalesFlag_ 以字面量 true / false 分流传参，共享专家路径固定传 false，消除未启用 expertScales 场景逐 token 热循环中的分支开销。同步修复 arch22 / arch35 FullMesh 变体中的同款问题，行为与基线严格等价。 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> 关联Issue #5029 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 本地验证，二级冒烟 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 不涉及 ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： # PR #11394 代码检视报告 | 项目 | 内容 | |------|------| | PR 标题 | 将专家权重判断提至moe发送循环外，消除可选topk weight引入的性能劣化 | | PR 地址 | https://gitcode.com/cann/ops-transformer/pull/11394 | | 作者 / 来源分支 | zhong-zixin / fix_topkw_loop → master | | 检视基线 | merge-base 33d8246e0f，PR head 1e37cfe17（单提交） | | 变更范围 | 3 个文件（+93 / -46）：moe_distribute_dispatch_v2.h、arch22 / arch35 两个 FullMesh 变体 | | 模块 | mc2 | | 检视结论 | **可通过**（无阻塞问题；两项非阻塞观察项见第 5 节） | --- ## 1. 整体概述 ### 1.1 背景与动机 提交 2a0d633137（PR !7350，"Support optional topk weights for MTE low latency"）为 moe_distribute_dispatch_v2 引入了可选的 topK 权重输入 expertScales。该特性在逐 token 发送热循环内以运行时条件 (k < axisK_) && hasExpertScalesFlag_ 控制权重写入，对未启用 expertScales 的存量场景（绝大多数调用方）造成性能劣化。 ### 1.2 修复方式 将"是否写专家权重"的判断提升到循环外，通过函数参数显式传递： 1. FillTriple、ProcessToken 新增 bool writeExpertScale 参数； 2. SendToMoeExpert 拆分为入口 + SendToMoeExpertLoop 循环体，入口按 hasExpertScalesFlag_ 以字面量 true/false 分流； 3. SendToSharedExpert（共享专家路径）固定传 false。 该修复同时覆盖标准 kernel 与两个 FullMesh 变体，回归在三种部署形态下全部消除。 --- ## 2. 主头文件变更解析 - FillTriple / ProcessToken 新增 writeExpertScale 参数，内部判断 if (writeExpertScale)； - SendToMoeExpert 拆分为入口 + SendToMoeExpertLoop，入口按 hasExpertScalesFlag_ 以字面量分流； - SendToSharedExpert 固定传 false； - 两类调用路径（MoE：k = expertIdx % axisK_ 恒小于 axisK_；共享专家：k = axisK_ + idx 恒不小于 axisK_）行为与基线严格等价； - expertScaleAlign_ 仅在 hasExpertScalesFlag_ == true 时初始化，expertScalesTensor_ 仅在同条件下加载且先于发送，无读未初始化风险； - 调用点全部同步，v3/v4 经头文件复用自动覆盖。 --- ## 3. FullMesh 两文件变更解析 ### 3.1 改动模式 两个 FullMesh 文件复刻主头文件的修复思路，但因函数族不同（TokenToExpert / TokenToExpertInQuant 直接持有 FillTriple 调用）适配方式略有差异： 1. FillTriple 新增 bool writeExpertScale，内部判断由 (k < axisK_) && hasExpertScalesFlag_ 改为 (k < axisK_) && writeExpertScale（注意：与主头文件不同，k < axisK_ 被保留）； 2. TokenToExpert / TokenToExpertInQuant 新增 bool writeExpertScale 形参并透传给 FillTriple； 3. SendToMoeExpert 拆分为入口 + SendToMoeExpertLoop，入口按 hasExpertScalesFlag_ 以字面量 true/false 分流； 4. SendToSharedExpert 的两处调用固定传 false。 ### 3.2 arch22（moe_distribute_dispatch_v2_full_mesh.h）等价性论证 调用路径逐一验证： | 路径 | k 取值来源 | 旧行为 | 新行为 | 结论 | |------|-----------|--------|--------|------| | 共享专家（SendToSharedExpert:607/609） | axisK_ + toSharedExpertIndex，恒 >= axisK_ | (k < axisK_) 恒假 → 不写 | 字面量 false → 不写 | 等价 | | MoE 专家（SendToMoeExpertLoop:707/710） | topKIndex = calExpertIdsIdx % axisK_（:700），恒 < axisK_ | 条件退化为 hasExpertScalesFlag_ | writeExpertScale = hasExpertScalesFlag_（入口 :666-670 分流） | 等价 | 拆分完整性：入口保留 SplitExpertNumToCore() + CalExpertSendNum() + 分流；calExpertIdsIdx / maskN64Num / dstWinGMTensor / expertMaskTensorU64 四个声明（均无副作用）与双重循环体逐语句移入 SendToMoeExpertLoop，循环体与旧版逐行一致（仅两处调用增加实参）。 BS 模式旁证：SendToMoeExpertByBS（:836）不调用 TokenToExpert / FillTriple，不受签名变更影响，无需改动。 ### 3.3 arch35（moe_distribute_dispatch_v2_a5_full_mesh.h）等价性论证 | 路径 | k 取值来源 | 旧行为 | 新行为 | 结论 | |------|-----------|--------|--------|------| | 共享专家（SendToSharedExpert:626/628） | axisK_ + toSharedExpertIndex，恒 >= axisK_ | 恒不写 | 字面量 false → 不写 | 等价 | | MoE 专家（SendToMoeExpertLoop:695/697） | topKId = index % axisK_（:671），恒 < axisK_ | 条件退化为 hasExpertScalesFlag_ | writeExpertScale = hasExpertScalesFlag_（入口 :651-655 分流） | 等价 | 拆分完整性：与旧版 SendToMoeExpert 逐语句对比确认——前奏（Duplicate、validTokenNum 计算、syncFlagId_ = 0、SetFlag 循环）保留在入口；dstWinGMTensor / dstTokenIdx 声明（无副作用）与 token 循环移入 SendToMoeExpertLoop；尾部 WaitFlag 循环保留在入口 if/else 之后。执行顺序与旧单函数完全一致（SetFlag 全部置位 → 逐 token Wait/Set → 收尾 Wait）。 ### 3.4 arch22 与 arch35 实现一致性 实现模式一致（FillTriple 判断式、字面量分流、共享专家传 false 均相同）。存在两处结构差异，均为两文件既有循环组织差异所致，非本次引入： - SendToMoeExpertLoop 签名不同：arch35 额外传 validTokenNum（其循环按 token 索引跨核步进，validTokenNum 在前奏中计算）；arch22 按专家分核，循环上界用成员 sendNum_，无需传参。 - 拆分边界不同：arch22 入口只保留分核与计数两步；arch35 入口还保留 Duplicate/SetFlag 前奏与 WaitFlag 尾声。各自与旧版单函数语义一一对应。 ### 3.5 状态一致性 - expertScaleAlign_ 仅在 Init 中 hasExpertScalesFlag_ == true 时初始化（两文件同款守卫，arch22:384 / arch35:384）；新代码仅在 writeExpertScale == true（即 hasExpertScalesFlag_ == true）时读取，无读未初始化成员风险。 - expertScalesTensor_ 在 ExpIdsCopyAndMaskCal 尾部按 hasExpertScalesFlag_ 守卫加载（arch22:1966-1970 / arch35:1816-1820），先于 AllToAllDispatchA3/A5 分流执行；共享专家核虽也执行该函数，但路径固定传 false 不读 scales，与旧代码（靠 k < axisK_ 恒假跳过）行为一致。 ### 3.6 调用点完整性 全库检索确认： - 两文件内 FillTriple 全部调用（定义体内各 2 处）、TokenToExpert / TokenToExpertInQuant 全部调用（共享专家各 2 处 + MoE 循环各 2 处）实参数目与新签名一一匹配； - 四者为类私有成员，无外部调用者； - 实例化点 moe_distribute_dispatch_v2 / moe_distribute_dispatch_v3 的 arch22 *_a3.cpp 与 arch35 *_apt.cpp 共 4 个 cpp 仅调用公共入口（Init / Process），私有方法签名变更随模板惰性实例化自动传播，无需改动； - examples/fast_kernel_launch_example/ 下的 full_mesh 副本是独立的旧版拷贝（独立命名空间、未被本 PR 修改），不受影响。 ### 3.7 格式检查 以仓库 .clang-format（clang-format 22.1.8）对 3 个文件 PR 版本全文执行： - 两个 FullMesh 文件：无任何偏差； - 主头文件：仅第 458、1065 行两处偏差（本 PR 未触碰的历史行，注释对齐，疑为 clang-format 版本差异），无新增偏差。 --- ## 4. 性能修复有效性 - 主头文件：无权重场景热循环中权重写入、成员加载、比较与分支全部消失；有权重场景仅保留无条件写入。字面量实参 + 内联 + 常量传播可生成两份无内部分支的特化循环；即使编译器未完成折叠，循环内分支也退化为寄存器参数判断，不会劣于旧代码。 - FullMesh：无权重场景（回归场景）(k < axisK_) && false 经内联 + 常量折叠完全消除，回归修复覆盖 FullMesh 部署形态；有权重场景保留一次 k < axisK_ 运行期比较（见观察项 5.2），仍优于旧代码（成员加载 + 比较 + 分支）。 - 相比把 hasExpertScales 提升为模板参数的方案（需翻倍实例化、增加 tiling key 复杂度），当前运行时分流 + 编译期折叠的折中是合理的。 --- ## 5. 检视发现 ### 阻塞问题 无。 ### 观察项（非阻塞） **[观察-1] FullMesh 修复未覆盖 BS 模式路径（arch22）** arch22 的 SendToMoeExpertByBS（:836，canUseBSMode 分支）不经过 TokenToExpert / FillTriple，本就不含 (k < axisK_) && hasExpertScalesFlag_ 判断，无回归残留。仅作完整性说明，无需改动。 **[观察-2] FullMesh FillTriple 保留了冗余的 k < axisK_ 判断（可选清理）** 两文件 FillTriple 的判断为 (k < axisK_) && writeExpertScale，而两条调用路径上该条件已可静态判定：共享专家路径 writeExpertScale == false 使 k < axisK_ 成为死条件；MoE 路径 k = xxx % axisK_ 恒真。主头文件的对应修改已将判断简化为 if (writeExpertScale)。FullMesh 保留 k < axisK_ 的后果：无权重特化路径（回归场景）经常量折叠完全消除，不受影响；有权重特化路径每次 FillTriple 多一次运行期比较，属微小冗余。保留亦可视为防御性写法，不要求修改；如后续清理，建议与主头文件风格统一。 --- ## 6. 综合判定 | 维度 | 判定 | |------|------| | 正确性 | 通过。三类 kernel 变体（主、arch22 FullMesh、arch35 FullMesh）两类调用路径与基线严格等价，状态初始化/加载时序一致 | | 一致性 | 通过。arch22 / arch35 实现模式一致，结构差异源于既有循环组织差异 | | 调用点 | 通过。全库无私有成员外部引用遗漏，4 个实例化 cpp 无需改动 | | 性能 | 通过。回归场景（无 expertScales）热循环开销在三种 kernel 变体中全部消除 | | 格式/规范 | 通过。两 FullMesh 文件 clang-format 干净；主头文件仅存两处历史行偏差（本 PR 未触碰） | | 综合判定 | **可通过（观察-2 可选清理）** | See merge request: cann/ops-transformer!11394 | 14 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !11224 merge fix_2 into master 删除mc2 op_kernel扁平化__has_include守卫，3rd出包对齐op_kernel层级 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 关联issue： https://gitcode.com/cann/ops-transformer/issues/4946 https://gitcode.com/cann/ops-transformer/issues/4304 ## 描述 承接 !10920（出包恢复 op_kernel 层级）：CANN 包内算子/common/3rd 目录现与源码树结构完全一致，kernel 相对路径引用两边解析结果相同，扁平化双路径 __has_include 守卫成为死代码，本 PR 予以清理，并对齐 3rd 出包结构。 ### 改动内容 1. **删除 mc2 扁平化守卫（60 个文件，-360 行）** - 66 处双分支守卫（#if __has_include(扁平路径) ... #else ... #endif）→ 只保留 else 分支（源码树/新包统一路径） - 4 个 v3 算子 .cpp 的三分支守卫（#if/#elif/#else）→ 只保留 else 分支 - 保留非路径用途守卫：CANN 版本探测（version/asc_devkit_version.h 等 25 处）、API 探测（adv_api/hcomm/hcomm.h 等 8 处）、UT 环境（hccl_stub.h 2 处） 2. **cmake 3rd 出包补齐 op_kernel 层级** - custom_build.cmake 3rd install 目的地追加 /op_kernel，消除源码树（mc2/3rd/<lib>/op_kernel/）与包内（原 ascendc/3rd/<lib>/ 扁平）的 300 处相对引用路径不一致 - mc2/3rd 加入 OPS_TRANSFORMER_SHARED_KERNEL_INSTALL_DEPS 白名单（与 mc2/common 同等），消除 depend 安装循环产生的空目录 ascendc/3rd/op_kernel 3. **commAlg 注释 spelling 修复（关联 issue #4304，3 处 1 行）** - switchwing → switching：mc2/common/op_host/op_tiling/mc2_tiling_struct.h、mc2/common/op_kernel/mc2_tiling_struct.h、mc2/grouped_mat_mul_all_reduce/tests/ut/op_kernel/grouped_mat_mul_all_reduce_tiling_def.h - 纯注释改动，无代码逻辑变化 ### 效果 新增/存量算子 kernel include 统一按源码目录结构写相对路径即可，不再需要区分 static_true/static_false；matmul 系算子（引用 3rd）后续切换在线编译无路径障碍。 ## 测试 - ascend950 出包验证（10 个 static_true 算子 + matmul_reduce_scatter）：编译出包成功 - 包产物解包检查：算子/common/3rd 均含 op_kernel 层级；跨算子、跨 common、跨 3rd 相对引用包内全部可解析；空目录消除；包内 #if/#endif 配平 ## 文档更新 无 See merge request: cann/ops-transformer!11224 | 15 小时前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
mc2相关文件，pre-commit规范整改 Co-authored-by: yayahello<zhaopenglei@hisilicon.com> # message auto-generated for no-merge-commit merge: !11337 merge master into master mc2相关文件，pre-commit规范整改 Created-by: yayahello Commit-by: yayahello Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> mc2代码仓，pre-commit 整改 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!11337 | 1 天前 | |
移除 mc2 op_kernel 摊平机制，统一编译框架与 include 风格 Co-authored-by: gitcode_lijd<lijiandong20@huawei.com> # message auto-generated for no-merge-commit merge: !7544 merge compile into master 移除 mc2 op_kernel 摊平机制，统一编译框架与 include 风格 Created-by: gitcode_lijd Commit-by: gitcode_lijd Merged-by: cann-robot Description: ## 背景 ops-transformer 出包时 op_kernel/ 目录被扁平化展开：mc2/common/op_kernel/xxx.h → ascendc/common/xxx.h。对于 static_true（JIT 在线编译）算子，kernel 代码需兼容两种环境： 1. **本地预编译**：源码树，op_kernel/ 层级存在 2. **CANN 包 JIT 编译**：扁平化，op_kernel/ 层级消失 ## 治理原则 ### 核心规则 - **static_true 算子**：需要 __has_include 守卫，兼容两种路径 - **static_false 算子**：不需要守卫，直接用本地 op_kernel/ 路径 - **同目录引用**：不需要守卫 ### 三种标准模式 // 1. op_kernel 层 → common #if __has_include("../common/xxx.h") // CANN（无 op_kernel） #include "../common/xxx.h" #else #include "../../common/op_kernel/xxx.h" // 本地（有 op_kernel） #endif // 2. arch 层 → common #if __has_include("../../common/xxx.h") #include "../../common/xxx.h" #else #include "../../../common/op_kernel/xxx.h" #endif // 3. op_kernel 层 → 兄弟算子 #if __has_include("../sibling_op/xxx.h") #include "../sibling_op/xxx.h" #else #include "../../sibling_op/op_kernel/xxx.h" #endif ### 合并原则 同深度、紧邻的 __has_include 块可合并为一个。**不可合并**的情况： - 两个块之间有其他 #include（依赖排序） - 第一个块在 #if defined(__NPU_ARCH__) 条件编译内 - quantize_functions.h 等特殊依赖 ## 已完成工作清单 ### 1. cmake 出包扁平化 - common/: install 目标去掉 op_kernel 中间层 - 3rd/: install 加尾 /（op_kernel → op_kernel/），展开内容 ### 2. __CCE_KT_TEST__ 守卫还原（4 个文件） matmul_all_reduce 下 common.h + 3 个 *_tiling_data.h，被误删的守卫恢复，并修正 else 分支路径（combined.h 的 ../common/ → ../../common/） ### 3. __has_include 路径纠正 - op_kernel 层：../../common/ → ../common/ - arch 层：../../../common/ → ../../common/ - 覆盖全部 static_true 算子（14 个 → 20 个） ### 4. 同级块合并（8 个文件） 相邻同深度的 __has_include 块合并 ### 5. setup/teardown 预加守卫（4 个算子，8 个文件 → 已纳入守护范围） 已加 __has_include 守卫，后续切 static_true 无需修改 .h 文件： - moe_distribute_combine_setup - moe_distribute_dispatch_setup - moe_distribute_combine_teardown - moe_distribute_dispatch_teardown ### 6. 高风险拆分 moe_distribute_combine_v2_quant.h：quantize_functions.h 从合并块拆出，单独守卫 ### 7. 无效守卫清理 - engram_fetch_wait（纯 static_false）：移除守卫，直接用本地路径 ### 8. 新增 EP 算子守护（3 个算子） 新增 3 个 static_true 算子： - moe_ep_dispatch（守卫已正确） - moe_ep_combine（修正 __has_include 路径中多余 op_kernel/ 层级） - moe_ep_dispatch_epilogue（同上） ### 9. MegaMoe 跨算子引用加守卫（2 个文件，4 处） mega_moe/op_kernel/arch35/ 下 mega_moe.h + mega_moe_combine_send.h： - quantize_functions.h 加 __has_include 双路径守卫 - 原裸 "moe_distribute_dispatch_v2/op_kernel/..." 路径（依赖 -Imc2/）改为相对路径 ### 10. MegaMoe CMake 清理 - 删除 -I${CMAKE_CURRENT_SOURCE_DIR}/../../（-Imc2/，仅 mega_moe 使用） - 删除 -I${CMAKE_CURRENT_SOURCE_DIR}/../../3rd（目录不存在，无引用） - 新增 mega_moe_apt_depends，声明 apt 编译依赖 mc2/moe_distribute_dispatch_v2 mc2/moe_distribute_dispatch_v3，确保 opc 编译时跨算子头文件可解析 ## 当前 static_true 算子清单（共 17 个已启用 + 3 个守卫待启用 = 20 个） | 算子 | 目录 | 守卫状态 | |------|------|---------| | AttentionToFFN | mc2/attention_to_ffn/ | ✓ | | DistributeBarrier | mc2/distribute_barrier/ | ✓ | | DistributeBarrierExtend | mc2/distribute_barrier_extend/ | ✓(*) | | FFNToAttention | mc2/ffn_to_attention/ | ✓ | | MegaMoe | mc2/mega_moe/ | ✓ | | MoeDistributeCombine | mc2/moe_distribute_combine/ | ✓ | | MoeDistributeCombineAddRmsNorm | mc2/moe_distribute_combine_add_rms_norm/ | ✓(*) | | MoeDistributeCombineSetup | mc2/moe_distribute_combine_setup/ | ✓(†) | | MoeDistributeCombineTeardown | mc2/moe_distribute_combine_teardown/ | ✓ | | MoeDistributeCombineV2 | mc2/moe_distribute_combine_v2/ | ✓ | | MoeDistributeCombineV3 | mc2/moe_distribute_combine_v3/ | ✓(*) | | MoeDistributeDispatch | mc2/moe_distribute_dispatch/ | ✓ | | MoeDistributeDispatchSetup | mc2/moe_distribute_dispatch_setup/ | ✓(†) | | MoeDistributeDispatchTeardown | mc2/moe_distribute_dispatch_teardown/ | ✓(†) | | MoeDistributeDispatchV2 | mc2/moe_distribute_dispatch_v2/ | ✓ | | MoeDistributeDispatchV3 | mc2/moe_distribute_dispatch_v3/ | ✓(*) | | MoeEpCombine | mc2/moe_ep_combine/ | ✓ | | MoeEpDispatch | mc2/moe_ep_dispatch/ | ✓ | | MoeEpDispatchEpilogue | mc2/moe_ep_dispatch_epilogue/ | ✓ | | MoeUpdateExpert | mc2/moe_update_expert/ | ✓ | > (\*) 守卫仅存在于 .cpp 文件，.h 文件无跨目录引用，无需守卫 > (†) 守卫已就位，当前 jitCompile.flag 为 static_false，后续切换不需改 .h 文件 ## 后续开发注意事项 ### 新增算子 1. 确认 jitCompile.flag（在 op_host/*_def.cpp） 2. static_true → 所有跨 common/兄弟算子的 include 加守卫 3. 同目录引用、系统头文件不需要守卫 ### 切换 static_false → static_true 1. 改 jitCompile.flag 为 "static_true" 2. 扫描全部跨算子 include，加 __has_include 守卫 3. 参照已有 setup/teardown 做法 ### 代码审查要点 - op_kernel 层引用 common：是否用了 ../common/（非 ../../common/） - arch 层引用 common：是否用了 ../../common/（非 ../../../） - #else 分支路径是否包含 op_kernel/ - 同目录引用是否被误加了守卫 See merge request: cann/ops-transformer!7544 | 2 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 天前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 6 天前 | ||
| 1 天前 | ||
| 16 小时前 | ||
| 5 天前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 10 小时前 | ||
| 15 小时前 | ||
| 1 天前 | ||
| 11 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 1 天前 | ||
| 15 小时前 | ||
| 10 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 16 小时前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 10 小时前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 10 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 10 小时前 | ||
| 10 小时前 | ||
| 14 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 15 小时前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 2 个月前 |