这个排序我在不止一次AI集群方案评审里见到过UALink SUE RoCEv2 TCP。第一次看到的人多半会问一句SUE是什么它凭什么排在RoCEv2前面而稍微了解网络的人则会盯着那个问号——因为这条从低到高的延迟链恰恰是当下加速器互连技术的一个完整分层图谱里面既有物理链路的差距也有协议语义的差距还有可靠性机制带来的隐藏成本。标题末尾用问号我认为是合适的因为它在大多数典型场景下成立但并非绝对的铁律。这篇文章我想把这个排序掰开揉碎讲清楚。会先说这四个东西各自是什么、放在什么层级然后拆解延迟到底是从哪里冒出来的再依次解释为什么UALink能跑到最低、SUE为什么比RDMA快、RDMARoCEv2为什么只能到微秒级、TCP以太网为什么垫底。最后聊两句这个排序对实际组网选型意味着什么以及我在测试中踩过的一些坑。适合正在做AI基础设施选型、GPU集群组网、高性能网络调优的工程师也适合想搞明白这些新互连名词的架构师。1. 先把四者的位置摆正这不是同一类东西的简单比较1.1 这四种“互连”到底分别解决什么问题很多人把UALink、SUE、RoCEv2、TCP放在一起看会误以为它们只是“网速快慢”的差异。实际上它们覆盖的是完全不同的通信层级只是最终都表现为“两个节点之间传输数据需要多少时间”。先说清楚每个东西的定位UALink全称Ultra Accelerator Link是针对AI加速器之间直连互连的开放标准。它的目标是替代/对标头部GPU厂商私有互连方案在单台整机或一个机柜内部把多张加速卡用极高带宽、极低延迟的方式连成一张“大卡”。它面向的是Scale-Up场景一句话概括让多个加速器看起来像一个大加速器。SUE全称在不同资料里有出入我按出现频率最高的System Unified Express来理解也可以把它当成“系统统一互连”这一类方案的代称。它处在机内加速器直连和机间RDMA网络之间通常用于超节点内部、多个机柜之间的整体互连。它的核心思路是把一整组计算节点的内存、缓存、加速器资源统一编址让节点间通信接近“本地内存访问”的语义。RDMARoCEv2是远程直接内存访问技术在以太网上的承载方案。它让一台主机直接访问另一台主机的内存区域绕过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访问的耗时。我拆解给各位看发送端的路径用户态程序创建一个发送WRWork 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 1server端和client端用法略有区别建议先在server端起ib_write_lat -aclient端同样命令加对端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延迟可能超过TCPUALink链路只要发生连接级重训练延迟也会瞬时飚升。所以在评估延迟时不要只信“标准答案”要结合你的真实拓扑和流量模型去测。8. 常见问题与实操避坑记录8.1 测延迟的三种正确姿势测不同的互连要用不同的工具和口径。内存语义互连UALink/SUE类通常用厂商提供的微基准或者直接用原子操作往返测试RoCEv2用perftest的ib_write_lat/ib_read_latTCP用sockperf或netperf的TCP_RR模式。但无论哪种测试都要注意三个坑一是测试数据要足够小16~64字节否则测出来的是带宽影响而不是纯延迟二是要做“热循环”跳过启动阶段的前几百次操作三是一定要记录P99和P999不要只报平均。8.2 我踩过的实测坑干扰、中断绑定、驱动版本差异第一次给RoCEv2集群做延迟测试时我测出来的P99高得离谱平均5微秒、P99却到40微秒。排查半天最后发现测试进程跑在CPU 0号核心上而网卡队列中断全部落在另一个NUMA节点上。后来用taskset绑定到网卡所在NUMA又开启了busy pollingP99立刻降到10微秒以内。这个经验后来成了我的标准操作测试前先查网卡位于哪个NUMA节点再把进程绑过去。另一个坑是驱动版本。不同版本的网卡驱动对RoCEv2 GID索引和拥塞控制算法默认配置不同同一张卡仅仅升级固件就可能让延迟差出2微秒。所以做对比测试之前先统一版本否则数据根本不可比。8.3 延迟优化的几条实用清单最后给一份我长期使用的检查清单无论是为延迟测试做准备还是做性能优化都建议按这个顺序过一遍物理层确认链路速率和FEC配置一致光模块功率正常单模和多模不要混用。交换层保证所有交换机开启同一套流控/ECN配置队列深度不要过大过大会稀释PFC效果。主机层网卡固件和驱动版本统一开启RDMA的拥塞控制算法如DCQCN或厂商推荐参数。软件层绑定CPU NUMA优先使用轮询模式关闭节能模式检查BIOS里有没有开启低延迟相关的性能选项。测试层小消息、大样本量、记录P99/P999同一组参数至少跑三遍。如果你刚接触这些内容不需要一次全弄懂先理解延迟排序背后的逻辑短距离、内存语义和简单可靠性机制是低延迟的来源。只要抓住这三条主线将来再看到任何新的互连协议都能很快判断它大致处在哪个延迟区间。这也是我写这篇文章最想传递的一个思路。