CANN 组织链接： https://atomgit.com/cann
GE 仓库链接： https://atomgit.com/cann/ge

---

在人工智能计算堆栈中，GE（Graph Engine） 扮演着“指挥官”的关键角色。它连接了上层的深度学习框架（如 TensorFlow, PyTorch）与底层的 NPU 硬件资源。作为 CANN 的核心组件，GE 负责将上层定义的计算图进行一系列复杂的图优化、算子融合、内存规划和流分配，最终生成可在 AI 处理器上高效执行的离线模型或实时任务流。

1. 分布式训练的通信拓扑构建与流编排

在跨节点或多卡的分布式训练场景中，计算图不再局限于单一设备。GE 的首要任务是构建高效的通信拓扑，确保数据并行策略下的梯度同步不会成为系统瓶颈。

1.1 集合通信算子的自动注入

当用户启用分布式策略时，GE 会深度解析反向传播计算图。在每一个可训练参数（Weights）的梯度计算节点之后，GE 能够识别出同步需求，并自动插入 HCOM（High Performance Collective Communication） 算子。

• AllReduce 编排：针对数据并行，GE 插入 AllReduce 算子以实现多卡间的梯度聚合。
• 拓扑感知：GE 会根据集群的物理连接（如服务器内的 PCIe/HCCS 高速互联 vs 服务器间的以太网/RoCE），选择最优的环状（Ring）或树状（Tree）通信算法。

1.2 计算与通信的流水线叠加（Overlapping）

为了掩盖高昂的通信延迟，GE 引入了多流（Multi-Stream）并发机制。

• 独立流调度：计算任务被分配到计算流（Compute Stream），而通信任务被分配到通信流（Communication Stream）。
• 依赖同步：GE 在图中插入必要的事件（Event）同步节点，确保只有在当前层的梯度计算完成后，通信流才开始传输数据。这种设计使得第 $N$ 层的梯度传输可以与第 $N-1$ 层的前向/反向计算并行执行，极大地提升了集群算力的线性加速比。

2. 梯度传输优化：切分与融合策略

面对万亿级参数的大模型，简单的梯度传输策略会导致网络拥塞或握手开销过大。GE 在图编译阶段实施了精细的梯度张量管理策略。

2.1 小梯度融合（Gradient Fusion）

在深度网络中，往往存在大量参数量较小的层（如 Bias 或 Normalization 层）。传输这些微小的张量会产生大量的通信握手开销（Latency Bound）。
GE 实现了**梯度桶（Gradient Bucket）**机制：

1. 内存连续化：将多个小的梯度张量在物理内存上进行连续排布。
2. 打包传输：将这些连续的小张量视为一个大的“融合张量”，仅发起一次 AllReduce 指令。这显著减少了通信原语的调用次数，降低了 CPU 的调度负载。

2.2 大梯度切分（Gradient Splitting）

相反，对于超大的权重矩阵（如 Embedding 层），直接传输可能导致长时间占用通信链路，阻塞其他流的执行。GE 会根据网络带宽的 MTU（最大传输单元）和链路状态，将大张量切分为多个切片（Slices）。这些切片可以被分摊到不同的时间片传输，或者在多网口环境下进行负载均衡。

3. 量化感知图构建：精度与性能的平衡

GE 原生支持量化感知训练（QAT）和训练后量化（PTQ）的模型部署，它是连接高精度算法与低精度硬件执行单元的桥梁。

3.1 量化算子的转换与注入

当接收到经过 AMCT（Ascend Model Compression Toolkit）量化标记的模型时，GE 会执行算子替换流程：

• 类型映射：将原始的 Conv2D（FP32）替换为硬件加速的 QuantizedConv2D（INT8）。
• 数据流适配：由于 AI 处理器的 Cube 单元通常输出 INT32 累加结果，而下一层输入可能需要 FP16 或 INT8，GE 会自动在算子间插入 ReQuantization（重量化）和 DeQuantization（反量化）节点，管理缩放因子（Scale）和零点偏移（Zero Point）。

3.2 精度混合流水线

GE 并非简单地将所有算子量化。它维护着一个精度约束表。对于那些对精度敏感且量化收益不高的层（如最后的 Softmax 或某些激活层），GE 会保留其 FP16/FP32 属性，并在其前后插入 TransData 和 Cast 算子，确保数据格式在不同计算单元（Cube vs Vector）之间正确流转。

4. 深度算子融合：打破内存墙

为了最大化 AI 处理器的利用率，GE 内置了强大的算子融合引擎（Fusion Engine）。其核心目标是减少中间结果对全局内存（Global Memory）的读写，尽可能让数据在片上缓存（Unified Buffer）中流转。

4.1 “Conv + Post-Ops” 融合模式

这是推理场景中最典型的融合范式。GE 会识别出计算图中连续的结构，例如 Conv2D -> BatchNorm -> Scale -> ReLU。

• UB 融合：GE 将这些离散的算子合并为一个超级算子（Super-Kernel）。
• 执行逻辑：底层的 Cube 单元完成卷积计算后，结果不写回 DDR，而是直接保留在累加器或本地缓冲中，紧接着由 Vector 单元应用缩放和激活函数。这种“一次读取，多次计算”的模式可带来倍数级的性能提升。

4.2 量化特定的融合

在量化场景下，融合更为激进。例如 Conv + ReQuant + Add 结构。GE 会生成特定的指令序列，使得量化参数的施加和残差连接（Residual Add）在同一流水线阶段完成，避免了 INT32 到 FP16 再到 INT8 的多次无效转换。

5. 异构计算架构与子图切割

虽然 NPU 提供了强大的 AI 算力，但面对快速演进的算法，计算图中可能包含少量硬件尚未原生支持的算子。GE 通过异构计算机制保障了模型功能的完备性。

5.1 支持度校验与子图划分

在 Session 初始化阶段，GE 会遍历计算图中的每个节点，查询内部的 OpInfoStore。

• 校验机制：检查算子类型、输入输出数据类型、Shape 范围是否在当前硬件版本的支持列表中。
• 切割策略：一旦发现不支持的算子（例如特定的逻辑控制或非标量计算），GE 会以此节点为边界，将计算图切割为“NPU 子图”和“CPU 子图”。

5.2 跨设备数据搬运

为了连接被切割的子图，GE 会自动插入数据拷贝节点：

• MemcpyAsync：在 NPU 子图执行完毕后，GE 调度异步拷贝任务，将中间结果从 Device 侧显存传输到 Host 侧内存。
• CPU 执行：Host CPU 接收数据并执行不支持的算子（通常利用 TensorFlow 或 PyTorch 的原生 CPU 实现）。
• 回传 Device：处理结果再次通过 PCIe 通道回传给 NPU，继续执行后续的 NPU 子图。虽然这会引入 PCI-E 传输开销，但它确保了模型能够“跑得通”，为开发者提供了优化的缓冲期。

6. 硬件级预处理加速：AIPP 集成

在端侧和边缘侧推理中，图像预处理（如解码、缩放、格式转换）往往占据了大量 CPU 时间。GE 通过集成 AIPP（AI Pre-Processing） 模块，将这些任务卸载到专用的硬件电路。

6.1 静态与动态 AIPP 配置

开发者可以通过配置文件或 API 开启 AIPP。

• 色域转换（CSC）：硬件自动完成 YUV420 到 RGB/BGR 的转换，这是视频分析任务的标配。
• 零拷贝处理：AIPP 模块直接位于内存接口前端。当数据从内存读入 AI Core 之前，预处理即在传输路径上“顺便”完成。这意味着预处理操作对于 AI 计算单元是透明且零时间开销的。

6.2 动态分辨率（Dynamic Resolution）支持

在实际业务中，输入图像的尺寸可能不断变化。GE 允许在构建图时定义多个“档位”（Gears）。

• 多档位编译：GE 会预先为 720p、1080p 等分辨率生成不同的参数配置。
• 运行时路由：在推理请求到达时，GE 根据实际输入数据的 Shape 信息，动态选择最匹配的档位参数，驱动硬件执行。这避免了为每种分辨率重新编译模型的巨大开销。