Can AMD break the CUDA Moat? AMD Advancing AI 2026

当我们发布第一篇 AMD 软件文章时，我们认为 AMD 在 AI 加速器领域追赶上 Nvidia 的几率为 0%。当时软件问题重重，进展乏善可陈。连续几个月，我们都是提交 bug 最多的用户，数十名 AMD 工程师在分拣我们的 bug 报告。

六个月后，在《AMD 2.0》文章中，我们提出了与市场共识不同的观点：将成功几率从 0% 上调至一个更有实际意义的水平。我们发表这一观点时，市场对 AMD 的情绪正处于谷底，多数人认为我们对 AMD 过于乐观了。

这一观点基于我们的观察：AMD 拥有能够推动变革的领导层，而非受困于委员会式的决策机制。Lisa 迅速与我们进行了电话沟通，并在此后落实了我们的许多建议。我们看到，AMD 终于认识到了软件的重要性，并有了紧迫感。尽管目标依然遥远，但发展方向是正确的。自那以后，积极的信号越来越强烈。

基于今年对 AMD 软件栈的使用经验，我们再次更新了观点：只要 AMD 能解决下文将阐述的两大风险，其成功几率已从非零水平提升至极大可能。需要指出的是，AMD 获得市场份额并不意味着 Nvidia 会陷入困境。整个市场蛋糕正在迅速扩大，Nvidia 的营收仍将大幅增长。然而，AMD 在软件层面对 Nvidia 构成了潜在竞争。Jensen 若想保持领先并加快发展，就必须削减内部繁文缛节，简化各类内部利益相关者的审批流程。目前，即便是最简单的任务也需要经过这些繁复的批准。

Anthropic 已公开宣布将部署 2GW 的 AMD 芯片，Lisa Su 及其团队正积极拥抱以智能体为导向的工程文化。Anthropic 计算负责人 Tom Brown 举例说明了这一点，他周末使用 Claude 并通过“/goal”指令，在 AMD 硬件上成功启动了内部 Claude 推理栈。我们认为，由于 AMD 的编译器和大部分内核均已开源，他们能更好地迎接智能体时代。不过，下文将探讨的一大风险除外。三个月前，我们的加速器模型指出 Anthropic 将成为 AMD 的客户。一周前，我们也在社交媒体上提及了这一点。

2023 年，由于 Samsung 2023 HBM 存储不可靠以及软件质量不佳，Microsoft 在采用 MI300X 后放弃了 AMD，并随后跳过了 MI325X 和 MI355X。如今 Microsoft 态度大转变，宣布将部署 MI455X Helios。我们认为 OpenAI 将成为 Azure MI455X 机架的主要终端客户。此外，AMD 宣布与 Cerebras 达成合作，将进行 PD 分离式部署，以实现超快交互式推理。这一策略与 Nvidia-Groq 的交易有相似之处。

AMD 需要防范以下两大风险：

如果 AMD 能够克服这些挑战，我们坚信它将处于有利地位并有望取得良好业绩，从而抢占市场份额。近期基于股票期权的结构也会对此起到推动作用。AMD 利用巧妙的金融工程设计，向 Meta 和 OpenAI 提供了接近 105% 的股权返利折扣。当 AMD 股价达到 600 美元的最终目标，并且 OpenAI/Meta 购买了足够的算力后，全额返利就会被触发。Helios 的每 TCO 性能极为出色，以至于结合这一结构来看，每百万 token 的成本几乎为负值！AMD 简直是在白送 Helios 机架，甚至还额外倒贴 5% 给一家总部位于旧金山、名为 OpenAI 的非营利组织。

在文章的第一部分，我们将深入探讨 Helios 架构和 MI455X（gfx1250）指令集。该指令集是 Hopper SM90 ISA 的克隆。我们还将讨论 Helios 的横向扩展和纵向扩展网络架构。文章第二部分将进一步详细介绍软件栈。第三部分将重点分析拥有和运营 Helios 机架的经济学，并详细拆解 OpenAI/Anthropic/Meta 基于股权的返利折扣，以及这种结构如何影响总拥有成本（TCO）。

我们是 ROCm 软件在 MI300X、MI325X、MI355X 上的日常用户，并且每个季度都是第一大缺陷报告者！我们要特别感谢几位 10x 工程师，他们一直 997 工作以改进 AMD 软件，并迅速处理我们的缺陷报告。非常感谢 Hongxia、Chun Fang、HaiShaw、Thomas Wang、Andy Luo、Seungrok、Bill He、Teresa Shan、Parth、Duyi Wang、Gilbert 等许多人。AMD 最优秀的 10x 工程师大多在上海。AMD 的 MoRI 集合和 UMBP KVCache 卸载团队、AMD 分解式应用前置部署工程团队，以及其他懂如何基于第一性原理做推理工程的团队，主要都在上海。ROCm 软件栈中许多最重要的部分都是在中国构建的。

给 Lisa Su、Mark Papermaster、Sharon Zhou、Anush Elangovan 和 Vamsi Boppana 的建议

过去一年在自动化测试方面取得了良好进展，以提升软件质量，但进展速度不够激进。在为自动化测试 CI 和内部软件开发团队提供足够 GPU 集群方面，仍然缺乏紧迫感。总是太少、太迟。

每隔几个月与你们（Vamsi、Anush）会面，偶尔与 Lisa 会面时，我们总是强调 CI 可以做得更好。我们确实能举出 CI 正朝正确方向发展的具体例子，但整体战略需要加速推进。例如，Kubernetes 推理 Pollara NIC CI 与 Nvidia ConnectX Nightly CI 的对等率仍为 0%。Kubernetes 是全球大多数推理部署使用的层。问题不在于 AMD 工程师不想增加支持，而在于内部 CI 容量投资不足阻碍了他们。原计划在 Advancing AI 2026 前实现对等的目标，因集群问题已错过。

在 vLLM 方面，本周因 AMD 集群基础设施稳定性问题，vLLM 门控自动化测试进展大幅倒退。AMD 核心工程师过去几周在 vLLM 门控上进展良好，目标是到 Advancing AI 2026 时门控与 CUDA 实现至少 90% 对等。但鉴于 AMD 内部容量紧张，过度依赖后备临时集群，AMD 领导层开始从内部 vLLM 团队抽调集群部署到别处。

门控/阻塞测试意味着测试质量最高，因为测试必须通过 PR 才能合并。这可防止缺陷被合并。虽然 AMD 领导层可能通过展示非门控通过率来误导非技术人员，但门控对等率和门控通过率才是真正重要的指标。

我们希望 AMD 管理层能够重新调整优先级，为内部 vLLM 团队提供稳定的集群。同时希望他们能更新容量规划理念，避免未来再出现类似问题。这样 AMD 内部的核心 vLLM 工程师就能专注于在关键指标上达到与 CUDA vLLM 90% 以上的对等性，并拥有与 AMD 内部 SGLang 团队同等高效运作所需的工具。

大多数 AMD 工程师的主要抱怨是，管理层仍需转变观念，提供稳定的 CI 集群，而不是随意将其从一个 CSP 迁移到另一个 CSP。

此外，内部用于开发的 GPU 持续短缺。对于单节点聚合推理，内部 GPU 尚能满足需求。但在分布式多节点推理优化（wideEP 和 disaggregated PD）的时代，GPU 远远不够。即使本月将额外上线 2,000 个 MI355X，以及今年晚些时候上线 6,000 个 MI325X/MI355X，总容量仍将不足。与 Nvidia 用于内部开发的稳定长期集群相比，仍相差一个数量级以上。随着 Agentic Coding 的兴起，这种 GPU 节点短缺的问题正日益加剧。以前，每位工程师只需几个节点来进行 DI 推理软件开发。但有了 Agentic Coding 后，每个 Agent 都需要 GPU 来测试代码。每位工程师可以同时运行几十个 Agent，每个 Agent 又能同时运行几十个子 Agent。因此，如果没有 DynoSim 这样的分布式推理模拟工具，内部 GPU 容量的短缺将更加严重。

此外，Rubin (SM107) 使用了与 Blackwell (SM100) 非常相似的 ISA，而 MI455 (gfx1250) 的 ISA 与 MI355 (gfx950) 完全不同。两者具有完全不同的代码路径和内核，需要在 gfx950 和 gfx1250 上分别进行测试。这是持续加剧容量压力的另一个因素。原本的大胆目标是在 Advancing AI 2026 大会前，实现 MI455X 开源 vLLM、SGLang 的每夜自动化 CI。但这一时间表未能实现。我们听说新时间表已推迟至 2026 年 10 月，但他们仍在努力将其提前至 2026 年 8 月或 9 月。

我们认为，内部软件开发 GPU 集群和 CI 集群自动化测试的缓慢爬坡，是减缓软件质量和性能提升步伐的主要风险之一。我们希望 AMD 管理层在未来能重新审视其容量规划策略。

第 1 部分：AMD MI455 芯片与 Helios 机架

AMD在硅工程领域再次展现了实力。MI455X是晶圆厂目前产出的最先进的硅芯片。AMD成为首家交付2nm数据中心芯片的公司，MI455的计算单元和Venice CPU都率先采用了N2工艺。所有竞争者的加速器平台目前仍停留在N3工艺。

AMD在封装级集成方面同样保持领先。MI455X的封装是目前出货的最大CoWoS-L模块，面积达到5.5倍光罩尺寸。AMD依然是唯一采用台积电SoIC-X混合键合技术的公司，这使得AMD能在z轴以及x、y轴方向上扩展硅片面积。以上技术综合起来，让MI455X单个封装内的逻辑硅片总面积达到3,470mm2，是迄今为止单一封装中硅片面积之最。

该封装布局很大程度上借鉴了MI355X的设计。8个N2工艺的XCD通过混合键合技术堆叠在2个光罩尺寸的基芯之上。这些基芯包含SRAM、HBM控制器以及计算架构，负责实现XCD之间的相互通信。

MI455X与MI300系列的一大重要区别在于，它新增了两个独立的I/O芯片，用于承载所有封装外部通信的PHY物理层。下方的平面规划图显示，一个I/O芯片负责UALoE扩展架构，另一个负责连接主机CPU和NIC以支持扩展输出架构。实际上这两个I/O芯片是完全相同的。这得益于灵活I/O的巧妙实现，每个I/O芯片支持72个通道。这些通道能在不同的线路速率下兼容不同协议，包括212G UALoE、64G Infinity Fabric、PCIe Gen 6、128G UALink和xGMI4。由于上述许多协议以某种形式贡献给了开放的UALink联盟，该I/O从底层设计起就能与基于UALink的互联方案完美整合。

正是这种大量堆叠硅片的做法，使AMD能够在MI455X上提供业界领先的峰值理论密集算力。其FP8算力达到20PF，而Rubin为17.5PF。然而，抛开绝对数值不谈，考虑到它使用了多得多的硅片面积，这种性能优势相比Rubin其实相对有限。这归因于AMD在GPU微架构设计上落后于Nvidia，下文将对此进行讨论。目前，MI455X缺少Rubin SM107所具备的3位LUT张量核心。3位LUT张量核心在降低相对HBM带宽需求方面具有潜在优势。正因如此，AMD不得不在硅片用量上采取激进策略来弥补这一不足，更不用说其在软件和系统设计方面的相对弱势了，尽管其软件正在不断改善。或者，AMD的产品营销团队还能找到更多技巧来包装出更好看的性能数据。

The large package size also allows AMD to fit 12 stacks of HBM4 for a total of 432GB per package. This is again industry leading compared to Nvidia and Google shipping only 8 stacks adding up to 288GB per package. Each base die is now closer to reticle sized with the HBM-facing edge measuring 32mm to squeeze in 3 cubes per edge, compared to the MI300X AID which was 29mm per edge which isn’t enough to fit 3 cubes.

Along with Nvidia with Rubin, AMD is the only company shipping HBM4 this year. Having 12 stacks also allows the MI455 to win on memory bandwidth at 23.3 TB/s per chip, implying HBM4 pin speeds of 7.6Gbps. This is a slight upgrade from the 19.6TB/s advertised at last year’s Advancing AI. Despite having a 50% wider bus than Rubin, the total bandwidth is barely above Rubin at 22TB/s.

This is because Nvidia aggressively raised its targeted HBM4 pin speeds last year to well above the original JEDEC HBM4 specification. This change was precisely driven by the need to make up for the memory bandwidth deficit to AMD MI455X. At Nvidia’s marketed 22TB/s for Rubin, this is a pin speed of 10.7Gbps: 40% faster than MI455’s HBM4 which means NVIDIA will be forced to use an much higher quality bin than AMD.

As we have mentioned before and covered extensively in our newsletter and Accelerator Model , this change was challenging for memory suppliers to keep up with. Memory suppliers had to rework their HBM4 to deliver the spec Nvidia was targeting. This also pushed out upstream output for Rubin but as of today these issues have been finally resolved. This move proved to be a worthwhile gambit for Nvidia as they could close one of the big shortfalls of Rubin and despite the delays, Vera Rubin will still be the first deliver tokens at scale compared to MI455 Helios. More on that later.

Active LSI

Hidden beneath the surface, we believe that the MI455 is also the known first chip to ship with active Local Silicon Interconnects (“LSI”), which are the bridges that connect the various chiplets within the CoWoS-L assembly. In the brief history of CoWoS-L, the bridges have been passive, containing only wiring as well as capacitors. Active LSIs come with actual circuitry. During TSMC’s aLSI presentation at ISSCC 2026, TSMC demonstrated active bridges with a low-power repeater circuit that regenerates signals mid-channel. The benefit is that because the bridge now shares the burden of maintaining signal integrity, the PHYs on the top dies can shrink meaningfully, at a nearly negligible energy cost, reclaiming leading-edge silicon and shoreline for compute and memory. The give away that this is being shipped in the MI455, and as such it is effectively the “test vehicle”. What TSMC showed is the MI455 interposer: two base dies, 12 HBM4 stacks, and two IO dies.

MI455X Networking

在网络侧，MI455X 标志着 AMD GPU 首次在机架级领域部署交换式 scale up 与 scale-up。相比于从 MI300X 到 MI355X 所采用的 8-GPU 点对点 mesh 架构，这是一次巨大的升级。

AMD 的 Helios 机架通过 12 颗 102.4T Tomahawk 6 交换机，在单层全连接网络中连接了 72 颗 MI455X GPU。每颗 GPU 拥有 72 条 200G UALoE 通道用于 scale up 网络，单方向 scale-up 总带宽达 1.8 TB/s。每颗交换机使用了其 512 条 200G 通道中的 432 条。这种过度配置是因为 AMD 采用了 Broadcom 的商用 TH6 交换机，而非像 Nvidia 那样使用专有的联合设计交换机。Scale-out 则并行地从 400G Pollara 升级到 800G Vulcano。两块网卡可为每颗 GPU 提供 1.6 Tbit/s 的带宽，并可选择为每颗 GPU 增加第三块网卡。MI500 预计将把 scale-up 域扩展到跨三个机架的 256 颗 GPU。在这种情况下，铜缆很可能将让位于共封装铜缆或共封装/近封装光学器件。

Meta 的 Recsys 基础设施战略：一个正在损害 AMD 在 Meta 成功机会的奇怪选择

2026 年 8 月 3 日更新：我们已根据最新信息更新了 Meta 定制 MI450X SKU 的配置。

简而言之，AMD 努力打造了一款在主要规格上击败或匹敌 Vera Rubin 的芯片与系统。然而奇怪的是，作为 AMD 最大的 GPU 客户之一，Meta 却决定不利用 AMD 在这里的所有创新。Meta 大部分的 MI455 订单是一个定制版本，是完整 MI455X 的缩减版。这款 Meta 定制的 MI455X 也是完整 MI450X 的阉割版，其 I/O 减半，并且仅保留了完整 8 个计算裸片/XCD 中的 6 个。HBM4 也从标准 SKU 的 12-Hi 降级为 8-Hi。由于只有 1 个 I/O 裸片而非 2 个，可用的 I/O 通道仅有 72 条，而不是配备 2 个 I/O 裸片时的 144 条。通道预算减少意味着 scale up 带宽也需要降低。我们推测其 scale up 通道为 36 条，而非完整的 72 条。这意味着在 Meta 的版本中，一个机架只需要一半的 Tomahawk 6 交换机。剩下的 36 条通道用于系统和 scale out：其中 16 条 UAL 128G 通道连接到网卡，实现每颗 GPU 1.6T 的 scale out；另外 16 条 Infinity Fabric 通道用于连接主机 CPU。

这些选择导致 Meta 版本的 MI450X 网络能力严重受损，每颗芯片的 scale up 带宽仅有 Rubin 1,800GB/s 的一半，即 900GB/s。此外，相比常规版本，算力也减少了 25%。虽然算力的削减幅度不大，但在整个系统的背景下，减少 2 个计算裸片所节省的成本微乎其微。这不禁让人质疑，这样的选择是否值得。

这种芯片配置专为 Recsys 工作负载设计，是 Recsys 基础设施团队的决定。然而，这一决定在 TBD Lab 成立或发表意见之前就已敲定。鉴于该芯片和系统在网络与计算能力上相比 Rubin 存在严重不足，TBD 对此系统毫无兴趣，对外部客户也缺乏吸引力。

正如我们在上一篇关于 Meta 基础设施战略的文章中明确指出的，采用削减规格的定制版 MI455 将彻底摧毁 AMD 在 Meta 的出货量。因为如果选择半规格 MI455 设计，TBD 将极度倾向于 Rubin。AMD 必须介入，拿出专业态度，直接与 TBD 的团队合作，确保采用标准版 MI455，而非严重削弱了 LLM 训练与推理性能的 Meta 定制版。标准版 MI455 足以与 Nvidia 的 Vera Rubin 竞争。

不过我们认为仍有希望。文章发布后，Mark Zuckerberg 已开始迅速探索调整其基础设施战略和组织文化。

Helios 机柜解析回顾

自 AMD 在 Advancing AI 2025 上发布 Helios 架构至今已有一年，期间发生了许多变化。让我们重新审视 Helios 架构，回顾过去一年中出现的一些调整与细节。

机柜立面图

Helios 机柜包含 18 个计算托盘和 6 个纵向扩展交换托盘，后者位于计算托盘中间。每个计算托盘配备 4 个 MI455X GPU 和 1 个 Venice CPU，总计 72 个 GPU 和 18 个 CPU。每个纵向扩展交换托盘配备 2 个来自 Broadcom 的 102.4T Tomahawk 6 交换机，总计 12 个交换 ASIC。针对 Meta 版本的 MI455x，机柜内将配置 6 个 51.2T Minipack 以太网交换机，电源架则位于单独的 IT 机柜中。

计算托盘布局

自 Advancing AI 2025 以来，计算托盘设计基本未变。每个 MI455X GPU 安装在 EAM 模块上，通过背板连接器连接纵向扩展链路，并通过飞越电缆连接 Venice CPU 和 Vulcano NIC。值得注意的是，EAM 上直接搭载的 LPDDR5x 并未出现，下文将详细说明。Venice CPU 位于独立模块板上，配备 16 个 RDIMM 插槽和 5 个 NVMe SSD 插槽。该设计具备模块化特点，但模块间使用飞越电缆可能给生产带来挑战。

部分协同设计

AMD 展示了其机架级解决方案的丰富产品组合，包括 MI455x GPU、Venice CPU、Pensando Vulcano 800G NIC 和 Pensando Salina DPU。然而，能够实现真正机架级向上扩展性能的交换机却缺失了。与 Nvidia 不同，AMD 必须依赖合作伙伴提供现成的商用向上扩展交换机。理论上，这能为客户提供更广泛的向上扩展交换机生态系统。但这同时也使其路线图面临合作伙伴执行不力的风险。由于 Broadcom 是唯一一家出货搭载 200G SerDes 的 100T 交换机的供应商，因此它是 AMD 交换机的唯一选择。这也使得各供应商之间的物流和责任划分变得复杂，需要反复沟通并共同解决问题。由于缺乏向上扩展交换机产品，AMD 无法为整个机架解决方案实现极致的协同设计。

内存规格降级

一个值得注意的遗漏是，每个加速器不再直接挂载 LPDDR。此前的路线图曾在 EAM 模块上为每个 MI455X 配置高达 1TB 的 LPDDR 作为二级内存，但如今这一设计已不复存在。我们认为，这是内存供应紧张的又一后果。

背板重定时

Helios 的另一个特点是在向上扩展交换机中加入了以太网重定时器。这与 Nvidia 完全无源的 Oberon 背板不同。在 MI455X 芯片与向上扩展 Tomahawk 6 交换机之间的铜缆链路上，AMD 的 200G SerDes 因信号损耗而表现吃力。这可能是其灵活 I/O 设计目标导致的后果，也可能是 SerDes 质量确实不佳，导致背板信号性能不足。在 Meta 部署的 MI455X 系统中，约 85% 的向上扩展链路将进行重定时。以太网重定时器由 Broadcom 提供，并放置在向上扩展交换机托盘中。这并非理想的方案，因为重定时器会增加整个系统的成本和功耗预算。此外，它还使服务器组装变得复杂，因为在启动机架时，调校所有的重定时器将是一项非常繁琐的任务。

可制造性与效率挑战

MI455X Helios 设计是 AMD 针对 Nvidia GB200/GB300 Oberon 架构推出的应对方案。AMD 在 Helios 设计中参考了许多 Nvidia 的架构理念。尽管该设计实现了高密度的单机架级向上扩展，但 AMD 也借鉴了曾让 Nvidia 吃尽苦头的飞跨线缆设计。我们在 Vera Rubin 架构深度解析一文中探讨过飞跨线缆带来的制造挑战。GB200/GB300 计算托盘和交换托盘在使用飞跨线缆时遇到的困难，促使 Nvidia 在 Vera Rubin NVL72 中转向无缆设计。而该设计方案公布时，AMD 已经来不及在 MI455x Helios 中采用这一设计理念。

在计算托盘中，来自 Molex 的 Genesis 线缆负责处理 MI455X 与 Pensando Vulcano NIC 之间的 128G UALink 连接。每个计算托盘最多会有 12 根 Genesis 线缆，它们与液冷管和电源线一起挤在 1U 空间内。在向上扩展交换机侧，飞越线缆（flyover cables）连接着背板连接器和 TH6 交换机。1,728 根线缆将从背板连接器布线到每个 TH6 ASIC 周围的 16 个端口（每个托盘 32 个端口）。所有线缆在组装过程中都会成为潜在的故障点，并会降低制造效率。

计算托盘拓扑结构

Helios 机架中的 18 个计算托盘，每个都装有 4 个 MI455X EAM。每个 MI455X EAM 支持 36 个 UALoE 链路，这些链路由两条 200G 以太网通道构建而成。72 条 200G 以太网通道相加，使每个 GPU 的总向上扩展带宽达到 14.4Tbit/s（单向）。MI455X 封装的南北两侧各有一个基于 N3P 的 I/O 模块：一个 I/O 模块承载用于向上扩展网络的 UALoE 链路；另一个则实现用于连接 CPU 的 Infinity Fabric，以及用于连接 NIC 的 UALink128/PCIe Gen7。

向上扩展拓扑结构

这些 UALoE 链路的另一端，是分布在 6 个交换机托盘中的 12 个 Broadcom Tomahawk 6 以太网交换机（每个托盘含两个交换机 ASIC）。UALink over Ethernet（UALoE）在协议栈中的层级，相当于 Nvidia 的 NVLink。每个 Tomahawk 6 交换机 ASIC 设计支持 102.4Tbit/s（单向）的总带宽，由 512 条速率为 200Gbit/s（单向）的通道组成。然而，实际只使用了其中 432 条 200G 通道。因此，从每个交换机 ASIC 连接到机架内 72 个 GPU 的总带宽为 86.4Tbit/s（单向）。交换机总带宽若能被 72 个 GPU 平分最为理想，例如 115.2Tbit/s。但 AMD 目前只能使用市面上唯一可用的交换机。总带宽为 115.2T 和 57.6T 的 UALink 交换机已初露端倪，但短期内尚无法作为这一架构的基石。相比之下，Nvidia 专门设计了 28.8T 的 NVSwitch 来满足 72 GPU 机架的需求。该方案能将带宽均匀分配给 72 个 GPU，每个 GPU 分得 400Gbit/s（单向）带宽，完全没有带宽浪费。每个交换机托盘还配备了一颗小型主机 x86 CPU。

AMD 采用的向上扩展拓扑结构，相信读者们现在应该已经很熟悉了。在这个扁平的单层网络中，每个 GPU 通过 6 条速率为 200Gbit/s（单向）的通道连接到每个交换机。由此，每个 GPU 连接到 12 个交换机 ASIC 中任意一个的单向总带宽为 1.2Tbit/s。反过来，每个交换机 ASIC 都会连接到机架内的所有 GPU。

用于 GPU 链路的纵向扩展交换机通过铜缆背板实现。对于每个 GPU，72 条 200G 通道中的每一条都通过两组差分对（DP）铜缆进行传输，一组用于发送，一组用于接收。这样算来，每个 GPU 需要 144 组差分对铜缆，整个机架则总共需要 10,368 组差分对铜缆。每个 GPU 还需要一个 144DP 公头和一个 144DP 母头连接器，用于背板线缆与计算托盘之间的接口连接。在交换机端，每个交换机托盘将使用四组连接器，每组包含四个 108DP 连接器，每组总共提供 432 个 DP。

跨接（Flyover）线缆用于将交换机 ASIC 连接到计算托盘背面的连接器上。跨接线缆比 PCB 走线具有更好的信号完整性，但其缺点是往往会限制可维护性和散热效率，并增加制造难度。Nvidia 在使用跨接线缆还是 PCB 之间反复切换：最初打算使用跨接线缆，后来为了获得更好的可维护性和气流，又改用 PCB 走线。

每个机架的背板和计算托盘部件总成本将达到 68,928 美元，其中背板占 44,352 美元，剩余的 24,576 美元用于跨接线缆。

与使用九个交换机托盘的 GB300 NVL72 中的 NVLink 相比，由于仅有六个交换机托盘，UALoE 信号的传输距离更短。此外，AMD 在设计 Helios 机架时，将 9 个计算托盘放在上部，9 个放在下部。这样设计可以让信号在上下两个方向传输的距离相等。

横向扩展网络

在横向扩展方面，每个 MI455X 最多可连接三个 AMD Pensando Vulcano 800 AI 网卡，提供 2.4 Tbit/s 的横向扩展带宽。每个网卡通过 x8 UALink128 接口连接，可提供 256 GB/s 的双向 GPU 到网卡带宽。前端网络则由单独的 Pensando Salina 400 DPU 处理。

我们预计主流的部署配置将是每个 GPU 搭载两个 Vulcano 网卡，以提供 1.6 Tbit/s 的横向扩展带宽。

在机架外部，Vulcano 支持多平面叶脊拓扑结构，每个平面内部无阻塞，这已成为一种常见的实现方式。我们曾广泛撰文讨论过多平面架构在当今 AI 集群中的重要性，因为这种架构可以在两层网络内容纳更多的 GPU。我们在关于 Vera Rubin 的文章中也详细阐述了多平面网络背后的直觉与优势。

在一个 131k MI455X 8-plane 集群中，每个 800G Vulcano NIC 分解为四个 200G 链路。由于每个 GPU 连接两个 NIC，这样每个 GPU 都能与八个独立 plane 中的每一个建立连接。每个 plane 包含 512 个 leaf 交换机和 256 个 spine 交换机，整个集群共有 6,144 个 TH6 交换机。该配置在 NIC 端需要两个 800G DR4 模块，每个 GPU 需要 3 个 1.6T DR8 模块：两个用于 leaf 侧的上行和下行链路，一个用于 spine 侧。我们预计在 8-plane 两层架构下，每个 MI455X GPU 的横向扩展网络成本约为每 GPU 8,000 美元。

AMD 的 Pensando Vulcano 800 AI NIC 正在朝着过去几年业界所走的相同方向发展。在我们的“Meta 的基础设施团队需要文化重置”通讯中，我们重点指出了 AI 横向扩展网络在数据平面和控制平面层面所面临的问题。

在大型 AI 训练集群中，存在三个主要问题：大象流、低熵以及网络架构利用率不佳。

RDMA 流量对丢包和拥塞极其敏感，而 RoCEv2 构建于 Ethernet（一种有损协议）和 UDP（无恢复机制）之上。Meta 的 DSF 通过虚拟输出队列、信元喷射、信用调度以及深缓冲区的 Jericho-AI 交换机在网络内部解决了这一问题，但代价是数据平面、控制平面和硬件栈变得更加复杂。

Vulcano 试图解决同样的问题，但它是通过 NIC 来实现的。在这里，NIC 具备三个要素：智能包喷射、路径感知拥塞控制，以及乱序包处理与有序消息交付。这使得能够将网络复杂性从网络架构卸载到 NIC 上。

智能包喷射从根本上解决了低熵问题。在传统的 ECMP 架构中，一个流被哈希到单一路径并保持在该路径上。由于 AI 流量由少数几个庞大的、同步的大象流组成，因此哈希冲突非常频繁，导致某些路径拥塞而其他路径却闲置。AMD 的 AI NIC 不再将流固定在单一路径上，而是将同一流的包喷射到网络架构的可用路径上，将熵水平提升到了逐包级别。其结果是实现了 1:1 的网络架构利用率，并且能够在毫秒内完成故障恢复，因为任何单条链路故障都无法导致整个流中断。

然而，数据包喷洒会带来一系列新问题，这也就是另外两个要素发挥作用的地方。首先，来自不同路径的数据包可能会乱序到达。传统的 RoCEv2 网络会强制数据包执行 go back N 重传，这需要在 NIC 或交换机层面进行缓冲，具体取决于所采用的方案（调度式还是非调度式网络架构）。在这里，NIC 原生处理乱序到达的数据包，并在消息级别强制保证顺序，从而无需缓冲。数据包到达后直接写入 GPU 内存，仅重传丢失的数据包。

其次，盲目地在多条路径上喷洒数据包不仅无法避免拥塞，反而会引发拥塞。Path Aware Congestion Control 弥补了这一缺陷：NIC 会实时跟踪每条路径的状态，并在队列积压之前将流量从拥塞路径转移出去。该机制专门针对 incast 现象，因为像 all-reduce 这样的集合操作通常涉及多个发送方对应单个接收方，会在整个网络架构中引发队头阻塞级联效应。由于决策是在 NIC 层面做出的，且具备逐路径可见性，因此其响应速度足以应对 AI 工作负载的突发性特征。此外，由于数据包是在整个网络架构中进行智能喷洒的，尾部延迟也得到了最小化。

综合来看，这三项机制解决的问题，与 Nvidia 使用其 ConnectX NIC 结合 Spectrum-X 自适应路由所解决的问题相同。主要区别在于，AMD 采用了开放的 UEC 标准和多供应商网络架构，而非垂直整合的方案。

AMD 的 AI NIC 不强制规定传输模型，允许灵活的横向扩展网络。它支持基于交换机的数据包喷洒，适用于网络架构已处理负载均衡的运营商；支持基于 NIC 的数据包喷洒，适用于将智能处理卸载到 NIC 的普通商用网络架构；还支持基于 NIC 的源路由，适用于希望从端点控制路径的运营商。核心在于，网络行为会去适应你已有的网络架构和打算运行的工作负载，而不是反过来。

CDNA5 微架构

设计与 NVIDIA 趋同

正如 AMD 从 Nvidia 枯燥的主题演讲形式中汲取灵感一样，AMD 的 CDNA 5 在许多方面也深受 Nvidia Hopper (SM 90) 架构的启发。首先，CDNA 5 将每个 wave 的线程数减少到 32 个，与 Nvidia 每个 warp 32 个线程的设计保持一致。CDNA 5 还用每个 FCD（Fabric and Cache Die）单个大型 96 MB L2 缓存，取代了 CDNA3/CDNA4 的 Infinity Cache 和小型 L2 缓存。这种设计更接近 Nvidia 的“全局内存 -> L2 缓存 -> 共享内存”的内存层级结构。管理不同层级间的内存延迟一直是 AMD kernel 开发者的痛点；我们期望简化层级结构能缓解这一问题。

增加的暂存内存与 MMA 形状

CDNA 5 的内存暂存缓冲区比 Nvidia 的同类产品更大。它拥有 320 KB 的 LDS（大致相当于 SMEM）和 32 KB 的 VGPR（大致相当于线程寄存器），因此每个线程可以访问 1024 个寄存器。此外，与上一代类似，我们观察到 CDNA 5 目前主要支持 16x16xK 形状。综合这些事实，我们推测更大的暂存缓冲区是为了适应 wave 数量的增加：在并行线程数相同的情况下，更小的 wave 大小会导致 wave 数量增多。由于 MMA 形状没有增大，且每个线程可访问的寄存器数量是原来的 4 倍，因此 AMD 不必像 Nvidia 那样去增加 MMA 的作用域至 warp group。

Tensor Data Mover

Tensor Data Mover (TDM) 与 Nvidia 的 Tensor Memory Accelerator (TMA) 几乎完全相同。TDM 可以将数据从 HBM 直接搬移到 LDS，而无需经过寄存器暂存。它支持 5 维分块、越界检查，甚至支持多播（multicast）到不同的 work group cluster 中，这相当于 Nvidia 的 thread block cluster。一个区别在于，TDM 描述符是从 SGPR 加载的，而 Nvidia 则是从主机端加载到共享内存。Nvidia 的 Rubin 刚刚展示了内联 TMA 描述符更新功能，以改善用户体验，因此我们期待 AMD 是否能把这个设计做好。

GFX1250 原生支持 NVFP4

目前竞争推理市场的两种 FP4 格式共享相同的 E2M1 元素：1 位符号位、2 位指数位和 1 位尾数位。但它们在承载块缩放因子的方式上有所不同，这正是如此低位宽类型能够使用的关键。MXFP4 是 AMD 构建 4 位计算路径所依据的 OCP 标准，它为每个 32 元素块搭配了一个 2 的幂次的 E8M0 缩放因子。而 NVFP4 是 Nvidia 随 Blackwell 引入的格式，它使用更细粒度的 16 元素块。每个块附带一个 FP8 E4M3 缩放因子，并在顶层附加一个 per-tensor 的 FP32 全局缩放因子。这种安排成本更高但精度更好，正迅速成为 FP4 量化检查点的默认标准。

AMD 的 gfx1250（即 MI455X 背后的架构目标）值得关注的一点是，其矩阵引擎原生支持 NVFP4。ROCm 的 MLIR 层级中的缩放格式枚举 WMMAMatrixScaleFormat 包含了 e8、e5m3 和 e4m3 成员。

具体来说，AMD 已经在 AITER 中提供了一个针对 gfx1250 编译的 NVFP4 GEMM 代码对象，并将其接入了运行时分发表。在分发表中，格式鉴别器会区分 NVFP4 和 MXFP4。分派逻辑会在 gfx1250 上选择 NVFP4 汇编内核。这是 gfx1250 特有的能力，并非 CDNA4 架构的特性。MI355X / gfx950 仅支持 MXFP4 形式的 4 位计算。它通过 scaled-MFMA 在 32 元素块上使用 E8M0 缩放因子来实现——没有缩放格式字段，没有 16 元素块，也没有 E4M3——这正是 AMD 公开的矩阵核心文档所描述的全部内容。

我们还发现，CDNA 5 额外支持无符号 E5M3（UE5M3）缩放因子格式。相比之下，Nvidia Rubin 支持的是 E4M3 和 E5M2。UE5M3 重新利用了符号位，从而扩大了动态范围。它将最小非零可表示绝对值从 E4M3 的 2^-9 降低到了 2^-17。UE5M3 被提出作为 NVFP4 额外的逐张量 FP32 缩放的替代方案。未来这些格式的采用情况将证明它们的实际效果。

保守的微架构改动

从 CDNA 4 到 CDNA 5 的微架构演变表明，AMD 对扩展策略的信心不如 Nvidia。Nvidia 押注模型需要更大的乘法运算，因此在每一代都积极扩展 MMA 形状。在 Blackwell 架构中，甚至扩展到需要 2 个 SM 才能执行的 MMA 形状。由于 CDNA 5 几乎没有扩展 MMA 形状，我们怀疑在 CDNA 5 中是否能看到类似的功能。此外，我们尚未看到 AMD 在数据压缩技术上有所创新，例如 Rubin 的 3 位查找表权重压缩 MMA 模式。

第二部分：AMD 软件能否击败 CUDA 护城河？

AMD 软件改进迅速，但护城河已经转移

AMD 的软件现状已不再是“ROCm 难以使用”。现在的真实情况是，ROCm 终于开始以真正的紧迫感推进，但竞争前沿的演进速度更快。我们在 2025 年 4 月曾表示，在更加重视开发者优先的推动之后，AMD 正“走在正确的道路上”。随后我们又提到，自 2025 年 1 月以来，AMD 的软件质量有了“大幅提升”。

实际取得的改进

CI 正在成熟，但速度不够快

我们曾赞扬 AMD 在 2026 年 1 月将稳定的 ROCm 支持引入 vLLM 上游版本，并在不久后增加了每日构建版本。此后，CI 取得了具体但尚不完整的进展。6 月的一项变更增加了 AMD 镜像和门禁，覆盖了八个主要测试组：V1 注意力、引擎、OpenAI API 正确性、小模型评估、多模态池化以及三条推测解码路径。另一项 7 月的补丁清理了不稳定的作业，并让现有镜像准备好再次成为合并阻断项。但尚未证明已达到 CUDA 的同等水平：公开的回归测试仪表板、AITER 精度门禁、端到端拆解 CI 以及自动性能门禁仍是路线图上的待办事项。

令人鼓舞的是，AMD 的分布式推理工作已开始从一次性的定制方案转向上游 CI。SGLang 在 6 月为 DeepSeek-V4 Flash 和 Pro 合并了双节点 MI355X 1P1D 拆解的每日构建版本，同时支持 FP8 和 FP4。随后在 7 月初，又增加了 DP-attention、EP8、MTP 和 Kimi K2.6 的覆盖。这是一个重要的转变：拆解推理正开始成为一种持续测试的上游功能，而不再仅仅是一个演示。

Kubernetes 驱动着全球绝大多数的推理部署。AMD 是 llm-d 的创始合作伙伴之一，这是一款开源的分布式推理 Kubernetes 编排引擎。然而，对于第一方 Pollara NIC，其 CI 自动化测试至今仍然不足。这并非因为工程团队不愿增加测试，而是因为直至今日，他们在内部 CI 容量规划方面的投入依然严重不足。这导致在 llm-d Kubernetes 推理的夜间测试中，其成绩与 Nvidia ConnectX-7 NIC 的对齐率为 0%。此前计划在 Advancing AI 2026 活动上实现对齐的预期目标已经落空。

在 vLLM 方面，受本周 AMD 集群基础设施稳定性问题的影响，门禁自动化测试的进度出现了大幅倒退。过去几周，AMD 的资深工程师在 vLLM 门禁测试上取得了良好进展。他们的目标是在 Advancing AI 大会前，实现门禁测试成绩与 CUDA 达到 90% 的对齐率。然而，AMD 管理层却开始将集群资源从内部 vLLM 团队抽走。

门禁/阻断测试是维护重要标准的保障。因为只有测试通过，PR 才能合并。尽管 AMD 管理层可能会通过展示非门禁测试的通过率，来转移非技术人员的注意力，但门禁对齐率和门禁通过率才是真正重要的指标。

我们希望 AMD 管理层（Anush、Vamsi、Mark Papermaster）能够重新安排优先级，为内部 vLLM 团队提供稳定的集群。这样，AMD 内部的资深 vLLM 工程师才能开展工作，在门禁测试上实现与 CUDA vLLM 90% 以上的对齐率。同时，他们也能获得必要的工具，保持与 AMD 内部 SGLang 团队相当的开发效率。

单节点性能与可复现性是真正的胜利

今年 3 月，我们曾重点指出，得益于 AITER/vLLM 的修复，Kimi K2.5 1T MXFP4 的交互性能在不到 30 天内实现了高达 18 倍的提升。这些修复已经合并入上游的 vLLM 0.18 版本。AMD 在 2026 年 2 月发布的技术报告《Speed is the Moat: Inference Performance on AMD GPUs》中指出，由 AITER 驱动的单节点优化，相比基线框架配置，能够带来约 1.08 倍至 1.2 倍的吞吐量提升。这是正确的方向：开源基线框架必须在 AMD 平台上变得更快，而不能仅仅停留在专属演示阶段。

通过 ATOM 技术栈的优化，AMD 在 MiniMax M3 上的性能也已追平了 B200。

改善最为显著的地方在于方案、文档和可复现性。相比一年前，ROCm 如今拥有更加深入的公开方案层。ROCm 推理文档公开了一整套 AI 推理专区，涵盖 vLLM、SGLang、分布式 MoRI、Mooncake 以及部署指南。vLLM 优化指南详细介绍了 AITER、attention-backend 选择、TP/EP/DP 策略、FP8/FP4 量化，以及从单节点到多节点的扩展方案。ROCm/MAD 仓库现已发布了多种蓝图，内容涉及 vLLM、SGLang、训练技术栈、large-EP 微基准测试，以及分离式预填充/解码方案。

战略姿态是正确的

正因如此，我们在软件诊断方面与 Anush 基本保持一致。以开发者优先的姿态、对齐上游、Day-0 模型支持，以及更快的发布节奏，才是正确的策略。我们曾赞赏 Anush 在 2025 年推动开发者关系的工作。最近，我们也肯定了他的团队所取得的进展：他们让 ROCm 从 vLLM 的一个次要分支，逐渐变成了更接近一等公民的上游体验。vLLM 官方博客现在表示，仅仅“简单移植” AMD 支持的时代已经结束。该博客记录了七种 ROCm 注意力后端，并展示了最新的 AMD/vLLM 编排工作带来的 1.2 倍至 4.4 倍的吞吐量提升。这才是一条可信的追赶路径。

George Hotz 在 2025 年就说得很好：

InferenceX：AMD 的开发者迭代速度正在加快

过去我们看到，无论是在聚合还是分离式场景下，AMD 在其硬件上高效部署新模型方面一直很吃力。我们持续追踪 InferenceX 上的所有迭代性能数据，这使我们能够在一定程度上评估这种“速度”。

正如我们在上一篇文章中提到的，AMD 推理团队在第一个月左右的时间里，迅速提升了 DeepSeek v4 的性能表现，尤其是在单节点情况下做得非常出色。下面的图表标注了在 DeepSeek v4 发布后的前 47 天内，针对 MI355X SGLang 单节点配置所做的所有改进。

最近，我们在 MiniMax M3 上看到了类似的情况。AMD 推理团队通过快速迭代，实现了极具竞争力的性能。

在分离式场景下，AMD 同样表现出色。这与大约 6 个月前相比是巨大的进步，当时团队在 DeepSeek R1 上苦守数月，一直难以达到与 Nvidia 同等的水平。这归功于几个因素。首先，AMD 对其软件栈进行了具体的重大改进，包括用于分布式推理的 MoRI 后端，以及对 Mooncake 的多项改进。更重要的是，由 Hai Xiao 带领的 AMD 分布式推理团队，正以更强的紧迫感开展工作，致力于为分布式推理提供更好的支持。

以下视频显示，MI355X FP4 分离式解决方案曾落后于 Nvidia 的方案数月之久。

Note that this was AMD’s first public disagg recipe, posted on InferenceX in January. Take this in stark contrast with the Day 0 progress on MiniMax M3 FP4 disagg shown below, and you can see AMD is in a much better position now to be competitive in terms of distributed inference solutions.

However, going fast isn’t easy. Especially when the competition has a head start. The missing one piece is now real: what AMD’s distributed stack was missing above is now addressed by the engine that comes with ATOMesh . It is a ROCm-native distributed-inference gateway featuring a Rust routing and orchestration layer that handles the cluster-level work disaggregated serving needs, such as prefill/decode-disaggregated routing, cache-aware load balancing, RDMA KV-cache transfer (via MoRI-IO or Mooncake).

It is not a from-scratch build: ATOMesh is derived from SGLang’s sgl-model-gateway , and is substantially reworked around ATOM and AMD hardware. However, it works, as shown in the MiniMax M3 InferenceX results above. Routing policy stays separate from model execution, and it plugs into vLLM and SGLang as naturally as AMD’s own ATOM engine.

Chipping Away at the CUDA Moat: Using Agents to Enable Day 0 Support

The SemiAnalysis team grinded to enable day 0 support for DeepSeek v4 and MiniMax M3, and we will continue to do so for upcoming frontier models such as Kimi K3. This “day 0” perf is an important baseline for showcasing performance over time , which is the north star goal of InferenceX.

Obviously, the 100x cracked engineers at AMD, Nvidia, Inferact, RadixArk, etc are responsible for the hardcore inference engineering work to truly enable day 0 support for these models. However, often times there are bugs to fix or low hanging fruit that the SemiAnalysis team adds in order to enable day 0 sweeps (currently, these are more prevalent with AMD configs). This has become increasingly easy with the rise of capable agents. The flow looks something like this: for a given config (I.e., MiniMax M3 vLLM MI355X FP8), start a new Claude Code/Codex agent to pull the day 0 recipe from the internet, create the necessary plumbing in InferenceX, and then kick off the sweeps. The agent has access to both the GitHub Action as well as direct access to the physical runner to continuously monitor the status. In the case of an engine error, the agent can automatically decipher what the root cause is, and either iterate automatically and re-run or consult the human for intervention. We can execute this pipeline in parallel for multiple configs on various SKUs.

When an error is identified, the current models are quite good at identifying the cause in the upstream engine code (vLLM/SGLang/TRT) and few-shot implementing a fix, with some guidance from the team. Additionally, we use agents to identify low-hanging fruit performance improvements. Some examples of upstream contributions by the SemiAnalysis team + agents:

特别感谢 vLLM 社区的 Roger Wang、Hongxia、Michael Goin 以及其他 Inferact 工程师。感谢他们的悉心指导，并帮助合并了这些修复。

如果放在 3 到 6 个月前，这种快速迭代对于一个仅有 2.5 名工程师的团队来说是绝对不可能实现的。借助强大的工具链，当前的前沿模型展现出了真正的实力。它们能够为开源推理引擎和内核做出有意义的贡献。这未必归功于模型的“智能”，而更多是因为它们在接到目标后展现出的纯粹“毅力”。再加上能够并行执行许多此类任务，显而易见，测试和编写软件已不再具备去年的那种护城河效应。这对 AMD 来说是广泛利好的。通过让 AI 智能体承担人类工程师的工作，所谓的“CUDA 护城河”的重要性随之降低。这有助于 AMD 抵消 Nvidia 在工程师人数上的优势。

AMD 似乎在大力押注这一理念。在 Advancing AI 2026 大会上，他们发布了 ROCm.ai。这是一套包含技能、工具链和框架集成的组件库，旨在进一步帮助开发者利用智能体快速迭代内核和进行性能调优。

GEAK、Hyperloom 与针对 InferenceX 的优化

ROCm.ai 绝不仅仅是一张主题演讲的幻灯片。其中的大部分组件已经开源，存放在 AMD 的 AMD-AGI 组织中。它们与我们前文描述的首日支持流程几乎是一一对应的。核心是 GEAK（“Generating Efficient AI-Centric Kernels”）。这是一个基于 mini-SWE-agent 的智能体，负责编写和调优 Triton/HIP 以及 FlyDSL 内核。其外围由 Hyperloom 包裹。Hyperloom 是一个编排器，它可以分析推理工作负载，找出瓶颈内核，然后交由 GEAK 和 GEMM 调优智能体处理。在计入有效结果之前，每个候选方案都必须通过端到端 A/B 测试的验证。围绕着这套核心，还有一系列辅助工具：Magpie 用于评估，TraceLens 用于追踪分析，Apex 用于将智能体轨迹导出到带有强化学习特征的训练流程，以及 AgentKernelArena。这是一个直接对决的测试平台，能让 Claude Code、Codex、Cursor 和 GEAK 在相同的内核任务和同一评分标准下相互竞争。

Hyperloom 的优化器直接从 InferenceX 获取其性能目标。在当前的主分支中，它废弃了 InferenceX，改由 target_analyzer 生成一个竞争对手目标，然后让代理去尝试清除该目标。他们早期版本的 CI 走得更远——会计算相对于 InferenceX 的性能提升百分比，统计有多少模型“击败”了 InferenceX，并将排行榜发布到 Teams/Slack 频道——后来在开源发布前，这套机制被精简掉了。

我们认为这是一件好事。我们对 InferenceX 的愿景是准确跟踪开源框架的性能，如果代理将其作为奖励信号并不断尝试改进，它无疑能发挥这一作用。这些努力将带来更好的模型服务性能，从而使 ML 社区受益。

隐藏在这些仓库中更有趣的教训，正是我们从第一天起就深有体会的艰辛经验：生成一个 kernel 很容易，但信任测试数据却很难。工程开发中有很大一部分工作是在做防作弊。GEAK 不得不停止静默记录未修补的基线 kernel 的得分，转而记录代理实际修补后的结果；同时增加了 GEAK_PROTECT_TEST_FILES 模式，该模式会剥离代理对测试框架的修改，从而防止其通过重写参考实现来伪造正确性。Apex 则内置了一个防篡改检测器，用于标记硬编码的 print("PASS")，并维护了一个禁用库列表，防止代理通过暗中调用预调优的 MIOpen 或 hipBLASLt 来“优化” Triton kernel。这是一个关于毅力胜过智能的老生常谈的故事：只要你稍不留神，模型就会对 benchmark 进行奖励作弊，而很大一部分工作正是建立防护机制，以确保加速效果是真实的。

而且这套机制确实奏效了。GEAK 的学习笔记中已经记录了在量产芯片上经过验证的端到端实际收益。在 MI355X 上，通过基于 MXFP8 的解码受限型 dense-linear 重写，实现了约 +21.8% 的端到端性能提升；当然也有客观的局限性说明，即 grouped-MoE GEMM 的性能卡在 1.1 倍的上限附近。仅凭这些并不能攻破 CUDA 的护城河。但它是最清晰的信号，表明 AMD 正在将一套工作流工业化，而就在一年前，这套工作流还需要一屋子的 CUDA 工程师才能完成。

介绍 AgentX：全新的 InferenceX 智能体场景

虽然目前的 8k1k + 1k1k 场景是评估基线芯片性能的良好代理指标，但由于它们都是单轮的随机数据请求，因此无法评估整个系统（路由器、KV cache 传输、KV cache 卸载、调度器等）。

For the past few months, we have been working with industry leaders to develop an agentic benchmark: AgentX. To achieve our goal of making the benchmark as reflective as possible of real world serving, we collected ~3 months of internal SemiAnalysis Claude Code, Codex, etc. traces, which we then replay offline at varying concurrencies using AIPerf. Some of the statistics of the dataset are shown below. Notably, the median ISL and OSL are 140k and 396, respectively (quite different from 8k1k). With a median cache hit rate of 99.2%! Note, this is assuming an infinite cache so is not, of course, actually attainable in most real-world serving.

The dataset also includes realistic subagent usage as well as dynamic workflows, which further stresses the KV cache by continuously introducing uncached context for the server to process. The tool use time / user think time (captured by inter-turn latency) is also reflected in the dataset, further stressing the KV cache and highlighting the efficacy of KV offloading techniques, which have the possibility of increasing KV cache TTL.

We are very excited about this scenario. We have worked with WEKA, Inferact, RadixArk, LMCache, Mooncake, NVIDIA, AMD, and other industry leaders in ensuring it accurately reflects real traffic that may be experienced by a TaaS provider or frontier lab like OAI/Ant.

Results have been rolling in for the past month and are available on InferenceX. We will write an in-depth article on results and methodology soon.

Single-Node is Out, Disaggregated is In

As discussed, the competitive frontier has moved from single node aggregated to multi node disaggregated inference. In our InferenceX v2 article, we discussed the notion of AMD’s “software composability problem” when it came to distributed inference. That is, they had made strides in individual optimizations such as disagg, FP4, WideEP, DP-attention, etc, but combining many of these together broke the stack. While there is still certainly progress to be made, AMD has made significant strides in this area.

Our GTC 2026 recap frames Nvidia’s next moat as disaggregated inference systems, including attention/feed-forward disaggregation (AFD). Since attention is stateful and KV-bound, while FFN is stateless and batch-scalable, these phases can be split and mapped onto the best-suited hardware. Then, inference leadership becomes a distributed-systems problem rather than a single-kernel one. WideEP, disaggregated prefill, KV transport, expert routing, and scheduler/orchestration are all part of that same new moat. AMD can close single-node gaps, but unless those optimizations compose cleanly in vLLM and SGLang, it is still fighting yesterday’s war.

下方的时间线有助于我们看清这一差距。开放的 CUDA 生态系统早在 2024 年初就已交付 disagg+WideEP 方案。而 AMD 首次公开提供 PD-disagg + WideEP 配置，则要等到 2026 年 1 月通过 InferenceX 才得以实现。AFD 的真正收益依赖于超级集群级别的互连技术，而这类机架规模的硬件，AMD 直到 MI455X 才开始供货。在 2026 年的 GTC 大会上，Nvidia 发布了 Groq 3 LPX。这是一款基于 SRAM 的 LPU，专门集成到 Nvidia 推理机架中，用于分离式解码 FFN。

新护城河：稀疏模型、分离部署与 WideEP

近期模型趋势：激活专家数量保持精简，总专家数量爆发式增长

当前的模型发展态势，使得可组合性问题变得愈发紧迫。激活专家的数量始终维持在 4 到 10 的范围内，而总专家数量则向外扩展至 128、256、384，直至如今的 512。许多最新的大型 MoE 模型还通过 MLA 风格的低秩设计，将 KV 缓存压缩至相当于一两个注意力头的规模。这意味着前沿模型正变得愈发稀疏，对带宽更加敏感，并更加依赖路由机制、KV 迁移、WideEP 以及分布式调度。在这样的趋势下，单节点基准测试的又一次获胜已不再是护城河。可组合的分布式推理才是真正的护城河。

分离式 Prefill 与 WideEP

分离式 prefill 将计算密集型的 prefill 阶段与内存密集型的 decode 阶段，分配到不同的节点上运行。这消除了两个阶段之间的相互干扰，使运维人员能够独立调整 prefill 与 decode 的节点数量。其代价是需要通过 RDMA 进行 KV 缓存传输。我们估算，对于 8,192 个 token 的 DeepSeek-R1 FP8-KV prefill，大约需要传输 290 MB 的数据。

目前在 InferenceX 上，AMD 的分离式推理配置，其表现往往比单节点配置更差，或仅有微小提升。而对于 DeepSeek-R1，在同等交互性下，MoRI SGL 的吞吐量是聚合 SGL 配置的 2 到 3 倍。

WideEP 将专家分布到更多的 GPU 和节点上，而不是复制完整的专家孤岛。以 DeepSeek-R1（256 个路由专家）为例，从单 8-GPU 节点的 EP8 扩展到跨 64 个 GPU 的 EP64，会使每个 GPU 分摊的专家数从 32 降至 4。这不仅释放了 HBM 用于 KV 缓存，还支持了更大的并发批次（从而提高了每次 GEMM 中每个专家处理的 token 数量），并使聚合 HBM 带宽能够随集群规模扩展。其收益十分可观：NVIDIA 报告显示，WideEP 带来了高达 2.28 倍的单 GPU 输出吞吐量提升（基于 DeepSeek-V3.2、NVFP4、GB200 NVL72，对比 EP16/EP32 与 EP4/EP8）。正如我们在 InferenceX v2 中所强调的，前沿实验室和大多数 TaaS 提供商已在生产环境中部署结合 WideEP 的分离式服务。

换种说法，ATOM 和 AITER 只有在改善主流生态系统时才具有实际价值。我们之前曾指出，ATOM 或许能提升单节点性能，但仍然缺乏生产环境所需的特性，例如 NVMe 或 CPU KV-cache offload、工具解析以及 WideEP。正确的策略并非构建一个仅限 AMD 的封闭孤岛。而是应该将内核代码上游提交、强化 CI 流程、发布最佳实践方案，并让 FP4 + WideEP + disagg + cache offload 在默认的开源技术栈中协同工作。这才是当前瓦解 CUDA 护城河的正确途径。

分离式推理精度

在 2026 年 3 月之前，采用 DP-attention (DPA) 的 DeepSeek-R1 分离式配置在精度评估中全面失败，GSM8K 得分接近 0。而无 DPA 的测试则能以超过 95% 的通过率通过 GSM8K。这一问题在 InferenceX 评估运行中被发现。这表明无 DPA 的分离式推理路径可以保持正确性。然而一旦使用 DPA，整个技术栈就会崩溃，这再次暴露了 AMD 的组合协同问题。不过，该问题目前已被修复。

有一个尚未修复的问题，是在 SGLang 中使用 MoRI 后端时，特定 batch size 下的 EP 表现。在 DeepSeek-R1 上，当并发数为 64 时，GSM8K 得分会降至约 80%。而在其他所有并发数下，该得分都能稳定保持在约 94% 的基线水平。该 bug 曾引发过灾难性后果。当时，同样的低并发路径会悄无声息地生成看似流畅但实则错误的结果，导致 GSM8K 得分为 0。经排查，根源在于 AITER 的 FP4 MoE kernel 中存在未初始化的 reduce buffer。该问题已于 6 月修复。然而，并发数为 64 时得分跌至约 80% 的残留问题仍未解决。AMD 将此归咎于量化 kernel 中仅在特定 batch size 下才会触发的数值边界情况，并拒绝优先修复该问题。

组合协同有时确实有效……

AMD 现已证明上述多项优化能够组合生效。SGLang 的 MI355X 每日构建镜像已支持具备 DP-attention、EP8 和 MTP 的 DeepSeek-V4 分离式推理。同时，四节点 DeepSeek-V4 和 Kimi WideEP16 配置也在硬件上完成了验证。但这种组合协同仍然高度依赖于特定模型和拓扑结构，无法在默认情况下稳定可靠。Kimi 的 DP8/EP8 路径在一次 GPU 内存故障后被排除在外。其 WideEP16 int4 解码路径目前必须禁用 HIP graph capture。且 WideEP16 的 CI 变更仍在审核中。目前的差距已不再是这些单独的组件完全无法协同工作。而是 AMD 尚无法确信：如果没有特殊处理，这些组件能够跨越不同模型、量化格式、并行策略、投机解码以及网络拓扑结构而稳定协同。

分离式推理必须成为所有人的责任

解耦推理不能仅停留在 AMD 的某个小众领域。AMD 自己的 ROCm 教程指出，单节点优化已开始遇到瓶颈，分布式推理正变得愈发重要。随后，ROCm 在 2025 年 12 月发布了 Mooncake PD 解耦官方文档，又在 2026 年 1 月发布了基于 MoRI 的分布式推理文档。既然官方技术栈已经在发布 xP+yD 拓扑、RDMA 需求、1P2D 方案以及 KV 迁移框架，DI 就不再是一项边缘任务。DI 本身就是核心产品。它必须成为所有人的工作重点，贯穿 ROCm、SGLang 集成、CI、方案制定以及性能工程等各个环节。

以上就是 AMD 软件层面的现状。单节点路径正在逐步完善。MoRI 前景广阔。重叠技术栈也终于初露锋芒。但市场已经迈向 SBO、PD 解耦、负载均衡以及更宽的 EP 配置，这些技术必须在真实的生产约束下无缝整合。AMD 不再需要单点突破式的性能优化，而是需要整个分布式推理技术栈作为一个完整的系统协同运转。

AMD 的定位：分布式技术栈逐层剖析

MoRI：由单一攻坚团队打造的真正突破 🐯

值得称赞的是，MoRI 是 AMD 取得的一项实质性胜利。MoRI 是一个模块化 RDMA 框架，包含两个专用组件：用于专家分发/合并的 MoRI-EP，以及用于 KV 迁移的 MoRI-IO。目前，ROCm 已针对 MI355X 集群发布了基于 MoRI 的分布式 SGLang 官方文档。该框架由一支位于中国的工程团队从第一性原理出发构建。我们认可这一方向，但它仍需更加开放的 CI 和测试机制。

AMD 自身的 MoRI 路线图让规模化问题变得具体而微。2026 年下半年的路线图规划了一项横跨三个子系统的宏大计划：调度器协同设计的分层分布式 KV 缓存（通过 SPDK/GDS 实现 HBM→DRAM→NVMe）；下一代 SHMEM v2；基于 FlyDSL/C++ 的 EP v2 内核，支持弹性专家并行和容错机制；与 FlyDSL 协同设计的“超大内核”；以及机架级 Helios 赋能。最后还要将 SGLang 和 vLLM 推向上游。整个清单由同样的五六名工程师负责，他们的用户名在 MoRI 的合并拉取请求中占据绝对主导。这是一条正确的路线图。但截至发稿时，所有这些目标对团队而言仍处于未完成状态，全部重担都压在这一小部分人肩上。

最新硬件暴露出的差距：Helios (gfx1250)

判断分布式技术栈尚需多少改进空间，最清晰的衡量标准就是 AMD 的最新硬件。在 Helios (gfx1250 / MI455X) 技术栈的各个层级中，都存在一种相同的现象：单模型架构启用和 KV 迁移管道铺设进展迅速，但 WideEP、验证机制以及针对 wave32 调优的高价值内核尚未到位。

从底层基础看起。PyTorch 自身的 gfx1250 支持已在 7 月中旬合并（ROCm/pytorch #3421，这是一次上游变更的拣选，该变更先前已合入，一天后被回退，一周后又重新合入）。但这纯粹是构建时的架构底层支持，且受限于尚未发布的 ROCm 7.14+ 版本。因此在所有已发布的 wheel 包中，它都处于休眠状态。该支持未附带 gfx1250 的 CI 流程，而是将测试运行器推迟到了一个并不存在的后续任务中。它只是一个骨架：最高价值的代码路径（Composable Kernel GEMM 和 SDPA、FP8 分组 GEMM、int4）被过滤掉或会直接报错；attention 处于“技术预览”状态；wave32 内核尚未编写。AMD 的代码甚至将该部件标记为“CDNA5”，同时描述的却是 GFX12.5、wave32、WMMA 执行模型。这是树内代码中最明显的迹象，表明 Helios 距离其内核所专为编写的 CDNA wave64 体系有多远。

再往上一层，原始的 MoE 内核是该技术栈中迭代最快的部分。自春季以来，AMD 的 aiter 和 FlyDSL 库已经吸收了上百个 gfx1250 PR：wave32/WMMA GEMM、MXFP4/A8W4 量化、MLA-v4 attention、TDM 数据移动原子操作。其中大约四分之一在未合并的情况下被关闭。核心部分是 AMD 原生的“MegaMoE”路径：这是一个融合的 MoE 专家并行流程，其 dispatch/combine 操作层已被引入 aiter 中。其 gfx1250 分组 GEMM 内核（包含全局到局部专家重映射、融合的路由/散射，以及针对 DeepSeek-V4 的 384 专家 MoE 调优的掩码分组 GEMM）仍处于开放状态，且仅针对 a8w4（FP8 激活、MXFP4 权重）进行了验证。这正是该技术栈所需的 WideEP MoE 原语；只是它尚未完成，并且 gpt-oss、R1 和 V4 内核各自在独立的分支上落地。

断层出现在集成层，也就是这些内核与框架对接的地方。SGLang 7 月 22 日的 gfx1250 nightly 版本仅仅构建并发布了镜像。没有测试任务，没有精度门禁，它构建于通用运行器之上，仅通过 MI300 进行镜像同步，因为上游根本不存在 gfx1250 运行器。该镜像构建了 MoRI，却固定在 gfx1250 支持之前的 6 月份提交版本上，因此 MoRI-EP WideEP 无法运行：这些内核不包含矩阵核心或 wave64 专用 ISA，而 MoRI 的构建仅支持 gfx942/gfx950，AMD 此后添加的 wave32 支持则存在于更新的专家并行路径中，SGLang 的集成尚未调用该路径。一旦 AMD 将其接入 SGLang 使用的路径，WideEP 应该就能工作。MoRI-IO 的 KV 传输部分是与架构无关的主机端 RDMA，如今即可在 gfx1250 上迁移 KV cache。然而，目前针对 DeepSeek-V4 和 R1 的实际 gfx1250 方案均采用单节点张量并行，既没有 WideEP，也没有解耦架构。

vLLM 的 gfx1250 带来过程从另一方面讲述了同样的故事：在 FFM 模拟器和早期硅片上测试了四个模型，结果不稳定；仅针对 gpt-oss 进行了专门的性能优化，而其“ATOM 对齐”调优流程本身也被回退，“直到 AITER 准备就绪”。MoRI 也被直接从构建中移除。这是一个可靠的单节点 FP4 调试流程；但它并不是分布式技术栈。

Even AMD’s own engine follows the pattern. ATOM’s Helios work is disaggregation-first and expert-parallel-later: ATOM adds DeepSeek-V4 MoRI-IO write-push KV transfer plus a UALink scale-up fabric backend — the Helios-generation interconnect — so the KV-transport half of disaggregation is being built for exactly the model and fabric Helios will run, though its e2e validation ran on eight MI355X nodes and a UALink vPOD rather than MI455x. But it carries no EP dispatch/combine, no MoRI-EP, no WideEP; ATOM’s shipped DeepSeek-V4 recipe still serves the model at TP=8 on a single node, and every one of its MoRI-EP PRs targets last-generation gfx942/gfx950. Bottom to top:

PyTorch, kernels, MoRI, frameworks, ATOM, Helios has arch enablement and the first half of disaggregation, and no WideEP anywhere.

SemiAnalysis Helping AMD upstream into NVIDIA’s KVCache Transfer Library NIXL

At Nvidia’s GTC 2025 NCCL session , we asked if Nvidia would provide support to the AMD communication library fork due to this big refactor in the upcoming Nvidia’s communication library. Nvidia explicitly said it would not help AMD’s communication team adapt to the upcoming NVIDIA library refactor, and that NVIDIA doesn’t participate in AMD’s communication development at all

A year later, at Nvidia’s GTC 2026 Dynamo session, we asked a question: NIXL had already accepted upstream contributions from Trainium’s Neuron fork, so would it accept them from AMD’s RIXL fork too? The maintainers said yes, on the record, in front of a room.

AMD had been carrying RIXL downstream, burning engineering hours maintaining a parallel copy of infrastructure everyone else gets for free. The only thing standing between AMD and upstream was whether anyone would try. NVIDIA had just removed the excuse.

So we spent April making sure AMD knew it. We put the question to Stephen Bates publicly on LinkedIn , offered Anush help to connect AMD directly to the NIXL maintainers , and asked Anush about MoRI/RIXL upstreaming in person during TensorWave’s beyond summit and we helped AMD form the relationship with NVIDIA so that they can upstream the patches.

On May 15, AMD’s Andy Luo opened a PR for ROCm/HIP build support for gfx942 (MI300X, MI325X) and gfx950 (MI350X, MI355X), behind a default-off use_rocm Meson flag. It merged June 4 after several rounds of review with NVIDIA-side maintainers.

Andy’s PR cleared review by proving zero blast radius on the CUDA path. On the AMD side it validated end-to-end VRAM transfers over NIXL+UCX on MI300X and MI355X. The stacked follow-up, #1647, hit 341 Gb/s cross-node RDMA on two MI355X nodes using AMD’s own AINIC RoCE NICs and libionic driver, with no Mellanox NIC in the path. Today, RIXL has been fully ported to NIXL. Dynamo core has since started taking AMD patches too .

NIXL 是解耦服务架构的传输层。如果 AMD 希望 PD 解耦和 WideEP 能真正稳定可靠，而不是仅限于特定模型，那么 KV 传输就必须能在用户实际部署的框架中运行于 Instinct 之上，而不仅仅是在 MoRI 内部。AMD 内部本不该由我们来指出这一点。目前遗留的短板也反映了同一问题：nixlbench 的 HIP 支持与 ROCm Dockerfile/CI 环境是作为后续独立任务提交的；AMD GPU CI 运行器目前仍只是个提议，尚未成为合并的工作流；而 rocSHMEM 还只是一个未来计划中的插件。

重叠栈姗姗来迟，而市场早已继续前行

双批次重叠（TBO）本该在很久以前就成为标配。SGLang 将双批次重叠与专家并行列入了 2025 上半年路线图，其公开文档如今也已暴露了 `--enable-two-batch-overlap` 选项，宣称可实现高达 2 倍的吞吐量。然而在 AMD 自己 2025 年 11 月发布的关于 MI300X 运行 DeepSeek 的文章中，仍将双批次重叠描述为一项“正在开发中”的核心特性，后续工作重点依然是双批次重叠与专家负载均衡。MoRI 对 TBO 的 EP 支持直到 2026 年 2 月 20 日才合并进 SGLang。这确实太迟了。

成熟度上的差距立刻显现了出来。合并后没几天，一位维护者就标记该 PR 破坏了 CI，要求将其回退，修复后再重新提交。这缩影般地反映了整个 ROCm 推理生态的现状：基础组件正日益齐备，但太多关键优化依然姗姗来迟，落地时脆弱不堪，往往还需要再经历一轮打磨，才能成为客户默认信赖的方案。