文件最后提交记录最后更新时间
layered_doc add bs limit Co-authored-by: wangchenfeng6<wangchenfeng6@h-partners.com> # message auto-generated for no-merge-commit merge: !5828 merge master into master layered_doc add bs limit Created-by: wangchenfeng6 Commit-by: wangchenfeng6 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/ops-transformer!58284 天前
D&C 示例代码修复 Co-authored-by: jiangxiuhan1<jiangxiuhan@huawei.com> # message auto-generated for no-merge-commit merge: !4371 merge master into master D&C 示例代码修复 Created-by: jiangxiuhan1 Commit-by: jiangxiuhan1 Merged-by: cann-robot Description: ## 描述 IS_TEST_* 需要手动设置,直接运行示例代码,没有设置IS_TEST_* 会导致 example 运行失败,example daily会运行失败; 修复上述问题,将原先独立的IS_TEST_A3和IS_TEST_A5布尔标志合并为统一的IS_TEST_A3A5标志,并设置为true,可直接运行示例代码。 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/1948 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: # 代码检视报告 **检视文件**:test_aclnn_moe_distribute_combine_v2.cpp **检视类别**:C++ 安全编码规范(Host 侧测试代码) **规范来源**:cpp-secure.mdascendc-topk.md **检视时间**:2026-04-20 --- ## 风险点列表 ### 【中风险】问题1:LOG 参数类型不匹配 **代码位置**:116-118 行、80 行 ```cpp LOG_PRINT("[INFO] rank = %d, ...", args.rankId, ...); // args.rankId 是 uint32_t,应用 %u LOG_PRINT("[ERROR] aclrtMalloc failed. ret: %d\n", ret); // ret 是 int,%d 正确 ``` **假设检验过程**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | 规则 11.3:LOG 参数类型与格式化说明符不匹配 | +40% | | 上下文防御缺失 | 无类型检查 | +30% | **自信值**:70%(> 60%,判定存在风险) **规范条款**:规则 11.3 LOG API 参数类型必须与格式化说明符匹配 [适用: Tiling] **建议修复**:uint32_t 类型使用 %u 而非 %d。 --- ### 【中风险】问题2:资源释放后未置空 **代码位置**:315-320 行、576-581 行 ```cpp if (dispatchV2WorkspaceSize > 0) { aclrtFree(dispatchV2WorkspaceAddr); // 释放后未置 nullptr } ``` **假设检验过程**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | 规则 3.2:资源释放后指针应置新值 | +40% | | 上下文防御缺失 | 后续无重复使用,但不符合规范 | +20% | **自信值**:60%(= 60%,判定存在风险) **规范条款**:规则 3.2 指向资源句柄的变量,在资源释放后立即赋予新值 [适用: Tiling] **建议修复**: ```cpp if (dispatchV2WorkspaceSize > 0) { aclrtFree(dispatchV2WorkspaceAddr); dispatchV2WorkspaceAddr = nullptr; } ``` --- ### 【中风险】问题3:函数返回值未校验 **代码位置**:768-772 行 ```cpp if (IS_TEST_A2) { int ret = run_example_on_A2(); // 返回值未使用 } else if (IS_TEST_A3A5) { int ret = run_example_on_A3A5(); // 返回值未使用 } ``` **假设检验过程**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | TOPK 问题1:必须校验函数返回值 | +40% | | 上下文防御缺失 | 未处理执行失败情况 | +30% | **自信值**:70%(> 60%,判定存在风险) **规范条款**:TOPK 问题清单 规则 1 必须校验函数返回值 [适用: Host] --- ## 检视总结 | 风险级别 | 数量 | 问题类型 | |---------|------|---------| | 中风险 | 3 | LOG类型不匹配、资源释放后未置空、返回值未校验 | # 代码检视报告 **检视文件**:test_aclnn_moe_distribute_dispatch_v2.cpp **检视类别**:C++ 安全编码规范(Host 侧测试代码) **规范来源**:cpp-secure.mdascendc-topk.md **检视时间**:2026-04-20 --- ## 风险点列表 ### 【中风险】问题1:LOG 参数类型不匹配 **代码位置**:115 行、361 行 ```cpp LOG_PRINT("[INFO] rank = %d, ...", args.rankId, ...); // args.rankId 是 uint32_t,应用 %u ``` **假设检验过程**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | 规则 11.3:LOG 参数类型与格式化说明符不匹配 | +40% | | 上下文防御缺失 | 无类型检查 | +30% | **自信值**:70%(> 60%,判定存在风险) **规范条款**:规则 11.3 LOG API 参数类型必须与格式化说明符匹配 [适用: Tiling] --- ### 【中风险】问题2:资源释放后未置空 **代码位置**:314-318 行、572-577 行 ```cpp if (dispatchV2WorkspaceSize > 0) { aclrtFree(dispatchV2WorkspaceAddr); // 释放后未置 nullptr } ``` **假设检验过程**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | 规则 3.2:资源释放后指针应置新值 | +40% | | 上下文防御缺失 | 后续无重复使用,但不符合规范 | +20% | **自信值**:60%(= 60%,判定存在风险) **规范条款**:规则 3.2 指向资源句柄的变量,在资源释放后立即赋予新值 [适用: Tiling] --- ### 【中风险】问题3:函数返回值未校验 **代码位置**:763 行、767 行 ```cpp if (IS_TEST_A2) { LOG_PRINT("Example on <Atlas A2> will be executed!\n"); int ret = run_example_on_A2(); // 返回值未使用 } else if (IS_TEST_A3A5) { LOG_PRINT("Example on <Atlas A3> or <Atlas A5> will be executed!\n"); int ret = run_example_on_A3A5(); // 返回值未使用 } ``` **假设检验过程**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | TOPK 问题1:必须校验函数返回值 | +40% | | 上下文防御缺失 | 未处理执行失败情况 | +30% | **自信值**:70%(> 60%,判定存在风险) **规范条款**:TOPK 问题清单 规则 1 必须校验函数返回值 [适用: Host] --- ## 检视总结 | 风险级别 | 数量 | 问题类型 | |---------|------|---------| | 中风险 | 3 | LOG类型不匹配、资源释放后未置空、返回值未校验 | See merge request: cann/ops-transformer!43711 个月前
优化多线程访问下化context可能存在竞争导致的数据错误问题 Co-authored-by: zzg_code<zengzhiguo1@huawei.com> # message auto-generated for no-merge-commit merge: !5851 merge updatacontext into master 优化多线程访问下化context可能存在竞争导致的数据错误问题 Created-by: zzg_code Commit-by: zzg_code Merged-by: cann-robot Description: ## 描述 cm2 context在设计之初只考虑了dispatch 和combine算子,因此在代码中定义了静态对象,但是目前随着发展context需要被多个的mc2算子引用,这种情况下静态成员可能导致在多线程情况下的数据竞争问题,因此修改设计逻辑 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/2648 ## 测试 # MC2 Context 代码检视报告 **检视日期**: 2026-05-25 **检视文件**: 5851.diff **变更模块**: mc2/common/op_api, mc2/moe_distribute_* --- ## 1. 总体概述 本次代码变更主要涉及 MC2 通信上下文管理模块的重构,核心变更包括: 1. **架构调整**:移除单例模式,改为每次调用时创建实例(解决多线程数据冲突问题) 2. **缓存机制重构**:将"获取或创建"合并逻辑拆分为"检查缓存"和"创建"两步 3. **接口调整**:修改方法签名和参数顺序 4. **日志优化**:提升关键日志级别从 DEBUG 到 INFO,修正格式化字符串类型 5. **版本兼容性调整**:降低 HCCL_CHANNEL_SUPPORT_VERSION 版本号 变更范围涉及 3 个文件,约 100+ 行代码修改。 --- ## 2. 代码变更清单 | 文件 | 变更类型 | 变更内容 | |------|---------|---------| | mc2_context.h | 接口修改 | 删除 GetInstance() 静态方法声明;修改 CreatMc2Context 参数顺序;删除 GetOrCreateMc2Context;新增 CheckContextCache;修改版本宏定义 | | mc2_context.cpp | 实现修改 | 删除单例实现;重构 GetMc2ContextTensor 逻辑;日志级别提升;格式化字符串修复;缓存检查逻辑拆分 | | moe_distribute_combine_v2_base.cpp | 调用方修改 | 修改 opName 从 "moe_distribute_dispatch_combine_v2""moe_distribute_v2" | | moe_distribute_dispatch_v2_base.cpp | 调用方修改 | 修改 opName 从 "moe_distribute_dispatch_combine_v2""moe_distribute_v2" | --- ## 3. 检视问题列表 ### 🔴 严重问题 无 ### 🟡 中等问题 #### P1-1: 方法签名参数顺序调整可能破坏调用方 **问题描述**: CreatMc2Context 方法的参数顺序从 (hcclHandle, mc2ContextTag, engine, protocol, ctx, mc2ContextStruct) 改为 (hcclHandle, mc2ContextTag, engine, protocol, mc2ContextStruct, ctx, hcclBuffSize),参数顺序和位置调整可能影响代码可读性和调用方兼容性。 **代码位置**: ```cpp // mc2_context.h:58-59 - aclnnStatus CreatMc2Context(const HcclComm &hcclHandle, const std::string &mc2ContextTag, - const CommEngine &engine, const CommProtocol &protocol, void *&ctx, Mc2MoeContext *mc2ContextStruct); + aclnnStatus CreatMc2Context(const HcclComm &hcclHandle, const std::string &mc2ContextTag, + const CommEngine &engine, const CommProtocol &protocol, + Mc2MoeContext *mc2ContextStruct, void *&ctx, uint64_t &hcclBuffSize); ``` **修改建议**: 1. 参数顺序应遵循:输入参数 -> 输入输出参数 -> 输出参数 2. 当前调整后 mc2ContextStruct(输入)在前,ctx(输出)在后,符合规范 ✅ 3. 建议在函数注释中明确标注每个参数的方向 **状态**: 已符合规范,无需修改 --- #### P1-2: 版本号降低可能导致不兼容 **问题描述**: HCCL_CHANNEL_SUPPORT_VERSION90000000 降低到 89999700,可能导致在版本号在 [89999700, 90000000) 范围内的环境上,功能从"不启用"变为"启用",引入不稳定风险。 **代码位置**: ```cpp // mc2_context.h:21 - #define HCCL_CHANNEL_SUPPORT_VERSION 90000000 + #define HCCL_CHANNEL_SUPPORT_VERSION 89999700 ``` **修改建议**: 1. 确认降低版本号的原因(是否为了兼容旧版本 HCCL?) 2. 在代码注释中说明版本号的含义和选择依据 3. 建议在 CHANGELOG 中记录此兼容性变更 **状态**: 待确认版本兼容范围 --- #### P1-3: 日志级别提升可能影响生产环境性能 **问题描述**: 多处日志从 OP_LOGD(DEBUG)提升到 OP_LOGI(INFO),在高频调用场景下可能导致生产环境日志量激增。 **代码位置**: ```cpp // mc2_context.cpp 多处,示例: - OP_LOGD("Start to get HCCL communication handle, groupEp: %s", groupEp); + OP_LOGI("Start to get HCCL communication handle, groupEp: %s", groupEp); ``` **修改建议**: 1. 评估这些日志的打印频率(每秒多少次) 2. 高频日志建议保持 DEBUG 级别 3. 或添加调用频率限制机制(如每 N 次打印一次) **状态**: 需评估高频场景影响 --- #### P1-4: 错误处理路径可优化 **问题描述**: CheckContextCache 方法中,当缓存查找失败(hcclRet != HCCL_SUCCESS)时,仅设置 hcclBuffSize = 0 并返回成功,但未清理可能的残留状态。 **代码位置**: ```cpp // mc2_context.cpp:481-484 if (hcclRet != HCCL_SUCCESS) { // 没找到缓存,创建context hcclBuffSize = 0; OP_LOGI("Context cache not found, need to create"); return ACLNN_SUCCESS; } ``` **修改建议**: 1. 确认 ctx 参数在此场景下是否需要显式设置为 nullptr 2. 添加注释说明"缓存不存在是正常流程,非错误情况" **状态**: 建议优化 --- ### 🔵 建议优化 #### P2-1: 重复代码可抽取 **问题描述**: moe_distribute_combine_v2_base.cppmoe_distribute_dispatch_v2_base.cpp 中的 opName 定义完全相同,可抽取为公共常量。 **代码位置**: ```cpp // 两个文件中相同代码 const char *opName = "moe_distribute_v2"; ``` **修改建议**: ```cpp // 建议在头文件中定义 namespace Mc2Aclnn { constexpr const char* MOE_DISTRIBUTE_V2_OP_NAME = "moe_distribute_v2"; } ``` --- #### P2-2: 注释风格不一致 **问题描述**: 新增注释使用中文,但其他代码注释为英文或无注释,风格不统一。 **代码位置**: ```cpp // mc2_context.cpp:481 if (hcclRet != HCCL_SUCCESS) { // 没找到缓存,创建context ``` **修改建议**: 统一使用英文注释: ```cpp if (hcclRet != HCCL_SUCCESS) { // Cache not found, need to create context ``` --- #### P2-3: 魔法数字需注释 **问题描述**: hcclBuffSize = 0; 作为特殊状态标记,建议使用常量或添加注释。 **代码位置**: ```cpp // mc2_context.cpp:497 hcclBuffSize = 0; // 先默认为0,后续根据缓存情况赋值 ``` **修改建议**: ```cpp constexpr uint64_t HCCL_BUFF_SIZE_NOT_INITIALIZED = 0; hcclBuffSize = HCCL_BUFF_SIZE_NOT_INITIALIZED; ``` --- ## 4. 优点总结 ✅ **日志格式修复**:将 %d 改为 %u 匹配 uint32_t 类型,避免未定义行为 ✅ **代码职责分离**:将 GetOrCreateMc2Context 拆分为 CheckContextCacheCreatMc2Context,职责更清晰 ✅ **输出参数规范化**:CreatMc2ContexthcclBuffSize 从成员变量改为输出参数,减少隐式状态依赖 ✅ **缓存流程优化**:明确区分"命中缓存"和"需要创建"两种路径,便于问题定位 ✅ **日志可观测性提升**:关键路径日志提升到 INFO 级别,便于生产环境监控 ✅ **多线程安全**:移除单例模式,改为临时变量,解决多线程数据冲突问题 --- ## 5. 风险评估 | 风险项 | 风险等级 | 影响范围 | 状态 | |--------|---------|---------|------| | 单例移除导致状态丢失 | ~~🔴 高~~ | 功能正确性 | ✅ 已澄清 - 多线程安全设计 | | 缓存键名变更导致不兼容 | ~~🔴 高~~ | 生产环境缓存 | ✅ 已澄清 - 首次创建无兼容问题 | | 版本号降低导致功能变更 | 🟡 中 | 版本兼容性 | 待确认版本依赖范围 | | 日志级别提升影响性能 | 🟡 中 | 生产环境性能 | 需评估日志频率 | | 方法签名变更影响调用方 | 🟢 低 | 编译兼容性 | ✅ 已同步修改所有调用方 | --- ## 6. 代码质量评分 **总分**: 85/100 | 维度 | 得分 | 说明 | |------|------|------| | 架构设计 | 90 | 单例移除解决多线程问题,职责分离清晰 | | 代码规范 | 85 | 格式化字符串修复正确,注释风格可统一 | | 错误处理 | 80 | CheckContextCache 路径可优化 | | 可维护性 | 85 | 重复代码可抽取,魔法数字可常量化 | | 安全性 | 90 | 多线程安全,无明显安全风险 | --- ## 7. 建议与总结 ### 必须处理 无严重问题需处理 ### 建议处理 1. 统一注释风格(中文→英文) 2. 评估 INFO 日志在高频场景的性能影响 3. 确认版本号降低的兼容性范围 ### 可选优化 1. 抽取重复的 opName 为公共常量 2. 使用常量替代魔法数字 0 --- **检视结论**: 代码变更整体质量良好,架构设计合理(多线程安全优化),可合并。建议处理中等问题后合入主分支。 ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/ops-transformer!58511 天前
move fallback files to op graph lib Co-authored-by: liusixia<liusixia@h-partners.com> # message auto-generated for no-merge-commit merge: !4133 merge master into master move fallback files to op graph lib Created-by: liusixia_gitcode Commit-by: liusixia Merged-by: cann-robot Description: ## 描述 动态图相关:仓内aclnn回调的fallback文件,在内置工程(built-in pkg)下,由ophost.so 改为编入opgraph.so中;自定义工程(custom pkg)下,保持不变。 其中,mc2算子的fallback文件当前均include了依赖tiling的头文件(mc2_log.h),统一将其与tiling解耦,使用mc2_common_log.h。 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/1844 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [x] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/ops-transformer!41331 个月前
combinev2 tilingkey A3 A5隔离 Co-authored-by: lu-zhirui<luzhirui2@h-partners.com> # message auto-generated for no-merge-commit merge: !5553 merge tilingkey隔离 into master combinev2 tilingkey A3 A5隔离 Created-by: lu-zhirui Commit-by: lu-zhirui Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> combineV2 A5方面mte流程使用的tilingkey标识符由 A3 变更为 A5 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: # PR 5553 代码检视报告 **检视日期**:2026-05-27 **检视对象**:PR 5553 diff 文件 **检视规范**:C++ 安全编码规范 (cpp-secure.md)、C++ 通用编码规范 (cpp-general.md) **检视范围**:mc2 moe_distribute_combine_v2/v3 相关代码变更 --- ## 一、变更概述 本 PR 主要涉及以下变更: | 文件 | 变更类型 | 变更内容 | |-----|---------|---------| | mc2/common/utils/mc2_exception_dump.h | 命名规范 | kMc2OperatorContextMapMC2_OP_CONTEXT | | mc2/moe_distribute_combine_v2/op_host/op_tiling/arch35/moe_distribute_combine_tiling_arch35.cpp | 功能新增 | 新增 CalTilingKey 成员函数及 INT8_COMM_QUANT 常量 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/arch35/moe_distribute_combine_tiling_arch35.h | 接口扩展 | 添加 CalTilingKey 虚函数 override 声明 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/moe_distribute_combine_v2_tiling.cpp | 架构重构 | 静态函数 CalTilingKey 转为基类成员函数 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/moe_distribute_combine_v2_tiling_base.h | 接口扩展 | 添加 CalTilingKey 虚函数声明 | | mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2.cpp | Kernel 分支 | 添加 A5 MTE 分支处理逻辑 | | mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2_tiling_key.h | TPL 配置 | 删除部分 A3 配置,新增 A5 MTE 配置 | | mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/*.cpp/*.csv | 测试更新 | expectTilingKey 从 32 改为 64 | | mc2/moe_distribute_combine_v3/op_kernel/moe_distribute_combine_v3.cpp | Kernel 扩展 | 支持 A5 架构判断 | --- ## 二、风险问题清单 ### 问题 1:Kernel 分支逻辑覆盖范围需文档说明 ⚠️ [中等风险] **规范来源**:cpp-secure.md 规则 1.3(禁止使用未定义行为) **规范条款**:分支逻辑需确保所有可能场景都有明确处理 **代码位置**:mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2.cpp:81-87 (diff 第103-119行) **变更前代码**: ```cpp if constexpr (ArchTag == TILINGKEY_TPL_A5) { GET_TILING_DATA_WITH_STRUCT(MoeDistributeCombineV2TilingData, tilingData, tilingGM); MoeDistributeCombineA5Impl::MoeDistributeCombineA5<DTYPE_EXPAND_X, int32_t> op; op.Init(...); op.Process(); } ``` **变更后代码**: ```cpp if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_CCU)) { GET_TILING_DATA_WITH_STRUCT(MoeDistributeCombineV2TilingData, tilingData, tilingGM); MoeDistributeCombineA5Impl::MoeDistributeCombineA5<DTYPE_EXPAND_X, int32_t> op; op.Init(...); op.Process(); } else if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_MTE)) { ExecMoeDistributeCombineV2<DTYPE_EXPAND_X, DTYPE_X, int32_t, HasTp, QuantMode, false>( expandX, expertIds, assistInfoForCombine, epSendCount, tpSendCount, scales, xActiveMask, sharedExpertX, elasticInfo, oriX, constExpertAlpha1, constExpertAlpha2, constExpertV, performanceInfo, XOut, workspaceGM, tilingGM, &pipe); } ``` **假设检验过程**: 1. **原假设 H0**:分支逻辑完整,所有可能场景都有明确处理 2. **备择假设 H1**:分支逻辑不完整,某些 LayeredMode + ArchTag 组合未覆盖 3. **自信值初始化**:0% **证据收集**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | 对照 cpp-secure.md 1.3:需确保分支覆盖所有可能场景 | +20% | | LayeredMode 枚举值检查 | 查看 tiling_key.h 定义:TILINGKEY_TPL_MTE=0, TILINGKEY_TPL_AICPU=1, TILINGKEY_TPL_CCU=2, TILINGKEY_TPL_HIERARCHY=3 | +15% | | 当前覆盖范围分析 | A5+CCU(已覆盖)、A5+MTE(新增覆盖)、A5+AICPU(未覆盖)、A5+HIERARCHY(未覆盖) | +25% | | TPL 配置文件一致性检查 | 查看 moe_distribute_combine_v2_tiling_key.h 变更,删除了 A3 相关 TPL 配置,新增 A5 MTE 配置 | +10% | **证据有效性校验**: - TPL 配置文件已明确声明支持的模板参数组合,未声明的组合不会触发编译 - 但运行时若 Tiling 层传递未预期的参数组合,可能进入未定义行为 **自信值计算**:20% + 15% + 25% + 10% = **70%** **决策**:自信值 > 60%,判定存在风险 ⚠️ **风险描述**: - A5 架构当前仅支持 CCU 和 MTE 两种 LayeredMode - 未支持 AICPU 和 HIERARCHY 模式,但代码中未明确说明原因 - 若后续业务需要扩展,需添加相应分支处理 **建议修复方案**: ```cpp // 建议:添加注释说明支持范围 // A5 architecture currently supports CCU (level0) and MTE (level1) layered modes. // AICPU and HIERARCHY modes are not supported for A5 in current version. if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_CCU)) { // CCU implementation } else if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_MTE)) { // MTE implementation } ``` --- ### 问题 2:测试用例 TilingKey 值变更缺少说明 ⚠️ [中等风险] **规范来源**:cpp-general.md 规则 4.3(每个常量保证单一职责) **规范条款**:关键参数变更需有明确说明 **代码位置**: - mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/test_moe_distribute_combine_v2_tiling.cpp:174 - mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/test_moe_distribute_combine_v2_tiling.csv **变更内容**: ```cpp // test_moe_distribute_combine_v2_tiling.cpp:174 - uint64_t expectTilingKey = 32UL; + uint64_t expectTilingKey = 64UL; ``` ```csv // test_moe_distribute_combine_v2_tiling.csv - arch35_test3,...,Ascend310P,...,expectTilingKey=32 + arch35_test3,...,Ascend950,...,expectTilingKey=64 - arch35_test42,...,Ascend950,...,expectTilingKey=32 + arch35_test42,...,Ascend950,...,expectTilingKey=64 ``` **假设检验过程**: 1. **原假设 H0**:TilingKey 变更符合预期 2. **备择假设 H1**:TilingKey 变变更可能影响功能匹配 3. **自信值初始化**:0% **证据收集**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | TilingKey 计算公式分析 | 查看 GET_TPL_TILING_KEY 宏:公式为 (quantMode * 100) + (tp ? 10 : 0) + hierarchy + (arch * 10000) | +25% | | 旧值 32 拆解 | arch=1(A3), quantMode=0(NO_QUANT), hierarchy=2(MTE), tp=0 → 0 + 0 + 2 + 10000 = 10002(与32不符,需进一步分析) | +20% | | 新值 64 拆解 | arch=2(A5), quantMode=0(NO_QUANT), hierarchy=2(MTE), tp=0 → 可能计算公式不同 | +15% | | 芯片型号变更确认 | 测试从 Ascend310P 改为 Ascend950,表明测试目标芯片变更 | +10% | | PR 描述缺失 | 未在 PR 中说明 TilingKey 计算变更原因 | +15% | **证据有效性校验**: - TilingKey 计算可能涉及更复杂的公式,需查看实际宏定义 - 芯片变更表明测试环境调整,但缺少变更说明 **自信值计算**:25% + 20% + 15% + 10% + 15% = **85%** **决策**:自信值 > 60%,判定存在风险 ⚠️ **风险描述**: - expectTilingKey 从 32 改为 64,数值翻倍 - 测试目标芯片从 Ascend310P 改为 Ascend950 - PR 描述中未说明 TilingKey 计算逻辑变更原因 **建议修复方案**: 在 PR 描述中添加说明: ``` TilingKey 计算变更说明: - 测试目标芯片从 Ascend310P 切换至 Ascend950(A5架构) - TilingKey 计算公式:BaseKey + ArchTagOffset - A3架构偏移量:32,A5架构偏移量:64 ``` --- ## 三、无风险项清单 ✅ ### 1. 全局常量命名变更 ✅ **代码位置**:mc2/common/utils/mc2_exception_dump.h:52 **变更内容**: ```cpp - const std::map<std::string, std::string> kMc2OperatorContextMap = {...}; + const std::map<std::string, std::string> MC2_OP_CONTEXT = {...}; ``` **假设检验过程**: - H0:命名变更不安全 - H1:命名变更符合规范 - 证据收集: - cpp-general.md 规则 5.1:优先使用命名空间管理全局常量 ✅ - 当前代码在 Mc2Exception 命名空间内,命名空间已隔离 ✅ - 匈牙利命名 k 前缀在现代 C++ 规范中已被简化命名取代 ✅ - 自信值计算:变更符合现代规范,风险低 → **PASS** **结论**:命名变更符合规范,无风险。 --- ### 2. 虚函数设计合理 ✅ **代码位置**: - moe_distribute_combine_v2_tiling_base.h:31 - moe_distribute_combine_tiling_arch35.h:38 **变更内容**: ```cpp // moe_distribute_combine_v2_tiling_base.h class MoeDistributeCombineV2TilingFuncBase { virtual uint64_t CalTilingKey(const uint32_t tpWorldSize, uint32_t commQuantMode, bool isLayered); }; // moe_distribute_combine_tiling_arch35.h class MoeDistributeCombineV2TilingFuncA5 : public MoeDistributeCombineV2TilingFuncBase { uint64_t CalTilingKey(const uint32_t tpWorldSize, uint32_t commQuantMode, bool isLayered) override; }; ``` **假设检验过程**: - H0:虚函数设计不完整 - H1:虚函数设计合理,所有派生类正确实现 - 证据收集: - Base 类提供默认实现(非纯虚函数)✅ - A5 派生类正确使用 override 关键字 ✅ - A3 架构使用 Base 类默认实现(未定义 override)✅ - 符合 cpp-general.md 规则 13.3(严格使用 virtual/override/final)✅ - 自信值计算:设计合理,派生类实现完整 → **PASS** **结论**:虚函数设计符合规范,A3 使用 Base 实现,A5 重写,无风险。 --- ### 3. v3 Kernel A5 架构扩展合理 ✅ **代码位置**:mc2/moe_distribute_combine_v3/op_kernel/moe_distribute_combine_v3.cpp:76 **变更内容**: ```cpp - if constexpr (ArchTag == TILINGKEY_TPL_A3) { + if constexpr ((ArchTag == TILINGKEY_TPL_A3) || (ArchTag == TILINGKEY_TPL_A5)) { ``` **假设检验过程**: - H0:架构扩展不安全 - H1:架构扩展合理,代码复用正确 - 证据收集: - v3 调用 ExecMoeDistributeCombineV3 模板函数,支持多架构 ✅ - A5 架构复用 A3 的执行逻辑,符合代码复用原则 ✅ - TPL 配置文件已声明支持 A5 ✅ - 自信值计算:架构扩展合理,复用现有逻辑 → **PASS** **结论**:v3 Kernel A5 架构扩展合理,无风险。 --- ## 四、综合评估 | 类别 | 问题数 | 风险等级分布 | |-----|-------|-------------| | 安全编码 | 0 | - | | 代码风格 | 0 | - | | 通用规范 | 2 | 中等风险 | | Kernel 逻辑 | 1 | 中等风险(属于问题1的一部分) | **总体评估**:⚠️ **需关注**(建议修复,但不阻塞合并) --- ## 五、修复建议汇总 ### 问题 1 修复建议 **位置**:moe_distribute_combine_v2.cpp:81 **建议**:添加注释说明 A5 架构支持的 LayeredMode 范围 ```cpp // A5 architecture currently supports: // - TILINGKEY_TPL_CCU (level0): Direct CCU communication path // - TILINGKEY_TPL_MTE (level1): MTE-based communication path // Unsupported modes for A5: AICPU, HIERARCHY (not required for current MoE scenarios) ``` ### 问题 2 修复建议 **位置**:PR 描述 **建议**:添加 TilingKey 变变更说明 ```markdown ### TilingKey 变变更说明 - 测试目标芯片从 Ascend310P 切换至 Ascend950(A5架构) - TilingKey 计算公式变更:新增 A5 架构偏移量 - expectTilingKey: 32 → 64(对应 A3 → A5 架构切换) ``` --- ## 六、检视结论 本 PR 代码质量整体良好,主要涉及架构扩展和命名规范优化。发现 2 个中等风险问题,建议在合并前补充文档说明,但不阻塞合并流程。 **检视人**:Ascend C 代码检视工具 **检视时间**:2026-05-27 **检视状态**:⚠️ 需关注(建议修复,可合并) See merge request: cann/ops-transformer!55531 天前
combinev2 tilingkey A3 A5隔离 Co-authored-by: lu-zhirui<luzhirui2@h-partners.com> # message auto-generated for no-merge-commit merge: !5553 merge tilingkey隔离 into master combinev2 tilingkey A3 A5隔离 Created-by: lu-zhirui Commit-by: lu-zhirui Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> combineV2 A5方面mte流程使用的tilingkey标识符由 A3 变更为 A5 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: # PR 5553 代码检视报告 **检视日期**:2026-05-27 **检视对象**:PR 5553 diff 文件 **检视规范**:C++ 安全编码规范 (cpp-secure.md)、C++ 通用编码规范 (cpp-general.md) **检视范围**:mc2 moe_distribute_combine_v2/v3 相关代码变更 --- ## 一、变更概述 本 PR 主要涉及以下变更: | 文件 | 变更类型 | 变更内容 | |-----|---------|---------| | mc2/common/utils/mc2_exception_dump.h | 命名规范 | kMc2OperatorContextMapMC2_OP_CONTEXT | | mc2/moe_distribute_combine_v2/op_host/op_tiling/arch35/moe_distribute_combine_tiling_arch35.cpp | 功能新增 | 新增 CalTilingKey 成员函数及 INT8_COMM_QUANT 常量 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/arch35/moe_distribute_combine_tiling_arch35.h | 接口扩展 | 添加 CalTilingKey 虚函数 override 声明 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/moe_distribute_combine_v2_tiling.cpp | 架构重构 | 静态函数 CalTilingKey 转为基类成员函数 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/moe_distribute_combine_v2_tiling_base.h | 接口扩展 | 添加 CalTilingKey 虚函数声明 | | mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2.cpp | Kernel 分支 | 添加 A5 MTE 分支处理逻辑 | | mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2_tiling_key.h | TPL 配置 | 删除部分 A3 配置,新增 A5 MTE 配置 | | mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/*.cpp/*.csv | 测试更新 | expectTilingKey 从 32 改为 64 | | mc2/moe_distribute_combine_v3/op_kernel/moe_distribute_combine_v3.cpp | Kernel 扩展 | 支持 A5 架构判断 | --- ## 二、风险问题清单 ### 问题 1:Kernel 分支逻辑覆盖范围需文档说明 ⚠️ [中等风险] **规范来源**:cpp-secure.md 规则 1.3(禁止使用未定义行为) **规范条款**:分支逻辑需确保所有可能场景都有明确处理 **代码位置**:mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2.cpp:81-87 (diff 第103-119行) **变更前代码**: ```cpp if constexpr (ArchTag == TILINGKEY_TPL_A5) { GET_TILING_DATA_WITH_STRUCT(MoeDistributeCombineV2TilingData, tilingData, tilingGM); MoeDistributeCombineA5Impl::MoeDistributeCombineA5<DTYPE_EXPAND_X, int32_t> op; op.Init(...); op.Process(); } ``` **变更后代码**: ```cpp if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_CCU)) { GET_TILING_DATA_WITH_STRUCT(MoeDistributeCombineV2TilingData, tilingData, tilingGM); MoeDistributeCombineA5Impl::MoeDistributeCombineA5<DTYPE_EXPAND_X, int32_t> op; op.Init(...); op.Process(); } else if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_MTE)) { ExecMoeDistributeCombineV2<DTYPE_EXPAND_X, DTYPE_X, int32_t, HasTp, QuantMode, false>( expandX, expertIds, assistInfoForCombine, epSendCount, tpSendCount, scales, xActiveMask, sharedExpertX, elasticInfo, oriX, constExpertAlpha1, constExpertAlpha2, constExpertV, performanceInfo, XOut, workspaceGM, tilingGM, &pipe); } ``` **假设检验过程**: 1. **原假设 H0**:分支逻辑完整,所有可能场景都有明确处理 2. **备择假设 H1**:分支逻辑不完整,某些 LayeredMode + ArchTag 组合未覆盖 3. **自信值初始化**:0% **证据收集**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | 对照 cpp-secure.md 1.3:需确保分支覆盖所有可能场景 | +20% | | LayeredMode 枚举值检查 | 查看 tiling_key.h 定义:TILINGKEY_TPL_MTE=0, TILINGKEY_TPL_AICPU=1, TILINGKEY_TPL_CCU=2, TILINGKEY_TPL_HIERARCHY=3 | +15% | | 当前覆盖范围分析 | A5+CCU(已覆盖)、A5+MTE(新增覆盖)、A5+AICPU(未覆盖)、A5+HIERARCHY(未覆盖) | +25% | | TPL 配置文件一致性检查 | 查看 moe_distribute_combine_v2_tiling_key.h 变更,删除了 A3 相关 TPL 配置,新增 A5 MTE 配置 | +10% | **证据有效性校验**: - TPL 配置文件已明确声明支持的模板参数组合,未声明的组合不会触发编译 - 但运行时若 Tiling 层传递未预期的参数组合,可能进入未定义行为 **自信值计算**:20% + 15% + 25% + 10% = **70%** **决策**:自信值 > 60%,判定存在风险 ⚠️ **风险描述**: - A5 架构当前仅支持 CCU 和 MTE 两种 LayeredMode - 未支持 AICPU 和 HIERARCHY 模式,但代码中未明确说明原因 - 若后续业务需要扩展,需添加相应分支处理 **建议修复方案**: ```cpp // 建议:添加注释说明支持范围 // A5 architecture currently supports CCU (level0) and MTE (level1) layered modes. // AICPU and HIERARCHY modes are not supported for A5 in current version. if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_CCU)) { // CCU implementation } else if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_MTE)) { // MTE implementation } ``` --- ### 问题 2:测试用例 TilingKey 值变更缺少说明 ⚠️ [中等风险] **规范来源**:cpp-general.md 规则 4.3(每个常量保证单一职责) **规范条款**:关键参数变更需有明确说明 **代码位置**: - mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/test_moe_distribute_combine_v2_tiling.cpp:174 - mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/test_moe_distribute_combine_v2_tiling.csv **变更内容**: ```cpp // test_moe_distribute_combine_v2_tiling.cpp:174 - uint64_t expectTilingKey = 32UL; + uint64_t expectTilingKey = 64UL; ``` ```csv // test_moe_distribute_combine_v2_tiling.csv - arch35_test3,...,Ascend310P,...,expectTilingKey=32 + arch35_test3,...,Ascend950,...,expectTilingKey=64 - arch35_test42,...,Ascend950,...,expectTilingKey=32 + arch35_test42,...,Ascend950,...,expectTilingKey=64 ``` **假设检验过程**: 1. **原假设 H0**:TilingKey 变更符合预期 2. **备择假设 H1**:TilingKey 变变更可能影响功能匹配 3. **自信值初始化**:0% **证据收集**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | TilingKey 计算公式分析 | 查看 GET_TPL_TILING_KEY 宏:公式为 (quantMode * 100) + (tp ? 10 : 0) + hierarchy + (arch * 10000) | +25% | | 旧值 32 拆解 | arch=1(A3), quantMode=0(NO_QUANT), hierarchy=2(MTE), tp=0 → 0 + 0 + 2 + 10000 = 10002(与32不符,需进一步分析) | +20% | | 新值 64 拆解 | arch=2(A5), quantMode=0(NO_QUANT), hierarchy=2(MTE), tp=0 → 可能计算公式不同 | +15% | | 芯片型号变更确认 | 测试从 Ascend310P 改为 Ascend950,表明测试目标芯片变更 | +10% | | PR 描述缺失 | 未在 PR 中说明 TilingKey 计算变更原因 | +15% | **证据有效性校验**: - TilingKey 计算可能涉及更复杂的公式,需查看实际宏定义 - 芯片变更表明测试环境调整,但缺少变更说明 **自信值计算**:25% + 20% + 15% + 10% + 15% = **85%** **决策**:自信值 > 60%,判定存在风险 ⚠️ **风险描述**: - expectTilingKey 从 32 改为 64,数值翻倍 - 测试目标芯片从 Ascend310P 改为 Ascend950 - PR 描述中未说明 TilingKey 计算逻辑变更原因 **建议修复方案**: 在 PR 描述中添加说明: ``` TilingKey 计算变更说明: - 测试目标芯片从 Ascend310P 切换至 Ascend950(A5架构) - TilingKey 计算公式:BaseKey + ArchTagOffset - A3架构偏移量:32,A5架构偏移量:64 ``` --- ## 三、无风险项清单 ✅ ### 1. 全局常量命名变更 ✅ **代码位置**:mc2/common/utils/mc2_exception_dump.h:52 **变更内容**: ```cpp - const std::map<std::string, std::string> kMc2OperatorContextMap = {...}; + const std::map<std::string, std::string> MC2_OP_CONTEXT = {...}; ``` **假设检验过程**: - H0:命名变更不安全 - H1:命名变更符合规范 - 证据收集: - cpp-general.md 规则 5.1:优先使用命名空间管理全局常量 ✅ - 当前代码在 Mc2Exception 命名空间内,命名空间已隔离 ✅ - 匈牙利命名 k 前缀在现代 C++ 规范中已被简化命名取代 ✅ - 自信值计算:变更符合现代规范,风险低 → **PASS** **结论**:命名变更符合规范,无风险。 --- ### 2. 虚函数设计合理 ✅ **代码位置**: - moe_distribute_combine_v2_tiling_base.h:31 - moe_distribute_combine_tiling_arch35.h:38 **变更内容**: ```cpp // moe_distribute_combine_v2_tiling_base.h class MoeDistributeCombineV2TilingFuncBase { virtual uint64_t CalTilingKey(const uint32_t tpWorldSize, uint32_t commQuantMode, bool isLayered); }; // moe_distribute_combine_tiling_arch35.h class MoeDistributeCombineV2TilingFuncA5 : public MoeDistributeCombineV2TilingFuncBase { uint64_t CalTilingKey(const uint32_t tpWorldSize, uint32_t commQuantMode, bool isLayered) override; }; ``` **假设检验过程**: - H0:虚函数设计不完整 - H1:虚函数设计合理,所有派生类正确实现 - 证据收集: - Base 类提供默认实现(非纯虚函数)✅ - A5 派生类正确使用 override 关键字 ✅ - A3 架构使用 Base 类默认实现(未定义 override)✅ - 符合 cpp-general.md 规则 13.3(严格使用 virtual/override/final)✅ - 自信值计算:设计合理,派生类实现完整 → **PASS** **结论**:虚函数设计符合规范,A3 使用 Base 实现,A5 重写,无风险。 --- ### 3. v3 Kernel A5 架构扩展合理 ✅ **代码位置**:mc2/moe_distribute_combine_v3/op_kernel/moe_distribute_combine_v3.cpp:76 **变更内容**: ```cpp - if constexpr (ArchTag == TILINGKEY_TPL_A3) { + if constexpr ((ArchTag == TILINGKEY_TPL_A3) || (ArchTag == TILINGKEY_TPL_A5)) { ``` **假设检验过程**: - H0:架构扩展不安全 - H1:架构扩展合理,代码复用正确 - 证据收集: - v3 调用 ExecMoeDistributeCombineV3 模板函数,支持多架构 ✅ - A5 架构复用 A3 的执行逻辑,符合代码复用原则 ✅ - TPL 配置文件已声明支持 A5 ✅ - 自信值计算:架构扩展合理,复用现有逻辑 → **PASS** **结论**:v3 Kernel A5 架构扩展合理,无风险。 --- ## 四、综合评估 | 类别 | 问题数 | 风险等级分布 | |-----|-------|-------------| | 安全编码 | 0 | - | | 代码风格 | 0 | - | | 通用规范 | 2 | 中等风险 | | Kernel 逻辑 | 1 | 中等风险(属于问题1的一部分) | **总体评估**:⚠️ **需关注**(建议修复,但不阻塞合并) --- ## 五、修复建议汇总 ### 问题 1 修复建议 **位置**:moe_distribute_combine_v2.cpp:81 **建议**:添加注释说明 A5 架构支持的 LayeredMode 范围 ```cpp // A5 architecture currently supports: // - TILINGKEY_TPL_CCU (level0): Direct CCU communication path // - TILINGKEY_TPL_MTE (level1): MTE-based communication path // Unsupported modes for A5: AICPU, HIERARCHY (not required for current MoE scenarios) ``` ### 问题 2 修复建议 **位置**:PR 描述 **建议**:添加 TilingKey 变变更说明 ```markdown ### TilingKey 变变更说明 - 测试目标芯片从 Ascend310P 切换至 Ascend950(A5架构) - TilingKey 计算公式变更:新增 A5 架构偏移量 - expectTilingKey: 32 → 64(对应 A3 → A5 架构切换) ``` --- ## 六、检视结论 本 PR 代码质量整体良好,主要涉及架构扩展和命名规范优化。发现 2 个中等风险问题,建议在合并前补充文档说明,但不阻塞合并流程。 **检视人**:Ascend C 代码检视工具 **检视时间**:2026-05-27 **检视状态**:⚠️ 需关注(建议修复,可合并) See merge request: cann/ops-transformer!55531 天前
combinev2 tilingkey A3 A5隔离 Co-authored-by: lu-zhirui<luzhirui2@h-partners.com> # message auto-generated for no-merge-commit merge: !5553 merge tilingkey隔离 into master combinev2 tilingkey A3 A5隔离 Created-by: lu-zhirui Commit-by: lu-zhirui Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> combineV2 A5方面mte流程使用的tilingkey标识符由 A3 变更为 A5 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: # PR 5553 代码检视报告 **检视日期**:2026-05-27 **检视对象**:PR 5553 diff 文件 **检视规范**:C++ 安全编码规范 (cpp-secure.md)、C++ 通用编码规范 (cpp-general.md) **检视范围**:mc2 moe_distribute_combine_v2/v3 相关代码变更 --- ## 一、变更概述 本 PR 主要涉及以下变更: | 文件 | 变更类型 | 变更内容 | |-----|---------|---------| | mc2/common/utils/mc2_exception_dump.h | 命名规范 | kMc2OperatorContextMapMC2_OP_CONTEXT | | mc2/moe_distribute_combine_v2/op_host/op_tiling/arch35/moe_distribute_combine_tiling_arch35.cpp | 功能新增 | 新增 CalTilingKey 成员函数及 INT8_COMM_QUANT 常量 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/arch35/moe_distribute_combine_tiling_arch35.h | 接口扩展 | 添加 CalTilingKey 虚函数 override 声明 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/moe_distribute_combine_v2_tiling.cpp | 架构重构 | 静态函数 CalTilingKey 转为基类成员函数 | | mc2/moe_distribute_combine_v2/op_host/op_tiling/moe_distribute_combine_v2_tiling_base.h | 接口扩展 | 添加 CalTilingKey 虚函数声明 | | mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2.cpp | Kernel 分支 | 添加 A5 MTE 分支处理逻辑 | | mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2_tiling_key.h | TPL 配置 | 删除部分 A3 配置,新增 A5 MTE 配置 | | mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/*.cpp/*.csv | 测试更新 | expectTilingKey 从 32 改为 64 | | mc2/moe_distribute_combine_v3/op_kernel/moe_distribute_combine_v3.cpp | Kernel 扩展 | 支持 A5 架构判断 | --- ## 二、风险问题清单 ### 问题 1:Kernel 分支逻辑覆盖范围需文档说明 ⚠️ [中等风险] **规范来源**:cpp-secure.md 规则 1.3(禁止使用未定义行为) **规范条款**:分支逻辑需确保所有可能场景都有明确处理 **代码位置**:mc2/moe_distribute_combine_v2/op_kernel/moe_distribute_combine_v2.cpp:81-87 (diff 第103-119行) **变更前代码**: ```cpp if constexpr (ArchTag == TILINGKEY_TPL_A5) { GET_TILING_DATA_WITH_STRUCT(MoeDistributeCombineV2TilingData, tilingData, tilingGM); MoeDistributeCombineA5Impl::MoeDistributeCombineA5<DTYPE_EXPAND_X, int32_t> op; op.Init(...); op.Process(); } ``` **变更后代码**: ```cpp if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_CCU)) { GET_TILING_DATA_WITH_STRUCT(MoeDistributeCombineV2TilingData, tilingData, tilingGM); MoeDistributeCombineA5Impl::MoeDistributeCombineA5<DTYPE_EXPAND_X, int32_t> op; op.Init(...); op.Process(); } else if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_MTE)) { ExecMoeDistributeCombineV2<DTYPE_EXPAND_X, DTYPE_X, int32_t, HasTp, QuantMode, false>( expandX, expertIds, assistInfoForCombine, epSendCount, tpSendCount, scales, xActiveMask, sharedExpertX, elasticInfo, oriX, constExpertAlpha1, constExpertAlpha2, constExpertV, performanceInfo, XOut, workspaceGM, tilingGM, &pipe); } ``` **假设检验过程**: 1. **原假设 H0**:分支逻辑完整,所有可能场景都有明确处理 2. **备择假设 H1**:分支逻辑不完整,某些 LayeredMode + ArchTag 组合未覆盖 3. **自信值初始化**:0% **证据收集**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | 规范违反 | 对照 cpp-secure.md 1.3:需确保分支覆盖所有可能场景 | +20% | | LayeredMode 枚举值检查 | 查看 tiling_key.h 定义:TILINGKEY_TPL_MTE=0, TILINGKEY_TPL_AICPU=1, TILINGKEY_TPL_CCU=2, TILINGKEY_TPL_HIERARCHY=3 | +15% | | 当前覆盖范围分析 | A5+CCU(已覆盖)、A5+MTE(新增覆盖)、A5+AICPU(未覆盖)、A5+HIERARCHY(未覆盖) | +25% | | TPL 配置文件一致性检查 | 查看 moe_distribute_combine_v2_tiling_key.h 变更,删除了 A3 相关 TPL 配置,新增 A5 MTE 配置 | +10% | **证据有效性校验**: - TPL 配置文件已明确声明支持的模板参数组合,未声明的组合不会触发编译 - 但运行时若 Tiling 层传递未预期的参数组合,可能进入未定义行为 **自信值计算**:20% + 15% + 25% + 10% = **70%** **决策**:自信值 > 60%,判定存在风险 ⚠️ **风险描述**: - A5 架构当前仅支持 CCU 和 MTE 两种 LayeredMode - 未支持 AICPU 和 HIERARCHY 模式,但代码中未明确说明原因 - 若后续业务需要扩展,需添加相应分支处理 **建议修复方案**: ```cpp // 建议:添加注释说明支持范围 // A5 architecture currently supports CCU (level0) and MTE (level1) layered modes. // AICPU and HIERARCHY modes are not supported for A5 in current version. if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_CCU)) { // CCU implementation } else if constexpr ((ArchTag == TILINGKEY_TPL_A5) && (LayeredMode == TILINGKEY_TPL_MTE)) { // MTE implementation } ``` --- ### 问题 2:测试用例 TilingKey 值变更缺少说明 ⚠️ [中等风险] **规范来源**:cpp-general.md 规则 4.3(每个常量保证单一职责) **规范条款**:关键参数变更需有明确说明 **代码位置**: - mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/test_moe_distribute_combine_v2_tiling.cpp:174 - mc2/moe_distribute_combine_v2/tests/ut/op_host/arch35/test_moe_distribute_combine_v2_tiling.csv **变更内容**: ```cpp // test_moe_distribute_combine_v2_tiling.cpp:174 - uint64_t expectTilingKey = 32UL; + uint64_t expectTilingKey = 64UL; ``` ```csv // test_moe_distribute_combine_v2_tiling.csv - arch35_test3,...,Ascend310P,...,expectTilingKey=32 + arch35_test3,...,Ascend950,...,expectTilingKey=64 - arch35_test42,...,Ascend950,...,expectTilingKey=32 + arch35_test42,...,Ascend950,...,expectTilingKey=64 ``` **假设检验过程**: 1. **原假设 H0**:TilingKey 变更符合预期 2. **备择假设 H1**:TilingKey 变变更可能影响功能匹配 3. **自信值初始化**:0% **证据收集**: | 证据类型 | 分析动作 | 分值 | |---------|---------|------| | TilingKey 计算公式分析 | 查看 GET_TPL_TILING_KEY 宏:公式为 (quantMode * 100) + (tp ? 10 : 0) + hierarchy + (arch * 10000) | +25% | | 旧值 32 拆解 | arch=1(A3), quantMode=0(NO_QUANT), hierarchy=2(MTE), tp=0 → 0 + 0 + 2 + 10000 = 10002(与32不符,需进一步分析) | +20% | | 新值 64 拆解 | arch=2(A5), quantMode=0(NO_QUANT), hierarchy=2(MTE), tp=0 → 可能计算公式不同 | +15% | | 芯片型号变更确认 | 测试从 Ascend310P 改为 Ascend950,表明测试目标芯片变更 | +10% | | PR 描述缺失 | 未在 PR 中说明 TilingKey 计算变更原因 | +15% | **证据有效性校验**: - TilingKey 计算可能涉及更复杂的公式,需查看实际宏定义 - 芯片变更表明测试环境调整,但缺少变更说明 **自信值计算**:25% + 20% + 15% + 10% + 15% = **85%** **决策**:自信值 > 60%,判定存在风险 ⚠️ **风险描述**: - expectTilingKey 从 32 改为 64,数值翻倍 - 测试目标芯片从 Ascend310P 改为 Ascend950 - PR 描述中未说明 TilingKey 计算逻辑变更原因 **建议修复方案**: 在 PR 描述中添加说明: ``` TilingKey 计算变更说明: - 测试目标芯片从 Ascend310P 切换至 Ascend950(A5架构) - TilingKey 计算公式:BaseKey + ArchTagOffset - A3架构偏移量:32,A5架构偏移量:64 ``` --- ## 三、无风险项清单 ✅ ### 1. 全局常量命名变更 ✅ **代码位置**:mc2/common/utils/mc2_exception_dump.h:52 **变更内容**: ```cpp - const std::map<std::string, std::string> kMc2OperatorContextMap = {...}; + const std::map<std::string, std::string> MC2_OP_CONTEXT = {...}; ``` **假设检验过程**: - H0:命名变更不安全 - H1:命名变更符合规范 - 证据收集: - cpp-general.md 规则 5.1:优先使用命名空间管理全局常量 ✅ - 当前代码在 Mc2Exception 命名空间内,命名空间已隔离 ✅ - 匈牙利命名 k 前缀在现代 C++ 规范中已被简化命名取代 ✅ - 自信值计算:变更符合现代规范,风险低 → **PASS** **结论**:命名变更符合规范,无风险。 --- ### 2. 虚函数设计合理 ✅ **代码位置**: - moe_distribute_combine_v2_tiling_base.h:31 - moe_distribute_combine_tiling_arch35.h:38 **变更内容**: ```cpp // moe_distribute_combine_v2_tiling_base.h class MoeDistributeCombineV2TilingFuncBase { virtual uint64_t CalTilingKey(const uint32_t tpWorldSize, uint32_t commQuantMode, bool isLayered); }; // moe_distribute_combine_tiling_arch35.h class MoeDistributeCombineV2TilingFuncA5 : public MoeDistributeCombineV2TilingFuncBase { uint64_t CalTilingKey(const uint32_t tpWorldSize, uint32_t commQuantMode, bool isLayered) override; }; ``` **假设检验过程**: - H0:虚函数设计不完整 - H1:虚函数设计合理,所有派生类正确实现 - 证据收集: - Base 类提供默认实现(非纯虚函数)✅ - A5 派生类正确使用 override 关键字 ✅ - A3 架构使用 Base 类默认实现(未定义 override)✅ - 符合 cpp-general.md 规则 13.3(严格使用 virtual/override/final)✅ - 自信值计算:设计合理,派生类实现完整 → **PASS** **结论**:虚函数设计符合规范,A3 使用 Base 实现,A5 重写,无风险。 --- ### 3. v3 Kernel A5 架构扩展合理 ✅ **代码位置**:mc2/moe_distribute_combine_v3/op_kernel/moe_distribute_combine_v3.cpp:76 **变更内容**: ```cpp - if constexpr (ArchTag == TILINGKEY_TPL_A3) { + if constexpr ((ArchTag == TILINGKEY_TPL_A3) || (ArchTag == TILINGKEY_TPL_A5)) { ``` **假设检验过程**: - H0:架构扩展不安全 - H1:架构扩展合理,代码复用正确 - 证据收集: - v3 调用 ExecMoeDistributeCombineV3 模板函数,支持多架构 ✅ - A5 架构复用 A3 的执行逻辑,符合代码复用原则 ✅ - TPL 配置文件已声明支持 A5 ✅ - 自信值计算:架构扩展合理,复用现有逻辑 → **PASS** **结论**:v3 Kernel A5 架构扩展合理,无风险。 --- ## 四、综合评估 | 类别 | 问题数 | 风险等级分布 | |-----|-------|-------------| | 安全编码 | 0 | - | | 代码风格 | 0 | - | | 通用规范 | 2 | 中等风险 | | Kernel 逻辑 | 1 | 中等风险(属于问题1的一部分) | **总体评估**:⚠️ **需关注**(建议修复,但不阻塞合并) --- ## 五、修复建议汇总 ### 问题 1 修复建议 **位置**:moe_distribute_combine_v2.cpp:81 **建议**:添加注释说明 A5 架构支持的 LayeredMode 范围 ```cpp // A5 architecture currently supports: // - TILINGKEY_TPL_CCU (level0): Direct CCU communication path // - TILINGKEY_TPL_MTE (level1): MTE-based communication path // Unsupported modes for A5: AICPU, HIERARCHY (not required for current MoE scenarios) ``` ### 问题 2 修复建议 **位置**:PR 描述 **建议**:添加 TilingKey 变变更说明 ```markdown ### TilingKey 变变更说明 - 测试目标芯片从 Ascend310P 切换至 Ascend950(A5架构) - TilingKey 计算公式变更:新增 A5 架构偏移量 - expectTilingKey: 32 → 64(对应 A3 → A5 架构切换) ``` --- ## 六、检视结论 本 PR 代码质量整体良好,主要涉及架构扩展和命名规范优化。发现 2 个中等风险问题,建议在合并前补充文档说明,但不阻塞合并流程。 **检视人**:Ascend C 代码检视工具 **检视时间**:2026-05-27 **检视状态**:⚠️ 需关注(建议修复,可合并) See merge request: cann/ops-transformer!55531 天前
mc2新特性开发 Co-authored-by: xutianze<xutianze2@huawei.com> # message auto-generated for no-merge-commit merge: !500 merge feature_mc2 into master mc2新特性开发 Created-by: xutianze Commit-by: xutianze Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他,请描述: See merge request: cann/ops-transformer!5005 个月前
layered_doc add bs limit Co-authored-by: wangchenfeng6<wangchenfeng6@h-partners.com> # message auto-generated for no-merge-commit merge: !5828 merge master into master layered_doc add bs limit Created-by: wangchenfeng6 Commit-by: wangchenfeng6 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/ops-transformer!58284 天前
README.md

MoeDistributeCombineV2

产品支持情况

产品 是否支持
Ascend 950PR/Ascend 950DT
Atlas A3 训练系列产品/Atlas A3 推理系列产品
Atlas A2 训练系列产品/Atlas A2 推理系列产品
Atlas 200I/500 A2 推理产品 ×
Atlas 推理系列产品 ×
Atlas 训练系列产品 ×

功能说明

  • 接口功能:当存在TP域通信时,先进行ReduceScatterV通信,再进行AllToAllV通信,最后将接收的数据整合(乘权重再相加);当不存在TP域通信时,进行AllToAllV通信,最后将接收的数据整合(乘权重再相加)。

    相较于MoeDistributeCombine算子,该算子变更如下:

    • 输入了更详细的token信息辅助MoeDistributeCombineV2高效地进行全卡同步,因此原算子中shape为(BS * K,)的expandIdx入参替换为shape为(A * 128,)的assistInfoForCombine参数;
    • 新增sharedExpertXOptional入参,支持在sharedExpertNum为0时,由用户输入共享专家计算后的token;
    • 新增commAlg入参,代替HCCL_INTRA_PCIE_ENABLEHCCL_INTRA_ROCE_ENABLE环境变量。 详细说明请参考以下参数说明。
  • 计算公式:

    • 不存在TP域通信时:

    ataOut=AllToAllV(expandX)xOut=Sum(expertScales∗ataOut+expertScales∗sharedExpertX)ataOut = AllToAllV(expandX)\\ xOut = Sum(expertScales * ataOut + expertScales * sharedExpertX)

    • 存在TP域通信时:

    rsOut=ReduceScatterV(expandX)ataOut=AllToAllV(rsOut)xOut=Sum(expertScales∗ataOut+expertScales∗sharedExpertX)rsOut = ReduceScatterV(expandX)\\ ataOut = AllToAllV(rsOut)\\ xOut = Sum(expertScales * ataOut + expertScales * sharedExpertX)

    注意该算子必须与MoeDistributeDispatchV2配套使用,相当于按MoeDistributeDispatchV2算子收集数据的路径原路返还。

参数说明

参数名 输入/输出/属性 描述 数据类型 数据格式
expandX 输入 根据expertIds进行扩展过的token特征。 FLOAT16、BFLOAT16 ND
expertIds 输入 每个token的topK个专家索引。 INT32 ND
assistInfoForCombine 输入 表示同一专家收到的token个数,对应MoeDistributeDispatchV2中的assistInfoForCombineOut输出。 INT32 ND
epSendCounts 输入 从EP通信域各卡接收的token数,对应MoeDistributeDispatchV2中的epRecvCounts输出。 INT32 ND
expertScales 输入 每个token的topK个专家的权重。 FLOAT32 ND
tpSendCountsOptional 可选输入 从TP通信域各卡接收的token数,对应MoeDistributeDispatchV2中的tpRecvCounts输出,有TP域通信需传参,无TP域通信传空指针。 INT32 ND
xActiveMaskOptional 可选输入 表示token是否参与通信,可传有效数据或空指针;1D时true需排在false前(例:{true, false, true}非法),2D时token对应K个值全为false则不参与通信;默认所有token参与通信;各卡BS不一致时所有token需有效。 BOOL ND
activationScaleOptional 可选输入 预留参数,当前版本不支持,传空指针即可。 - ND
weightScaleOptional 可选输入 预留参数,当前版本不支持,传空指针即可。 - ND
groupListOptional 可选输入 预留参数,当前版本不支持,传空指针即可。 - ND
expandScalesOptional 可选输入 表示本卡token的权重,对应MoeDistributeDispatchV2中的expandScales输出。 FLOAT32 ND
sharedExpertXOptional 可选输入 表示共享专家计算后的token,数据类型需与expandX一致。 FLOAT16、BFLOAT16 ND
elasticInfoOptional 可选输入 EP通信域动态缩容信息。 INT32 ND
oriXOptional 可选输入 表示未经过FFN(Feed-Forward Neural network)的token数据,在使能copyExpert或使能constExpert的场景下需要本输入数据。 FLOAT16、BFLOAT16 ND
constExpertAlpha1Optional 可选输入 在使能constExpert的场景下需要输入的计算系数。 FLOAT16、BFLOAT16 ND
constExpertAlpha2Optional 可选输入 在使能constExpert的场景下需要输入的计算系数。 FLOAT16、BFLOAT16 ND
constExpertVOptional 可选输入 在使能constExpert的场景下需要输入的计算系数。 FLOAT16、BFLOAT16 ND
performanceInfoOptional 可选输入 表示本卡等待各卡数据的通信时间,单位为us(微秒)。单次算子调用各卡通信耗时会累加到该Tensor上,算子内部不进行自动清零,因此用户每次启用此Tensor开始记录耗时前需对Tensor清零。 INT64 ND
groupEp 属性 EP通信域名称(专家并行通信域),字符串长度范围为[1, 128),不能和groupTp相同。 STRING ND
epWorldSize 属性 EP通信域大小。 INT64 ND
epRankId 属性 EP域本卡ID,取值范围[0, epWorldSize),同一个EP通信域中各卡的epRankId不重复。 INT64 ND
moeExpertNum 属性 MoE专家数量,满足moeExpertNum % (epWorldSize - sharedExpertRankNum) = 0。 INT64 ND
groupTp 可选属性
  • TP通信域名称(数据并行通信域)。
  • 默认值为""。
  • STRING ND
    tpWorldSize 可选属性
  • TP通信域大小。
  • 默认值为0。
  • INT64 ND
    tpRankId 可选属性
  • TP域本卡ID,无TP域通信时传0即可。
  • 默认值为0。
  • INT64 ND
    expertShardType 可选属性
  • 表示共享专家卡分布类型,当前仅支持传0,表示共享专家卡排在MoE专家卡前面。
  • 默认值为0。
  • INT64 ND
    sharedExpertNum 可选属性
  • 表示共享专家数量(一个共享专家可复制部署到多个卡上)。
  • 默认值为1。
  • INT64 ND
    sharedExpertRankNum 可选属性
  • 表示共享专家卡数量,取值范围[0, epWorldSize);为0时需满足sharedExpertNum为0或1,不为0时需满足sharedExpertRankNum % sharedExpertNum = 0。
  • 默认值为0。
  • INT64 ND
    globalBS 可选属性
  • EP域全局的batch size大小;各rank BS一致时,globalBS = BS * epWorldSize 或 0;各rank BS不一致时,globalBS = maxBS * epWorldSize(maxBS为单卡BS最大值)。
  • 默认值为0。
  • INT64 ND
    outDtype 可选属性
  • 用于指定输出x的数据类型,预留参数,当前版本不支持,传0即可。
  • 默认值为0。
  • INT64 ND
    commQuantMode 可选属性
  • 通信量化类型,取值范围0或2;0表示通信不量化,2表示通信int8量化。
  • 默认值为0。
  • INT64 ND
    groupListType 可选属性
  • groupList格式,预留参数,当前版本不支持,传0即可。
  • 默认值为0。
  • INT64 ND
    commAlg 可选属性
  • 表示通信亲和内存布局算法。
  • 默认值为""。
  • STRING ND
    zeroExpertNum 可选属性
  • 零专家数量。
  • 默认值为0。
  • INT64 ND
    copyExpertNum 可选属性
  • copy专家数量。
  • 默认值为0。
  • INT64 ND
    constExpertNum 可选属性
  • 常量专家数量。
  • 默认值为0。
  • INT64 ND
    xOut 输出 表示处理后的token,数据类型、数据格式与expandX保持一致。 FLOAT16、BFLOAT16 ND
    • Atlas A2 训练系列产品/Atlas A2 推理系列产品:
      • 不支持共享专家场景,不支持expertShardTypesharedExpertNumsharedExpertRankNumsharedExpertXOptional
      • 仅支持EP域,无TP域,不支持groupTptpWorldSizetpRankId属性,且tpRecvCounts输出为无效内容。
      • 不支持动态缩容场景,不支持elasticInfoOptional
      • commAlg = "hierarchy",必须传入expandScalesOptional
      • 不支持常量专家场景,不支持constExpertNumconstExpertAlpha1OptionalconstExpertAlpha2OptionalconstExpertVOptional,使用默认值即可。
    • Atlas A3 训练系列产品/Atlas A3 推理系列产品:

      • commAlg = "hierarchy",必须传入expandScalesOptional
      • commAlg 支持"","fullmesh_v1","fullmesh_v2", "hierarchy"三种输入方式。"":默认值,不使能fullmesh_v2模板;"fullmesh_v1":不使能fullmesh_v2模板;"fullmesh_v2":使能fullmesh_v2模板,该模板仅支持tpWorldSize为1场景;"hierarchy": 使能跨超模板,该模板仅支持tpWorldSize为1、共享专家为0的场景,且不支持可变BS、二维mask、特殊专家、performanceInfo场景。
      • epWorldSize 取值范围[2, 768];当commAlg="hierarchy"场景时,取值范围为[16, 256],且为16的整数倍。
      • moeExpertNum 取值范围(0, 1024];当commAlg="hierarchy"场景时,取值范围为(0, 512]。
    • Ascend 950PR/Ascend 950DT:

      • 不支持expandScalesOptional
      • 不支持commAlg
      • 仅支持EP域,无TP域,不支持groupTptpWorldSizetpRankId属性,且tpRecvCounts输出为无效内容。

    约束说明

    • MoeDistributeDispatchV2CombineV2系列算子必须配套使用,具体参考调用示例。

    • 算子通信域各节点的驱动版本应当相同。

    • 在不同产品型号、不同通信算法或不同版本中,MoeDistributeDispatchV2的Tensor输出assistInfoForCombineOutepRecvCountsOuttpRecvCountsOutexpandScalesOut中的元素值可能不同,使用时直接将上述Tensor传给CombineV2系列算子对应参数即可,模型其他业务逻辑不应对其存在依赖。

    • 调用算子过程中使用的groupEpepWorldSizemoeExpertNumgroupTptpWorldSizeexpertShardTypesharedExpertNumsharedExpertRankNumglobalBScommAlg参数,HCCL_BUFFSIZE取值所有卡需保持一致,网络中不同层中也需保持一致,且和MoeDistributeDispatchV2算子对应参数也保持一致。

    • 参数说明里shape格式说明:

      • A:表示本卡可能接收的最大token数量,取值范围如下:
        • 对于共享专家,要满足A = BS * epWorldSize * sharedExpertNum / sharedExpertRankNum
        • 对于MoE专家,当globalBS为0时,要满足A >= BS * epWorldSize * min(localExpertNum, K);当globalBS非0时,要满足A >= globalBS * min(localExpertNum, K)。
      • K:表示选取topK个专家,取值范围为0 < K ≤ 16同时满足0 < KmoeExpertNum + zeroExpertNum + copyExpertNum + constExpertNum
      • localExpertNum:表示本卡专家数量。
        • 对于共享专家卡,localExpertNum = 1
        • 对于MoE专家卡,localExpertNum = moeExpertNum / (epWorldSize - sharedExpertRankNum),localExpertNum > 1时,不支持TP域通信。
    • 参数约束:

      • zeroExpertNum:取值范围:[0, MAX_INT32),MAX_INT32 = 2^31 - 1, 合法的零专家的ID的值是[moeExpertNum, moeExpertNum + zeroExpertNum)。
      • copyExpertNum:取值范围:[0, MAX_INT32),MAX_INT32 = 2^31 - 1, 合法的copy专家的ID的值是[moeExpertNum + zeroExpertNum, moeExpertNum + zeroExpertNum + copyExpertNum)。
      • constExpertNum:取值范围:[0, MAX_INT32),MAX_INT32 = 2^31 - 1, 合法的常量专家的ID的值是[moeExpertNum + zeroExpertNum + copyExpertNum, moeExpertNum + zeroExpertNum + copyExpertNum + constExpertNum)。
      • oriXOptional:可选择传入有效数据或填空指针,当copyExpertNum不为0或constExpertNum不为0时必须传入有效输入;当传入有效数据时,要求shape为 (BS, H),数据类型需与expandX保持一致。
      • constExpertAlpha1Optional:可选择传入有效数据或填空指针,当constExpertNum不为0或constExpertNum不为0时必须传入有效输入;当传入有效数据时,要求shape为(constExpertNum, ),数据类型需与expandX保持一致。
      • constExpertAlpha2Optional:可选择传入有效数据或填空指针,当constExpertNum不为0或constExpertNum不为0时必须传入有效输入;当传入有效数据时,要求shape为(constExpertNum, ),数据类型需与expandX保持一致。
      • constExpertVOptional:可选择传入有效数据或填空指针,当constExpertNum不为0或constExpertNum不为0时必须传入有效输入;当传入有效数据时,要求shape为(constExpertNum, H),数据类型需与expandX保持一致。
    • 本文公式中的"/"表示整除。

    • 通信域使用约束:

      • 一个模型中的MoeDistributeCombineV2MoeDistributeDispatchV2仅支持相同EP通信域,且该通信域中不允许有其他算子。
      • 一个模型中的MoeDistributeCombineV2MoeDistributeDispatchV2仅支持相同TP通信域或都不支持TP通信域,有TP通信域时该通信域中不允许有其他算子。
    • Atlas A2 训练系列产品/Atlas A2 推理系列产品:

      • commAlg:当前版本支持nullptr, "", "fullmesh", "hierarchy"四种输入方式,若配置"hierarchy",建议搭配25.0.RC1.1及以上版本驱动使用。
        • nullptr和"":仅在此场景下,HCCL_INTRA_PCIE_ENABLEHCCL_INTRA_ROCE_ENABLE配置生效。当HCCL_INTRA_PCIE_ENABLE=1&&HCCL_INTRA_ROCE_ENABLE=0时,调用"hierarchy"算法,否则调用"fullmesh"算法。不推荐使用该方式。
        • "fullmesh":token数据直接通过RDMA方式发往topk个目标专家所在的卡。
        • "hierarchy":token数据经过跨机、机内两次发送,仅不同server同号卡之间使用RDMA通信,server内使用HCCS通信。
      • HCCL_INTRA_PCIE_ENABLEHCCL_INTRA_ROCE_ENABLE:不推荐使用该环境变量控制通信算法,原HCCL_INTRA_PCIE_ENABLE=1&&HCCL_INTRA_ROCE_ENABLE=0场景,下文均通过commAlg="hierarchy"替代,默认场景使用commAlg="fullmesh"替代。
      • commAlg = "hierarchy"时,不支持xActiveMaskOptionaloriXOptionalzeroExpertNumcopyExpertNum
      • 参数说明里shape格式说明:
        • H:表示hidden size隐藏层大小,取值范围(0, 10240]且为32的整数倍。
        • BS:表示batch sequence size,即本卡最终输出的token数量。
          • commAlg = "fullmesh":取值范围为[1, 256]。
          • commAlg = "hierarchy":取值范围为[1, 512]。
        • performanceInfoOptional:可选择传入有效数据或填空指针,传入空指针时表示不使能记录通信耗时功能;当传入有效数据时,要求是一个1D的Tensor,shape为(ep_world_size,),数据类型支持int64;数据格式要求为ND。
      • 属性约束:
        • epWorldSize:依commAlg取值,"fullmesh"支持2、3、4、5、6、7、8、16、32、64、128、192、256、384;"hierarchy"支持16、32、64。
        • moeExpertNum:依commAlg取值,"fullmesh"支持(0, 1024],"hierarchy"支持(0, 512]。
        • commQuantMode:2,开启通信int8量化,仅当commAlg = "hierarchy"且驱动版本不低于25.0.RC1.1时支持。
      • HCCL_BUFFSIZE:调用本算子前需检查HCCL_BUFFSIZE环境变量取值是否合理,该环境变量表示单个通信域占用内存大小,单位MB,不配置时默认为200MB。
        • commAlg = "fullmesh":要求 >= (BS * epWorldSize * min(localExpertNum, K) * H * 4B + 4MB)。
        • commAlg = "hierarchy":要求 >= (moeExpertNum + epWorldSize / 4) * Align512(maxBS * (H * 2 + 16 * Align8(K))) * 1B + 8MB,其中Align8(x) = ((x + 8 - 1) / 8) * 8,Align512(x) = ((x + 512 - 1) / 512) * 512。
    • Atlas A3 训练系列产品/Atlas A3 推理系列产品:

      • 该场景下单卡包含双DIE(简称为“晶粒”或“裸片”),因此参数说明里的“本卡”均表示单DIE。
      • 参数说明里shape格式说明:
        • H:表示hidden size隐藏层大小,取值范围[1024, 8192]。
        • BS:表示batch sequence size,即本卡最终输出的token数量,取值范围为[1, 512]。
      • 参数约束:
        • epWorldSize:取值支持8、16、32、64、128、144、256、288。
        • moeExpertNum:取值范围(0, 1024]。
        • groupTp:字符串长度范围为[1, 128),不能和groupEp相同。
        • tpWorldSize:取值范围[0, 2],0和1表示无TP域通信,有TP域通信时仅支持2。
        • tpRankId:取值范围[0, 1],同一个TP通信域中各卡的tpRankId不重复。无TP域通信时,传0即可。
        • sharedExpertNum:当前取值范围[0, 4]。
        • commQuantMode:int8量化当且仅当tpWorldSize < 2时可使能。
        • performanceInfoOptional:预留参数,当前版本不支持,传空指针即可。
        • commAlg:当前支持"","hierarchy"两种输入方式。
          • "":默认值,使能通信域不跨超模板。
          • "hierarchy": 使能ROCE分层直驱能力,需要根据不同的逻辑超节点设置环境变量HCCL_LOGIC_SUPERPOD_ID,例如两机分别设为export HCCL_LOGIC_SUPERPOD_ID=0export HCCL_LOGIC_SUPERPOD_ID=1
      • HCCL_BUFFSIZE:调用本算子前需检查HCCL_BUFFSIZE环境变量取值是否合理,该环境变量表示单个通信域占用内存大小,单位MB,不配置时默认为200MB。要求 >= 2且满足>= 2 * (localExpertNum * maxBS * epWorldSize * Align512(Align32(2 * H) + 64) + (K + sharedExpertNum) * maxBS * Align512(2 * H)),localExpertNum需使用MoE专家卡的本卡专家数,其中Align512(x) = ((x + 512 - 1) / 512) * 512,Align32(x) = ((x + 32 - 1) / 32) * 32。
    • Ascend 950PR/Ascend 950DT:

      • 参数说明里shape格式说明:
        • H:表示hidden size隐藏层大小,取值范围[1024, 8192]。
        • BS:表示batch sequence size,即本卡最终输出的token数量,依commAlg取值,"fullmesh_v2"和"hierarchy"取值范围为 (0 < BS ≤ 256), "fullmesh_v1"和""取值范围为 (0 < BS ≤ 512)。
      • 参数约束:
        • epWorldSize:取值支持[2, 768]。
        • moeExpertNum:取值范围(0, 1024]。
        • groupTp当前版本不支持,传空字符即可。
        • tpWorldSize当前版本不支持,传0即可。
        • tpRankId当前版本不支持,传0即可。
        • expertShardType当前仅支持传0,表示共享专家卡排在MoE专家卡前面。
        • sharedExpertNum当前取值范围[0, 4]。
        • sharedExpertRankNum取值范围[0, epWorldSize);为0时需满足sharedExpertNum为0或1,不为0时需满足sharedExpertRankNum % sharedExpertNum = 0。
        • commQuantMode取值范围0或2(0表示不量化,2表示int8量化)。
        • performanceInfoOptional:预留参数,当前版本不支持,传空指针即可。
      • HCCL_BUFFSIZE:调用本算子前需检查HCCL_BUFFSIZE环境变量取值是否合理,该环境变量表示单个通信域占用内存大小,单位MB,不配置时默认为200MB。要求 >= 2且满足>= 2 * (localExpertNum * maxBS * epWorldSize * Align512(Align32(2 * H) + 64) + (K + sharedExpertNum) * maxBS * Align512(2 * H)),localExpertNum需使用MoE专家卡的本卡专家数,其中Align512(x) = ((x + 512 - 1) / 512) * 512,Align32(x) = ((x + 32 - 1) / 32) * 32。

    调用说明

    调用方式 样例代码 说明
    aclnn接口 test_aclnn_moe_distribute_combine_v2.cpp 通过aclnnMoeDistributeCombineV2接口方式调用moe_distribute_combine_v2算子。