HCCL 的 RFC 机制从方案对齐到代码落地的技术决策流程与实践指南【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hcclHCCLHuawei Collective Communication Library在docs/en/rfcs/目录下维护了一套面向技术方案设计的 RFCRequest for Comments机制用于在编码实现之前对齐解决方案、记录设计决策。本文以该目录的 README.md 为核心骨架结合 RFC 模板、编号注册表、三个已合并的 RFC 实例以及仓库源码完整讲解 HCCL 的 RFC 编号规则、两级 PR 流程、文档生命周期、模板写作要求以及 RFC 与experimental/目录代码落地的衔接方式。读完本文你将掌握为 HCCL 提交一个 RFC 从需求发起、编号抢占、文档评审到最终合并的完整路径并能对照仓库中的真实 RFC 理解其设计深度。一、为什么 HCCL 需要 RFC 机制集合通信库的每一次演进都牵动算子算法、拓扑适配、资源调度等多层代码。若无前置的方案对齐容易出现两种问题一是实现完成后才发现设计方向错误返工成本极高二是多人并行开发时对关键术语、接口契约的理解不一致导致评审和联调困难。RFC 机制正是为化解这些风险而设它在编码实现之前用一份结构化的文档把做什么、为什么这样做、接口契约是什么、影响范围有多大固定下来作为后续代码实现的契约。从 CONTRIBUTING_en.md 的贡献流程图可以看到新增特性New Feature的必经路径是提交 Requirement Issue → SIG 决策 → 设计系统方案 → 编写/修改 RFC → 提交 RFC 文档 PR → Maintainer 评审 → 合并 RFC → 再进入代码实现。也就是说RFC 合并是代码 PR 的前置门槛合并后的 RFC 方案即成为代码实现必须遵循的合同。当前docs/en/rfcs/目录中已有 3 个 RFC 完成合并并进入代码落地阶段分别对应三种典型的演进诉求详见第七节新算法引入BIRS、自定义算法扩展框架HCCL-ALGO-Plugin、执行器架构重构recursive_executor。二、RFC 目录结构与文件命名规则HCCL 的 RFC 文档全部存放在 docs/en/rfcs/ 目录分为三类文件文件作用0000-template.mdRFC 写作模板规定了 RFC 文档必须包含的章节结构INDEX.mdRFC 编号注册表登记所有已分配的 RFC 编号及状态NNNN-xxx-xxx.mdRFC 正文文档4 位编号 短描述RFC 文件的命名格式为{4-digit number}-{short description}.md例如0001-add-new-feature.md。具体约束如下编号4 位数字、零填充范围0001到9999描述英文小写、短横线分隔、简洁明了。仓库中的真实命名示例0001-add-batch-invariant-reducescatter.md—— BIRS 算法 RFC0002-HCCL-ALGO-Plugin.md—— 自定义算法扩展框架 RFC0003-executor-template-refactor.md—— 执行器模板重构 RFC这种编号 语义化短描述的命名方式让开发者仅凭文件名即可快速判断某个 RFC 的主题同时保证编号可作为唯一索引在INDEX.md中登记和追溯。三、编号机制核心两级 PR、最小号优先、永不回收RFC 编号的分配是整套机制的核心采用number-claiming PR轻量 RFC document PR重量的两级流程把占号和写文档解耦Number-claiming PR轻量只修改 INDEX.md新增一行占位记录为编号预留名额。该 PR 只包含 INDEX.md 的一行更新评审成本极低目的就是尽早把编号锁定避免后续文档写完后才发现编号冲突。RFC document PR重量编写 RFC 文档并提交评审。此时编号已通过 number-claiming PR 锁定无需再担心被别人抢占。编号分配遵循三条硬性规则顺序分配最小未用编号优先新编号取当前已分配的最大编号 1或表中最小的空缺号永不回收即使某个 RFC 后来被取代superseded其编号也绝不回收复用冲突解决若两人同时抢占同一编号后提交者必须 rebase 并改用新的最小编号。对应地INDEX.md 中的状态字段定义了三种取值状态含义reserved编号已被抢占number-claiming PR 已合并RFC 文档待提交或评审中acceptedRFC 文档 PR 已合并RFC 正式生效superseded已被后续 RFC 取代原文档末尾带有Superseded by 00NN标注截至当前仓库编号注册表 INDEX.md 已登记0001BIRS for A3状态accepted对应 PR #1440其余编号按规则依次可分配给后续需求。四、RFC 生命周期七阶段全流程README.md 将 RFC 的生命周期划分为七个阶段与 CONTRIBUTING_en.md 中的贡献流程一一对应阶段 1需求发起Requirement phase提交 Requirement 类型的 Issue等待 SIG 组接受。只有被 SIG 接受的需求Issue 打上accepted标签才能进入 RFC 流程。这一步是值得不值得做的关口避免资源浪费在低价值需求上。阶段 2编号抢占 PRNumber-claiming PR在 INDEX.md 中按最小未用编号规则新增一行占位记录状态置为reserved提交 number-claiming PR。标题和作者可以先用占位符。阶段 3占号 PR 合并编号被锁定状态保持reserved此时可以开始编写 RFC 文档。阶段 4写作阶段Writing phase严格依照 RFC 模板 编写系统方案。模板的各章节要求详见第五节。阶段 5评审阶段Review phase提交 RFC 文档 PR 进行评审根据反馈持续修改方案。评审在 PR 评论区进行三个已合并 RFC 均遵循此惯例详见其文档末尾的 Review Records 章节。阶段 6决策阶段Decision phase合并MergedMaintainer 通过评审打上/lgtm和/approve标签后合并随后将 INDEX.md 中对应行状态更新为acceptedRFC 正式生效。关闭Closed评审未通过PR 被关闭。编号保持reserved且不回收作者可重新发起评审流程。阶段 7实现阶段Implementation phase合并后的 RFC 作为实现契约后续代码 PR 必须遵循 RFC 方案。这也是 RFC 与 CONTRIBUTING_en.md 中RFC 合并 → 软件实现 → 代码评审合并流程的衔接点。五、RFC 模板解析一份合格方案文档的必备章节RFC 模板 是 RFC 文档的写作规范任何新 RFC 都必须遵循。模板头部要求填写三个元信息字段Start Date起始日期YYYY-MM-DD 格式RFC PR Number关联的 PR 号Related Issue关联的需求 Issue 号。正文部分定义了以下章节每个章节都有明确的写作意图章节作用写作要点Summary核心决策摘要评审者 30 秒内掌握核心决策及其理由后续内容均为支撑材料Background and Motivation背景与动机为什么需要该特性、解决什么问题、预期使用场景Terminology术语对齐消除评审歧义跨模块/跨仓库 RFC 必填单模块变更可省略表格形式Architecture and Interface Contract架构与接口契约回答系统如何组织 外部契约是什么不涉及模块内部实现含总体架构模块职责、时序图与外部/依赖接口Impact Analysis影响分析性能影响、对既有功能的影响范围、对构建/依赖/发布的影响Compatibility Considerations兼容性考虑是否影响向后兼容、是否需要特性开关、分阶段灰度策略、外部与依赖接口变更的兼容影响Detailed Design详细设计仅限模块内部实现按模块组织跨层特性按层拆分。每个模块小节含模块职责一句话、核心数据结构可用 UML、关键逻辑与算法、与其它模块的内部接口Algorithm Design算法设计涉及核心算法时填写算法原理与数学模型、复杂度分析时间/空间/通信量、正确性论证Test Plan测试计划UT / ST / 板级测试方案验证功能正确性与兼容性Risk Assessment风险评估潜在风险点与缓解措施Alternative Solutions备选方案其他被考虑的方案及其优缺点Open Issues未决问题设计阶段未解决或需进一步讨论的问题以仓库中的实际 RFC 为例可以直观看到模板的落地效果0001 BIRS RFC 完整覆盖了 Summary、Background含行业确定性通信需求的多场景论证、Detailed Design逻辑 2D 拓扑、Scratch 内存布局、3 线程模型、主通信循环伪代码、FinalStep 树形归约、Compatibility平台/rankSize/对齐约束表、Test Plan、Risk Assessment0002 HCCL-ALGO-Plugin RFC 额外使用了 mermaid 时序图描述自定义算法调用的三阶段流程并给出完整的 C 接口定义HcclAlgoPlugin_t函数表、HcclAlgoPluginParamABI 结构、REGISTER_HCCL_ALGO宏0003 executor-template-refactor RFC 包含了类图、流程图、时序图与大量可编译的 C 代码片段并给出了新旧架构的代码量对比表。六、SupersessionRFC 被取代时的处理规范当某个 RFC 的实现被后续 RFC 取代时按以下规则处理对应 README.md 的 Supersession 章节和 INDEX.md 的编号规则在被取代的 RFC 文档末尾追加一行标注 Superseded by 00NN将 INDEX.md 中对应行状态从accepted更新为superseded不修改原始编号——编号一经分配永不回收保证历史可追溯。这套规范保证了 RFC 编号作为稳定标识符的语义完整性即使方案被演进取代研究者依然可以通过编号定位到原始设计文档并通过Superseded by标注追踪演进脉络。七、已落地 RFC 实例从方案到代码的三种范式RFC 的生命力在于落地。当前仓库的三个 RFC 均已进入实现阶段且代码位置与 RFC 中声明的目录一一对应可以作为RFC 方案 → 代码契约的实证样本7.1 0001 BIRS新增算法与编译/运行时双门控0001 RFC 提出 BIRSBatchsize Invariant ReduceScatter算法针对昇腾 A3 服务器 SIO HCCS 混合互联拓扑在保证确定性归约顺序bit 级可复现的前提下提升大消息场景带宽利用率。其代码落地遵循 RFC 声明的隔离策略新增experimental/ops/reduce_scatter/birs/目录承载算法实现executor 层、executor 基类、核心算法模板reduce_scatter_birs.cc/.h、中间结果处理reduce_scatter_birs_inter.cc/.h通过编译选项ENABLE_EXPERIMENTAL构建命令bash build.sh --pkg --full --experimental与运行时环境变量HCCL_BIRS_ENABLE实现双重门控默认关闭、对既有 ReduceScatter 行为零影响用户侧 API 不变仍调用标准HcclReduceScatter()算法选择完全由环境变量控制。RFC 中还明确了适用约束仅限 A3 平台、rankSize 必须为偶数典型值 4/8/16、切片需满足HCCL_MIN_SLICE_ALIGN_910B对齐要求不满足条件时由MatchBIRS()检查自动回退到既有算法。7.2 0002 HCCL-ALGO-Plugin自定义算法动态库扩展框架0002 RFC 设计了一套零侵入的自定义算法扩展框架解决既有算法添加时面临的代码侵入、构建耦合、发布依赖与选择逻辑封闭四大问题。其代码落地于 src/algo_plugin/HcclAlgoPluginMgrhccl_algo_plugin_mgr.cc作为单例嵌入 HCCL 主库通过dlopen加载 PluginBroker 动态库并持有其函数表指针自定义算法通过 SDK 宏REGISTER_HCCL_ALGO(algName, soPath, fnSymbol)注册为全局静态对象加载时由构造函数自动写入私有注册表算法选择与执行分别经SelectAlg()/ExecuteAlg()接口路由无自定义算法匹配时自动回退到原始选择逻辑。该框架以 CMake 选项ENABLE_HCCL_ALGO_PLUGIN默认 OFF编译门控以环境变量HCCL_ALGO_PLUGIN_PATHPluginBroker 路径与HCCL_PLUGIN_ALG_DIR自定义算法根目录运行时控制未配置时所有新分支直接跳过HCCL 行为完全不变。7.3 0003 recursive_executor执行器架构重构与插件式集成0003 RFC 提出以HcclAlgorithm静态算法描述、OpsExecutor通用解释器、Template单层执行单元、CommPlanner通信计划生成器四层结构统一算法编排将 53 个专用 Executor 合并为 1 个通用执行器。其代码落地于 experimental/ops/op_common/recursive_executor/目录结构与 RFC 声明完全一致inc/algo_desc.hHcclAlgorithm/AlgoExecDesc/TemplateExecDesc三层描述结构executor/AdaptorExecutor桥接 src 的InsCollAlgBase与OpsExecutor递归编排selector/alg_selector.cc算法注册表按算法名查询HcclAlgorithmtemplate/aicpu/与template/comm_planners/AllGather Mesh/NHR 模板与通信计划器topo/topo_match_four_level.cc四级拓扑匹配器。该重构遵循 experimental/README_en.md 的运行时开关规范REGISTER_ALG宏在静态初始化时被IsRecursiveExecutorEnabled()守卫编译期常量recursiveExecutorEnabled默认false环境变量HCCL_EXPERIMENTAL_RECURSIVE_EXECUTORtrue仅在常量开启后才生效确保实验代码不会误入主链路。对应测试位于 test/ut/recursive_executor/algo_desc_test.cc及配套 stub。八、RFC 与代码落地的衔接experimental/ 目录与运行时开关RFC 机制与experimental/贡献目录构成了 HCCL 社区方案先行、原型验证、成熟合入的完整闭环。从 experimental/README_en.md 可以看到两者在制度上的呼应维度src/experimental/目标生产级代码快速原型验证评审RFC SIG 评审RFC SIG 评审质量生产级原型级稳定性保证 API 稳定不保证而 CONTRIBUTING_en.md 进一步规定社区贡献的新算子、新算法或扩展特性原则上必须提交到experimental/目录尽量避免修改src/下的稳定代码确需修改时必须说明理由与影响范围并获得 Committer 评审。此外实验特性必须提供运行时开关以便快速回滚开关命名为HCCL_EXPERIMENTAL_NAMEtrue并遵循IsXxxEnabled()的标准实现模式编译期常量优先、默认关闭。这一制度的实际效果可以从三个 RFC 的落地方案中看到共性模式编译期隔离实验代码置于独立目录通过 CMake 选项ENABLE_EXPERIMENTAL、ENABLE_HCCL_ALGO_PLUGIN或 OBJECT 库方式控制是否参与编译运行时门控默认关闭的环境变量开关HCCL_BIRS_ENABLE、HCCL_ALGO_PLUGIN_PATH、HCCL_EXPERIMENTAL_RECURSIVE_EXECUTOR用户 API 不变算法选择对用户透明不引入新的对外接口自动回退条件不满足或插件未匹配时自动回退到原始算法选择与执行逻辑。九、给贡献者的实践要点综合 RFC 目录 README、编号注册表 与 贡献指南为 HCCL 提交一个 RFC 的核心检查清单如下先提需求 Issue提交 Requirement 类型 Issue 并等待 SIG 接受避免方案未获认可就投入写作尽早占号SIG 接受后立即提交只含 INDEX.md 一行更新的 number-claiming PR锁定最小未用编号状态reserved严格按模板写作以 RFC 模板 为骨架重点写透 Summary30 秒可读完核心决策、Architecture and Interface Contract、Impact Analysis、Compatibility Considerations 与 Test Plan评审充分迭代RFC 文档 PR 的评审在评论区进行根据反馈持续修改合并需 Maintainer 打/lgtm与/approve合并后更新状态RFC 合并后立即将 INDEX.md 对应行状态改为accepted实现遵循契约代码 PR 必须遵循已合并 RFC 的方案实验代码落在experimental/目录并提供运行时开关被取代时规范标注如方案被后续 RFC 取代在原文档末尾添加 Superseded by 00NN并将注册表状态更新为superseded编号永不回收。通过这套机制HCCL 将设计决策沉淀为可检索、可追溯、可引用的文档资产——任何一个新特性从立项到落地都有据可查这正是大型基础设施项目在快速演进中保持架构一致性的关键保障。【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
HCCL 的 RFC 机制从方案对齐到代码落地的技术决策流程与实践指南【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hcclHCCLHuawei Collective Communication Library在docs/en/rfcs/目录下维护了一套面向技术方案设计的 RFCRequest for Comments机制用于在编码实现之前对齐解决方案、记录设计决策。本文以该目录的 README.md 为核心骨架结合 RFC 模板、编号注册表、三个已合并的 RFC 实例以及仓库源码完整讲解 HCCL 的 RFC 编号规则、两级 PR 流程、文档生命周期、模板写作要求以及 RFC 与experimental/目录代码落地的衔接方式。读完本文你将掌握为 HCCL 提交一个 RFC 从需求发起、编号抢占、文档评审到最终合并的完整路径并能对照仓库中的真实 RFC 理解其设计深度。一、为什么 HCCL 需要 RFC 机制集合通信库的每一次演进都牵动算子算法、拓扑适配、资源调度等多层代码。若无前置的方案对齐容易出现两种问题一是实现完成后才发现设计方向错误返工成本极高二是多人并行开发时对关键术语、接口契约的理解不一致导致评审和联调困难。RFC 机制正是为化解这些风险而设它在编码实现之前用一份结构化的文档把做什么、为什么这样做、接口契约是什么、影响范围有多大固定下来作为后续代码实现的契约。从 CONTRIBUTING_en.md 的贡献流程图可以看到新增特性New Feature的必经路径是提交 Requirement Issue → SIG 决策 → 设计系统方案 → 编写/修改 RFC → 提交 RFC 文档 PR → Maintainer 评审 → 合并 RFC → 再进入代码实现。也就是说RFC 合并是代码 PR 的前置门槛合并后的 RFC 方案即成为代码实现必须遵循的合同。当前docs/en/rfcs/目录中已有 3 个 RFC 完成合并并进入代码落地阶段分别对应三种典型的演进诉求详见第七节新算法引入BIRS、自定义算法扩展框架HCCL-ALGO-Plugin、执行器架构重构recursive_executor。二、RFC 目录结构与文件命名规则HCCL 的 RFC 文档全部存放在 docs/en/rfcs/ 目录分为三类文件文件作用0000-template.mdRFC 写作模板规定了 RFC 文档必须包含的章节结构INDEX.mdRFC 编号注册表登记所有已分配的 RFC 编号及状态NNNN-xxx-xxx.mdRFC 正文文档4 位编号 短描述RFC 文件的命名格式为{4-digit number}-{short description}.md例如0001-add-new-feature.md。具体约束如下编号4 位数字、零填充范围0001到9999描述英文小写、短横线分隔、简洁明了。仓库中的真实命名示例0001-add-batch-invariant-reducescatter.md—— BIRS 算法 RFC0002-HCCL-ALGO-Plugin.md—— 自定义算法扩展框架 RFC0003-executor-template-refactor.md—— 执行器模板重构 RFC这种编号 语义化短描述的命名方式让开发者仅凭文件名即可快速判断某个 RFC 的主题同时保证编号可作为唯一索引在INDEX.md中登记和追溯。三、编号机制核心两级 PR、最小号优先、永不回收RFC 编号的分配是整套机制的核心采用number-claiming PR轻量 RFC document PR重量的两级流程把占号和写文档解耦Number-claiming PR轻量只修改 INDEX.md新增一行占位记录为编号预留名额。该 PR 只包含 INDEX.md 的一行更新评审成本极低目的就是尽早把编号锁定避免后续文档写完后才发现编号冲突。RFC document PR重量编写 RFC 文档并提交评审。此时编号已通过 number-claiming PR 锁定无需再担心被别人抢占。编号分配遵循三条硬性规则顺序分配最小未用编号优先新编号取当前已分配的最大编号 1或表中最小的空缺号永不回收即使某个 RFC 后来被取代superseded其编号也绝不回收复用冲突解决若两人同时抢占同一编号后提交者必须 rebase 并改用新的最小编号。对应地INDEX.md 中的状态字段定义了三种取值状态含义reserved编号已被抢占number-claiming PR 已合并RFC 文档待提交或评审中acceptedRFC 文档 PR 已合并RFC 正式生效superseded已被后续 RFC 取代原文档末尾带有Superseded by 00NN标注截至当前仓库编号注册表 INDEX.md 已登记0001BIRS for A3状态accepted对应 PR #1440其余编号按规则依次可分配给后续需求。四、RFC 生命周期七阶段全流程README.md 将 RFC 的生命周期划分为七个阶段与 CONTRIBUTING_en.md 中的贡献流程一一对应阶段 1需求发起Requirement phase提交 Requirement 类型的 Issue等待 SIG 组接受。只有被 SIG 接受的需求Issue 打上accepted标签才能进入 RFC 流程。这一步是值得不值得做的关口避免资源浪费在低价值需求上。阶段 2编号抢占 PRNumber-claiming PR在 INDEX.md 中按最小未用编号规则新增一行占位记录状态置为reserved提交 number-claiming PR。标题和作者可以先用占位符。阶段 3占号 PR 合并编号被锁定状态保持reserved此时可以开始编写 RFC 文档。阶段 4写作阶段Writing phase严格依照 RFC 模板 编写系统方案。模板的各章节要求详见第五节。阶段 5评审阶段Review phase提交 RFC 文档 PR 进行评审根据反馈持续修改方案。评审在 PR 评论区进行三个已合并 RFC 均遵循此惯例详见其文档末尾的 Review Records 章节。阶段 6决策阶段Decision phase合并MergedMaintainer 通过评审打上/lgtm和/approve标签后合并随后将 INDEX.md 中对应行状态更新为acceptedRFC 正式生效。关闭Closed评审未通过PR 被关闭。编号保持reserved且不回收作者可重新发起评审流程。阶段 7实现阶段Implementation phase合并后的 RFC 作为实现契约后续代码 PR 必须遵循 RFC 方案。这也是 RFC 与 CONTRIBUTING_en.md 中RFC 合并 → 软件实现 → 代码评审合并流程的衔接点。五、RFC 模板解析一份合格方案文档的必备章节RFC 模板 是 RFC 文档的写作规范任何新 RFC 都必须遵循。模板头部要求填写三个元信息字段Start Date起始日期YYYY-MM-DD 格式RFC PR Number关联的 PR 号Related Issue关联的需求 Issue 号。正文部分定义了以下章节每个章节都有明确的写作意图章节作用写作要点Summary核心决策摘要评审者 30 秒内掌握核心决策及其理由后续内容均为支撑材料Background and Motivation背景与动机为什么需要该特性、解决什么问题、预期使用场景Terminology术语对齐消除评审歧义跨模块/跨仓库 RFC 必填单模块变更可省略表格形式Architecture and Interface Contract架构与接口契约回答系统如何组织 外部契约是什么不涉及模块内部实现含总体架构模块职责、时序图与外部/依赖接口Impact Analysis影响分析性能影响、对既有功能的影响范围、对构建/依赖/发布的影响Compatibility Considerations兼容性考虑是否影响向后兼容、是否需要特性开关、分阶段灰度策略、外部与依赖接口变更的兼容影响Detailed Design详细设计仅限模块内部实现按模块组织跨层特性按层拆分。每个模块小节含模块职责一句话、核心数据结构可用 UML、关键逻辑与算法、与其它模块的内部接口Algorithm Design算法设计涉及核心算法时填写算法原理与数学模型、复杂度分析时间/空间/通信量、正确性论证Test Plan测试计划UT / ST / 板级测试方案验证功能正确性与兼容性Risk Assessment风险评估潜在风险点与缓解措施Alternative Solutions备选方案其他被考虑的方案及其优缺点Open Issues未决问题设计阶段未解决或需进一步讨论的问题以仓库中的实际 RFC 为例可以直观看到模板的落地效果0001 BIRS RFC 完整覆盖了 Summary、Background含行业确定性通信需求的多场景论证、Detailed Design逻辑 2D 拓扑、Scratch 内存布局、3 线程模型、主通信循环伪代码、FinalStep 树形归约、Compatibility平台/rankSize/对齐约束表、Test Plan、Risk Assessment0002 HCCL-ALGO-Plugin RFC 额外使用了 mermaid 时序图描述自定义算法调用的三阶段流程并给出完整的 C 接口定义HcclAlgoPlugin_t函数表、HcclAlgoPluginParamABI 结构、REGISTER_HCCL_ALGO宏0003 executor-template-refactor RFC 包含了类图、流程图、时序图与大量可编译的 C 代码片段并给出了新旧架构的代码量对比表。六、SupersessionRFC 被取代时的处理规范当某个 RFC 的实现被后续 RFC 取代时按以下规则处理对应 README.md 的 Supersession 章节和 INDEX.md 的编号规则在被取代的 RFC 文档末尾追加一行标注 Superseded by 00NN将 INDEX.md 中对应行状态从accepted更新为superseded不修改原始编号——编号一经分配永不回收保证历史可追溯。这套规范保证了 RFC 编号作为稳定标识符的语义完整性即使方案被演进取代研究者依然可以通过编号定位到原始设计文档并通过Superseded by标注追踪演进脉络。七、已落地 RFC 实例从方案到代码的三种范式RFC 的生命力在于落地。当前仓库的三个 RFC 均已进入实现阶段且代码位置与 RFC 中声明的目录一一对应可以作为RFC 方案 → 代码契约的实证样本7.1 0001 BIRS新增算法与编译/运行时双门控0001 RFC 提出 BIRSBatchsize Invariant ReduceScatter算法针对昇腾 A3 服务器 SIO HCCS 混合互联拓扑在保证确定性归约顺序bit 级可复现的前提下提升大消息场景带宽利用率。其代码落地遵循 RFC 声明的隔离策略新增experimental/ops/reduce_scatter/birs/目录承载算法实现executor 层、executor 基类、核心算法模板reduce_scatter_birs.cc/.h、中间结果处理reduce_scatter_birs_inter.cc/.h通过编译选项ENABLE_EXPERIMENTAL构建命令bash build.sh --pkg --full --experimental与运行时环境变量HCCL_BIRS_ENABLE实现双重门控默认关闭、对既有 ReduceScatter 行为零影响用户侧 API 不变仍调用标准HcclReduceScatter()算法选择完全由环境变量控制。RFC 中还明确了适用约束仅限 A3 平台、rankSize 必须为偶数典型值 4/8/16、切片需满足HCCL_MIN_SLICE_ALIGN_910B对齐要求不满足条件时由MatchBIRS()检查自动回退到既有算法。7.2 0002 HCCL-ALGO-Plugin自定义算法动态库扩展框架0002 RFC 设计了一套零侵入的自定义算法扩展框架解决既有算法添加时面临的代码侵入、构建耦合、发布依赖与选择逻辑封闭四大问题。其代码落地于 src/algo_plugin/HcclAlgoPluginMgrhccl_algo_plugin_mgr.cc作为单例嵌入 HCCL 主库通过dlopen加载 PluginBroker 动态库并持有其函数表指针自定义算法通过 SDK 宏REGISTER_HCCL_ALGO(algName, soPath, fnSymbol)注册为全局静态对象加载时由构造函数自动写入私有注册表算法选择与执行分别经SelectAlg()/ExecuteAlg()接口路由无自定义算法匹配时自动回退到原始选择逻辑。该框架以 CMake 选项ENABLE_HCCL_ALGO_PLUGIN默认 OFF编译门控以环境变量HCCL_ALGO_PLUGIN_PATHPluginBroker 路径与HCCL_PLUGIN_ALG_DIR自定义算法根目录运行时控制未配置时所有新分支直接跳过HCCL 行为完全不变。7.3 0003 recursive_executor执行器架构重构与插件式集成0003 RFC 提出以HcclAlgorithm静态算法描述、OpsExecutor通用解释器、Template单层执行单元、CommPlanner通信计划生成器四层结构统一算法编排将 53 个专用 Executor 合并为 1 个通用执行器。其代码落地于 experimental/ops/op_common/recursive_executor/目录结构与 RFC 声明完全一致inc/algo_desc.hHcclAlgorithm/AlgoExecDesc/TemplateExecDesc三层描述结构executor/AdaptorExecutor桥接 src 的InsCollAlgBase与OpsExecutor递归编排selector/alg_selector.cc算法注册表按算法名查询HcclAlgorithmtemplate/aicpu/与template/comm_planners/AllGather Mesh/NHR 模板与通信计划器topo/topo_match_four_level.cc四级拓扑匹配器。该重构遵循 experimental/README_en.md 的运行时开关规范REGISTER_ALG宏在静态初始化时被IsRecursiveExecutorEnabled()守卫编译期常量recursiveExecutorEnabled默认false环境变量HCCL_EXPERIMENTAL_RECURSIVE_EXECUTORtrue仅在常量开启后才生效确保实验代码不会误入主链路。对应测试位于 test/ut/recursive_executor/algo_desc_test.cc及配套 stub。八、RFC 与代码落地的衔接experimental/ 目录与运行时开关RFC 机制与experimental/贡献目录构成了 HCCL 社区方案先行、原型验证、成熟合入的完整闭环。从 experimental/README_en.md 可以看到两者在制度上的呼应维度src/experimental/目标生产级代码快速原型验证评审RFC SIG 评审RFC SIG 评审质量生产级原型级稳定性保证 API 稳定不保证而 CONTRIBUTING_en.md 进一步规定社区贡献的新算子、新算法或扩展特性原则上必须提交到experimental/目录尽量避免修改src/下的稳定代码确需修改时必须说明理由与影响范围并获得 Committer 评审。此外实验特性必须提供运行时开关以便快速回滚开关命名为HCCL_EXPERIMENTAL_NAMEtrue并遵循IsXxxEnabled()的标准实现模式编译期常量优先、默认关闭。这一制度的实际效果可以从三个 RFC 的落地方案中看到共性模式编译期隔离实验代码置于独立目录通过 CMake 选项ENABLE_EXPERIMENTAL、ENABLE_HCCL_ALGO_PLUGIN或 OBJECT 库方式控制是否参与编译运行时门控默认关闭的环境变量开关HCCL_BIRS_ENABLE、HCCL_ALGO_PLUGIN_PATH、HCCL_EXPERIMENTAL_RECURSIVE_EXECUTOR用户 API 不变算法选择对用户透明不引入新的对外接口自动回退条件不满足或插件未匹配时自动回退到原始算法选择与执行逻辑。九、给贡献者的实践要点综合 RFC 目录 README、编号注册表 与 贡献指南为 HCCL 提交一个 RFC 的核心检查清单如下先提需求 Issue提交 Requirement 类型 Issue 并等待 SIG 接受避免方案未获认可就投入写作尽早占号SIG 接受后立即提交只含 INDEX.md 一行更新的 number-claiming PR锁定最小未用编号状态reserved严格按模板写作以 RFC 模板 为骨架重点写透 Summary30 秒可读完核心决策、Architecture and Interface Contract、Impact Analysis、Compatibility Considerations 与 Test Plan评审充分迭代RFC 文档 PR 的评审在评论区进行根据反馈持续修改合并需 Maintainer 打/lgtm与/approve合并后更新状态RFC 合并后立即将 INDEX.md 对应行状态改为accepted实现遵循契约代码 PR 必须遵循已合并 RFC 的方案实验代码落在experimental/目录并提供运行时开关被取代时规范标注如方案被后续 RFC 取代在原文档末尾添加 Superseded by 00NN并将注册表状态更新为superseded编号永不回收。通过这套机制HCCL 将设计决策沉淀为可检索、可追溯、可引用的文档资产——任何一个新特性从立项到落地都有据可查这正是大型基础设施项目在快速演进中保持架构一致性的关键保障。【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
