这个排序，我在不止一次AI集群方案评审里见到过：UALink < SUE < RoCEv2 < TCP。第一次看到的人多半会问一句，SUE是什么？它凭什么排在RoCEv2前面？而稍微了解网络的人则会盯着那个问号——因为这条从低到高的延迟链，恰恰是当下加速器互连技术的一个完整分层图谱，里面既有物理链路的差距，也有协议语义的差距，还有可靠性机制带来的隐藏成本。标题末尾用问号，我认为是合适的，因为它在大多数典型场景下成立，但并非绝对的铁律。
这篇文章我想把这个排序掰开揉碎讲清楚。会先说这四个东西各自是什么、放在什么层级，然后拆解延迟到底是从哪里冒出来的，再依次解释为什么UALink能跑到最低、SUE为什么比RDMA快、RDMA（RoCEv2）为什么只能到微秒级、TCP以太网为什么垫底。最后聊两句这个排序对实际组网选型意味着什么，以及我在测试中踩过的一些坑。适合正在做AI基础设施选型、GPU集群组网、高性能网络调优的工程师，也适合想搞明白这些新互连名词的架构师。
1. 先把四者的位置摆正：这不是同一类东西的简单比较
1.1 这四种“互连”到底分别解决什么问题
很多人把UALink、SUE、RoCEv2、TCP放在一起看，会误以为它们只是“网速快慢”的差异。实际上，它们覆盖的是完全不同的通信层级，只是最终都表现为“两个节点之间传输数据需要多少时间”。先说清楚每个东西的定位：
UALink，全称Ultra Accelerator Link，是针对AI加速器之间直连互连的开放标准。它的目标是替代/对标头部GPU厂商私有互连方案，在单台整机或一个机柜内部，把多张加速卡用极高带宽、极低延迟的方式连成一张“大卡”。它面向的是Scale-Up场景，一句话概括：让多个加速器看起来像一个大加速器。
SUE，全称在不同资料里有出入，我按出现频率最高的System Unified Express来理解，也可以把它当成“系统统一互连”这一类方案的代称。它处在机内加速器直连和机间RDMA网络之间，通常用于超节点内部、多个机柜之间的整体互连。它的核心思路是把一整组计算节点的内存、缓存、加速器资源统一编址，让节点间通信接近“本地内存访问”的语义。
RDMA（RoCEv2），是远程直接内存访问技术在以太网上的承载方案。它让一台主机直接访问另一台主机的内存区域，绕过CPU和操作系统协议栈。RoCEv2跑在标准以太网物理层上，但依赖无损或准无损网络来维持低延迟。它面向的是Scale-Out场景，解决的是“很多台机器通过网络协同训练大模型”的通信问题。
标准以太网（TCP），是传统数据中心最通用的网络传输方式。TCP/IP协议栈提供的是“可靠字节流”语义，由操作系统内核负责连接管理、分片、重传、拥塞控制。它通用、稳定、好部署，但延迟在四者中最大。
看到区别了吗？UALink和SUE更接近“总线/交换结构”的范畴，RoCEv2是“网络传输协议”，TCP则是“通用网络协议栈”。用延迟给它们排序，本质上是在比较一条消息从发出到被对端读走，在整个路径上要跨越多少层、多少跳、消耗多少额外时间。
1.2 延迟排序成立的前提条件
UALink < SUE < RoCEv2 < TCP这个顺序，隐含了一个前提：它们承载的数据规模相同、两端距离相近、网络没有拥塞或故障。在这些条件下，延迟差异主要来自物理距离、协议语义和可靠性开销这三个因素。但如果把RoCEv2和TCP放在高拥塞网络上，把UALink和SUE放在跨长距离场景，排序就会被打乱。所以这个排序更像是一个“理想情况下的参考系”，而不是绝对的性能承诺。
1.3 为什么延迟这么重要，带宽反而排在后面
做AI集群的人都清楚，大规模分布式训练里有个公式：通信时间 = 数据量 / 带宽 + 往返次数 × 延迟。带宽决定你能“塞多少”，延迟决定你“每次交互来回多快”。对于张量并行这类需要频繁小消息同步的场景，延迟就是命门。一批几百字节的梯度同步，如果走TCP可能要几十上百微秒，走RoCEv2可能只要几微秒，走UALink/SUE这种共享内存式互连甚至可以在亚微秒量级完成。这直接影响GPU空闲等待时间，最终体现在训练吞吐上。
理解了这一点，下面就可以逐一拆解延迟的来源了。
2. 延迟到底从哪里来：四个层面的开销一个都跑不掉
2.1 物理链路：信号的飞行时间是下限
任何互连都绕不开物理层。电信号在铜缆/PCB走线里的传播速度大约是6纳秒每米，光信号在光纤里的速度大约是5纳秒每米。看起来差别不大，但UALink和SUE的典型传输距离是半米到几米，RoCEv2跨越的是两台机器之间的几米到几十米线缆加交换机转发，TCP同样走这些链路。光是链路长度，就能让短距离互连比机间网络少掉几十纳秒到几百纳秒。
物理层还有一个容易被忽略的开销叫SerDes（串行器/解串器）编解码和FEC（前向纠错）处理。距离越远、速率越高，为了让信号在噪声里可靠恢复，就需要插入纠错编码，这会带来额外的纳秒级甚至微秒级处理时延。短距离的机内互连通常可以不启用或轻量启用FEC，而长距离的有源光缆和以太网收发器往往强制启用，这部分开销是很多人测延迟时不会留意但真实存在的。
2.2 协议语义：消息传递和内存访问是两码事
延迟的最大分水岭在协议语义。TCP是典型的“消息/字节流”语义：发送方要把用户态数据拷贝到内核，经过socket层、TCP层、IP层，再交给网卡DMA发送；接收方收到包后要经过内核协议栈处理、ACK回复、拷贝到用户缓冲区，每一层都是开销。RoCEv2虽然绕过了内核协议栈，实现了用户态直接访问网卡，但它的语义仍然是“我要把一段数据从这台机器搬到那台机器”，需要发送方注册内存区、构建请求描述符、写门铃、硬件执行DMA、接收方完成通知、轮询CQ，整个路径虽然短但依然是一套“请求-完成”模型。
UALink和SUE更进了一步：它们实现的是“内存语义”。发送方写一个地址，对端在整个互连域内可以直接读到这个值，甚至可以通过原子操作做远端内存更新。数据不必作为“消息”被显式搬运，硬件帮你完成跨节点的缓存一致和地址映射。这也是为什么UALink/SUE的延迟能低到接近本地NUMA访问，因为它们的目标就是在延迟上向“内存”靠拢，而不是向“网络”看齐。
2.3 可靠性机制：无损、重传和拥塞控制的开销差异
同样是在一根线上跑数据，TCP为了保证可靠传输，要维护序号、确认、超时重传和拥塞窗口。一旦发生丢包，TCP会退避重传，最坏情况下延迟会从微秒级飙升到毫秒级。RoCEv2虽然跳过了这些内核机制，但它的可靠性部分丢给了无损网络基础设施去保障，也就是依赖交换机流控和拥塞控制。如果网络出现PFC暂停帧风暴，延迟也会大幅恶化。UALink和SUE则因为距离短、以专用链路为主，天然不需要复杂的重传和拥塞控制，可靠性主要由链路级纠错保证，路径上几乎不产生额外等待。
2.4 软件路径：驱动、中断、轮询和拷贝
最后一个常被忽视的层面是软件路径。TCP延迟大头在系统调用和内核协议栈，RoCEv2通过在用户态直接操作网卡把软件延迟压缩到了几微秒，而UALink/SUE的访问路径往往由硬件直接完成地址翻译和缓存维护，软件只负责建链时的配置，数据面的软件干预几乎为零。实测中，软件路径每多一层，延迟至少增加几百纳秒。这也是为什么RoCEv2再怎么优化，也很难在端到端延迟上追上机内互连。
3. UALink为什么能拿到最低延迟：它本来就是为“低延迟”设计的
3.1 UALink的本质不是“网”，而是“总线结构的延伸”
UALink的设计目标很明确：让互连的多个加速器共享统一的地址空间，让一个加速器访问另一个加速器的内存就像访问本地设备内存一样。它不是把数据打包成报文发出去，而是通过交换芯片把多个加速器连成一个大型设备。一次远端读取的本质是硬件帮你完成了“地址翻译-跨链路请求-数据返回”三步，路径短、开销小、无需软件介入。
有人会问，这不就是PCIe加CXL那套思路吗？确实很像。UALink在设计理念上和CXL偏向内存语义的方向一致，但针对GPU和AI加速器做了强化，比如更高的带宽、更强的点对点原子操作、更灵活的拓扑。它不追求“通用计算节点的内存扩展”，而是追求“多个加速器协同工作时，数据共享的开销足够低”。
3.2 低延迟来自哪里：短距离、简单语义、少跳数
我给一个常见的数据参照：本地PCIe设备DMA访问延迟在1~2微秒量级，CPU访问本地内存约100纳秒。UALink这类加速器互连的预期延迟介于两者之间，理想情况下可以做到亚微秒到1微秒出头，具体取决于拓扑跳数和交换设计。它的优势来源有三点：第一是链路短，线缆长度控制在机柜内部，信号飞行时间可以忽略不计；第二是语义少，不需要整包报文、不需要ACK、不需要重传，一次内存访问请求发出后硬件直接完成；第三是交换芯片少，UALink交换机虽然存在，但转发路径设计得像一个内存控制器，而不是一个网络转发器。
3.3 UALink的短板：距离、成本和生态
如果说UALink没有缺点，那是不客观的。它最明显的短板是传输距离被限制在很短的范围，通常也就是单机柜到临近几个机柜之间。超过这个范围，信号完整性和同步成本会急剧上升，延迟优势也会消失。其次是成本，专用交换芯片、专用线缆、专用驱动和诊断工具，都比普通以太网贵得多。第三是生态，目前成熟的软件栈基本围绕头部厂商私有互连方案发展，开放标准的UALink还需要时间补齐生态。
4. SUE：在“机内直连”和“机间网络”之间的系统级互连层
4.1 SUE解决的痛点：超节点比单机柜大，又比整个数据中心小
为什么需要SUE这层东西？因为UALink只解决机柜内互连，RoCEv2解决机间互连，但现在的超大AI集群有一种中间需求：几十到几百个GPU组成一个“超节点”，它们需要作为一个整体对外提供服务，节点间通信的延迟要远比普通RDMA网络低，又不能都塞在同一个机柜里用UALink互连。SUE就是填补这个空档的方案。
我理解的SUE，可以把它看成一种“系统级统一互连”，它会建立跨多个节点的共享内存域，让运行在任意节点上的进程都能以接近本地访问的方式读写另一个节点加速器的内存。它不一定依赖专用交换机，有些实现通过加速器本身的直连端口做多级扩展，有些通过专门设计的系统交换结构实现。这一层的特点是有全局地址映射、有原子操作、有硬件缓存一致性或至少是软件指导的一致性，但物理跨度比UALink大，需要少量交换跳数。
4.2 SUE凭什么排在RoCEv2前面
从名字上就能看出，SUE做的是“统一”的活，本质是把多个节点折叠成一个大节点。当一次通信不需要“打包-发送-解包”，而是直接变成跨节点的内存读写，延迟自然就下来了。它比RoCEv2快的主要原因是：RoCEv2还得经过“发送方网卡=》交换机=》接收方网卡”的DMA搬运流程，而SUE的数据路径更像是一个分布式的内存系统，交换硬件参与的是地址转发，而不是报文转发。延迟差距通常在1到3微秒之间，但这已经足以让分布式训练的通信时间产生明显差别。
4.3 为什么SUE没有完全取代UALink或RoCEv2
因为跨度和成本是连在一起的。SUE的物理范围和跳数比UALink大，所以它没法像UALink那样做到亚微秒；SUE的专用程度比RoCEv2高，所以它没法像以太网那样做到随处可用。三者其实是按跨度形成了互补关系：机柜内用UALink、超节点内用SUE、超节点之间用RoCEv2。有些场景里SUE和UALink的边界会模糊，比如某个厂商把超节点内部互连统一叫某种系统互连，但本质上各种方案都是在这条延迟-距离曲线上找自己的位置。
5. RoCEv2的真实水平：微秒级延迟背后的完整链路
5.1 一次RoCEv2读操作的延迟拆解
RoCEv2已经被很多人吹成“低延迟网络标配”，但它到底低到什么程度？我看过不少实测数据，在无损以太网里，一个小消息的ping-pong往返延迟通常在3~10微秒之间，具体取决于网卡型号、交换机跳数、驱动配置和CPU处理能力。这个量级比TCP快一个数量级，但比UALink/SUE慢多了一个PCIe访问的耗时。我拆解给各位看：
发送端的路径：用户态程序创建一个发送WR（Work Request），写到硬件队列，网卡解析后直接DMA读取发送缓冲区数据，加上RoCEv2头部后发出。这个过程如果是精心调优的polling模式，大约0.5~1微秒；如果走中断通知，可能就要2微秒以上。
网络路径：从发送方网卡到TOR交换机，一跳转发通常几百纳秒，再加上链路串行化和FEC处理，大约1~2微秒。两机隔两跳交换机，光网络路径就在2~4微秒。
接收端路径：网卡收到报文，解封装，DMA写入接收缓冲区，然后通过RoCEv2完成事件或轮询队列通知应用。这一段又是1微秒左右。
三条相加，端到端单程2~5微秒、往返4~10微秒是正常范围。所以“微秒级”不是神话，只要路径上没有拥塞和丢包，RoCEv2确实能稳定运行在个位数微秒。
5.2 无损网络是RoCEv2低延迟的前提，也是最脆弱的命门
RoCEv2本来跑在以太网上，但以太网天然会丢包，标准TCP机制能优雅地处理丢包，RoCEv2的期望却是“一个包都不能丢”，因为一旦丢包触发重传，延迟就会剧烈抖动甚至断崖式恶化。为了保证不丢包，网络里必须启用PFC流控和ECN显式拥塞通知，交换机要为每条优先级队列做缓存预留。
我见过太多案例，RoCEv2集群在空载时延迟很漂亮，一旦高优先级流量和背景流量混跑，PFC暂停帧开始反压，延迟立刻从5微秒飙到20微秒甚至更高。更麻烦的是PFC风暴会在网络里形成“拥堵传播”——一台交换机暂停，上游交换机跟着暂停，流控风暴一路倒灌。所以RoCEv2的调优，重点不是网卡那几个参数，而是整张网的缓存、队列和流控策略。
5.3 如何正确测出RoCEv2的真实延迟
推荐用perftest套件或者sockperf这类工具做最基础的延迟测试。常用命令是：
ib_write_lat -a -F -q 1 -s 16 -n 100000 -t 1<server端和client端用法略有区别，建议先在server端起ib_write_lat -a，client端同样命令加对端IP>。测的时候要保证网卡工作在RoCEv2模式、GID索引正确，还要用taskset把测试进程绑在离网卡近的NUMA节点上，否则你测出来的不完全是网络延迟，而是CPU跨NUMA访问内存的时间。
一条经验是，不要只看延迟平均值，更要看尾延迟P99和P999。RoCEv2在拥塞轻微时，平均值可能还在5微秒，但P99已经到20微秒了。做AI训练用的就是那几百次同步消息里的最慢一次，尾延迟比平均值更能说明问题。
6. TCP以太网垫底：不是协议不行，是它的设计目标里没有低延迟
6.1 TCP延迟的构成：从连接到ACK的每一步都在花钱
TCP走一次小消息，链路最多几十微秒，但端到端延迟通常一百微秒起步。问题出在软件路径上：首先，每次发送都需要进入内核态，完成一次系统调用，这一步就是微秒级；接着TCP层要做发送缓冲管理、分段、计算校验和，这又是微秒级；接收端收到包后，内核要解析头部、查找Socket、拷贝到接收缓冲区、发送ACK，中间还有定时器和软中断处理，这些都是开销。
我用ping-pong方式实测过，在一台普通的双路服务器上用TCP做小消息往返，哪怕走loopback地址，也要20到40微秒；走两块网卡跨交换机，80到150微秒很常见。问题是，这里面链路本身只占很小一部分，内核协议栈处理才是大头。
6.2 TCP延迟波动比延迟数值更致命
TCP最让人头疼的不是稳定的几十微秒，而是抖动和长尾。拥塞窗口一旦收敛，发送方会进入指数退避重传，延迟从微秒级直接跳到毫秒级。加上现在的Linux内核有各种调度延迟、软中断延迟、锁竞争，TCP的P999延迟往往比平均延迟高两个数量级。对普通业务来说无所谓，但对需要几百次同步的大模型训练来说，一次毫秒级的掉队就会拖慢整个集群的步调。
6.3 那为什么数据中心还是大量用TCP
因为它通用、便宜、成熟。任何两台设备之间只要支持IP网络就能通信，出的问题可以通过抓包直接定位，工具链丰富，运维团队学的也是这一套。在延迟不敏感的推理调度、数据上传、日志传输、控制面通信里，TCP依然是主力。专业点说，延迟排序里的“差”只是针对特定场景，不代表它在所有场景里都是坏选择。
7. 延迟排序的工程含义：组网选型不能只看“越快越好”
7.1 Scale-Up和Scale-Out的边界：两套通信模型要分层
明白了延迟排序之后，最直接的工程启示是：你的集群不能只用一套互连。一张典型的AI集群网络应该分成三层：机柜内部用UALink这一类加速器直连做Scale-Up，超节点范围用SUE一类系统互连把多机柜整合成一个大域，超节点之间用RoCEv2做Scale-Out。控制面、存储面和数据面再进一步分离，存储和日志通信走普通TCP以太网。
这样做的原因是：通信大小和频率不匹配。张量并行里每次迭代都有高频小消息，必须在UALink/SUE上跑；数据并行里的梯度同步是中等频率的中等消息，适合RoCEv2；检查点保存是低频大块数据，TCP也能胜任。一层到底的架构，要么延迟不够，要么成本爆炸。
7.2 按应用场景算延迟预算，而不是按“最牛技术”选型
我见过不少团队一上来就追求全部RoCEv2，甚至想上全套UALink。但去过在做决策前，更重要的是先估算通信模式。假如你的训练是纯数据并行、梯度同步频率为每秒几十次，那TCP可能都够用；如果是千卡级别的张量并行，RoCEv2都可能不够，得上SUE或UALink。有一个粗略的参考：单次同步消息大小小于4KB、每个迭代同步次数超过50次，延迟预算就要压在5微秒以内，这基本只有系统级互连可以满足。消息达到数MB、吞吐是瓶颈的，选更高带宽的RoCEv2更划算。
7.3 什么情况下这个排序会反转
延迟排序也会被物理距离打乱。RoCEv2跨两层交换机确实比UALink慢，但如果让AI模型的不同专家模块分布在不同城市，那RDMA网络要走几百公里，延迟反而远大于本地TCP。还有网络拥塞和故障的因素：无损网络进入PFC风暴时，RoCEv2延迟可能超过TCP；UALink链路只要发生连接级重训练，延迟也会瞬时飚升。所以在评估延迟时，不要只信“标准答案”，要结合你的真实拓扑和流量模型去测。
8. 常见问题与实操避坑记录
8.1 测延迟的三种正确姿势
测不同的互连，要用不同的工具和口径。内存语义互连（UALink/SUE类）通常用厂商提供的微基准，或者直接用原子操作往返测试；RoCEv2用perftest的ib_write_lat/ib_read_lat；TCP用sockperf或netperf的TCP_RR模式。但无论哪种测试，都要注意三个坑：一是测试数据要足够小（16~64字节），否则测出来的是带宽影响而不是纯延迟；二是要做“热循环”，跳过启动阶段的前几百次操作；三是一定要记录P99和P999，不要只报平均。
8.2 我踩过的实测坑：干扰、中断绑定、驱动版本差异
第一次给RoCEv2集群做延迟测试时，我测出来的P99高得离谱，平均5微秒、P99却到40微秒。排查半天，最后发现测试进程跑在CPU 0号核心上，而网卡队列中断全部落在另一个NUMA节点上。后来用taskset绑定到网卡所在NUMA，又开启了busy polling，P99立刻降到10微秒以内。这个经验后来成了我的标准操作：测试前先查网卡位于哪个NUMA节点，再把进程绑过去。
另一个坑是驱动版本。不同版本的网卡驱动对RoCEv2 GID索引和拥塞控制算法默认配置不同，同一张卡，仅仅升级固件就可能让延迟差出2微秒。所以做对比测试之前，先统一版本，否则数据根本不可比。
8.3 延迟优化的几条实用清单
最后给一份我长期使用的检查清单，无论是为延迟测试做准备还是做性能优化，都建议按这个顺序过一遍：
- 物理层：确认链路速率和FEC配置一致，光模块功率正常，单模和多模不要混用。
- 交换层：保证所有交换机开启同一套流控/ECN配置，队列深度不要过大，过大会稀释PFC效果。
- 主机层：网卡固件和驱动版本统一，开启RDMA的拥塞控制算法（如DCQCN或厂商推荐参数）。
- 软件层：绑定CPU NUMA，优先使用轮询模式，关闭节能模式，检查BIOS里有没有开启低延迟相关的性能选项。
- 测试层：小消息、大样本量、记录P99/P999，同一组参数至少跑三遍。
如果你刚接触这些内容，不需要一次全弄懂，先理解延迟排序背后的逻辑：短距离、内存语义和简单可靠性机制是低延迟的来源。只要抓住这三条主线，将来再看到任何新的互连协议，都能很快判断它大致处在哪个延迟区间。这也是我写这篇文章最想传递的一个思路。
