AMD 借力 Google 标准，与 Nvidia 在 Vulcano AI 网络测试中正面交锋

尽管 Nvidia 在大型 GPU 集群的高度集成网络领域占据领先地位，AMD 仍推出了其 800 Gbps Pensando Vulcano AI NIC。AMD 与 Google 的关联之所以重要，是因为两家公司都支持开放互连标准，旨在为基础设施采购方提供更多硬件选择。不过，Google 尚未公布部署 Vulcano 的计划。

Vulcano 试图解决 AI 数据中心内部一项代价高昂的问题：当网络拥塞、丢包或恢复缓慢延误服务器之间的通信时，加速器可能会闲置。AMD 表示，三张 Vulcano 网卡可为每块 GPU 提供 2.4 Tbps 的横向扩展带宽。

这一数字为 AMD 提供了醒目的卖点，但并不意味着必然胜出。Nvidia 已经销售由 GPU、Spectrum-X Ethernet、InfiniBand、NVLink、交换机及网络软件组成的成熟组合。Vulcano 必须证明，开放且可编程的以太网方案可以提供相当的运营一致性，而无需依赖单一供应商的完整技术栈。

AMD Pensando Vulcano 800 有何变化

Vulcano 将网络能力纳入 AMD 机架级 AI 平台的核心，而非在选定 GPU 后附加的配件。

AMD 于 2026 年 7 月 23 日公开详述了 Pensando Vulcano 800 AI NIC。这款适配器面向横向扩展网络，用于在本地纵向扩展链路达到实际极限后，连接跨服务器和机架的加速器。

每张网卡提供 800 Gbps 网络连接。AMD 支持为单块 GPU 配置最多三张 NIC，从而形成其宣称的 2.4 Tbps 聚合带宽。

这种安排不同于将一张网络适配器作为多块加速器共享的端点。多条独立链路既能提高可用带宽，也能让流量在集群中拥有不止一条传输路径。

AMD 将其称为多平面架构。网络平面是包含自身链路和交换资源的独立数据路径。将流量拆分到多个平面可限制链路故障或路由拥塞的影响。

该公司还表示，Vulcano 最多可将交换成本降低 33%。AMD 将这一估算归因于其参考配置中更少的线缆和收发器，而非每种部署场景下的普遍成本下降。

其性能声明同样需要作出限定。AMD 表示，Vulcano 最多可将 AI 任务完成时间缩短 13%。这一结果是与特定工作负载和系统假设相关的公司基准测试结果。

这两个百分比都不应被视为针对每个集群、经独立验证的性能表现。采购方需要进行工作负载级测试，其中应包括交换机、光模块、拓扑、软件版本、故障行为和加速器利用率。

其底层机制仍具可信度。分布式训练会在加速器之间反复交换模型参数和中间结果。一条路径的延迟就可能阻塞一次集合通信操作，让昂贵的 GPU 等待其他节点。

分布式推理会形成另一种流量模式。随着用户需求变化，它可能在系统之间转移请求、模型状态和缓存数据。可预测的延迟与峰值吞吐量同样重要。

Vulcano 通过可编程传输逻辑、拥塞控制、故障隔离和在线诊断来应对这些模式。AMD 表示，运营商可以通过软件更新其中部分行为，而无需更换网络芯片。

该 NIC 使用第三代可编程 P4 引擎。P4 是一种用于定义网络设备如何处理数据包的语言和架构。它允许供应商在硬件支持的范围内调整特定的转发和传输行为。

AMD 的 Vulcano design 还包括 PCIe 和 UALink 连接选项。这种灵活性使适配器能够在不同机架设计中与 CPU 或加速器连接。

因此，该产品不仅仅是更快的以太网端口。AMD 正尝试将 GPU、CPU、网络芯片、开放传输协议和管理软件协调为一个机架级系统。

AMD 与 Google 的标准关联为何重要

AMD 与 Google 的关系属于标准联盟，而非 Google Cloud 已选择将 Vulcano 用于生产环境的证据。

AMD 和 Google 是 2024 年 Ultra Accelerator Link 推动组织的首批成员之一。Broadcom、Cisco、Hewlett Packard Enterprise、Intel、Meta 和 Microsoft 也参与其中。

UALink 面向计算 Pod 内部加速器之间的纵向扩展通信。纵向扩展网络构建紧密连接的加速器域，而横向扩展网络则通过更大的网络结构连接多个服务器或域。

这两种角色在系统边界处有所重叠，但并不能互相替代。Vulcano 主要处理横向扩展和跨域扩展流量。其 UALink 接口有助于它在新兴的开放机架架构中直接连接加速器。

因此，AMD 与 Google 这一关键词可能造成误导性印象。没有经过验证的公告表明 Google 参与设计 Vulcano、采购了该 NIC，或承诺为其提供 Google Cloud 容量。

Google 的重要性来自其超大规模运营商和标准参与者的地位。其参与让开放互连工作更具意义，因为 Google 了解大型 AI 系统对流量、可靠性和集群管理的需求。

UALink consortium 发布了首个规范，可在单个 Pod 内连接最多 1,024 个加速器。多家云运营商和芯片供应商的支持，可降低该标准依赖单一供应商的风险。

Vulcano 还支持用于系统间通信的 Ultra Ethernet。UEC specification 定义了一个面向 AI 和高性能计算的、基于以太网的通信栈。

Ultra Ethernet 改变的不只是原始链路速度。它还涉及高度同步工作负载所需的数据包传输、拥塞管理、多路径、安全性和通信语义。

AMD 还在推进多路径可靠连接协议，即 MRC。这种传输协议可在保持可靠交付的同时，将数据分散到多条路径，并对拥塞或故障作出响应。

AMD 表示，其与 OpenAI 共同开发了 MRC，用于大型训练环境。该公司已在此前的 Pollara 400 NIC 上实现该传输协议，并表示在新平台正式普及后，Vulcano 将支持它。

根据 AMD 的 MRC implementation，Pollara 已在公司实验室中通过 Instinct MI350 和 MI355 集群验证。AMD 表示，OpenAI 参与了该验证工作。

MRC 可通过 IPv6 上的分段路由运行，从而让运营商明确控制数据包路径。它也可与等价多路径路由和动态负载均衡配合使用。

这种适应性支撑着 AMD 更广泛的论点：运营商应能采用新的传输行为，而无需更换围绕加速器集群的每一台交换机、每根线缆和每项管理流程。

Google 参与标准工作加强了这一论点，但并不能验证 AMD 的产品声明。规范定义的是共同的行为方式，而生产部署会暴露具体的实现质量。

书面标准无法保证拥塞时稳定的任务完成时间。它也不能证明诊断工具能够迅速识别故障，或不同供应商会以完全相同的方式解释每项可选功能。

因此，对采购方而言，AMD 与 Google 的故事关乎战略一致性。两家公司都支持封闭式加速器网络结构之外的替代方案，但 Vulcano 必须凭借可衡量的集群性能赢得采用。

这一差别对采购团队很重要。他们应将 Vulcano 视为新兴多供应商环境中的 AMD 产品，而不是一张获得 Google 背书的网络卡。

Vulcano 的机制是带宽加可编程性

Vulcano 最有力的技术论点不只是 800 Gbps，而是多路径、可编程传输和快速故障恢复的结合。

AI 网络涉及众多端点之间的同步通信。在训练期间，集合通信操作会合并或重新分配每个参与加速器产生的数据。

如果一个流遇到拥塞，整个训练步骤都可能减慢。其余 GPU 可能完成本地工作，却无法继续推进，直到集合通信完成。

传统以太网通常通过对流标识信息进行哈希来将流量分布到不同路径。一条大流可能始终被困在拥塞路由上，即使另一条路由尚有闲置容量。

MRC 的设计目标是更主动地使用多条路径。它可以将流量拆分为多个部分、根据路径状况作出反应，并在不强迫应用程序重启完整通信的情况下恢复。

Vulcano 的可编程数据包处理引擎将部分控制能力部署在网络边缘附近。这一位置很重要，因为 NIC 能够观察进入和离开每台服务器的流量。

该网卡还可在集群保持活动状态时隔离故障并执行诊断。AMD 表示，这些功能可缩短修复时间，并避免部分全集群维护窗口。

随着集群规模扩大，这类能力变得更加宝贵。即使每个组件本身都具有很高的可靠性，拥有数千个组件的系统仍会经历常规的链路、光模块、固件和交换机故障。

网络必须以可预测的方式降级，而不是让一次故障演变为任务停滞。多个平面提供替代路径，而传输逻辑决定流量应如何在这些路径间移动。

每块 GPU 配备三张 800 Gbps NIC，可提供可观的物理容量。然而，聚合带宽并不意味着每个工作负载都会持续传输 2.4 Tbps 的有效数据。

GPU、主机接口、集合通信库、拓扑和远端端点都必须高效提供流量。协议开销和工作负载同步也会降低应用层吞吐量。

AMD 的架构同时支持 PCIe 和 UALink 主机连接。PCIe 仍是 CPU 和外设熟悉的接口。UALink 则以较少依赖单一 GPU 供应商的方式，面向直接加速器连接。

Vulcano 还与 AMD Helios 相关联；后者是该公司的机架级设计，采用 Instinct MI400 系列加速器和 EPYC Venice 处理器。AMD 已将该 NIC 定位为 Helios 默认的横向扩展网络组件。

这种集成让 AMD 对验证拥有更大控制力。该公司可以将固件、ROCm 通信库、加速器行为和网络遥测作为协调一致的平台进行测试。

不过，可编程性也带来运营成本。可变更的数据包处理管线需要严格的版本控制、测试、可观测性和回滚流程。

网络团队必须了解任务失败时启用了哪些固件和传输设置。他们还需要能将拥塞事件与应用性能关联起来的工具。

P4 这一标签并不会消除这些要求。它只是让 AMD 及获批准的运营商拥有更大的空间，来改变受支持的数据包处理功能的行为方式。

开放标准带来了另一项实施挑战。两款产品都可能宣称支持同一规范，但在可选功能、性能上限或管理接口方面存在差异。

因此，互操作性测试将成为决定性因素。采购方需要证据证明，Vulcano 能够与第三方交换机、光模块、路由软件和监控系统可靠协同工作。

AMD AI NIC 页面重点提及超大规模云服务商和云提供商。这些客户拥有能够大规模测试复杂网络行为的工程团队。

企业采用的节奏可能更慢。许多企业会购买完整系统，因为它们缺少能够独立集成加速器、NIC、交换机、固件和传输设置的人员。

Vulcano 仍可通过经过验证的 Helios 系统或云服务帮助这些组织。开放程度将取决于有多少供应商推出受支持的配置。

这正是该产品面临的实际考验。可编程性必须降低网络适配成本，而不能将过多集成工作转嫁给客户。

Nvidia 的一体化技术栈仍是主要对手

AMD 挑战的是 Nvidia 对 AI 系统架构的掌控，而不只是与另一款 800 Gbps Ethernet 适配器竞争。

Nvidia 可在横向扩展域内通过 NVLink 连接其加速器，随后利用 Quantum InfiniBand 或 Spectrum-X Ethernet 在服务器和机架之间进行通信。

Spectrum-X 将 Nvidia 交换机、SuperNIC、拥塞控制、遥测和软件结合在一起。Nvidia 将这些组件作为与其 GPU 平台紧密绑定的端到端系统进行测试。

这种集成可简化责任归属。当 AI 任务表现不佳时，客户可以要求同一家供应商检查加速器、网络适配器、交换机、固件和通信库。

Nvidia 表示，Spectrum-X Ethernet 相比传统 Ethernet 可将网络性能提升 1.6 倍。与 AMD 的数据一样，这也是基于特定配置得出的厂商说法。

Spectrum-X 也支持包括 SONiC 在内的开放网络操作系统。因此，竞争并非简单地发生在开放 Ethernet 与完全封闭的替代方案之间。

真正的差异在于控制权和组件选择。Nvidia 优化其定义好的芯片与软件组合，而 AMD 则强调跨供应商的可编程设备和行业规范。

紧密集成可带来一致的行为，但也可能增加对单一供应商发布节奏的依赖。多供应商设计可提供更多选择，但认证工作会更加困难。

Vulcano 需要证明，其开放路线不会牺牲可预测的性能。仅凭峰值吞吐量无法解决这一问题。

AI 集群运营商会考察任务完成时间、尾延迟、故障恢复、有效 GPU 利用率以及租户之间的性能隔离。他们还会追踪功耗和所需光模块数量。

AMD 关于完成时间缩短 13% 的说法具有相关性，因为它衡量的是应用结果。不过，公开资料并未证明其相较 Spectrum-X 或 InfiniBand 具有普遍优势。

33% 的交换成本说法同样需要谨慎解读。更少的线缆和收发器可降低设备支出、安装工作量和故障点。

但每个 GPU 配置三张 NIC，也可能在其他环节增加适配器、主机接口和管理复杂性。总体结果取决于拓扑结构和比较基线。

Nvidia 还凭借已部署系统拥有另一项优势。其网络产品已在大型 AI 集群中运行，为客户提供了实施参考和成熟的支持实践。

AMD 也并非毫无经验。Pensando 过去曾推出 DPU 和 Pollara AI NIC，AMD 也曾与云服务商和系统供应商在数据中心网络领域合作。

不过，Vulcano 的推出同时伴随着其他多项变化。Helios 引入了新的 Instinct 加速器、EPYC 处理器、UALink 连接以及不断演进的开放软件栈。

任何一层出现问题都可能延缓认证。即使另一种设计承诺提供更好的组件灵活性，客户仍可能选择成熟配置。

对于急于获得近期训练能力的组织而言，风险最高。它们的优先事项通常是尽快让集群上线，而非最大化未来的供应商选择空间。

长期采购方可能更看重开放路线。基础设施会跨越数代加速器持续使用，而模型和通信模式的变化速度快得多。

Vulcano 的 P4 可编程性可帮助 AMD 应对这些变化。新的拥塞控制或传输行为，或可在硬件能力范围内通过软件实现。

Nvidia 同样可以更新其技术栈。它还受益于对更多组件的控制，这可加快整个系统的协调变更。

因此，主要竞争在于运营能力。AMD 必须证明，基于标准的选择能够匹敌 Nvidia 一体化平台的可靠性、工具和验证能力。

Google 参与开放互连组织，增强了人们对替代方案拥有严肃行业支持的信心。但这并不能抹去 Nvidia 的既有装机基础和执行优势。

AMD 仍需证明什么

最大的不确定性在于，Vulcano 已公布的收益能否经受现实多供应商集群中的独立测试。

AMD 公布的数据描述了最大能力和选定比较结果。它们尚未提供覆盖训练、分布式推理和混合工作负载的大范围第三方结果。

2.4 Tbps 数据指的是由三张 800 Gbps NIC 提供的聚合横向扩展带宽。它并不保证单个 GPU 应用能持续获得这一数据速率。

独立评测应在拥塞条件下测量有效吞吐量，还应报告延迟分布、数据包恢复行为和加速器空闲时间。

故障测试与稳态速度同样重要。评测人员应在分布式任务保持运行时禁用链路、引入丢包、重启交换机并改变路径延迟。

MRC 随后需要互操作性证据。AMD 表示该传输支持多种转发方式，但客户会希望看到经过验证的 NIC、交换机、固件和路由软件组合。

全面上市是另一个尚未明确的细节。AMD 表示 Vulcano 正在为 Instinct MI400 系列集群进行认证，而 Helios 预计将在 2026 年期间上市。

认证并不等同于广泛部署。一款产品可以达到设计目标，但系统供应商、云提供商和企业仍可能需要数月验证。

Google 的问题尤为重要，因为主要关键词暗示双方存在直接关系。Google 曾支持 UALink，但没有公开证据确认 Google Cloud 将提供基于 Vulcano 的实例。

Google 的部署将提供有意义的采用信号。它将表明，一家拥有内部网络专业能力的超大规模云服务商认为 Vulcano 适合生产环境使用。

没有这类公告并不代表产品不佳。超大规模云服务商通常会评估多种架构，并且只披露部分部署。

软件成熟度同样需要审视。ROCm 必须与网络协调集合通信，同时向调度器和运维团队提供有用的遥测数据。

快速 NIC 无法弥补低效的集合通信库或不佳的工作负载放置。若运营商希望获得一致的任务完成时间，网络感知必须延伸至编排层。

安全性也值得关注。可编程设备扩大了配置可能性，每一条固件路径都需要围绕签名、更新、访问和回滚建立控制措施。

开放规范并不会自动带来开放管理。客户应检查哪些功能需要 AMD 工具，以及第三方可观测性产品能否访问关键遥测数据。

成本说法需要完整的系统核算。公平比较应包括适配器、交换机、线缆、光模块、机架空间、功耗、支持服务和工程人力。

评估 Vulcano 的团队应通过可搜索的工程知识库保存基准测试记录。固件版本和拓扑细节可能决定后续比较是否仍然有用。

采购团队还应区分纵向扩展和横向扩展需求。UALink、Ultra Ethernet、MRC 和 PCIe 分别解决数据路径的不同部分。

混淆这些层级可能导致规格看似亮眼、部署却缺乏一致性。采购方需要一套架构，展示流量如何从一台加速器流向每一个相关端点。

AMD 的技术方向具有合理性。其挑战是将这一方向转化为客户能够订购、部署、监控和维修的可重复系统。

三个信号将决定 Vulcano 的 AI 网络前景

通过独立集群结果、具名生产客户和经过验证的多供应商互操作性，Vulcano 的定位将变得更加清晰。

第一个信号是对完整 Helios 系统进行独立测试。结果应在多种网络条件下比较任务完成时间、GPU 利用率、尾延迟和恢复能力。

有价值的测试将列明每个组件和软件版本，并区分链路层测得的带宽与实际交付给 AI 应用的吞吐量。

若在多种工作负载中取得强劲结果，将支持 AMD 关于 Vulcano 消除通信瓶颈的说法。结果若表现疲弱或不一致，其头条带宽的价值便会降低。

第二个信号是具名的超大规模或云部署。Oracle 已讨论 AMD 的机架级基础设施，而 OpenAI 已与 AMD 开展 MRC 验证合作。

鉴于 amd google 搜索热度及 Google 在开放互连工作中的角色，Google 的部署将尤为重要。不过，读者应等待直接的部署公告。

客户必须描述的不应只是评估。生产可用性、集群规模、支持的工作负载和服务级别预期，将提供更有力的证据。

第三个信号是超越全 AMD 参考设计的互操作性。Vulcano 应能与多家交换机供应商、网络操作系统、光模块和管理平台协同工作。

成功的互操作性将强化开放 AI 网络的经济合理性。它将使客户能够更换特定组件，而无需重新设计完整集群。

即便 Helios 作为封闭参考配置表现良好，兼容性受限也会削弱这一论点。尽管依赖开放规范，该系统在实践中仍可能变得高度一体化。

AMD 完成这项验证的同时，Nvidia 不会停滞不前。Spectrum-X 已将基于标准的 Ethernet 与 Nvidia 对周边平台的控制结合在一起。

因此，未来比较必须采用两家公司当前的产品。击败旧款 Ethernet，并不能证明相较 Nvidia 最新网络架构的优势。

对开发者而言，短期影响仍将是间接的。大多数人会通过云实例、托管集群或基础设施团队选定的系统接触 Vulcano。

不过，网络会影响训练时间、推理延迟、容量可用性和服务成本。网络架构层的改进，可能改变哪些 AI 工作负载在经济上仍然可行。

企业采购方应要求供应商提供工作负载层面的证据，而非端口速度摘要。他们也应要求故障测试，并明确跨供应商的支持边界。

关键问题已不再是以太网能否承载 AI 流量，而是开放式以太网系统能否在这样的规模下稳定交付结果——任何一条路径的延迟，都可能让数千颗加速器白白闲置。

AMD 现已通过 Vulcano、MRC、Ultra Ethernet 和 Helios 给出了具体答案。Google 及其他标准合作伙伴让这条开放路线更具可信度，但并不能保证 AMD 的执行能力。

值得关注的是首批独立的 Helios 基准测试、首个具名的 Vulcano 云端部署，以及首批大范围互操作性报告。这三个信号将决定 AMD 对标准的押注能否成为可投入生产的替代方案，还是仅停留在一份颇具吸引力的技术规范。