CANN 组织链接： https://atomgit.com/cann
GE 仓库链接： https://atomgit.com/cann/ge
图引擎（GE）在分布式异构计算环境中，不再仅仅是单卡算子的优化器，更升级为系统架构师，负责将复杂的并行算法转化为物理集群上的高效执行计划。在大规模模型训练中，GE 通过深度耦合硬件拓扑、精确定位通信瓶颈以及静态编排计算与通信任务，实现了集群资源的统一调度与效能的最大化。
1. 分布式图的构建与集群拓扑感知
1.1 集群拓扑的加载与硬件路径解析
分布式图编译的首要任务是获取集群的物理布局信息。GE 在编译阶段会接收来自 Runtime 的全局拓扑描述，该描述包含了参与计算的所有 NPU 的物理连接关系、网络带宽以及 Rank ID 映射。
- 硬件拓扑图建模：GE 在内部构建一个精细的硬件拓扑图，用以量化不同设备间的通信成本（延迟和带宽）。
- 成本函数定制：拓扑信息被用于计算集合通信操作（如 AllReduce）的最优路径选择，例如优先使用高带宽的 HCCS/PCIe 链路。
- 拓扑感知调度：根据拓扑图，GE 能够提前判断哪些通信操作更容易产生瓶颈，并分配额外的资源进行优化。
1.2 通信算子的识别与显式注入策略
GE 负责识别上层框架（如数据并行中的梯度同步点）中隐含的通信需求，并在计算图中显式插入通信算子节点。
- 语义转化 ：将逻辑上的梯度平均操作转化为
HCCL_ALLREDUCE等通信原语节点。 - 节点属性定义：为通信算子设置精确的组 ID (Group ID)、源/目标 Rank 以及数据类型，确保底层通信库能够正确解析。
- 执行流分离：标记通信算子应被分配到独立的通信流（Stream）中执行，以实现与计算流的并行。
1.3 逻辑并行到物理分片的转化
对于超大规模模型，GE 必须将原本在逻辑上连续的巨型算子（如一个 Transformer Block）拆分到多个 NPU 上执行。
- 算子分割：GE 识别出超过单卡内存上限的张量，并将其拆分为多个子算子。
- 通信节点注入：在子算子的输入输出端，GE 插入通信节点，用于将中间结果发送给其他 NPU，或接收所需的输入数据。
2. 资源分配与计算通信的耦合调度
2.1 计算块与通信块的时间窗口划分
在分布式场景下，资源调度的核心在于时间窗口管理。GE 通过对计算任务的执行时间进行静态估算，并结合通信路径的延迟，生成耦合调度计划。
- 通信预调度：GE 尝试将通信任务的提交（HCCL 调用）尽可能提前，确保通信操作的启动发生在计算单元的空闲时间。
- 数据依赖追踪：静态分析确保通信操作的提交发生在所需的输入数据准备就绪之后，避免数据竞争。
- 资源配额预留：GE 在图编译时，就向 Runtime 预留相应的通信资源配额（如通信缓冲区大小），防止运行时因资源竞争导致延迟增加。
2.2 静态调度与异步依赖链的建立
GE 生成的执行计划是一个时间确定的依赖图，强调异步执行和同步点插入。
- 事件依赖链：GE 在计算图的关键节点插入 Event Record/Wait 节点。前序计算完成后记录 Event，后续通信或计算任务等待该 Event 信号。
- 多流任务编排：将计算任务分配给 AI Core Stream，将通信任务分配给 Communication Stream，确保两个独立的硬件流能最大限度地并行运行。
2.3 通信与计算的深度重叠优化（Overlapping）
GE 的核心优化目标是实现通信时间对计算时间的完全遮蔽。
- 流水线插入：在反向传播过程中，GE 识别出梯度计算和梯度同步的依赖，并插入异步通信操作，确保下一层的计算能在通信完成前启动。
- 张量切分与调度：针对 AllReduce 等操作，GE 可以决定将张量切分（Tiling）为多块，并为每一块数据生成独立的通信任务，以实现细粒度的流水线重叠。
3. 内存管理：通信缓冲区与生命周期约束
3.1 通信张量生命周期的特殊管理
涉及跨卡通信的张量（如梯度缓冲区），其生命周期管理比单卡张量更为复杂。GE 必须确保张量在通信操作完成之前不会被复用或释放。
- 生命周期延长：GE 强制延长通信张量的存活区间，直到 Runtime 确认所有目标 Rank 都已接收或使用完该数据。
- 同步屏障依赖：GE 会追踪 HCCL/SHMEM 提交的完成信号，只有当该同步信号被确认后，通信所涉及的源/目标张量才会被标记为"可复用"。
3.2 对称堆内存（Symmetric Heap）的地址规划
GE 配合底层通信库（HCOMM）进行内存规划，以支持对称堆内存分配。
- 地址一致性：GE 确保集群中所有 Rank 上分配的通信缓冲区拥有相同的逻辑偏移量。
- 零拷贝基础：这种静态地址规划是底层实现零拷贝（Zero-Copy）和远程直接内存访问（RDMA）的基础。
3.3 通信缓冲区池化与资源预留
为了消除运行时内存申请的延迟，GE 在编译期就向 Runtime 预留了通信缓冲区（Comm Buffer）的配额。
- 静态预留：根据图中通信算子的峰值带宽需求，计算并预留所需的 HBM 内存总量。
- 避免碎片化：确保通信缓冲区是连续的大块内存，以适应底层硬件对突发传输的要求。
4. 动态 Shape 与分布式执行的适应性
4.1 动态 Shape 的多档位分布式编译
分布式模型同样面临变长输入的挑战。GE 支持为模型配置多个输入 Shape 档位。
- 多图生成：GE 会为每一个档位生成一套独立的、经过优化的分布式执行图和通信计划。
- 运行时切换：运行时，GE 根据实际输入数据的尺寸自动匹配并加载对应的优化执行路径，确保了静态编译的高效性和动态输入的灵活性。
4.2 异构调度与 CPU/NPU 协同通信
对于 NPU 暂不支持的算子，GE 执行子图切割，并将任务回退给 CPU。在分布式场景中，这要求 GE 具备协调跨设备和跨处理器的复杂通信。
- 数据桥接：GE 在 NPU-CPU 边界自动插入数据拷贝和格式转换节点。
- Host 参与同步：对于回退到 CPU 的逻辑，GE 需要在 Host 端插入额外的同步逻辑，确保 CPU 的处理结果在正确的时间点被重新注入到 NPU 的计算流中。
5. 性能度量与分布式诊断支持
5.1 通信与计算时间的量化分析
GE 编译阶段生成的任务描述符中包含了所有通信和计算操作的预估耗时。
- 性能瓶颈预测：GE 利用这些数据预测分布式执行的理论性能上限，并识别出通信-计算比最高（最容易成为瓶颈）的算子。
- 调优优先级：根据预测结果，开发者可以优先针对高通信成本的子图进行算法或融合优化。
5.2 Profiling 工具链的分布式视图
GE 协同 Runtime 和 Profiling 工具，提供分布式执行的全景视图。
- 多卡时序图：Profilier 可以展示所有 Rank 的执行时间轴，清晰地显示出不同 NPU 之间的同步等待时间（Wait Time）。
- 掉队者识别：通过分析 Wait Time 的分布，开发者可以快速识别出通信流或计算流中的"掉队者"（Staggler），从而对负载不均或硬件故障进行精准定位。
6. 工程实践：代码仓库协同与资产管理
6.1 GE 与 HCCL/HCOMM 的版本协同
GE 仓库的代码必须与底层的通信库（如 HCOMM）保持严格的版本协同。GE 在编译时依赖 HCOMM 提供的 API 接口和拓扑解析能力。任何接口的变更都要求 GE 进行同步更新，以确保生成的通信算子描述符能够被底层的驱动程序正确解析和执行。
6.2 分布式资产的生成与加载
GE 的最终产物是分布式离线模型。这些模型资产包含了：
- 单卡子图：每个 Rank 只需要加载和执行其对应的子图部分。
- 通信配置：内嵌了 HCCL Group ID 和 RankTable 信息。
这种分布式资产的生成模式，确保了部署过程中的数据安全性与执行的隔离性。
CANN 组织链接： https://atomgit.com/cann
GE 仓库链接： https://atomgit.com/cann/ge