AMD Helios QFX5252 交换托盘让开放以太网成为一项物理挑战

AMD 在 OCP 2026 展示了其 Helios QFX5252 交换托盘，公开呈现了两颗交换芯片、液冷管路、重定时器和密集铜缆。该硬件让 AMD 的开放以太网战略具象化，也揭示了落实这一战略的难度。

该托盘并非端口朝向网络通道的传统机架顶部交换机。它是一个集成式 scale-up 模块，用于连接单个 AMD Helios 机架内的加速器。其任务是让 72 块 Instinct MI455X GPU 更像一项统一的计算资源。

这使 QFX5252 置身于更大的竞争之中。AMD、HPE、Juniper 和 Broadcom 正在推进一种基于以太网的替代方案，以对抗高度受控的专有加速器网络。NVIDIA 仍是参照对象，但眼下的冲突在于架构：开放以太网的灵活性，对阵集成式网络的效率。

AMD Helios QFX5252 交换托盘在 OCP 2026 揭开面纱

OCP 上最重要的变化在于可见性，因为 QFX5252 的内部构造将一项架构承诺变成了可供检视的硬件。

HPE 于 2026 年 6 月发布了 QFX5252，但 OCP 展示说明了该 scale-up 模块如何组装而成。Patrick Kennedy 的开放式交换托盘照片显示，双宽机箱内设有两个相邻的交换部分。

2026 年 OCP 全球峰会于 10 月 12 日至 10 月 15 日在加州圣何塞举行。峰会日程将 AI 基础设施、开放网络、散热和供电列为核心议题。

QFX5252 将这些主题汇聚在一个托盘中。据 ServeTheHome 报道，其内部布局包含两颗 Broadcom Tomahawk 6 交换芯片。每颗芯片提供每秒 102.4 太比特的交换容量，使该托盘的总容量达到 204.8 Tbps。

这个数字需要谨慎解读。它描述的是两颗芯片合计的交换容量，而非单一应用可用的带宽。工作负载性能还取决于拓扑、协议效率、软件、拥塞状况以及机架的其他部分。

芯片位于液冷模块下方。ServeTheHome 认定为重定时器的组件上方，也配备了额外散热硬件。重定时器接收并重新发送高速信号，帮助信号跨越电气条件苛刻的更长路径。

这些部件之所以重要，是因为后部连接器并不都靠近每颗交换芯片。信号必须穿过托盘，到达高密度盲插连接器；当操作人员将模块滑入机架时，这些连接器会自动接合。

在 224G PAM4 信号速率下，电路板距离的代价变得高昂。PAM4 通过四种信号电平编码每个符号中的两比特，在提升容量的同时，也提高了对信号完整性的要求。更长的电气路径会遭受衰减、反射、抖动和串扰。

因此，该托盘采用线缆和重定时器，而非将印刷电路板视为完整的数据路径。这一选择造就了一台视觉上十分密集的设备，也说明高速网络为何日益依赖封装和机械工程。

甚至连把手也讲述了部分故事。ServeTheHome 注意到，该托盘配有异常长的插入杠杆。其后部连接器阵列会产生显著插入力，因此技术人员需要借助机械杠杆才能将组件正确就位。

在考虑可维护性后，这个细节便不再微不足道。AI 机架中的交换托盘必须连接供电、冷却液、管理系统及数百条高速通道。运营人员还需要能够在不重建机架布线系统的情况下更换它。

AMD 将 Helios 描述为一种模块化设计，集成了供电、冷却和网络连接。其公开的Helios 架构表示，更换 sled 无需重新布线，从而减少维护中断。

QFX5252 的展示为这一说法提供了更具体的依据，也暴露了其背后的工程成本。盲插在安装后简化了维护，但要实现这种简化，需要密集连接器、精确对准以及经过仔细管理的插入力。

其意义不止于一件外观吸引人的硬件。开放式机箱表明，scale-up 网络正成为机架级机械系统，而不只是若干高速交换芯片的集合。

为什么 Helios 需要机架内 scale-up 网络

QFX5252 的存在是因为，增加 GPU 并不会自动带来有用的计算能力，除非这些 GPU 能够在不等待网络的情况下交换数据。

大型 AI 模型并不总能装入单颗加速器的内存。训练和推理系统会将模型权重、激活值和计算拆分到多块 GPU 上，这些设备随后必须在整个工作负载运行过程中交换中间结果。

张量并行便是一例。它将单独的数学运算分配至多个加速器。每块参与的 GPU 都会反复共享部分结果，使网络延迟和一致性成为有效计算性能的一部分。

一条缓慢或不稳定的路径可能拖延整个群组。机架或许拥有巨大的标称处理能力，却因加速器等待集合通信而导致利用率不佳。

AMD 表示，Helios 在一个 scale-up 域内连接 72 块 Instinct MI455X GPU。该公司宣称其具备每秒 260 TB 的聚合双向 scale-up 带宽，并可访问 31 TB 的 HBM4 内存。

HBM4 是靠近加速器芯片部署的高带宽内存。它的作用是足够快速地提供数据，让计算引擎保持工作。要在多块 GPU 间整合这类内存，需要具备同样激进带宽的互连。

AMD 的 Helios 交换机规格描述了每台交换机 21.6 TB/s 的双向带宽。规格还列出两颗具有 512 条通道、200G 的 UALoE 交换 ASIC，每颗 ASIC 拥有 216 条活跃链路。

UALoE 指 Ultra Accelerator Link over Ethernet。它将 UALink 的 scale-up 模型适配至以太网技术，目标是在机架级系统内实现加速器间直接通信。

这不同于 scale-out 网络。scale-up 将加速器整合为紧密耦合的计算域，而 scale-out 则连接多台服务器或多个机架。两者都很重要，但解决的是不同的距离、延迟和故障问题。

AMD 将其更大的三层网络描述为前端、scale-up 和 scale-out 基础设施。前端负责用户、存储和服务；scale-up 连接机架内的 GPU，scale-out 则连接集群中的各个机架。

QFX5252 位于 scale-up 层。它承载的并非应用之间流动的普通企业以太网流量，而是直接影响昂贵 GPU 能否持续高效工作的同步和数据交换。

AMD 表示，每块 GPU 通过分布在不同交换托盘上的 18 个独立 UALoE station 连接。该公司称，当某一路径发生硬件事件时，这种安排能够维持统一的 GPU 域。

这一韧性主张仍需在生产工作负载下接受独立测试。不过，它解释了该设计为何采用多平面，而不是单一简单的交换路径。

HPE 最早于 2025 年 12 月概述了其 Helios 网络角色。该公司的机架公告将 Broadcom Tomahawk 6 芯片和 UALoE 确定为其 scale-up 交换机的基础。

HPE 还将 Helios 定位为 Open Rack Wide 设计。Open Rack Wide 采用双宽机架格式，旨在容纳高密度计算、供电、液冷和维护访问需求。

这种物理形态解释了 QFX5252 的特殊外形。传统的一机架单位交换机围绕前面板端口和可更换电源设计，而这个托盘属于按整体系统设计的机架。

它通过机架供电，而非依赖标准交换机电源线。其冷却连接集成至机架液冷回路。其后部连接器与线缆盒接合，而不是将完整网络结构暴露在前端。

最终形成的网络设备看起来更像一台服务器 sled。这并非造型选择，而是更广泛转变的体现：AI 集群正从采用通用组件进行组装，转向采购经过验证的机架级系统。

因此，对买家而言，评估单位正在变化。端口数量和独立交换机吞吐量依然有用，但无法概括维护流程、冷却液要求、拓扑、软件或工作负载层面的行为。

AMD Helios QFX5252 交换托盘让这些依赖关系变得可见。它将网络从一项外围采购，转变为加速器平台本身的一部分。

开放以太网遭遇 NVIDIA 的集成式网络模型

这场主要竞争并不是 AMD 与某一家交换机厂商之间的较量，而是开放以太网 scale-up 网络与紧密集成的专有网络之间的竞争。

NVIDIA 围绕 NVLink 和 NVSwitch 构建其 scale-up 系统。这种方式将加速器、互连芯片、系统设计和软件置于同一平台所有者的控制之下。

集成带来明确优势。一家供应商可以协调信号、拓扑、固件、集合通信库和加速器路线图。工程师可以共同优化这些层面，而无需协商跨公司标准。

其代价是依赖性。选择该系统的客户也会接受一套受到严格控制的软硬件栈。若不改变其他层，更换其中一层会变得困难。

AMD 和 HPE 正将 UALoE 展示为另一条路径。其设计结合了 AMD 加速器、HPE 系统工程、Juniper 网络软件、Broadcom 交换芯片以及源于以太网的互连技术。

HPE 于 2026 年 6 月正式命名 HPE Juniper Networking QFX5252。其网络发布公告称，该托盘是面向 AMD Helios 的 scale-up 模块。

HPE 表示，它提供大型 AI 系统所需的低延迟、高带宽交换能力。这是厂商说法，并非经独立证实的工作负载结果。

这种区别很重要，因为“开放”并不自动意味着可互换。标准可以公布电气、协议和管理要求，但实际部署仍可能依赖经过验证的软硬件组合。

QFX5252 同样采用商用芯片，但并非通用配置。Broadcom Tomahawk 6 提供交换基础，而 HPE 和 Juniper 将其封装用于 Helios，并以基于 SONiC 的软件进行运行管理。

SONiC 是一种开源网络操作系统，最初为云规模交换机开发。它将网络软件与单一硬件供应商分离，尽管生产环境的实现仍需要平台专属驱动程序和验证。

这种模式为 AMD 合作伙伴留下了差异化空间。HPE 可以提供机架集成、冷却、管理和支持服务。Juniper 提供网络运维专长。Broadcom 则供应高容量交换芯片。

但每增加一名参与者，协调工作就会增加。固件发布、协议变更、遥测、故障恢复和组件认证，必须跨越组织边界保持一致。

NVIDIA 的一体化模式将很大一部分协调工作内化。AMD 的路径则将其分散到合作伙伴和标准组织之间。客户获得了更多架构选择，但仍需要有人对最终的系统行为负责。

这也是 QFX5252 的意义不止于容量本身的原因。它证明了源自以太网的 scale-up 设计已经从标准讨论进入面向特定机架的产品阶段。

Tomahawk 6 的选择同样耐人寻味。ServeTheHome 指出，当前一代 Tomahawk Ultra 使用 112G PAM4 SerDes，而 Helios 使用 224G PAM4 链路。

SerDes 会将芯片的并行数据转换为高速串行信号，并在目的端执行逆向转换。其通道速率有助于决定交换机能够通过有限数量的物理连接传输多少带宽。

据报道，Tomahawk 6 符合所需的通道速率。不过，采用高容量以太网交换芯片并不能消除 224G 电气路径带来的物理损耗。

这直接引出了 retimer 和铜缆的问题。AMD 的设计通过有源组件和大型线缆组件来维持电气传输距离。据 ServeTheHome 报道，NVIDIA 曾讨论在某些设计中降低对 retimer 的依赖。

这种差异不应被简化为“开放更好”或“集成更快”。两条路径以不同方式分配复杂性。

AMD 的路径接受可见的物理复杂性和多供应商复杂性，以追求开放的 scale-up fabric。NVIDIA 的路径则将工程控制集中在其平台内部，并限制客户独立更换组件的空间。

商业压力首先落在基础设施采购方和系统供应商身上。他们需要可信的单一技术栈采购替代方案，但不能为了理论上的灵活性而牺牲可预测的训练性能。

HPE 同样有让这一模式奏效的战略理由。该公司于 2025 年完成对 Juniper Networks 的收购，使其在服务器、冷却、存储和服务之外，拥有了更大的网络产品组合。

QFX5252 让 HPE 能够将 Juniper 技术置于 AMD 机架内部，而不只是销售机架周边网络。这将其角色从提供 fabric 扩展为塑造 scale-up 系统。

对于 AMD 而言，该托盘回应了一项核心竞争需求。当市场日益以完整机架、软件环境、网络和部署周期来评估产品时，仅有强大的加速器还不够。

因此，OCP 展示也是一场生态系统测试。AMD 必须证明，基于标准的联盟能够交付一体化系统行为，而无需由一家公司控制每一层。

铜缆、Retimer 与冷却揭示真正的权衡

开放 fabric 的最大风险并非交换带宽是否充足，而是要在可维护机架内可靠交付这些带宽所需的复杂性。

机架内部仍青睐铜缆连接，因为它避免了光收发器及其相关的功耗、成本和控制要求。短距离电气链路也能提供出色的延迟表现。

问题在于传输距离。在 224G PAM4 下，每一个连接器、走线和线缆都会影响信号完整性。设计人员不能随意让通道穿越大型托盘，并假定接收器能够还原出干净的数据。

QFX5252 通过 retimer 应对这一问题。这些设备会在端点之间恢复信号质量，使通道能够传输得比直接无源路径所能支持的距离更远。

Retimer 很有用，但并非没有代价。它们消耗电力、产生热量、增加组件数量，并引入更多故障点。其固件和诊断功能也成为系统运维的一部分。

液冷负责处理主交换芯片和 retimer 模块周围的热量。ServeTheHome 的照片显示，内部歧管将冷却液分配至整个托盘。

一些其他组件仍采用风扇和散热器。这种混合冷却设计表明，液冷处理最集中的热源，而风冷对于低功耗电子元件仍然实用。

这种布局增加了维护复杂性。技术人员并非只是更换一台干燥、独立的交换机。该流程涉及一个与机架电源、冷却液连接、后部 fabric 连接器以及庞大线缆系统集成的组件。

AMD 表示，该设计支持无需重新布线即可快速更换 sled。如果盲插连接器和机架管路能在反复维护周期中可靠工作，这将提升可用性。

公开证据尚不足以证明这一结果能够在大规模部署中实现。OCP 展示设备证明了物理集成的存在，但并未证明连接器的长期耐久性、泄漏率、更换时间或应用可用性。

性能声明同样需要谨慎对待。HPE 曾宣传，其 Helios 配置可实现 260 TB/s 的总 scale-up 带宽，以及最高 2.9 exaflops 的 FP4 性能。

这些是平台规格。它们并未揭示特定模型、集体操作、序列长度、批量大小或故障场景下的持续吞吐量。

204.8 Tbps 的交换芯片合计容量，也不能与 260 TB/s 的机架总带宽直接比较。前者描述的是以太比特计的交换容量，后者则汇总了以太字节计的双向数据传输量。

不同的统计口径可能使架构看起来比实际更接近或更悬殊。采购方在将标称带宽用于采购比较之前，需要获得公开的测试方法。

功耗也是另一个悬而未决的问题。AMD 发布了 Helios 交换托盘的带宽和连接性细节，但其公开产品页面没有提供完整的 QFX5252 功耗配置。

这一缺失很重要，因为每个 retimer 和冷却组件都会增加机架功耗。相关指标不只是峰值计算能力，而是在现实利用率下，每单位能耗完成的工作负载量。

软件同样决定硬件的开放性能否转化为实际选择。预计 AMD Fabric Manager 和 Fabric OS 将负责管理整个 scale-up 网络中的配置、遥测、工作负载部署和故障恢复。

HPE 将 Juniper 运维能力和 SONiC 引入该系统。挑战在于，将这些层面呈现为一个可支持的产品，而不是多个彼此相邻的管理域。

故障将检验这一承诺。当训练任务变慢时，运维人员必须判断原因是加速器、线缆、retimer、交换路径、软件策略、热状态，还是集体通信库。

集成遥测能让这种排查变得可控。碎片化工具则可能让开放性演变成跨供应商的漫长升级流程。

这一物理设计还提出了另一个前瞻性问题：在这些通道速率和距离下，铜缆还能保持实用多久？

ServeTheHome 认为，QFX5252 展示了共封装光学（CPO）的必要性。CPO 将光引擎置于靠近交换芯片的位置，从而缩短高速电信号所需传输的距离。

这或许能消除部分铜缆和 retimer 复杂性，但也可能带来新的维护、散热、激光器、光纤管理和制造挑战。

因此，QFX5252 应被视为针对过渡性问题的一种精密解决方案。它将铜缆 scale-up 连接推入 224G 时代深处，同时也表明未来系统为何可能将光学器件移至更靠近芯片的位置。

这并不意味着该托盘在出货前就已过时。数据中心只有在技术满足成本、可靠性和供应要求时才会采用它。只要铜缆能够可预测地覆盖所需距离，它就仍有价值。

悬而未决的问题是，这种实现能否提供可接受的系统经济性。采购方需要来自生产部署的证据，而不只是照片和组件规格。

三个信号将决定 QFX5252 是否重要

下一阶段是商业和运营验证，因为引人注目的 OCP 展品并不能证明其具备生产级领导地位。

第一个信号是客户部署。AMD 在 10 月表示，客户正在自己的场地测试 Helios 系统、验证工作负载，并为更大规模部署做准备。

更有力的信号将是具名生产集群及其公开的安装里程碑。交付机架固然有用，但在训练和推理工作负载下持续运行，才能提供更有意义的证据。

部署披露应明确系统规模、工作负载类型和运营状态。计划中的订单，其分量低于已验收并在运行客户任务的硬件。

第二个信号是独立的性能和可靠性数据。采购方需要了解集体通信结果、应用吞吐量、功耗测量以及路径故障时的表现。

标准加速器基准测试只能捕捉故事的一部分。最具参考价值的测试将让网络承受大量 GPU、并发工作负载、长时间运行和注入式故障的压力。

关注 AMD 的多平面拓扑是否能在链路或托盘路径故障时保住任务的证据。无需终止昂贵训练任务即可恢复，将支持该架构的韧性论点。

维护指标同样重要。运维人员应报告诊断和更换 QFX5252 所需的时间，包括排空冷却液连接并重新插接盲插接口。

第三个信号是生态系统能否扩展到一种 HPE 配置之外。当多家供应商实施兼容产品、客户能够行使有意义的选择权时，开放标准才会获得战略价值。

另一家 Helios 系统供应商若采用不同的合格交换实现，将强化 AMD 的开放性主张。可互操作的管理和一致的工作负载行为，将使这一论点更有说服力。

相反的结果会削弱这一主张。如果每一家 Helios 供应商都依赖同一种紧密耦合的托盘和软件组合，那么该设计即使在规范上保持开放，行为上也可能像一个垂直整合产品。

NVIDIA 的回应将提供另一项有用参照，但不应重新定义评估标准。真正相关的测试是，基于 QFX5252 的系统能否为希望采用替代加速器技术栈的客户交付可预测的结果。

AMD Helios QFX5252 交换托盘作为工程演示已经取得成功。它将两颗高容量交换芯片、224G 通道、液冷、retimer 和高密度铜缆整合进一个可维护模块。

其暴露的内部结构也让简单口号难以成立。开放的 scale-up Ethernet 并非专有 fabric 的简单替代品。它将复杂性转移到了标准、合作伙伴协调、封装、软件和系统验证之中。

正在评估 Helios 的基础设施团队现在应要求提供工作负载层面的证据、功耗数据、故障恢复结果和记录完善的维护流程。他们还应审查哪些组件真正可互换。

这些证据将决定 OCP 硬件会成为持久平台，还是只停留在令人印象深刻的展示品。关注首批生产安装、独立集群测试和更多 UALoE 供应商。这三个信号将显示 AMD 的开放 fabric 能否作为一个运行系统竞争，而不只是作为一种架构。