打开网易新闻 查看精彩图片

AMD 有机会打破英伟达 CUDA 的护城河吗?

过去几年,这个问题的答案几乎没有悬念。虽然 AMD 能设计出性能很强的 GPU,也能提供比英伟达更大的显存。但客户购买 AI 芯片时,真正需要迁移的是整套软件:模型、框架、算子、通信系统和开发工具。CUDA 用十多年建立起的软件生态,让性能出色的 AMD GPU,始终难以成为与英伟达同样易用的 AI 计算平台。

2024 年,长期测试 AMD 产品的研究机构 SemiAnalysis 给出了一个极端判断:AMD 缩小软件差距的概率为 0。它们使用 ROCm 时遇到大量故障,一度成为 AMD 最活跃的软件缺陷提交者之一。

但两年后,SemiAnalysis 改变了判断。尽管 ROCm 仍然不如 CUDA 成熟,AMD 的软件团队却开始以更快的速度修复问题、支持新模型。Claude、Codex 等 AI Agent 也开始参与 GPU 代码的移植和优化,把过去需要工程师反复处理的工作压缩到几天,甚至一个周末。

变化从客户名单上就能看出。OpenAI、Meta 和 Anthropic 相继与 AMD 签下大规模合作,微软也决定在 Azure 部署 AMD 新一代Helios 机架。

AMD 第一次拥有了接近 CUDA 的机会。但要把这个机会变成市场份额,它还需要解决两个更具体的问题:软件能否在大型集群里稳定运行,以及 Helios 能否按时完成量产。

客户回来了

几年前讨论 AMD 与英伟达的竞争,问题通常很简单:AMD 的芯片不差,可是软件能不能用?

SemiAnalysis 曾给出一个极端判断。2024 年,在密集使用 MI300X 和 ROCm、提交大量软件缺陷后,它认为 AMD 缩小差距的概率为 0。软件经常出错,修复速度缓慢,许多问题需要数十名 AMD 工程师参与排查。

2025 年,情况开始变化了。AMD 将更多精力投入开发者支持,让软件团队直接参与 vLLM、SGLang 等开源推理框架,不再长期维护一套与主流社区脱节的分支。SemiAnalysis 因此把成功概率从 0 上调到“非零”。

一年后,它再次改变判断:只要解决 Helios 量产和内部测试集群不足两个问题,AMD 已经拥有“很大的成功机会”。

市场给出的信号更直接。OpenAI 在 2025 年 10 月与 AMD 签署最高 6 GW 的多年协议,首个 1 GW 计划于 2026 年下半年部署。Meta 在 2026 年 2 月公布另一份最高 6 GW 的协议,首批设备同样计划在下半年开始交付。加上 Anthropic 的 2 GW,三家公司规划规模的上限达到 14 GW。

这些不是立即兑现的收入。协议横跨多个产品世代,实际采购取决于 AMD 能否按时交付芯片、机架和可用的软件。OpenAI 的首个 1 GW 还设置了多个技术和商业节点,未达到条件时可以退出。

但订单还是改变了 AMD 在 AI 芯片市场中的位置。此前,MI300X 主要依靠较低价格和更大显存进入部分推理集群;MI455X 面对的则是 OpenAI、Meta 和Anthropic 的核心模型负载。客户不再只购买一张替代卡,而是要求 AMD 提供从 GPU、CPU、网络到软件的完整系统。

最明显的转变来自微软。SemiAnalysis 称,微软在 MI300X 部署中遇到内存可靠性和软件质量问题,此后跳过了 MI325X、MI355X。AMD 和微软没有公开解释中间两代产品未获大规模采用的原因。

2026 年 7 月,微软宣布将在Azure 大规模部署 Helios。AMD 预计从下半年开始向包括微软在内的客户发货。这次回归带有更高要求。微软购买的已经不只是 AMD 芯片,也包括 AMD 第一次真正承担起来的系统能力。

72 颗 GPU,和一座难造的机架

MI455X 仍然体现了 AMD 最熟悉的一面:用激进的芯粒设计和先进封装,把尽可能多的计算与内存装进一颗 GPU。

每颗 MI455X 配备 432 GB HBM4,内存带宽为 23.3 TB/s。同期 NVIDIA Rubin GPU 配备 288 GB HBM4,带宽为 22 TB/s。更大的显存可以容纳更多模型权重和 KV Cache,降低长上下文推理对跨节点通信的依赖。

图丨AMD MI455 芯片与 Helios 机架(来源:AMD)
打开网易新闻 查看精彩图片
图丨AMD MI455 芯片与 Helios 机架(来源:AMD)

72 颗 MI455X 被装进一座Helios 机架后,可以提供约 31 TB HBM4 内存和1.4 EFLOPS 峰值 FP8 算力。18 个计算托盘各安装 4 颗 GPU 和 1 颗 Venice CPU,6 个交换托盘负责把 72 颗 GPU 连成一个计算域。

从芯片推进到整座机架,AMD 开始进入自己并不熟悉的区域。

英伟达可以围绕 NVLink 自行设计 GPU、交换芯片和机架。AMD 选择了一条更开放的路线:Helios 使用基于以太网的 UALoE 连接 GPU,并采用Broadcom Tomahawk 6 交换芯片。客户未来可以选择不同服务器和网络厂商,不必进入一套完全封闭的互连体系。

开放减少了供应商锁定,也增加了系统协调的难度。AMD 必须让自己的 GPU、Broadcom的交换芯片、第三方连接器、铜缆背板和整机厂商共同完成量产。任何一段链路出现信号或装配问题,都会拖慢整柜交付。

SemiAnalysis 根据供应链调查判断,Helios 当前正在经历缓慢的生产爬坡。MI455X 的高速信号难以完整穿过 GPU 与交换芯片之间的铜缆路径,部分配置约 85% 的扩展连接需要加入重定时器。一座机架可能安装超过 550 颗 Broadcom 以太网重定时器,交换托盘一侧还要布置约 1728 根飞线。

图丨机架侧视图(来源:SemiAnalysis)
打开网易新闻 查看精彩图片
图丨机架侧视图(来源:SemiAnalysis)

这些数字尚未得到 AMD 确认。它们所展现的问题很现实:数百个重定时器需要调校,上千根线缆要同液冷管和电源线一起装进有限空间,每个连接点都可能影响良率和维修效率。

之前英伟达已经吃过类似的苦头,GB200、GB300 机架使用大量飞线,给装配和维护带来压力。到了 Vera Rubin,英伟达转向无缆化机架设计。AMD 的 MI455X 定型更早,已经来不及跟进这一改动。

Helios 计划在 2026 年下半年开始交付,恰好与 OpenAI、Meta 和微软首批部署的时间重叠。AMD 需要一边解决生产问题,一边向最重要的客户证明,这套第一次进入大规模量产的机架可以稳定运行。

AI 开始替 AMD 追赶软件

与硬件相比,ROCm 的变化更快,也更容易被忽略。2026 年 2 月,vLLM 在一篇官方技术文章中写道,AMD 支持已经走过“只求移植成功”的阶段。vLLM 当时为 ROCm 提供了 7 种注意力后端,AITER 与 vLLM 的联合优化可在部分负载上带来 1.2—4.4 倍的吞吐提升。

更重要的变化发生在新模型发布后。过去,一个新模型首先在 CUDA 上运行。AMD 团队往往要花几个月补齐内核、量化、通信和框架支持。等 ROCm 版本可以稳定部署,模型热度和推理架构已经继续向前。

在 DeepSeek V4 发布后的 47 天里,AMD 团队连续优化 KV Cache、并行调度、量化和融合算子,MI355X 的推理表现迅速改善。MiniMax M3 发布时,AMD 已经能够更早提供单机和分布式配置。两次适配之间的时间差,显示 AMD 的软件开发速度正在提高。

AI 编程 Agent 又进一步压缩了周期。

SemiAnalysis 团队描述了一套实际使用的流程:新模型发布后,让 Claude Code 或 Codex 自动获取公开配方,在真实 GPU 上部署测试,监控报错并定位上游代码。遇到简单问题,Agent 可以直接修改 vLLM 或SGLang、重新运行测试;复杂问题再交给人类工程师。

一个规模很小的团队由此可以同时测试多个模型、框架和 GPU。过去依赖大量 CUDA 工程师完成的移植工作,开始被拆成可以并行执行的 Agent 任务。

AMD 将这套思路做成了 ROCm.AI。Claude、Codex、Cursor 和 Gemini 可以通过 AMD 提供的Skills 理解 ROCm;Hyperloom 负责分析工作负载、寻找性能瓶颈,再调用不同 Agent 优化内核和并行策略。

这条路线对 AMD 很有吸引力,CUDA 最深的优势来自多年积累的代码、工具和工程经验。Agent 擅长阅读和修改公开代码,ROCm 又有大量组件开源。代码越开放,Agent 可获得的上下文越完整;软件追赶者由此获得了以前没有的杠杆。

问题随即转移到测试,Agent 可以在几分钟内生成一个新内核,却无法仅凭代码判断它在数十种模型、量化格式和并行组合下是否可靠。它有时还会修改测试文件、调用已有高性能库,制造一个看上去更快的结果。AMD 必须增加防作弊检查,并让每次代码修改都在真实 GPU 上运行。这需要大量稳定的开发集群。

SemiAnalysis 称,AMD 内部软件团队长期缺少固定的 GPU 资源。单机推理还能获得足够硬件,多节点开发和持续集成经常因为集群迁移、故障或临时调配而中断。Advancing AI 2026 前几周,AMD 原本希望把 vLLM 的关键合并测试做到 CUDA 的 90%,部分集群却被调往其他项目,进度随之倒退。

AMD 计划在 2026 年 7 月增加约 2,000 颗 MI355X,年内再增加约 6,000 颗 MI325X 和MI355X。SemiAnalysis 判断,这一规模仍比英伟达用于内部长期开发的稳定集群低一个数量级以上。

Agent 没有降低 AMD 对 GPU的需求,反而把需求放大了。一名工程师可以同时启动十几个 Agent,每个 Agent 都要在真实硬件上测试代码。写软件的速度提高后,测试软件的机器不够用了。

CUDA 的护城河正在向前移动

AMD 还面临另一个问题:它在追赶的目标一直变化。曾经,单机推理优化是主要战场。现在,前沿模型越来越依赖混合专家架构、长上下文和分布式推理。计算密集的提示词预填充与内存密集的逐词解码会被放到不同服务器;数百个专家分散在更多 GPU 上;KV Cache 要通过高速网络在节点间移动。

一套推理系统能否工作,取决于内核、通信、路由、调度、缓存和网络能否同时配合。单独优化其中一项,价值越来越有限。

AMD 已经做出一些关键组件。MoRI 负责专家通信和 KV Cache 传输,ATOMesh 处理预填充与解码之间的路由,AITER 提供高性能内核。MI355X 也已经在部分模型上跑通多节点分离式推理。

但当各个组件组合起来时,稳定性仍然不足。SemiAnalysis 的测试中,部分配置会在特定并发量下出现精度下降;某些WideEP 配置需要关闭 HIP Graph;换一个模型、量化格式或网络拓扑,还要增加新的例外处理。AMD 已经可以做出效果很好的演示,距离客户无需特殊照料即可部署仍有一段路。

MI455X 又增加了工作量,它的指令和执行方式与 MI355X 差异较大,许多内核需要重写。公开代码已经加入基础支持,覆盖完整的 MI455X 自动化测试、WideEP 和高价值内核仍在开发。

与此同时,英伟达正通过 Dynamo 把路由、解耦式推理、KV Cache 卸载和集群调度整合起来,并在 Vera Rubin 系统中加入 Groq 3 LPX,让不同芯片分别承担高吞吐和低延迟任务。

AMD 与 Cerebras 在发布会上宣布了相近的合作:Helios 处理提示词和高吞吐负载,Cerebras 晶圆级引擎负责低延迟生成。双方预计在 2026 年下半年通过 Cerebras Cloud 提供服务。

这说明 AMD 已经看到了新的竞争方向。它刚开始缩小 CUDA 的软件差距,护城河已经从“代码能否运行”移动到“整套分布式系统能否稳定运行”。

用股权换客户一起修路。

为了让头部客户更早进入这套仍在完善的系统,AMD 提供了很难拒绝的条件。

AMD 分别向 OpenAI 和Meta 发放了最多 1.6 亿股普通股认股权证,行权价为每股 0.01 美元。权证按照 GPU 采购和部署规模分批归属,还要满足 AMD 股价、技术交付和商业条件。OpenAI 权证的最终股价门槛达到每股 600 美元。

SemiAnalysis 将其理解为一种股权返利。在 AMD 股价达到 600 美元、客户完成全部采购并满足其他条件的极端情景下,OpenAI 获得的股权价值可能覆盖其购买 GPU 的全部成本,等效折扣约为 105%;Meta 的等效折扣约为 85%。

这不是 AMD 已经支付的现金折扣。截至 2026 年 3 月底,两份权证都没有归属,最终价值可能远低于这一测算。它仍然表明 AMD 愿意为生态入口支付多高的价格。

对 AMD 来说,OpenAI、Meta 和 Anthropic 不只是客户。它们拥有最新模型、最大的推理负载和一批最了解 AI 系统的工程师。让这些公司使用 Instinct,意味着真实工作负载会更早暴露 ROCm 的问题,客户也会参与修复软件、调整网络和定义下一代硬件。

AMD 无需立刻复制整个 CUDA 生态。只要少数前沿模型公司愿意使用 Helios,它就能获得足够多的负载、代码和工程反馈,逐步缩短差距。更低的总体成本、更大的内存和股权激励,都是把第一批客户拉进来的办法。

Tom Brown 可以让 Claude 用一个周末完成软件适配。Helios 生产线上,却没有一条“/goal”指令能够自动接好 1728 根线缆、调通数百颗重定时器,或者补出一座稳定的测试集群。

AMD 能否撬动 CUDA,最终可能不取决于下一个写得更快的内核,而取决于第一批 Helios 能否按时离开工厂。

参考资料:

https://newsletter.semianalysis.com/p/can-amd-break-the-cuda-moat-amd-advancing?_gl=1*vjtsjw*_gcl_au*MTE5OTIxNDI5Ni4xNzgzNjQyMDI0*_ga*MTM0NTYwNzgwOC4xNzgzNjQxOTY0*_ga_FKWNM9FBZ3*czE3ODUwMjM5MDAkbzUkZzAkdDE3ODUwMjM5MDAkajYwJGwwJGgxMjc2NTY2Mzc3