ETH-X Scale Up 互联协议如何破解超级GPU难题？

一 从 “单卡” 到 “超节点” 的算力协同需求

当模型参数规模突破千亿、计算任务涉及海量并行操作时，单卡算力与内存已难以支撑，须依靠多 GPU 协同计算才能实现高效运行。Scale Up 域的核心目标，是让由多 GPU、CPU 组成的集群像 “超级 GPU” 一样工作：GPU 间可高密度通信以支持超大模型分布式部署，CPU 负责任务调度，域内还能直接挂载内存作为模型运行时的存储空间。

《ETH-X Scale Up 互联协议白皮书》聚焦 GPU 超节点互联的技术，系统剖析大规模 GPU 集群在通信、传输、内存管理等方面的核心需求与解决方案，为构建超级GPU提供思路。(点击https://mp.weixin.qq.com/s/tENch_KwTxNJNEuso0rAxA下载)

ETH-X Scale Up IO整体概览

二 语义需求：两种核心访问模式

计算和通信往往是两大核心阶段。如果让两者串行执行，通信时处理器就会空转，造成GPU算力浪费，而计算通信 Overlap 技术能让通信时GPU继续执行计算任务，从而隐藏通信时延，这也是算力性能调优的关键方向。

实现 Overlap的两种方式

计算/通信的几种关系

计算/通信Kernel分离模式下，计算 Kernel 和通信 Kernel 分工协作，前者处理后一组数据时，后者传输前一组数据，数据在两个Kernel间通过 HBM 交互，适用于 DeepEP 等框架。这种方式可以在不改变并行任务计算通信各阶段算子现有实现前提下，利用框架和硬件的能力对数据流调度从而完成通信时延隐藏。

另一方面，可以将计算和通信Kernel进行整合，小粒度数据运算后直接发起通信，无需经过 HBM 中转，减少开销。这种方式可以优化推理TPOT时延，但对开发要求更高，适合极致性能优化场景。

Direct Copy：批量数据的高效 “搬运”

为满足不同场景的数据传输需求，Scale Up 域定义了两种核心访问语义，分别适配大规模连续数据与小粒度离散数据的处理。

针对粗粒度、大规模连续数据传输，Direct Copy 通过专用硬件(如 DMA 引擎)将本地 HBM 中的数据直接拷贝至远端 HBM，单次传输数据量可从 1B 到数 GB。这种方式能减轻 GPU 负担，尤其适合结构化数据的批量处理。譬如计算-通信Kernel分离模式下适合采用Copy语义。

Direct Copy示意图

Direct Access：小粒度数据的 “边读边算”

对于非连续、小粒度数据(如 1B 到数十 KB)，Direct Access 允许计算引擎直接读写远端 HBM 数据，并即时加载至 GPU 核心参与运算。它依托算力引擎直接发起访问，启动延迟极低，能高效处理非结构化数据。

Direct Access示意图

三 ETH-X传输层需求： “高效” 和 “可靠”

数据在 Scale Up 域内传输时，需同时解决 “效率” 与 “可靠性” 两大问题，这也是传输层设计的核心。在GPU 跨卡通信中，数据传输会伴随指令、包头等额外信息，若直接传输会显著降低有效带宽。例如，单个 Load 指令的有效数据仅 128B，却需携带 16B 指令与 34B 以太网包头，一组事务的请求和响应的有效效率仅 56%。为了解决效率问题，需要对报文头部进行压缩，并实现事务聚合能力。

GPU 片上及板上互联能通过点到点确认机制保障可靠性，但数据经以太网传输时，面临更高的误码率与丢包风险，且交换节点不会对异常报文重传。一旦访存事务丢弃，将使超节点域严重故障，因此Scale Up域需要从多层面构建容错能力，提升系统稳定性。

四 ETH-X事务层：“AXI的搬运工”

GPU与Scale Up通过AXI接口进行交互

AXI Adapter 接口是GPU通往Scale Up的“大门”——AXI作为 GPU 主要使用的总线协议，内部组件间所有交流都通过AXI事务进行。AXI 同样承载着 Direct Access 和 Direct Copy 两种语义的事务传输。为了使AXI事务能够跨越Scale Up网络，IOD 会将跨卡 AXI 访存事务封装成以太网数据包，完成调度、路由后，再解析为目标 GPU 可识别的 AXI 信号，确保指令与数据在不同 GPU 间 “无缝接力”。

GPU本地需要实现AXI事务代理

GPU 核心需通过 Outstanding Buffer 维护事务状态，若缓冲区满则会阻塞运算。事务代理为 store/write 类型事务提供 “本地快速响应”，后续传输由代理负责，可以大幅降低响应时延，提升并发吞吐能力，避免核心因等待远程响应而空转。

专用的 Scale Up 拷贝引擎(SU Engine)进一步优化 Direct Copy 效率。相比 GPU 本地拷贝引擎需两次穿越总线、切分聚合数据的冗余操作，SU Engine 可直接发起大包传输，减少总线流量与聚合开销，独立管理事务顺序，避免内存屏障对传输的干扰，让大规模数据搬运更高效。

五 Scale Up传输如何保证正确实施内存模型？

线程1写入一批数据后(d1和d2)由线程2读取，线程间通过 “Release-Acquire” 同步机制实现同步，当线程1执行 “Release” 操作(如写入Flag)，线程2 通过 “Acquire” 操作(如读取Flag)感知后，1 在 Release 前的所有写入对 2 可见。此时两个线程间的网络需要保证Release事务执行前的所有写数据(又称Relaxed事务)都执行完成。

线程间数据同步场景

Scale Up网络需要满足释放一致性模型

当线程A和B通过Scale Up域传递信号时，可能出现多种情况导致Release事务的执行顺序被破坏，当线程B收到Release事务的同步信号时，此前的数据仍未被写入存储空间，从而导致数据错误。这种情况轻则导致模型迭代时间增加，重则导致模型数据完全异常而不可用。因此Scale Up网络需要额外机制来保障GPU事务顺序正确运行。

两个GPU间的Relaxed-Release事务乱序示意图

全局释放一致性模型

当通信涉及多个 GPU 时，仅保证两两 GPU 间的数据一致性(P2P 一致性)可能仍有风险。例如某 GPU 向 3 个节点写入数据，若节点间同步不当，可能导致部分节点读取到旧数据。

多个GPU间的Relaxed-Release事务乱序示意图

在 Scale Up 域中，若内存事务的保序处理未能妥善实现，极易引发数据竞争、数据不一致等严重问题，进而直接破坏程序运行的正确性。Scale Up系统需要在正确处理数据传输顺序的情况下，尽可能优化设计引入的开销。

六 ETH-X：从软件到硬件件的完整技术框架

《ETH-X Scale Up 互联协议白皮书》围绕 Scale Up 域的核心技术需求展开系统梳理，构建了覆盖软件层至硬件层的完整技术框架。该框架从核心需求分析到具体技术落地形成闭环：先深入剖析 Direct Access/Direct Copy 的语义需求，以及 GPU 内存模型对 Scale Up 域的适配需求，再基于需求提出技术实现方案，包括 ETH-X PAXI 事务层的详细设计，同时完成数据链路层、物理层及 Die-to-Die 互联协议的技术规划。每一环都直指大规模 GPU 集群Scale Up互联的实际痛点。

点击https://mp.weixin.qq.com/s/tENch_KwTxNJNEuso0rAxA，下载相关文档

联系人：

腾讯 张老师 wikkizhang@tencent.com

信通院 王老师 wangshaopeng@caict.ac.cn

信通院 孙老师 suncong@caict.ac.cn