AMD 与 Google 的合作将 Meta 的 AI 伙伴关系推向 Nvidia 的考验

尽管 Nvidia 依然牢牢掌控着用于构建 AI 模型的软件，AMD 已将 2024 年的一场合作伙伴展示活动，发展为 2026 年的基础设施攻势。AMD 与 Google 的关系提供了云端可信度，而 Meta 则承诺投入工作负载、工程支持，以及最高六吉瓦的计划 GPU 容量。

这一组合的重要性超过又一次基准测试胜利。AMD 正要求主要模型开发商和云服务提供商协助优化整个计算栈，从芯片和网络到框架及模型代码。该战略直指 Nvidia 历来优势最强的领域：开发者早已熟悉的一体化平台。

最初的公告将 Meta、Google Cloud、Microsoft、Oracle 和多家 AI 开发商纳入 AMD 的硬件与 ROCm 软件生态。相关合作并未立即消除迁移成本，也没有建立广泛的性能对等。不过，Meta 和其他模型开发商后续作出的承诺表明，这项工作已超越一日的产品发布活动。

AMD 及其合作伙伴究竟改变了什么

AMD 的关键举措，是向那些其工作负载能够塑造硬件和软件的客户开放产品路线图。

在 2024 年 10 月的 Advancing AI 活动上，AMD 推出了 Instinct MI325X 加速器、第五代 EPYC 服务器处理器、新网络组件以及 Ryzen AI 企业级芯片。该公司还介绍了 ROCm 的持续开发工作；ROCm 是其用于编程 AMD GPU 的开源软件平台。

合作伙伴披露的信息为这次硬件发布提供了实际背景。根据 AMD 的 AI 产品发布公告，Meta 当时正使用 MI300X 加速器为其 Llama 3.1 405B 模型的全部实时流量提供服务。AMD 还表示，超过一百万个模型可在其平台上运行，无需单独进行移植工作。

Meta 的角色不止于采购芯片。双方正围绕芯片、完整系统、网络、软件和应用优化性能。这一范围至关重要，因为一颗高速处理器无法挽救受限于内存数据传输、互连拥塞或软件内核不成熟的集群。

Google 扮演了不同角色。它重点介绍了 Google Cloud 基础设施中的 AMD EPYC 处理器，包括与其 AI Hypercomputer 架构相关的工作负载。Google 还计划推出基于 AMD 更新一代 EPYC 9005 处理器的云虚拟机。

这并不意味着 Google 已用 AMD GPU 替代自身的张量处理单元，即 TPU。Google 为特定内部及云端 AI 工作负载设计 TPU。它还运营着一个多元化的云平台，客户期待获得多种处理器架构选择。

因此，AMD 与 Google 的关系代表的是基础设施选择，而非排他性联盟。Google 可以提供由 AMD 驱动的计算能力，同时继续开发 TPU、基于 Arm 的 Axion 处理器，以及围绕 Nvidia 加速器构建的服务。

Microsoft 和 Oracle 则提供了更多客户需求的证据。Microsoft 介绍了 MI300X 在 Azure 和 GPT 工作负载中的应用，而 Oracle 则讨论了其云平台内的 AMD CPU、GPU 和网络产品。

Databricks 提供了较为具体的性能说法之一。据称，其测试显示，使用 MI300X 硬件运行 Llama 和专有模型时，性能提升超过 50%。该数字来自 AMD 强调的一项合作伙伴测试，因此不应被视为普遍结果。

核心变化不只是汇集了一系列背书。AMD 正与在生产环境中运营大型模型的公司建立反馈闭环。这些公司能够识别瓶颈、影响产品设计，并贡献日后用户也能受益的优化成果。

此后，这一做法变得更加具体。AMD 在 2025 年表示，十大模型开发商和 AI 公司中有七家正在 Instinct 加速器上运行生产工作负载。Meta 则报告称，MI300X 已在 Llama 3 和 Llama 4 推理中获得更广泛部署。

这些合作现已跨越连续几代硬件。这种连续性将战略部署与在加速器供应紧张时期进行的临时试验区分开来。

AMD 与 Google 的基础设施为何此刻重要

AMD 与 Google 的联系之所以重要，是因为可信的竞争不仅需要更快的芯片，还需要分发渠道、开发者可及性和可复制的云端运营能力。

自 2024 年活动以来，Google Cloud 持续扩展其 AMD CPU 产品组合。其 C4D 虚拟机将第五代 EPYC 处理器与 Google 的 Titanium 基础设施相结合，后者可将部分网络、存储和管理任务从主机 CPU 卸载。

Google 表示，与上一代基于 AMD 的产品相比，其网页服务吞吐量最高提升 80%，通用计算性能提升 30%。其 C4D 性能结果还提到，本地存储延迟最高降低 35%。

这些并非生成式 AI 训练的直接测量结果。不过，AI 系统依赖的不只是加速器。数据准备、检索服务、数据库、调度和应用服务器都会消耗常规 CPU 容量。

一款 AI 应用可能在 GPU 上生成答案，同时使用 CPU 来验证用户身份、检索文档、筛选结果并路由请求。即使模型本身保持不变，改善这些外围任务也能提高系统吞吐量。

AMD 与 Google 的合作还扩大了工程团队接触 AMD 硬件的场景。熟悉度很重要，因为当开发者无法获得测试和优化所需的访问权限时，公司会犹豫是否引入第二个加速器平台。

云端可用性降低了这一门槛。团队可在作出更大规模基础设施承诺前，对工作负载进行性能分析、验证库支持并比较运行表现。它们也可以在熟悉的云上保留 CPU 工作负载，同时在其他环境评估不同的加速器。

随着推理在 AI 计算中占据更大份额，AMD 的机会也随之扩大。推理是指运行已训练模型，以产生答案、分类结果、图像或其他输出的过程。与有限次数的训练不同，推理成本会随每一次用户交互反复产生。

这种持续性成本让模型运营商有理由为特定工作负载优化硬件。通用加速器提供了灵活性，但可能包含某项定义明确的生产任务并不需要的内存或计算资源。

Meta 的推荐系统说明了这一点。它们以极大规模运行，并采用相对稳定的工作负载模式。针对这些模式定制的处理器，可以优先考虑成本、能耗或延迟，而非前沿模型研究所要求的广泛能力。

Google 面临相同的经济逻辑，尽管它部分通过自研 TPU 来应对这一问题。它愿意部署 AMD CPU，表明超大规模云服务商无需在每一层都采用单一处理器架构。

因此，AMD 与 Google 的关系是迈向异构计算这一更广泛转变的一部分。在这类系统中，运营商会将每项工作负载分配给最合适的处理器、加速器或定制芯片。

这一转变会对 Nvidia 形成压力，而无需客户放弃 Nvidia。云服务提供商可以继续提供 Nvidia 系统，同时为特定任务增加 AMD 或内部设计的硬件。即使只是部分多元化，也能增强议价能力并降低对单一路线图的依赖。

对开发者而言，实际问题在于工作负载是否仍具可移植性。若一个模型只有经过大量供应商特定的重写后才能良好运行，其切换成本可能超过有利的硬件基准表现。

ROCm 是 AMD 对这一问题的回应。它的价值取决于框架兼容性、文档、调试工具、优化库，以及对新发布模型的及时支持。当生产团队无法复现既有软件行为时，硬件可用性意义不大。

Meta 将合作讨论转化为六吉瓦测试

Meta 已将 AMD 的生态系统论点转化为一项具有可衡量里程碑和实质执行风险的部署测试。

2026 年 2 月，AMD 与 Meta 宣布了一项多年协议，涵盖最高六吉瓦的 AMD Instinct GPU 部署。吉瓦描述的是电力容量，而非固定数量的加速器，因为系统配置和功耗要求可能有所不同。

首个一吉瓦计划于 2026 年下半年开始出货。它将采用基于 MI450 架构的定制加速器、第六代 EPYC 处理器、ROCm 软件以及 AMD 的 Helios 机架级设计。

机架级系统将整个服务器机架视为一个集成计算单元。加速器、CPU、内存、网络、散热和软件必须协同工作，才能提供有用的模型性能。

AMD 表示，Helios 是通过 Open Compute Project 与 Meta 联合开发的。Meta 的 Open Rack Wide 规范影响了其物理设计，使 AMD 得以进入围绕 Meta 运营要求组织的基础设施体系。

这项 Meta 部署协议还协调了双方的芯片、系统和软件路线图。这一表述显示，双方的协同程度深于产品量产后购买标准加速器卡。

Meta 将成为 AMD Venice 和 Verano 服务器处理器的首批客户。预计 Verano 将包含围绕性能、能耗和运营成本设计的特定工作负载改动。

该协议包含一项基于业绩的认股权证，覆盖最高 1.6 亿股 AMD 股票。归属取决于出货量、AMD 股价门槛以及技术和商业条件。AMD 的第一季度文件称，截至 2026 年 3 月 28 日，这些股份尚无任何一股归属。

这些条件之所以重要，是因为标题中的容量不等于已完成部署。AMD 必须制造产品、组装系统、支持软件并满足 Meta 的要求。随后，Meta 必须安装这些容量，并将具有实际意义的工作负载导向其中。

这项交易也展示了 AMD 为何需要模型开发商参与。Meta 了解 Llama 推理、广告系统、排序模型及其不断扩展的 AI 助手在运营层面的特征。这些工作负载知识能够影响内存容量、互连设计和软件优先级。

AMD 获得了一位要求严苛的参考客户。Meta 获得了替代供应商，以及一个针对特定任务定制的平台。双方都在一个仍受 Nvidia 塑造的加速器市场中获得了更多筹码。

这一安排并不意味着 Meta 将全面迁移。Meta 同样已对 Nvidia 作出重大承诺，并持续开发自己的 Meta Training and Inference Accelerator，即 MTIA。

这种组合是合理的。前沿训练、推荐推理和通用 AI 服务并不具有相同的要求。Meta 可以在部分工作负载上使用 Nvidia，在其他工作负载上使用定制 AMD 产品，并在内部芯片具备合适经济性时采用 MTIA。

因此，主要竞争并非 AMD 与 Nvidia 争夺每一项 AI 任务，而是一体化的 Nvidia 默认选择与围绕特定工作负载构建的多供应商计算战略之间的竞争。

这项六吉瓦计划将检验这种替代方案在生产规模下是否仍具可控性。运行两套加速器平台会提高验证、可观测性、人员配置和软件维护方面的要求。

Meta 比一般企业更能承受这种复杂性。如果其优化成果回流到 ROCm 和通用框架中，较小规模的用户也能受益；如果这些成果始终高度定制化，这项协议对 AMD 更广泛可用性的说明就会有限。

其核心机制是软硬件协同设计

当客户共同优化模型和系统时，AMD 可以缩小性能差距；但要改变市场格局，协同设计必须产出可复用的软件。

模型性能并不只取决于芯片的标称规格。运营方还必须协调模型架构、数值精度、内存布局、通信库、编译器行为和调度策略。

数值精度决定了用多少比特来表示模型权重和中间值。在模型仍能保持可接受输出质量的前提下，较低精度可以减少内存占用并提高吞吐量。

内存布局同样重要。大型模型会在高带宽内存、加速器和网络链路之间持续移动权重与临时数据。如果这些传输无法让计算单元持续保持忙碌，处理器就可能处于空闲状态。

软件内核执行矩阵乘法、注意力机制和数据转换等单项操作。供应商会针对特定硬件和模型形状优化这些内核。细微的改进可在数十亿次重复操作中累积放大。

Nvidia 通过将硬件与 CUDA、优化库、开发者工具及长期框架支持结合起来，建立了自身优势。多年来，各类组织已积累了 CUDA 代码、专业经验和故障排查实践。

ROCm 采用开源模式，并支持 PyTorch 等广泛使用的框架。开放性可以帮助开发者检查代码、贡献改动，并避免依赖单一专有编程层。

开源代码并不会自动带来成熟的运营能力。团队仍需要稳定版本、可预测的安装流程、完整的功能覆盖、清晰的诊断能力，以及在多样化工作负载下的性能表现。

AMD 与模型构建者的合作伙伴关系直接瞄准了这些缺口。Meta 带来了 PyTorch、Triton 和大规模推理经验；Microsoft 和 Oracle 带来了云端部署知识；独立开发者则可以优化 vLLM 和 SGLang 等引擎。

AMD 在其 2025 年平台更新中报告了 ROCm 7 的改进、更广的兼容性和新的开发工具。该公司还表示，MI350 一代相较 MI300X 实现了显著提升，不过供应商间的比较高度依赖模型、批量大小、精度和系统配置。

参与独立基准测试提供了更好的审视路径。MLPerf 会按照既定工作负载和规则发布提交结果，帮助买家比较系统，而不必仅依赖产品发布演示。

MLPerf 结果数据库收录了 AMD Instinct 的提交结果，以及采用 Nvidia 和其他加速器的系统。结果仍需谨慎解读，因为硬件数量、软件版本、延迟约束和基准测试分组可能不同。

某一类别中的胜出结果并不能证明在所有场景中的领先地位。但它能够显示供应商是否可以按通用规则提交可运行的系统，并披露足够的配置细节以供知情比较。

Google 为这一机制增添了另一重维度。其云服务采用 AMD EPYC 处理器，同时 Google 也在开发 TPU 及自有配套软件。这种共存表明，基础设施公司可以在多个层面进行优化，而无需在所有领域只选择一家供应商。

AMD 与 Google 的关系并不能直接解决 ROCm 的采用问题。但它使大型云服务内部的架构多样性更趋常态，并为 AMD 技术在 AI 相邻工作负载中的应用创造机会。

Meta 提供了更有力的加速器验证案例。通过在 MI300X 上承载 Llama 流量，并共同设计基于 MI450 的系统，它为 AMD 提供了合成基准测试无法带来的真实生产反馈。

决定性问题在于，AMD 能否将这些客户特定的经验转化为默认能力。模型发布当日支持——即模型发布时即可用的支持——将是一个指标。

文档质量将是另一个指标。开发者会在安装失败、内存错误、不受支持的算子和性能回退时评判平台。一个平台必须让这些故障易于理解且能够修复。

当协同设计能够缩短从新模型到可靠生产服务的路径时，它才真正有效；如果每次部署都需要芯片供应商派出专门团队重建软件栈，它就没有达到目标。

AMD 的合作伙伴叙事尚未证明什么

大型客户承诺验证了需求，但尚未证明广泛的软件能力对等、大规模交付能力或更优的经济性。

AMD 的公告包含多层由公司自行报告的性能数据。关于吞吐量、能效和代际提升的说法，往往依赖经过选择的配置。买家应在对自己真正重要的延迟和质量要求下比较自身模型。

推理性能对批量大小尤其敏感。一个系统可以通过将大量请求合并处理来报告很高的总吞吐量，但对交互式助手而言，其延迟可能无法接受。

模型长度也会改变结果。长上下文会消耗更多内存并增加注意力计算量。适合处理短推荐内容的平台，在处理长文档或延长的智能体会话时可能表现不同。

系统利用率同样影响经济性。一个在满负载下看似高效的加速器，在需求不均衡时可能成本高昂。运营方必须计入闲置容量、网络、电力供应、冷却和工程人力。

这项六吉瓦 Meta 计划带来了制造风险。AMD 依赖外部代工厂和供应商提供先进芯片、封装、内存及其他组件。任何一层的瓶颈都可能拖慢完整系统的交付。

Helios 增加了集成风险，因为机架级产品需要协调 CPU、GPU、网络接口卡、交换机、软件和冷却系统。验证单个组件并不能保证集群运行稳定。

AMD 在其 2025 年年报中表示，MI400 和 Helios 的量产出货仍按计划将在 2026 年下半年进行。这是一项重要的时间表声明，而不是对首个计划吉瓦已投入运行的确认。

Meta 的定制加速器带来了另一项不确定性。针对已知工作负载进行定制，可以通过移除不必要的能力，或调整计算、内存和网络之间的平衡来提高效率。

同样的专用化也可能限制灵活性。如果 Meta 改变其模型或服务架构，经过狭义调优的加速器可能比通用系统提供更少选择。最终权衡将取决于尚未披露的规格和真实工作负载行为。

Nvidia 也在持续改进其硬件、网络、推理软件和机架级系统。AMD 面对的是一个持续演进的平台，而不是 MI300X 发布时已有的产品。

Google 的战略从另一方向施加压力。TPU 为 Google 的 Gemini 和部分云客户提供了垂直整合的替代方案。Amazon 也在开发 Trainium 和 Inferentia 加速器，而 Microsoft 已推出内部 AI 芯片。

这些定制平台意味着，AMD 正在争夺超大规模云服务商更愿意从外部采购的那部分 AI 算力。其可触达市场可以快速增长，但每项工作负载仍将面临更激烈的竞争。

“AMD Google”这一关键词也可能引出不准确的结论。Google 使用 EPYC 处理器，并不能证明 Google 为 Gemini 大规模采用 Instinct GPU。已得到验证的关系主要围绕云 CPU 和更广泛的基础设施合作。

同样，Meta 的采用也不能证明普通公司可以毫无摩擦地从 CUDA 切换到 ROCm。Meta 拥有工程资源、对自身模型的控制权，以及直接接触 AMD 路线图的渠道。

更有力的解读应当更为克制。AMD 已赢得足够信任，使大型客户愿意将生产工作负载和未来产能部署在其技术之上。现在，它必须将定制化合作转化为其他开发者能够可靠使用的平台。

这一差异应当指导企业评估。买家需要进行工作负载级测试、核算总运营成本、获得软件支持承诺，并制定可信的迁移计划。他们不应将合作伙伴标识视为技术验证的替代品。

三个信号将决定 AMD 能否向 Nvidia 施压

出货量、可移植的模型性能，以及可重复的第三方部署，将决定 AMD 的联盟是否能改变竞争平衡。

第一个信号是 Meta 首批基于 MI450 的部署。AMD 计划在 2026 年下半年开始支持首个吉瓦的出货。已安装产能、生产工作负载和里程碑完成情况的证据，将加强协同设计能够达到实体规模的论据。

延迟的影响不会局限于一位客户。Helios 是 AMD 预计承载其机架级雄心的平台，因此问题可能影响后续部署，以及整个合作伙伴网络对其的信心。

第二个信号是私有客户项目之外的模型支持。开发者应关注 ROCm 对新版 Llama、与 Claude 和 Gemini 相关的开放模型，以及其他广泛采用版本的支持速度。

有用的支持不只是启动一个容器。团队还需要有竞争力的延迟、可预测的输出质量、稳定的多 GPU 行为和持续维护的库。公开基准测试提交应说明每项结果背后的硬件与软件配置。

AMD 在 2026 年 7 月通过一项协议扩展了这一战略：Anthropic 将部署最多两吉瓦的 MI450 Series GPU。两家公司还计划在旨在改进 AMD 工作负载和 ROCm 开发的工作中使用 Claude。

这项协议带来了新的检验。如果 Meta、Anthropic 和开源开发者产出的优化成果汇聚到公开软件中，AMD 平台将更容易采用；如果每位客户都需要单独的分支，规模化仍将代价高昂。

第三个信号是没有超大规模云服务商级工程团队的组织能否实现可重复使用。Oracle、云服务商、系统制造商和软件公司可以揭示 Helios 与 ROCm 是否作为产品运行，而非定制集成项目。

最有说服力的证据将包括持续的生产流量、公开的运营细节和独立测量。额外的产能公告只能反映需求，无法证明易用性。

Google Cloud 不断扩展的 AMD CPU 产品线在这里仍然相关。AMD 与 Google 的关系让客户能够成熟地使用基于 EPYC 的系统，并展现出对 AMD 服务器路线图的持续信心。它也提醒人们，云基础设施正日益在设计上采用多供应商模式。

对于开发者和企业买家，眼下应采取的行动是测试具有代表性的工作负载，而不是抽象地争论供应商主张。应在不同平台上使用相同的模型、数据类型、上下文长度、延迟目标和故障条件。

团队还应保留每项决策背后的证据。随着平台不断演进，一个可搜索的工程知识库可以关联基准测试结果、部署说明、模型变更和供应商文档。

AMD、Google 和 Meta 的故事归根结底在于：模型开发者能否通过联合工程打造出一条可行的第二路径。值得关注的是 Meta 的首次部署、ROCm 模型的公开就绪情况，以及普通客户的实际部署。如果这三方面都取得进展，Nvidia 将面临一个持久的平台级竞争对手；若其中任何一项停滞，AMD 的合作伙伴关系仍将重要，但并不完整。