AMD 推动 AI 进步：MI350X 与 MI400 UALoE72，MI500 UAL256 软件改进、市场营销 RDF、AMD 培育 Neocloud、MI355 不是机架级、MI400 是 UALoE 而非 UALink
本文信息来源：semianalysis
作者：Kimbo Chen，Dylan Patel，Daniel Nishball，Wega Chu，Ivan Chiam，Patrick Zhou 和 Gerald Wong
在过去六个月里，AMD 一直处于战时状态 。他们一直在努力并且聪明地朝着与 Nvidia 竞争的目标前进。在其 Advancing AI 2025 活动上，AMD 发布了 MI350X/MI355X GPU，这些产品在小型到中型 LLMs 推理的性能与总拥有成本（TCO）方面，可能具备与 Nvidia HGX B200 解决方案竞争的能力。尽管 AMD 营造了现实扭曲场，但 MI355X 并不是一个机架级产品，在前沿模型推理或训练方面也无法与 Nvidia 的 GB200 NVL72 竞争。
实际上，MI400 系列才是真正的机架级解决方案，有望在 2026 年下半年与 Nvidia 的 VR200 NVL144 机架级解决方案竞争。关于 MI400 系列，AMD 也进行了一些市场宣传，将其“IF over Ethernet”协议更名为“UALink Protocol over Ethernet”，但这并不是真正的 UALink。
在本文中，我们将讨论 AMD 新产品的相对竞争力，并分析其总体拥有成本。我们还将详细阐述 AMD 的新超大规模客户 AWS，以及另一方面，现有客户微软在后续订单上的持续令人失望的表现。
最近，Nvidia 推出了 DGX Lepton Marketplace，旨在将算力商品化，这一举措让不少 Neocloud 合作伙伴感到不满。我们认为，这一发展也为 AMD 培育自己的 Neocloud 生态系统打开了一扇机会之窗。我们将解释 AMD 如何更愿意投资于 Neoclouds，他们为帮助这些 Neoclouds 所采用的巧妙财务工程，以及 AMD 对其内部开发研发集群的投资。
执行摘要
- MI355X 在中小型模型推理方面可以与 HGX B200 竞争，但在与 GB200 NVL72 的竞争中将不具优势。
- 尽管有 AMD 的市场宣传 RDF，MI355 128 GPU 机架并不是“机架级解决方案”——它的扩展世界规模只有 8 个 GPU，而 GB200 NVL72 的世界规模为 72 个 GPU。在大型前沿推理模型推理方面，GB200 NVL72 在每 TCO 性能上将优于 MI355X。
- MI355X 的集体性能将与 HGX B200 相似，但 MI355X 的集体操作速度至少会比 GB200 NVL72 慢 18 倍，甚至可能更慢。
- AMD 宣布推出其开发者云，将 MI300 的按需定价降至每小时每 GPU 1.99 美元，而当前 AMD Neocloud 市场的价格为每小时每 GPU 3.00 美元，此举有望使租用 AMD GPU 在价格上具备与 Nvidia GPU 竞争的能力。
- Nvidia 的 DGX Lepton Marketplace 让许多 Neocloud 感到不满，这可能为 AMD 提供机会来说服 Neocloud 同时支持 Nvidia 和 AMD。
- AMD 终于开始采用类似于 Nvidia 的策略，利用其强大的资产负债表，通过从云服务商处回租部分 GPU，来支持 Neocloud 和超大规模生态系统采纳 AMD 产品。这将有助于加速终端用户对 AMD 系统的采用。
- MI400 系列将是一种机架级解决方案，有望在 2026 年下半年与 Nvidia 的 VR200 NVL144 展开竞争。
- 目前有一项正在进行中的新举措，旨在提高 AMD 工程师的薪酬，使其更具市场竞争力，并使薪酬与 AMD 的成功更加紧密地挂钩。AMD 何时会向其 AI 工程师宣布这一消息尚未可知。
- MI400 系列机架实际上并未使用真正的 UALink 进行扩展网络。AMD 反而将其基于以太网的 Infinity Fabric 重新命名为“UALink over Ethernet”，并将其用于扩展网络。
- MI400 系列的扩展网络将采用博通以太网 Tomahawk 6 交换机，因为 Marvell 和 Astera Labs 的 UALink 交换机在 2026 年底前还无法准备好
- 尽管有上述情况，MI400 系列通过以太网的 UALink 在扩展带宽方面仍能与 VR200 NVL144 的 NVLink 竞争，并且其扩展世界规模可达 72 个逻辑 GPU
- 2027 年底，AMD 将发布 MI500 UAL256，其将配备 256 个物理/逻辑芯片，而不仅仅像 VR300 NVL576 那样配备 144 个物理/逻辑芯片
MI350X 和 MI355X 规格
该系列的 CDNA4 芯片有两个版本——即 MI350X 和 MI355X。MI350X 是 1000W 的风冷版本，而 MI355X 是 1400W 的版本，支持风冷和 DLC 液冷。尽管 MI355X 的功耗高出 1.4 倍，但其理论参数显示，在 TFLOPS 吞吐量方面仅比 MI350X 快不到 10%。然而，我们预计 MI355X 的实际性能提升会超过 10%，因为由于功耗限制，公布的参数往往无法完全实现。这些公布的参数假设峰值时钟频率可以在实际工作负载中持续保持，但无论是 AMD 还是 Nvidia 的系统，实际情况都并非如此。
MI350X 和 MI355X 的纸面规格在 BF16/FP8/FP4 数据类型（dtypes）上都能与 HGX B200 竞争。我们预计 BF16 和 FP8 将用于训练，而 FP8/FP6/FP4 将用于推理。在 HGX B200 上，FP6 与 FP8 共用相同的物理电路，因此 FP8/FP6 的纸面 FLOP/s 相同。在 MI355X 上，FP6 与 FP4 共用相同的物理电路，因此 FP6 的峰值 TFLOP/s 速度与 FP4 相同。这意味着 MI355X 的 FP6 比 B200 的 FP6 快 2.2 倍。实际上，由于 AI 芯片总是受限于功耗，MI355X 的 FP6 速度至少会比 MI355X 的 FP4 慢 20%。
SemiAnalysis 的基准测试显示 ，尽管 MI300X 和 H100 在纸面上 FP16 与 BF16 的 TFLOP/s 相同（即 Nvidia 的 FP16 TF = BF16 = 989 TFLOP/s，AMD 的 FP16 = BF16 = 1307 TFLOP/s），但在实际运行 FP16 与 BF16 时，每张卡实现的 TFLOP/s 却不同。我们将在不久的将来发布一篇文章，运行微基准测试，以找出 MI355X FP6 与 FP4 的实际 TFLOP/s。
对于 4 位浮点格式，MI355X 只支持 OCP MX4，其中一个微指数缩放因子应用于 32 个元素的区块。相比之下，Nvidia 的 Blackwell GPU 同时支持 OCP MX4 和 NVFP4，不过 NVFP4 使用更小的 16 元素区块，这在进行 QAT/PTQ 量化时有助于减少数值精度校准的难度。我们与一些 vLLM 和开源推理的贡献者交流过，他们提到 NVPF4 在信息/模型质量保留方面远优于 MX4，但通过额外的运行时量化软件技术，MX4 也有可能达到相同的质量。
在 Blackwell Ultra B300 HGX NVL8 上，Nvidia 移除了大部分 FP64 和 int8 张量核心，以腾出空间增加 1.4 倍的 FP4 张量核心电路。这使得 B300 在 FP4 推理方面相较于未采用此优化的 MI350 和 MI355 具有绝对优势。因此，B300 的 FP4 TFLOP/s 比 MI355X 快 1.3 倍，同时功耗减少了 200 瓦。
在 HBM 方面，MI350/MI355 拥有与 B300 相同的内存带宽和容量，但其 HBM 容量大幅提升，达到 288GB，而 B200 仅为 180GB。这在 AMD 单节点推理时是一个关键优势。然而，在多节点高阶专家并行和分布式预填充的时代，每个 GPU 拥有更多 HBM 虽然依然有益，但已不再那么关键。带宽变得更加重要，这也是为什么两家 HBM 厂商正在为两个高端 ASIC 项目加速推出 8Hi HBM4。更多详情请参见 SemiAnalysis 的加速器和 HBM 模型。
对于 MI350/MI355 的扩展网络，AMD 能够将其 XGMI 协议（使用 PCIe 5.0 PHY Serdes）“超频”1.2 倍，从 64GB/s 提升到 76.8GB/s。这是通过使用 PCIe 5.0 PHY 扩展速率模式实现的，该模式每条链路提供约 38GT/s，而不是 32GT/s。尽管如此，Nvidia 的同类产品在扩展网络速度上仍然远超 MI350/MI355，因为 HGX B200/B300 采用了全互连交换拓扑结构，其速度比 MI350/MI355 的网格拓扑扩展网络快 1.6 倍。至于 GB200 NVL72/GB300 NVL72，与 MI350/MI355 的扩展解决方案根本没有可比性或竞争性，因为 GB200 NVL72/GB300 NVL72 是真正的机架级解决方案，在单一扩展域内连接 72 个 GPU，而 MI350/MI355 在其扩展域内仅能连接 8 个 GPU。
接下来谈谈扩展领域，MI350/MI355 每个 GPU 支持 400 Gbit/s 的速度——与 B200 和 GB200 NVL72 相同，但很快将被 B300 HGX NVL8 和 GB300 NVL72 超越，这两者都提供每个 GPU 800 Gbit/s 的网络带宽。整体来看，AMD 在扩展网络方面将落后于 Nvidia，因为 Nvidia 将在今年晚些时候开始大规模部署其 800GbE ConnectX-8 网卡，而 AMD 的 800GbE“Vulcano”网卡要到 2026 年下半年才会开始大规模部署。
与 HGX B200 NVL8 的 TCO 竞争性能
我们认为，MI355X 在小型到中型 LLMs 生产推理工作负载方面有望与 HGX B200 竞争。这是因为对于自有集群，MI355X 的总体拥有成本比 HGX B200 低 33%，同时提供了更多的 HBM 内存容量、略高的 FP8 和 FP4 TFLOP/s 以及两倍的 FP6 TFLOP/s。在 Anush（AMD 的 AI 软件之王）的领导下，AMD 软件的快速进步也将进一步提升 MI355X 在 TCO 上的相对性能优势。
AMD 关于 MI355X 竞争力的宣传，主要集中在其无需直接芯片液冷（DLC）这一点。某种程度上，这确实有其合理性，但具有一定讽刺意味的是，AMD 仍然将下一代 MI355X 定位为与 Nvidia 已经上市一段时间的“经济型”HGX 产品竞争。由于上文提到的规模扩展受限，AMD 的 MI355X 无法在前沿推理推断方面与 Nvidia 的旗舰 GB200 NVL72 正面竞争，因此其定位是与风冷的 HGX B200 NVL8 和风冷的 HGX B300 NVL8 竞争。
也就是说，这一产品细分市场的出货量将会相当可观，具体取决于 MI355X 的软件质量以及 AMD 愿意出售的价格。我们预计，它在那些不需要大规模扩展世界规模的小型到中型模型用户中可能会获得最大的关注。但对于需要大规模分布式部署或采用专家混合模型、能够利用大规模扩展网络的推理模型和前沿推理应用，GB200 NVL72 在性能和每单位总拥有成本的表现上仍将占据主导地位，尤其是在推理方面。
Nvidia 正在用 DGX Lepton 搅动新云服务商
本周在 GTC 巴黎大会上，黄仁勋进一步阐述了 DGX Lepton 及其商业战略，这可能会导致 AI 算力在全球范围内的商品化。这意味着客户能够自动且无缝地将其推理工作负载在不同云之间切换，同时理论上保持相同的软件用户界面和体验。这对于主要专注于推理和小规模训练工作负载的用户来说尤其具有吸引力，因为我们预计大规模推理部署或大规模训练不会使用 DGX Lepton。
如果 DGX Lepton 获得成功，他们将为所有新云服务商创造一个标准化的用户体验，拥有完全相同的功能集、价值主张和性能，这将使所有新云服务商在价格上展开“竞底”竞争。他们实际上会将新云服务商的利润率变成极低的商品级利润率。
就像 Uber/Lyft 是连接客户与司机的平台一样，DGX Lepton 似乎也在寻求成为 GPU 算力的连接平台。众所周知，Uber/Lyft 催生了一大批利润微薄、受制于其平台的零工经济工作者。DGX Lepton 可能会对 Neoclouds 产生同样的影响。
另一方面，就像 Uber/Lyft 一样，DGX Lepton 对消费者来说将是极大的利好。通过降低中间商的利润空间，Nvidia 实际上提升了终端用户的每 TCO 性能表现，同时并未影响 Nvidia 自身令人咋舌的利润率。算力成本将会降低，而用户体验则会变得标准化。
根据与多家 Neoclouds 的交流，许多人对 DGX Lepton Marketplace 并不满意，原因如前所述。尽管他们对 DGX Lepton 不满，但许多人仍觉得有义务参与，以维持与 Nvidia 的良好关系。The Information 最近发表了一篇文章 ，也详细阐述了 Neoclouds 内部的复杂情绪以及对 DGX Lepton 的普遍不满。 据称，NVIDIA Lepton 团队的一些工程师也对他们与 Neoclouds 的合作关系将如何发展感到焦虑。
Jensen 在 DGX Lepton 可以采取的另一种替代方案是，完全开源 Lepton 出色的软件平台，并允许参与的 Neoclouds 在自托管 Lepton 软件时，除了参与 DGX Lepton marketplace 之外，也能免费部署 Lepton 的软件。
这将让 Neoclouds 拥有独立于 Nvidia marketplace 的多种销售渠道，同时依然为消费者带来强劲的性能和更好的体验，提升整个生态系统的标准。
DGX Lepton 持续发酵的一个结果是，Neoclouds 开始重新考虑完全依赖单一供应商的做法，许多公司最终可能会寻求替代方案以降低这一风险。这一发展为 AMD 提供了绝佳的机会，可以迅速提升其在 Neoclouds 领域的参与度，并快速扩大部署 AMD GPU 的 Neoclouds 数量。
MI355X 不是机架级解决方案——AMD 的市场宣传
AMD 一直在将 MI355X 宣传为“机架级解决方案”，但无论如何定义，MI355X 都不是机架级解决方案。所谓的 MI355X “128 GPU 机架”其实只是把 16 台 MI355X UBB8 服务器放在同一个机架里，但并没有一个贯穿整个机架的统一扩展域。
MI355 “128 GPU 机架”就像是 temu.com 上的机架级产品。把 MI355 DLC 机架称为“机架级解决方案”，就像你在即将上映的好莱坞大片里，试图说服制片人用 Jesse Plemons 替代 Matt Damon 一样。
正如我们后面会详细说明的，这意味着 MI355X “机架级解决方案”的集体性能比 GB200 NVL72 差了 18 倍。对于 MI355X，UBB8 服务器 A 里的 GPU 只能通过以太网以 400Gbit/s 的速度与同一机架内 UBB8 服务器 B 里的 GPU 通信；而对于 GB200NVL72，不同计算托盘中的 GPU 之间通信速度可达 900GByte/s。
如果将 MI355 的 128 GPU 机架视为“机架级解决方案”，那为什么不把许多 H100 机架也称为“机架级解决方案”呢？显然，如果 MI355 被贴上“机架级解决方案”的标签，那么 H100 也应该被视为“机架级解决方案”。这是一个荒谬的说法，因为没有人把 xAI 每个机架配有 64 个 GPU 的 H100 部署称为“机架级解决方案”。和 MI355 一样，这种 H100 部署在所有 64 个 GPU 之间并没有一个统一的扩展域，它只是一个机架里有八台 HGX H100 NVL8 服务器而已。
在推理和训练专家混合模型时，最重要且通信密集的集体操作是全互连操作，它将 token 路由到正确的专家。对于全互连通信，MI355X 的速度比 GB200 NVL72 慢 18 倍，比 HGX B300 NVL8 慢 2 倍。对于使用 2D+并行训练模型的常见 LLM 模式，通常会使用带有 0x7 分割掩码的全归约操作，在此操作中，MI355X 同样比 GB200 NVL72 慢 18 倍。这个例子说明，MI355X 显然不具备机架级扩展能力，也无法与 GB200 NVL72 相提并论。
超大规模和 AI 实验室对 AMD 新产品的采用
尽管关于 MI355 机架的市场宣传有些夸张，但我们在总拥有成本和每 TCO 性能潜力方面提出的观点，显然已经引起了超大规模客户和大型 AI 实验室客户的共鸣，我们看到这些客户的高度参与和良好的订单势头。
AWS 是 AMD Advancing AI 活动的冠名赞助商，现在将首次大规模采购并部署 AMD GPU 以供租用。
Meta 过去通常专注于在 AMD 上进行推理用例，现在也开始在 AMD 上进行训练。他们是 72 GPU 机架背后的关键推动力，并且将会使用 MI355X 和 MI400。Meta 的 PyTorch 工程师现在也开始参与 AMD Torch 的开发，而不仅仅是 AMD 的工程师在开发 AMD Torch。
对于 OpenAI，Sam Altman 在 AMD 活动上登台亮相。OpenAI 喜欢 AMD 在我们第一篇关于 AMD 和 Nvidia 的基准测试文章之后进步得如此之快。
x.AI 将会使用这些即将推出的 AMD 系统进行生产推理，进一步扩大 AMD 的市场份额。过去，只有很小一部分生产推理使用 AMD，大多数工作负载都运行在 Nvidia 系统上。
GCP 正在与 AMD 洽谈，但双方已经讨论了一段时间。我们认为 AMD 应该像对待一些关键 Neocloud 一样，给 GCP 同样的合作条件——也就是通过为 AMD 内部研发需求回租算力，来推动 AMD 租赁产品的启动。
甲骨文在快速部署 Neocloud 算力方面无疑是领头羊，同时也计划部署 30,000 颗 MI355X。
微软是唯一一个保持观望态度的超级云厂商，仅订购了少量 MI355，尽管它对部署 MI400 持积极态度。
这些超级云厂商中有许多由于其传统数据中心设计架构，拥有大量风冷数据中心，因此非常乐意采用风冷的 MI355X，因为其性能/总拥有成本极具吸引力。总体来看，我们预计所有这些超级云厂商都会部署 MI355，并且许多还将进一步部署 MI400 真正的机架级解决方案。
AMD 正在解决其在 Neocloud 租赁市场的弱点
增加 AMD 采用率的主要挑战之一是，目前专注于 AMD 的 Neocloud 数量非常少，而专注于 Nvidia 的 Neocloud 却有上百家。这种供应的稀缺以及租赁市场上产品种类的缺乏，导致 AMD GPU 租赁价格被人为抬高，削弱了 AMD GPU 的整体成本竞争力。
截至 2025 年第二季度，目前 H200 的 1 个月期合同市场租赁价格约为每小时 2.50 美元/每块 GPU，不同云服务之间价格差异较大，低质量云的价格更低。MI325X 的 1 个月租赁合同几乎不存在。MI300X 的 1 个月租赁合同价格为每小时 2.50 美元，这使得 MI300X 在租赁市场上与 H200 相比缺乏竞争力。下文中，我们将说明 MI300 和 MI325X 的 1 个月租赁价格大致需要达到多少，才能在租赁市场上与 Nvidia H200 竞争。这一分析很大程度上基于我们的真实推理基准测试 。
对于推理推断任务（1k 输入，4k 输出），MI300X 需要在 1 个月合约下的定价低于每小时 2.10-2.40 美元，才能在每美元性能上与 H200 竞争。MI325X 则需要根据交互性，将定价控制在每小时每 GPU 2.75 美元到 3.00 美元之间，才能具备竞争力。这个价格区间目前没有任何 AMD Neocloud 服务在没有经过大量谈判的情况下能够提供，这意味着由于这种市场低效，Nvidia 目前在租赁服务的每美元性能上占据优势。
全速前进——AMD 正在加速 AMD Neocloud 生态系统的发展
直到几个月前，AMD 并未特别关注在 Neocloud 生态系统中推动其产品的更强增长，也没有为 GPU 云服务商提供足够的激励措施，让他们愿意承担托管 AMD GPU 并可能无法将其租出去的风险。在过去的几个月里，AMD 的领导层已经意识到，建立一个健康的 Neocloud 生态系统非常重要，因为这有助于提升开发者的采用率，并有助于降低虚高的 AMD GPU 租赁价格。最终结果是，终端用户能够获得更高的性价比，同时有更多开发者熟悉 AMD，并能为更广泛的 AMD 生态系统做出贡献。
为此，AMD 为 AWS、OCI、Digital Ocean、Vultr、Tensorwave、Crusoe 以及其他 Neoclouds 提供了极具吸引力的激励措施，以支持这些超大规模云服务商和 Neocloud 采用 AMD 产品，并降低其业务风险。AMD 达成的协议是，作为客户愿意购买更多 AMD GPU 的交换条件，AMD 将以长期合同的形式回租相当大一部分产能，用于 AMD 内部的软件开发。这类似于 Nvidia 已经从 GCP、OCI、AWS、Azure、CoreWeave 等租用大量 GPU 集群，以满足 Nvidia 庞大的内部计算需求。对于某些 Neocloud，AMD 还提供激励措施，完全消除其投资风险，即如果 Neocloud 无法完全售出其产能，AMD 将作为兜底方租用这些产能。据我们了解，目前有许多 Neocloud 正在与 AMD 探讨类似的激励合作模式。
在这些激励措施的推动下，可以认为这些新型云服务商通过与 AMD 合作，正在构建一个比那些仅短期租用 Nvidia 集群、承担较大价格和占用率风险的同行更低风险的商业模式。
AMD 开发者云的推出也是其让 AMD 算力以有竞争力的价格普及的重要战略。作为此次发布的一部分，AMD 大幅降低了 MI300X GPU 的租赁价格，使更多开发者能够平等获取资源。不幸的是，在我们测试时，默认配额被设置为零 GPU，提升 GPU 配额也较为困难。我们建议 AMD 将新用户的默认配额至少设置为 16 块 MI300X GPU，以便更有效地吸引开发者进入其生态系统。由于 AMD 开发者云的按需价格定在每 GPU 每小时 1.99 美元的更合理水平，我们预计，提供按需 MI300 的 AMD 新型云服务商，可能需要将目前高达每 GPU 每小时 3 美元的价格下调至每 GPU 每小时 2 美元，以实现价格匹配。
ROCm 软件改进
AMD 发布了 ROCm 7，重点提升了推理能力和性能。在推理吞吐性能方面，AMD 宣称 ROCm 7 相比 ROCm 6 平均提升了 3.5 倍，相比 Nvidia B200 在服务 DeepSeek R1 时提升了 1.3 倍。我们期待验证这些说法。
AMD 还致力于与开放生态系统合作，推动分布式推理。除了支持推理框架 vLLM 和 SGLang 外，AMD 还支持编排框架 llm-d，这是 Nvidia Dynamo 的一个替代方案，用于实现分布式推理技术 PD 解耦。llm-d 技术栈目前还缺少不少功能，这些功能可以实现与 Nvidia Dynamo KVCache 管理器相同的作用。KVCache 管理器非常重要，因为它能够为推理工作负载带来巨大的 TCO 优势，并为许多推理工作负载带来数倍的吞吐量提升。
ROCm 对内核编写库 Triton 的支持在过去几个版本中也有了很大提升。ROCm 去年实现了对 Triton 的功能性支持，而 ROCm 7 则专注于性能提升。我们希望 AMD 能够继续努力，并扩展对 FlexAttention 等高级特性的支持。
最近，字节跳动 Seed 团队开发了 Triton Distributed，这是一个基于 Triton 的库，可以实现计算与 GPU 通信的重叠。AMD 对 Triton Distributed 表现出了极大兴趣，并表示将会提供更广泛的支持。然而，目前尚不清楚 OpenAI（Triton 的维护者）是否会接受字节跳动 Triton Distributed 特性的贡献并合并回原始 Triton 库。也有可能 OpenAI 正在自行开发 Triton 的分布式计算与通信内核。
此外，鉴于对中国的芯片出口限制日益严格，字节跳动可能会减少对西方 GPU 开源库的贡献。尽管如此，字节跳动正在大力投资 AMD，我们预计他们将会租用大量基于 AMD 的 GPU 算力。不过，字节跳动的主要阵营仍然是 Nvidia，因为他们算力扩展的绝大部分将来自于租用基于 Nvidia 的算力。字节跳动的大部分算力要么来自云服务租赁，要么来自位于中国以外的大规模专用裸金属集群，而他们的大多数 Neocloud 和云服务提供商目前仍主要依赖 Nvidia 的算力。
在更底层，AMD 声称他们正在集成流行的数据传输接口 Mooncake Transfer Engine 和专业的并行通信库 DeepEP。然而，截至目前，我们还没有在任何开源 ROCm 仓库中看到 DeepEP 或 Mooncake 的相关内容。
最后，AMD 宣布了其开发者云和开发者积分计划。除了为计算访问申请提供简单的界面外，AMD 还为开发者创建了名为“rocm”的 Python 软件包，方便开发者轻松安装 ROCm PyTorch、HipBLAS 等 ROCm 库以及这些 ROCm 库的开发工具。所有代码都在 GitHub 仓库 ROCm/TheRock 中开源。
MI355X PyTorch 持续集成（CI）与测试
AMD 已经开始为 MI355 芯片在 PyTorch 中添加 CI 和自动化测试。需要注意的是，MI355X 的所有 PR 目前还没有合并，但很高兴看到 AMD 从第一天起就考虑开源 PyTorch MI355X 的 CI。相比之下，Nvidia 自 Blackwell 大规模交付已经过去六个月，但他们还没有为开源 PyTorch 启动 CI，只专注于内部的 Blackwell CI。实际上，Meta 承担了 PyTorch CI 的大部分费用，每月支出超过 100 万美元，而 AMD 则为 AMD 上的开源 PyTorch CI 买单。虽然 Nvidia 目前还没有为开源 PyTorch CI 捐赠有意义的资金或算力，但他们确实计划通过捐赠大量来自 DGX Cloud 的算力积分，以及将其从各类 Neocloud 服务商租用的 GPU 算力捐赠给 Meta 开源 PyTorch 来做出贡献。
Nvidia 正在积极推进为 B200 添加开源 PyTorch CI，并已承诺向 PyTorch 基金会捐赠 48 块 B200，用于 PyTorch CI。虽然大家都希望从第一天起就有 CI，但在 6 个月后为 PyTorch 增加 Blackwell 的开源 CI，总比没有要好。我们对 AMD 缺乏 CI 的关注很可能促使他们在这方面取得了重大进展。Nvidia 应该继续加大对 Blackwell PyTorch CI 的投入。此外，他们的消费级 GPU 也需要被加入到 PyTorch 及主流推理库的 CI 中，以确保消费级 AI 的稳定性。目前，Nvidia 的消费级 GPU 在使用某些框架时，由于缺乏 CI 资源，存在一定的不稳定性。
ROCm MLPerf 训练提交
上个月，AMD 提交了他们首个 MLPerf Training 单节点 Llama2 70B LoRA 微调和 BERT 训练的测试结果。这是一个非常重要的进展，因为它证明了训练可以在单个 AMD 节点上运行。下一步，AMD 应该参与更多真实世界的训练基准测试，比如 MLPerf Llama 405B 多节点训练基准。我们认为他们在这项测试中可以展现出有竞争力的成绩。
在基准测试方面，我们很欣赏 AMD 通过为其 MLPerf 测试提供易于理解且可复现的操作说明，清楚地展示了他们的解决方案何时表现良好 。这与 Nvidia 的 MLPerf 提交形成了鲜明对比，后者的结果很难复现。
MIG 分区正在浪费时间和工程资源
AMD 目前正在他们的宠儿项目上浪费大量工程资源和资金，该项目旨在支持 GPU 分区。这个项目将允许用户把一块 GPU 分成 8 块更小的 GPU。没有客户提出这样的需求。Meta、OpenAI、x.AI 都没有提出这样的需求，因为所有在线推理工作负载至少都需要一块 GPU。我们认为，AMD 硬件工程师辛苦开发出拥有大量 HBM 的先进芯片，却想把这块 GPU 分成 8 部分，这种做法是不合逻辑的。
事实上，Meta、OpenAI、x.AI 都希望得到相反的结果，他们希望 AMD 能更好地支持多节点推理，至少通过使用 DeepEP 和分离式预填充等技术支持 16 块 GPU。
MI355X 制造——更新后的 Chiplet 架构
自 MI300 发布以来的两年里，AMD 不断完善其小芯片架构。从上图中的芯片可以看出，芯片布局经过了微调，底层的有源中介层芯片（AID）由原来的四个象限合并为两个掩模尺寸的半区。HBM 位置的微调也使得原本位于 HBM 之间的结构支撑硅片被移到了四个角落。
这种调整对于跨小芯片通信的好处非常明显，消除了整个 2.5D Infinity Fabric Advanced Package 链路的一条轴向，减少了芯片边界的跨越，从而节省了功耗和面积。同时也消除了 MI300 对角象限之间需要跨越两次芯片才能通信的“两跳”场景。
然而，这种设计也使得 3D 堆叠的良率变得更加重要。AMD 继续采用台积电的 SoIC 混合键合工艺，现在每个基底芯片需要连接两倍数量的加速器复合芯片（XCD），如果出现问题，可能会加剧良率损失并造成更多硅片浪费。AMD 选择这一路线，说明了台积电 SoIC 工艺的成熟度，以及 AMD 与台积电晶圆厂技术与运营团队长达 5 年以上的深度合作关系，AMD 一直是 SoIC 的首要客户。
虽然仍然采用台积电 N6 工艺，基底芯片在速度方面进行了多项升级。剩余的芯片间互联带宽从 MI350 上的 4.8TB/s 双向等效提升到了 5.5TB/s 双向等效。Infinity Fabric 的扩展速度提升了 20%。更重要的是，内存控制器现在可以支持更快的 HBM3E。AMD 依然采用久经考验的 CoWoS-S 技术来连接 AID 和 HBM，并指出其占用面积与 MI300 保持一致。
对于计算芯片，XCD 已经从 N5 工艺转移到台积电的 N3P 工艺节点，并采用了下文详细介绍的更新版 CDNA4 架构。这一次，AMD 只启用了芯片上印制的 36 个 CU 中的 32 个，而 MI300 上则是 40 个中的 38 个。有趣的是，XCD 在 AID 上的布局方向发生了变化，数据键合垫现在位于 AID 的中央区域。数据随后通过 256MB 的 Memory Attached Last Level（MALL）缓存向外传递，最终进入 HBM。
总体来看，这款新芯片集成了 1850 亿个晶体管，比 MI300 增加了 21%。我们估算每个 AID 大约有 230 亿个晶体管，每个 XCD 有 174 亿个晶体管。这意味着从 N5 到 N3P，晶体管预算提升了 30%。
CDNA4 微架构（UArch）
AMD 的架构设计正逐步从传统的高性能计算（HPC）转向针对 AI 工作负载进行优化。在 CDNA4 上，我们看到传统 HPC 的残余影响正在持续减弱，AMD 在架构层面更加倾向于 AI，尽管 CDNA4 仍然在 FP64 矩阵核心上浪费了大量芯片面积。
CDNA 4 配备了 256 个计算单元（CU）、160 KB 本地数据共享（LDS——相当于 SMEM），以及每个 CU 每周期 4,096 FLOPs 的 FP16 矩阵核心。与 CDNA 3 相比，CU 数量减少了 16%，LDS 容量提升了 1.5 倍，矩阵核心吞吐量提升了 2 倍。这些变化都表明架构正朝着支持更大阵列规模的 AI 工作负载方向收敛。高性能计算（HPC）工作负载通常受益于大量的 CU，而 AI 工作负载则更依赖于每个 CU 计算大型矩阵，这两种需求在功耗和面积预算上存在竞争。LDS 容量的提升表明矩阵核心的速度非常快，AMD 需要增大二级缓冲区的容量，以便为核心提供足够快的数据。鉴于 AMD 选择提升 LDS 而不是常规的中转缓冲区 VGPR（相当于 RMEM），我们推测下一代矩阵核心要想继续提升性能，可能需要进行重大的架构变革。
CDNA 4 在 FP8 上的吞吐量是 FP16 的 2 倍，在 FP4 上的吞吐量是 FP16 的 4 倍。有趣的是，CDNA 4 的 FP6 理论吞吐量与 FP4 相同，因为 FP6 和 FP4 共用一条数据通路。然而，由于实际应用中的功耗限制，FP6 的实际吞吐量仍会略低于 FP4。这与 Nvidia Blackwell 不同，后者将 FP6 的吞吐量标注为与 FP8 相同。
然而，与 Nvidia 的 Blackwell 设计相比，CDNA 4 没有异步特性、数据传输加速硬件（如 sm90/sm100 TMA）、TMA 多播或专用内存（sm100 TMEM）。这导致 CDNA4 在每单位智能的皮焦耳能效上不如 Nvidia 的 SM100。截至目前，我们仍在等待关于 ISA 的详细信息，以了解 MFMA 操作的变化，看看是否有类似 WGMMA 的功能。尽管如此，CDNA 4 也表明这些特性对于进一步提升性能是必要的，因此我们预计 CDNA-NEXT 将会有重大的架构变革。
AMD Advancing AI 开发者会议环节令人失望
今年，AMD 在 ROCM 博客上为开发者提供的内容有了很大提升。我们带着希望来到 AMD Advancing AI，期待 AMD 能在整个技术栈上举办许多开发者专场，但实际的演讲和会议安排让我们感到有些失望。大多数 AMD 库，比如 RCCL、Composable Kernels、rocSHMEM、aiter 等，都没有相关的演讲。我们希望 AMD 能在今年晚些时候的会议中，拓展演讲和研讨会的内容，让开发者能够更有针对性地深入自己感兴趣的领域。
RCCL – ROCm 集体通信库
AMD 宣布，他们全新的 400G 网卡将支持 Ultra Ethernet（UEC），同时兼容现有的 RoCEv2 协议以及全新的 Ultra Ethernet 传输（UEC）协议。在 UEC 模式下，这款网卡能够实现分组喷射，并可将乱序数据直接放入 GPU 内存，无需像 Bluefield-3 那样使用网卡重排序缓冲区。AMD 全新自研的 400G 网卡将使其更容易实现软硬件垂直整合，提升开箱即用体验，而无需依赖 Nvidia 的 CX-7 网卡或 Broadcom 的 Thor-2 网卡。Oracle 以及像 Tensorwave 这样的 AMD Neoclouds 已经承诺采用 AMD 的网卡，但 Meta 由于初步测试尚未达到预期，对采用 AMD 网卡仍持观望态度，因此将在其 MI355X 集群中使用 ConnectX-7 网卡。由于 AMD 和 Nvidia 将网卡垂直整合进自家解决方案，Broadcom 的 Thor 2 和 Thor 3 网卡在市场推广方面面临挑战。不过，我们认为 Broadcom 的网卡在各种 ASIC 项目中仍有其用武之地。
AMD 自研的 400GbE 网卡还支持许多有趣的功能，例如能够为 RING 和 PAT 等算法卸载 all-gather 集合操作。AMD 声称 CPU 代理线程也将被卸载到网卡上，但我们不确定这是否意味着他们在使用 IBGDA，还是在做其他事情。
ROCm 7.0 的 RCCL 通信库也已发布，但遗憾的是，它似乎又一次只是 Nvidia NCCL 的一个完全复制的分支，因此它仍然是限制 AMD 多节点能力的关键瓶颈。正如我们在 AMD 2.0 文章中所建议的，我们依然认为 AMD 需要彻底从零开始重写他们的通信库，而不是依赖于分支 Nvidia 的软件。
AMD 新举措按市场价支付 AI 工程师薪酬
业内众所周知，大多数 AMD AI 工程师的薪酬水平略低于市场价。唯一的例外似乎仅限于最近几个月新招聘的少数员工以及通过收购引进的工程师。例如，两年前通过收购 NodAI 引进的大多数 AI 工程师，即使在经验和技能水平相当的情况下，其薪酬也明显高于现有 AMD 工程师。有趣的是，AMD 的人力资源部门在几个季度前就已经提出了这个问题，并认识到这种薪酬差距，已在公司内部上报，但 AMD 管理层至今仍未将其提升为高优先级问题。值得一提的是，在我们公开发表文章指出 AMD 为 AI 工程师支付的薪酬远低于市场水平后，AMD 人力资源主管立即将此事提升为最高优先级，正在积极推进解决这些巨大薪酬差距的流程——但具体落实仍在进行中。 鉴于 AMD 手头拥有数十亿美元的现金，我们希望 AMD 能够做出正确的决定，为其顶尖的个人贡献者提供具有竞争力的总薪酬，并与 AMD 的成功保持一致。
MI400 系列灵活输入输出（I/O）
AMD 从 MI300X 部署的 Infinity Fabric 明显不如 NVLink 的失误中吸取了教训。他们也意识到自己没有足够的硬件人才来实现类似 NVSwitch 的产品。此外，他们也不希望通过过度垂直整合来侵蚀行业生态系统。因此，他们选择了“广撒网”的策略，支持市面上的各种方案。
引入了灵活的 I/O 通道。AMD 不再为每种不同类型的 I/O（如 PCIe 和 Scale Up）分别使用独立的 SerDes 和 I/O 通道，而是提供了 144 条可支持多种标准的 I/O 通道。这些 I/O 通道可以支持 PCIe 6.0、64G 的 Infinity Fabric、128G 的 UALink、128G 的 xGMI 4（某种程度上是 UALink 的超集），以及 212G 的基于以太网的 Infinity Fabric。这种方式让 AMD 的芯片团队在各种不同的应用场景下拥有最大的灵活性。
通过灵活的 I/O，AMD 可以部署 Scale Up 的 UALink 或基于以太网的 UALink。他们可以让 SSD 直接连接到 GPU，也可以通过 UALink 连接 NIC。可能性几乎是无限的。这为系统带来了极其丰富的组合方式，并允许系统不断变化和演进。
然而，要在芯片工程上实现这些不同形式的 I/O 并不容易。AMD 必须设计能够兼容所有这些不同组合的 SerDes 和数据通道。这是一条极其艰难的工程道路，充满了工程风险。
在接下来的章节中，我们将更深入地探讨 MI400 真正的机架级解决方案，讨论关键的扩展架构选择，并借助立面图和板卡设计示意图来解释完整的机架设计。我们还将提供详细的物料清单分解，以及总拥有成本和每 TCO 性能的分析。
