昇腾CANN ascend-boost-comm：M×N 算子复用是怎么做到的
CANN 生态里 50 多个仓库，每个仓库有十几到几十个算子。这些算子之间存在大量公共功能：内存搬运算子需要数据切分、通信算子需要拓扑发现、融合算子需要 shape 推导。如果每个仓库各自实现一遍，代码膨胀的同时，任何一个公共功能的 bug 修复或性能优化需要推开几十个仓库的 PR。
ascend-boost-comm 的设计目标就是把这个问题变成 M×N 的复用：M 个上层算子仓库通过 N 个公共模块共享实现，而不是 M×N 的各自重复。
它不是通信库——名字里带 comm 容易误读。ascend-boost-comm 是算子公共平台，提供的是中间件性质的基础能力：数据切片、拓扑感知、生命周期管理、跨算子状态共享。
为什么需要中间件层
看一个实际例子。CANN 里有三个仓库都需要对输入张量做二维切分：
- ops-math 的 Reduction 算子需要沿 dim 切分
- ops-nn 的 MatMul 需要按 M×K 分块
- ops-transformer 的 FlashAttention 需要按 Br×Bc 分块
没有 ascend-boost-comm 时，三个仓库各自写切分逻辑：
// ops-math/reduce/tiling.cpp —— 自己的切分代码// ops-nn/matmul/tiling.cpp —— 差不多的切分代码，换了个名字// ops-transformer/flash_attn/tiling.cpp —— 还是差不多的切分代码有 ascend-boost-comm 时，三个仓库共用统一的切分框架：
// ascend-boost-comm/tiling/tiling_framework.h// 所有算子仓库共用此接口template<intDIM>structTilingStrategy{intnum_blocks[DIM];// 每维切多少块intblock_size[DIM];// 每块的大小intremainder_block[DIM];// 尾块的策略（对齐/不对齐）staticTilingStrategycompute(constShape<DIM>&total_shape,// 总shapeconstShape<DIM>&max_block,// 单块最大容量（L1约束）TilingPolicy policy// 切分策略){TilingStrategy result;for(intd=0;d<DIM;d++){// 按 L1 容量约束计算最优分块intmax_elements=max_block[d];inttotal=total_shape[d];result.num_blocks[d]=(total+max_elements-1)/max_elements;result.block_size[d]=max_elements;// 尾块处理：可以选择对齐到 16（Cube 约束）或保持原始大小intlast_size=total-(result.num_blocks[d]-1)*max_elements;if(policy==ALIGN_TO_CUBE&&last_size%16!=0){result.remainder_block[d]=(last_size+15)/16*16;}else{result.remainder_block[d]=last_size;}}returnresult;}};三个仓库的代码变成：
// 三个仓库各自只用一行调用autotiling=TilingStrategy<2>::compute({M,N},// 矩阵尺寸{MAX_M_TILE,MAX_N_TILE},// L1 容量上限ALIGN_TO_CUBE// 对齐策略);修复一个切分 bug，升级 ascend-boost-comm 里的 TilingStrategy 就行——所有 50 个仓库自动受益。
五大公共模块
一、数据切片引擎
除了前面的 shape 维切分，还处理数据布局转换。算子从 NCHW 换到 NHWC、从 RowMajor 换到 ColMajor 的跨步映射，全部由切片引擎提供：
// 数据布局转换 + 分块：一次调用#include"ascend-boost-comm/tiling/data_slice.h"autoslice=DataSlice::builder().shape({BATCH,CHANNEL,HEIGHT,WIDTH}).layout(LAYOUT_NCHW)// 输入格式.target_layout(LAYOUT_NHWC)// 输出格式（Cube 友好）.max_block_size(L1_CAPACITY)// L1 容量约束.build();// slice 自动生成最优的切分计划——// 包含了 layout 转换所需的 stride 映射二、拓扑发现服务
分布式算子（AllReduce、AllGather 等）需要知道 NPU 之间的物理拓扑来选最优算法。ascend-boost-comm 提供统一的拓扑发现：
// 任何算子仓库都可以调拓扑发现#include"ascend-boost-comm/topology/topo_discovery.h"TopologyGraph topo=TopologyDiscovery::get_instance()->discover();// 判断任意两张 NPU 之间走什么链路for(inti=0;i<num_npus;i++){for(intj=i+1;j<num_npus;j++){autopath=topo.shortest_path(i,j);// path.type: NVLink / RoCE / PCIe// path.bandwidth: 链路有效带宽（GB/s）// path.latency: 链路延迟（μs）}}// 基于拓扑选算法if(topo.is_nvlink_full_mesh()){returnALG_HALVING_DOUBLING;}elseif(topo.is_ring()){returnALG_RING;}else{returnALG_NAIVE;}这个接口被 hcomm、hccl、asc-comm 三个通信层共用。拓扑发现逻辑只在 ascend-boost-comm 里维护一份，改动了 NPU 拓扑描述数据结构后，三个通信层自动同步。
三、算子生命周期管理
CANN 算子从注册到执行有完整的生命周期：注册 → InferShape → Tiling → 内存分配 → Kernel Dispatch → 执行 → 内存释放。ascend-boost-comm 管理这个生命周期，让每个算子只关注「计算逻辑」部分：
// 算子生命周期——ascend-boost-comm 统一管理#include"ascend-boost-comm/lifecycle/op_lifecycle.h"// 算子开发者只需要实现 OpInterfaceclassMyAddOp:publicOpInterface{ShapeInferShape(constvector<Shape>&inputs)override{...}KernelTypeDispatchKernel(constOpConfig&config)override{...}StatusExecute(constvector<Tensor>&inputs,Tensor&output)override{...}};// ascend-boost-comm 管剩下的所有事：// - 内存预分配（从内存池复用）// - workspace 管理// - 异步执行流绑定// - 执行完成的同步点autolifecycle=OpLifecycle::create<MyAddOp>();lifecycle->infer_shape(inputs);lifecycle->allocate_memory();lifecycle->dispatch_kernel();lifecycle->execute();lifecycle->free_memory();四、跨算子状态共享
某些状态需要跨多个算子共享——比如混合精度训练的 loss scale 因子、推理的 KV Cache 块池。ascend-boost-comm 提供了一个分布式状态管理器：
// 跨算子全局状态#include"ascend-boost-comm/state/global_state.h"// 设置全局状态（任意算子可读写）GlobalState::set("amp_loss_scale",65536.0f);GlobalState::set("kv_cache_block_pool",pool_ptr);// op-nn 的 LayerNorm 读 loss_scalefloatscale=GlobalState::get<float>("amp_loss_scale");// op-transformer 的 Attention 读 KV Cache 池auto*pool=GlobalState::get<void*>("kv_cache_block_pool");状态管理器解决了「全局配置项到处传参数」的问题——loss_scale 只需要在 AMP 初始化时设一次，后续所有算子的梯度缩放自动感知。
五、调试与诊断
算子出问题时，快速定位是哪个阶段出的错。ascend-boost-comm 内建了分阶段的 profiling 和诊断：
// 分阶段 profiling// ascend-boost-comm 在生命周期每个阶段自动插桩#include"ascend-boost-comm/debug/profiler.h"OpProfilerprofiler("MatMulV2");profiler.enable_trace();// 开启全生命周期跟踪// 执行后输出：// [MatMulV2] InferShape: 0.12ms// [MatMulV2] Tiling: 0.05ms// [MatMulV2] AllocMem: 0.23ms ← 瓶颈？内存分配慢了// [MatMulV2] Dispatch: 0.01ms// [MatMulV2] Execute: 2.34ms// [MatMulV2] FreeMem: 0.08msProfiling 是分阶段自动注入的，不需要算子开发者手动加计时器。
依赖关系全景
ascend-boost-comm 在 CANN 依赖链中的位置：
opbase（基础组件：Tensor、DataType） ↓ ascend-boost-comm（公共平台：Tiling、Topology、Lifecycle、State、Debug） ↓ ├─ ops-math / ops-nn / ops-blas / ops-cv ...（核心算子仓库） ├─ hccl（集合通信库——用 Topology 做算法选择） ├─ hcomm（高层通信原语——用 Topology + Lifecycle） └─ ge（图编译器——用 Lifecycle 管理算子执行流）每个上层仓库通过 ascend-boost-comm 的模块各取所需。hccl 可能只用 Topology 模块，ops-nn 用了 Tiling + Lifecycle + Debug 三个模块——但代码是同一套，维护也是同一套。
M×N 复用不是新鲜的架构概念——操作系统的内核模块、浏览器的渲染引擎、游戏引擎的 ECS 框架——在各自领域用了几十年。但算子生态里的 M×N 复用在 CANN 开源之前从未被系统性解决。大多数框架的做法是让每个算子仓库自己维护一套 tiling/topology/lifecycle 代码，靠 code review 保持一致性。ascend-boost-comm 把这条路径反过来了——先建公共层，再在上面长