CANN 组织链接 ： https://atomgit.com/cann
HCCL 仓库链接 ： https://gitcode.com/cann/hccl
1. 算子层面的极限优化：超越原子操作
算子性能的上限由硬件峰值决定，但实际性能受限于数据流。
1.1 融合的深度与广度
ops-nn 和 ATVOSS 共同推动了算子融合，旨在最大化计算单元的持续工作时间：
- 计算内融合：如 Conv-BN-ReLU，将 I/O 密集型操作整合到单个核函数中，将数据活动限制在 Local Memory 范围内。
- 跨操作依赖融合：对于 Transformer 结构，融合 Attention 链（MatMul-Scale-Softmax-MatMul）是消除中间结果全局存储的关键，它要求底层 Ascend C/PyPTO 能够处理复杂的跨操作依赖和精度转换。
1.2 精度策略的适应性
在应对超大规模模型时，精度管理是内存和带宽优化的核心手段：
- BF16 作为基准：在模型训练和需要高动态范围的推理中，BF16 成为标准，因为它平衡了精度和 2 倍的带宽优势。
- 局部 INT8 优化：对于激活值、偏置等对精度不敏感的部分，通过 ops-nn 的 INT8 算子在局部实现最高吞吐率，只有在关键的累加或激活点才提升精度。
2. 通信与计算的交织：HCCL 的层次化调度
随着模型规模的扩大，通信开销逐渐超过计算时间，成为分布式训练/推理的主导瓶颈。
2.1 通信路径的拓扑感知
HCCL 库通过分析集群的物理拓扑（PCIe 拓扑、节点间互联）来决定数据传输路径。
- 层次化选择：对于单节点多卡通信，HCCL 倾向于利用高带宽、低延迟的 PCIe 或专有互联链路（如 Clover/RDMA）。对于跨节点通信，则利用 InfiniBand 或其他高速网络。Runtime 负责将逻辑 Rank ID 映射到物理拓扑位置，供 HCCL 调用。
2.2 异步通信与计算的精确同步
Runtime 调度器必须精细控制计算流和通信流。
- 依赖前置 ：对于模型并行，当一个 NPU 需要其他 NPU 的部分权重时，Runtime 会在计算开始前很早就提交 HCCL 的
AllGather或Broadcast请求。 - 同步屏障的粒度：同步屏障不能设置得过于粗粒度（否则会浪费 NPU 计算时间），也不能过于细粒度（否则会增加同步开销）。HCCL 配合 Runtime 确保同步点设置在两个原子操作序列之间，以实现最小的等待时间。
3. 算子开发的未来：简化定制与提升效率
未来的优化将侧重于使自定义算子开发更易于接入和维护。
- PyPTO 的普及：PyPTO 将成为定义复杂算子（如自定义 Attention 变体）的首选方式，因为它能自动处理 Tiling 和流水线细节，降低了像 Ascend C 那样的底层内存操作的复杂性。
- 性能反馈回路：Profiler 数据的自动解析和反馈机制将指导编译器（如 ATVOSS 驱动的 TVM）自动调整 Tiling 参数，从而在部署新模型或新硬件时，实现性能的"自适应优化"。
4. 结论
CANN 算子生态是一个多层级的、高度协同的系统。从 ops-nn 提供的硬件级优化，到 Runtime 的图级调度，再到 HCCL 提供的跨设备通信，每层都致力于消除计算与访存、计算与通信之间的延迟。这种设计哲学确保了昇腾平台能够持续应对深度学习领域对计算效率的不断攀升的需求。
CANN 组织链接 ： https://atomgit.com/cann
HCCL 仓库链接 ： https://gitcode.com/cann/hccl