1. 先说结论UALink 1.0要解决什么UALink 1.0发布的时候我的第一反应是AI计算集群的互连江湖终于有人愿意站在同一张桌子前定规矩了。 如果你这几年的工作涉及大规模训练集群、GPU/加速器互联、或者数据中心网络卡片的选型那你一定知道过去几年有一个让人非常无奈的现状——高性能加速器互连几乎被几家厂商的私有方案垄断别人想插一脚只能靠“不够快”的通用方案凑合。UALink全称是Ultra Accelerator Link由AMD、博通、思科、谷歌、惠普企业、Meta、微软等一批巨头在UALink Consortium框架下共同推出来的开放加速器互连规范目前已经发布了1.0版本的Chiplet Specification。 这个规范的目标很直白定义一套开放、高带宽、低延迟、专门用于AI加速器之间直接通信的互联协议让不同厂商的加速器、交换芯片、网卡能够在统一框架下高效协同而不是继续困在专有生态里。它能解决什么问题简单说大模型训练和推理过程中模型并行、张量并行、专家并行都会产生大量节点间的数据搬运而搬运的效率直接决定集群的算力利用率。 我们常看到宣传上写“几千张卡”、“多少EFLOPS”但如果互连带宽不够、延迟太高、协议不统一几千张卡里可能有三分之一的时间都在空等数据。UALink 1.0出现就是希望把这条“搬运数据的高速公路”修得足够宽、足够统一、足够开放。这篇文章适合谁看两类人一类是做AI基础设施架构、GPU/加速器硬件选型、集群网络设计的朋友你需要理解UALink的技术定位和演进路径另一类是芯片设计、FPGA验证、板卡互联相关工程师UALink基于PCIe 6.0物理层这意味着它的评估和落地有不少可以复用的方法论。 下面我把这个规范拆开揉碎结合我自己在互联技术评估和项目落地中的经验聊聊它的设计逻辑、硬件实现细节、生态影响以及值得避开的坑。2. 核心规格拆解把每个数字背后的逻辑讲清楚2.1 物理层为什么直接“吃”PCIe 6.0的红利UALink 1.0最有意思的设计决策就是电气层直接建立在PCIe 6.0的物理层基础之上。很多人听到这里会问我不如直接用PCIe 6.0何必要一个UALink这个问题的答案要看PCIe的本质定位。PCIe是通用I/O总线它要兼顾存储、网卡、显卡、加速器等各种设备因此为了兼容性和通用性做了大量折中。 UALink不是通用总线它只需要把加速器到加速器的点对点超高速传输做极致优化因此在继承PCIe 6.0物理层的前提下砍掉了很多与AI通信无关的通用性负担换来了更低的延迟、更好的功耗控制和更灵活的拓扑支持。PCIe 6.0给UALink带来了哪些具体红利64 GT/s传输速率单根lane单向64Gbps双向128GbpsPAM4调制用4电平信号实现双倍信息密度同时配合前向纠错机制保证信号质量Flit模式编码把数据流切分成固定大小的包单元简化了链路同步和纠错复杂度。这些底层能力是经过多年验证的UALink等于站在成熟的地基上往上盖楼不需要从零发明信令、时钟恢复、均衡这些麻烦的物理层技术。 说句大白话PCIe 6.0已经把所有吃力不讨好的物理信号问题解决了UALink专注做上层针对AI通信的协议优化和价值定义。2.2 链路层和事务层不是简单“拉一根高速线”物理层只负责“能传”链路层和事务层才决定“传什么、怎么传得高效”。UALink 1.0在事务层定义了针对非一致I/O语义的报文格式也就是专门用来搬运数据、门铃、中断和同步消息的机制。我个人的理解UALink在协议层面的取舍很明确它不追求提供处理器缓存一致性这种复杂语义而是聚焦在加速器之间大批量数据搬移、同步原语和连接管理。 为什么要这么做因为AI训练的通信模式非常有规律主要是集合通信、对等搬移、屏障同步这几类把这些做透就够了堆更多通用语义只会增加延迟。链路层方面UALink支持类似以太网的可靠传输机制包括端到端重传和流量控制。 另外还定义了链路训练、错误检测、恢复流程这些对大规模系统尤其重要当上百个加速器互连在一起任何一条链路抖动都可能被放大成整个训练作业的中断健壮的稳定性和快速恢复能力很重要。2.3 拓扑与规模一台“GPU超节点”内部怎么连接UALink 1.0规范支持的端点规模设计目标是把几十个加速器高效连成一个超节点级别的互联域。 这个数字在AI集群场景里很有讲究以千卡万卡级别的scale-out网络来看节点之间的通信可以容忍几微秒延迟但在单节点内的张量并行通信几乎是每几步就要发生一次延迟极其敏感。UALink瞄准的正是后者也就是scale-up域。我帮很多朋友画过这类拓扑图实际落地时最常用的还是两种形态直连拓扑加速器两两直连简单的all-to-all形态适合节点数量少的场景交换拓扑通过UALink交换芯片连接多端口加速器类似NVSwitch的角色可以扩展到更大规模。基于PCIe 6.0物理层UALink x16端口的单向带宽可以做到128GB/s双向做到256GB/s这个数据已经远远超出普通PCIe Gen5 x16的带宽也超过了目前绝大多数网卡的互连能力足以满足大规模模型训练中张量并行的通信需求。2.4 多节点带宽计算实战每次评估互连方案我都会习惯性地做一道简单估算题这里也带大家算一遍。 假设一个加速器节点包含8个加速器每个加速器用16条lane的UALink连接到交换网络单向带宽是128GB/s双向就是256GB/s。一个大模型训练任务如果采用张量并行每步迭代的通信量大概是模型参数量的几倍到几十倍。以175B参数级别的模型为例张量并行度设为8则每步通信量约百GB级用单个UALink x16端口的双向往返带宽256GB/s来看通信时间大约在几百微秒到一毫秒量级。只要计算量足够大就能做到通信和计算重叠利用率可以拉得比较理想。 相比之下如果用传统的200Gbps网卡走以太网单向带宽只有25GB/s同样数据量要好几秒大数据搬运在训练中根本扛不住。这也就是为什么AI集群的scale-up域需要UALink这种专用互连。3. UALink不是凭空冒出来的和一堆互连方案的关系梳理3.1 与PCIe/CXL的关系看得多了很多朋友容易把UALink和PCIe/CXL混淆我自己也犯过迷糊。 简明版本是PCIe负责系统和外设之间的通用通信CXL在PCIe物理层上增加了内存语义和缓存一致性主要用于内存扩展和资源池化而UALink则专攻加速器之间的非一致高带宽通信。它们不是替代关系。 实际系统里很可能是CXL用来做内存池扩展PCIe用来接存储和常规I/OUALink负责加速器之间的高速数据搬移各干各的活。有一点值得注意UALink不走缓存一致性走的是非一致I/O语义意味着它不负责维护各加速器视图下的缓存一致性这反而让设计简洁高效。 AI工作负载中程序员通常能控制何时需要同步数据不需要硬件层面全局一致性。3.2 与UCIe/BoW的关系封装内和封装外UALink标题里的“Chiplet”让不少人误以为它和UCIe是同一类东西。这里我特别想讲清楚。 UCIe关注的是封装内部的chiplet间互连比如把计算芯粒、存储芯粒放在同一颗封装里die-to-die互连的延迟在纳秒量级而UALink关注的是封装之外、机框之内甚至跨机框的chiplet/板卡之间的互连延迟是微秒量级的本质上是系统和系统之间的关系。如果做一个类比UCIe是芯片内部的“立交桥”UALink是城市之间的“高速公路网”。 在实际系统里一个计算节点中可能既有UCIe连接着内部chiplet又通过UALink连接着其他计算节点。3.3 与InfiniBand/以太网的关系scale-up和scale-out我们常说的InfiniBand、RoCE、Ultra Ethernet这类方案定位是scale-out——横向扩展成千上万个节点之间的通信。 这类通信特点是距离远、跳数多、存在复杂的路由和拥塞控制延迟通常在微秒级以上带宽以每端口200G/400G为主。UALink定位是scale-up——把几十个加速器拉近到一台“超节点”里做近距离高带宽互联。它的拓扑相对固定延迟可以更低带宽密度可以做得更高。 一个现代AI数据中心既需要scale-out网络也需要scale-up域二者是配合关系。3.4 与NVLink/NVSwitch的关系最直接的对手UALink最直接的参照系当然是NVIDIA的NVLink和NVSwitch。 NVIDIA在自家GPU之间使用NVLink做高速互连并通过NVSwitch构建多GPU全互连AMDG其他厂商没有授权无法直接使用。 这种专有方案性能出色但生态封闭其他加速器、交换芯片、网卡厂商很难融入。UALink本质上是这类技术的开放替代保留高带宽低延迟专用互连的优势却允许多家芯片厂商实现和互操作。 从产业生态选型看市场中AMD方案、自研AI芯片、白盒加速器ULink对他们都很友好而在NVIDIA生态为主的场景NVLink的统治力短期内很难被动摇。4. 从标题里的Chiplet说开去为什么这是一件趋势性的事4.1 chiplet思想对互连行业的冲击UALink规范名称里带着“Chiplet”我认为相当精准。 今天做AI加速器几乎没有厂商像以前那样只做一颗超大单芯片了。CPU、GPU/NPU、HBM、SerDes、NoC等部分会被拆成多个chiplet再通过先进封装集成。这种趋势带来一个关键变化互连不再是一块均匀的“芯片内部线路”而是从die内、封装内、板级到机框级逐层延伸每一层都需要清晰的标准接口。 UALink实际上在做的事情就是把系统级也“chiplet化”——每块加速板卡或者说加速器chiplet可以被独立设计、生产、升级和替换只要遵循统一互连接口就能跨厂商组装成大规模互连系统。这和传统“主板多卡”思路相比更像是在建立一套面向AI计算基础设施的模块化生态。4.2 开放标准对整个行业的影响UALink由多家巨头共同推动正向意义在于让生态不再被一家公司绑定下游用户有了更多选择上游芯片厂商也有了更公平的竞争空间。 为什么这么多厂商愿意坐在一起因为AI基础设施投资体量太惊人谁都不想把命运押在单一供应商上。我参与过一些加速卡方案的沟通团队反馈很一致只要UALink生态成熟他们愿意在后续产品中引入UALink接口因为这样做可以同时兼容多个客户的集群方案采购灵活性和供应链安全性更高。 即便现阶段IP、开发工具、测试流程还不够完善方向已经确定了。4.3 对AI芯片厂商的实际影响如果你所在团队正在做自研AI加速器你大概率要考虑这么一个问题加速器之间用什么互连方案 过去没什么选择要么倒向专有生态要么用普通以太网凑合。UALink出现后关键影响主要有三点互连方案可以从标准里找不需要自己发明协议栈可以参照规范直接采购或自研PHY和控制器IP减少兼容性风险用户侧软件栈可以标准化不必绑定特定厂商库。当然开放不等于免费UALink同样需要IP授权费用和大量工程验证投入但它给行业一开始就划定了一个共同基准总比各搞各的强得多。5. 实操参考架构师和工程师现在能做什么5.1 评估UALink适不适合你的场景我的建议是先做客观的需求分析不要因为“新标准”三个字就盲目上马。这里给一个简单的评估框架如果你的产品定位是单卡推理或低带宽边缘计算UALink大概率用不上如果你的产品是训练/推理集群用的AI加速器并且需要多卡张量并行、专家并行UALink就是应该认真评估的候选方案如果你做的是智能网卡、交换芯片、高速背板UALink则为定义新形态的加速器交换设备提供了可能性。带宽估算需要结合具体的模型和并行策略来做不能只看峰值数字。 通信占比超过20%的工作负载非常适合从普通网络迁移到UALink这类scale-up互连。通信占比在几个百分点以下的大概率还是受限于计算和访存互连方案升级收益不显著。5.2 硬件实现层面的注意事项如果开始评估硬件实现我觉得有几件事需要提前想清楚。PCBA和信号完整性。64GT/s PAM4信号对布线的损耗、串扰和反射极其敏感。我见过不少百G信号项目里工程师按原有习惯做背板走线和连接器选型最后眼图惨不忍睹。 UALink落地时建议提前用仿真工具做完整的通道评估选择合适的板材、连接器、线缆并严格控制走线长度和阻抗一致性。时钟与参考时钟设计。PAM4对时钟抖动很敏感参考时钟的相位噪声要求比普通PCIe复杂最好在选择时钟芯片时留出足够裕量。热设计和功耗预算。高速SerDes功耗不可小觑。 以64GT/s速率计算每组PHY功耗通常是数瓦级集成多端口时必须整体看待散热和电源方案。测试接口预留。主板或板卡建议预留高速测试点至少包括一个可访问的调试接口方便链路层训练状态读取和错误寄存器观测。5.3 软件生态观察API、驱动和编程模型UALink的硬件标准定下来了但软件生态还在建设期。 从目前行业格局看用户侧的编程框架如PyTorch、TensorFlow等不会直接感知UALink中间需要一个类似集合通信库的适配层。实际项目里软件栈通常是这么个形态PyTorch分布式拉到底层集合通信库再通过厂商驱动把集合通信操作映射到UALink链路。 因此评估UALink时必须同步评估软件SDK质量、驱动稳定性、常见集合通信操作的支持程度。 如果产品节奏很赶需要确认原厂能否提供完善的用户态驱动和通信库集成方案不然空有硬件带宽上层用不起来就等于白搭。5.4 测试与验证建议我自己做互联类项目时非常看重验证环节流程一般是这样的单链路自环测试先验证单条链路的基本收发观察误码率和眼图确保物理层没有问题双端口互通测试用两台设备的单端口对连确认链路训练、链路状态机和基本数据传输正常多端口并发压力测试开启全端口流量观察是否出现重传、降速、链路抖动这一阶段最容易暴露电源纹波和散热问题长时间稳定性测试结合真实AI通信模式跑连续高负载至少要运行72小时以上观察错误和重传统计是否有递增趋势故障注入测试人为断开链路、插拔线缆确认系统能否正确感知链路异常并恢复这是分布式系统可靠性的基础。如果测试团队暂时没有PAM4误码仪也可以用FPGA内部集成的测试模块做初步验证但最终量产后还是要有支持64GT/s速率的测试设备做一致性测试。6. 常见问题速查与避坑记录这里把我在实际交流中经常被问到的问题整理成速查表帮助大家快速定位问题说明避坑建议UALink和UCIe是不是一回事不是。UCIe是封装内die互连UALink是系统级加速器互连两者可能出现在同一套系统里别混为一谈UALink能不能替代PCIe插槽不能。PCIe仍然承担系统和外设的通用I/OUALink只用于加速器之间产品设计时两者各司其职别指望一口吃成胖子UALink支持内存语义或缓存一致性吗1.0不支持它专注于非一致I/O语义的数据搬运和同步如果要做内存池化还是看CXL能否直接用PCIe连接器跑UALink电气层面可以复用PCIe 6.0技术但物理形态和协议栈不同严格按照UALink参考实现设计连接器方案小规模双卡或者四卡系统需要UALink吗看通信需求如果集合通信占比很低现有PCIe/CXL可能更经济别为了追新标准而叠成本开放标准是否一定兼容开放标准只保证规范不代表所有厂商实现都百分百互通采购前要做互操作性验证不要只看协议文档UALink的低延迟到底能到多少与具体实现和拓扑强相关没有统一数字真实系统上做延迟测试别只看厂商宣传想尽早支持UALink现在能做什么可以先做通道评估、IP选型和软件SDK调研等规范更多配套工具陆续到位后再全面转向还有两个比较容易被忽略的坑我这里也单独提一下。坑一把仿真性能当实际性能。链路能不能跑通跑起来之后的实际有效带宽和延迟往往会受驱动、软件栈、拓扑拥塞影响差距可以非常大。坑二低估系统级联调的成本。芯片本身只是连起来了各厂商设备之间的协议互操作、错误处理路径协调、链路退避恢复机制都需要大量联调工作。我在很多项目里的经验是多厂商设备联合调试验证的时间往往比孤立的单点测试多3到5倍这个时间要提前排进项目计划。7. 对UALink后续发展的几点个人观察1.0规范只是开始UALink后续演进方向其实已经比较清晰速率进一步提升、拓扑规模扩大、内存语义支持、更完整的可管理性和安全机制。 从PCIe 6.0物理层出发将来的版本很可能会跟随PCIe后续速率演进比如基于PCIe 7.0的信号系统把单链路带宽再往上拔。我个人觉得更值得关注的不是UALink某一项技术指标而是它代表的生态整合趋势。 AI基础设施行业正在从单一厂商主导走向高度标准化。 当年x86服务器生态靠PCIe完成了统一如今AI加速器生态很可能要靠UALink这类标准完成互连层面的统一。还有一个观察UALink和UCIe一个管板级互连一个管封装内互连未来两者结合会定义完整的chiplet开放平台。 系统厂商可以做“算力单元”插接模块加速器厂商可以只造chiplet核心由别人集成封装这种全新的制造分工可能比单独某款芯片的发布更有长期价值。最后说点实在的。 我接触UALink以来最大的体会是技术标准最后能不能站住脚从来不是只看技术指标多炫而是看有没有足够多的真实系统用它跑出了真实收益。 UALink走的是开放路线有众多有分量的厂商投入这在起步阶段是很强的信任背书。但接下来IP成熟度、软件生态友好度、跨厂商互操作一致性才是真正决定它能否大规模落地的关键。如果你正在规划的下一代AI加速器或集群我建议认真把UALink纳入技术调研清单尽早做通道仿真、IP选型和软件生态梳理。 等到大规模铺开的时候再开始动手项目排期上会吃不少亏。多看看规范原文多了解生态工具的进展这件事值得投入时间。