AMD 与 Cerebras 携手打造低延迟、高吞吐量 AI 推理

AMD 和 Cerebras 将两套此前从不同方向攻克 AI 推理问题的计算系统结合在一起。双方于 7 月 23 日宣布的合作，同时瞄准高吞吐量与低延迟。

Tom's Hardware 的报道介绍了一种解耦式平台：由 AMD Helios 负责提示词处理，Cerebras Wafer-Scale Engines 则承担生成 token 时的内存密集型任务。两家公司预计，与仅使用 Cerebras 的配置相比，该方案每瓦每秒可生成的 token 数量最高可提升五倍。

这一说法仍基于公司建模，而非独立的生产环境基准测试。不过，在数据获得外部验证之前，该架构本身已具重要意义。AMD 和 Cerebras 正在挑战一种既有假设：AI 请求的每个阶段都应由同一类加速器负责。

Nvidia 已通过其软硬件战略对推理任务进行拆分。此次新合作则将这种分工转化为支持混合架构的竞争论点。AMD 提供机架级算力，而 Cerebras 提供专用的解码性能。

这一结果更像是巨头之间的协作会面，而非荷马《奥德赛》中那种敌对相遇。每个巨头各自处理最适合其架构的任务。两者之间的连接能否高效运行，将决定这场联盟是否不止是一张令人印象深刻的示意图。

Tom's Hardware 的报道准确展示了改变之处

AMD 和 Cerebras 正在利用两个物理上独立的计算平台，构建一项推理服务。

两家公司于 7 月 23 日 AMD 的 Advancing AI 2026 活动期间宣布了这项技术合作。其系统将 AMD Helios 机架级基础设施与 Cerebras Wafer-Scale Engine 技术结合起来。

Cerebras 计划在自己的数据中心部署 Helios 系统。两家公司表示，首批公开访问预计将在 2026 年下半年通过 Cerebras Cloud 提供。

这一部署计划使该公告不同于一份宽泛的兼容性协议。Cerebras 将在其自有 WSE 机架旁运行 AMD 设备，并将组合后的基础设施作为服务对外提供。

该架构将大语言模型推理分为两个主要阶段。Prefill 处理用户的提示词，并创建生成所需的内部状态。Decode 则反复生成用户看到的响应 token。

这些阶段给硬件带来的压力各不相同。当提示词包含长篇文档、检索记录或大量对话历史时，Prefill 会变得计算密集。Decode 则需反复读取模型数据，因此高度依赖内存带宽和较低的通信开销。

AMD Helios 将处理 Prefill，包括具有大上下文窗口的提示词。Cerebras WSE 系统将负责 Decode 和 token 生成。一个编排层必须在这些环境之间移动每个请求及其相应的中间状态。

官方的推理合作公告将这一分工描述为避免在交互性和总体容量之间二选一的方法。AMD 提供吞吐量引擎，Cerebras 则提供低延迟生成引擎。

两家公司表示，其组合平台每瓦每秒生成的 token 数量最高可提升五倍。该比较采用了在相近交互性水平下，每千瓦每秒生成的 token 数量。

AMD Performance Labs 和 Cerebras 于 2026 年 7 月使用 Kimi 2.6 万亿参数模型对结果进行了建模。基准是仅使用 Cerebras WSE 的配置，而非竞争性的 Nvidia 系统。

这一限定很重要。五倍这一数字并不意味着相较于每一种替代方案均有五倍优势。它估算的是：当 AMD 算力加入某一特定 Cerebras 部署时，效率可提升多少。

Tom's Hardware 还指出了一个关键缺失细节。AMD 和 Cerebras 尚未说明两个平台将如何互联。它们也尚未公布完整工作流的延迟、吞吐量、利用率或可靠性测量数据。

移动键值缓存，即 KV cache，尤其重要。该缓存存储在 Prefill 期间创建的信息，以便 Decode 系统无需重复此前的计算即可继续处理请求。

当连接速度较慢时，大规模缓存传输可能会抵消专业化带来的收益。高效的路由还必须避免快速的 WSE 等待过载的 Helios 机架。

因此，该公告在性能问题得到解决之前，就已改变了竞争格局。AMD 获得了进入延迟敏感型推理领域的路径，而无需设计晶圆级处理器。Cerebras 则获得了高容量提示词引擎，而无需替换其标志性架构。

这项合作也为该设计提出了明确的交付时间。客户应能在 2026 年底前通过 Cerebras Cloud 测试这一概念。在此之前，该架构具有可信度，但其运行特性仍未经验证。

为什么 AI 推理正分裂为两类硬件问题

这项合作之所以出现，是因为提示词处理和 token 生成已不再像统一的工作负载那样运行。

一个简单的聊天机器人可能会掩盖这种区别。用户输入一个简短问题，模型进行处理，随后显示答案。两个推理阶段都足够快，以至于基础设施保持不可见。

Agentic 软件改变了这一模式。一个编程代理可能会摄取代码仓库、问题历史、工具输出和反复反馈。一个研究代理则可能在生成回复前检索大量文档。

这些应用增加了提示词长度和并发需求。它们也让响应延迟更明显，因为一个代理可能为一次用户操作执行多次模型调用。

Prefill 会并行处理所有输入 token。其需求会随着上下文长度、模型规模和请求量而上升。大型 GPU 系统适合这项工作，因为它们能够将密集型计算分配至多个加速器。

Decode 的行为则不同。模型通常会按顺序生成 token，因为每个新 token 都依赖此前的输出。仅有快速的算术运算并不能保证快速响应。

处理器必须持续访问权重和缓存状态。内存带宽、数据移动和调度的重要性可能高于峰值计算指标。较低的批处理规模可以改善响应速度，但会降低系统整体效率。

这种冲突构成了核心基础设施问题。运营商希望获得高吞吐量，因为这能降低处理大量请求所需的资源。用户则希望低延迟，因为缓慢的代理会显得缺乏响应。

解耦式推理通过创建独立的工作池来应对这一冲突。Nvidia 的服务文档描述了一个创建 KV cache 的 Prefill 引擎：它传输该缓存，并将请求传递给 Decode 引擎。

独立的工作池让运营商能够根据每个阶段实际的瓶颈进行扩展。长上下文流量可以获得更多 Prefill 容量，而无需对 Decode 进行同等扩展。高并发生成则可以获得更多 Decode 工作器。

AMD 和 Cerebras 将这一软件理念扩展到不同的处理器架构之上。Helios 使用由 EPYC CPUs 和 AMD 网络支持的传统机架级 GPU。Cerebras 则使用由几乎整片硅晶圆构成的处理器。

传统芯片制造商会将一片晶圆切割成许多独立的 die。Cerebras 则保持晶圆级计算织构的连接，从而减少由较小处理器集群之间出现的一些通信边界。

WSE 方法旨在让模型操作和内存通信贴近一大片计算表面。这使 Cerebras 成为快速 token 生成的合理候选方案，因为反复的数据移动会影响响应速度。

Helios 带来了方程式的另一半。该平台包含 72 个 Instinct MI455X GPUs、EPYC 服务器处理器、Pensando 网络，以及开放式机架设计。

AMD 列出的 Helios 机架峰值 MXFP4 性能最高为 2.9 exaFLOPS。其还列出 31 TB 的 HBM4 内存，以及约 1.67 PB/s 的聚合内存带宽。

这些数字是理论平台规格，而非应用基准测试。尽管如此，它们说明了 AMD 为何希望将 Helios 定位为高容量提示词引擎。

因此，这一联盟并没有其庞大的硬件所暗示的那般神秘。两家公司单独行动时都存在明显弱点。AMD 缺少 Cerebras 专用的晶圆级 Decode 路径，而 Cerebras 缺少 Helios 广泛的机架容量。

将两者结合有望实现更好的资源匹配。但这也会增加一个网络边界、一个编排问题和一个软件集成层。其价值取决于专业化节省的时间是否多于协调所消耗的时间。

真正的对手是 Nvidia 的一体化 AI 工厂

AMD 和 Cerebras 正在挑战 Nvidia 将推理作为一个协调统一平台销售的能力。

眼前的对手不是某一款 Nvidia GPU，而是 Nvidia 对加速器、网络、系统和推理软件的整合组合。

Nvidia Dynamo 已支持解耦式服务。它将 Prefill 和 Decode 工作器分开，传输 KV cache 状态，并通过专用基础设施路由请求。

Nvidia 可以在围绕其 GPU 和网络构建的环境中应用这一方法。尽管该架构仍包含不同的工作器角色，但客户可获得统一的软件栈和一个主要供应商。

Tom's Hardware 的报道还将这一合作与 Nvidia 早期的 CPX 概念进行了比较。该提案将专用硬件分配给上下文处理，同时由高带宽内存 GPU 负责生成。

AMD 和 Cerebras 则反转了这种专业化分工。Helios GPUs 承担提示词和大上下文阶段，Cerebras WSE 硬件承担对延迟敏感的 Decode 阶段。

自该报道以来，Nvidia 的竞争定位再次发生变化。Nvidia 现将 Groq 3 LPX 定位为 Vera Rubin 平台中的低延迟推理加速器。

Nvidia 于 2026 年完成了对 Groq 的收购，将这个曾经的专业竞争对手纳入其更广泛的基础设施战略。其 Groq 3 架构通过 Dynamo 将低延迟硬件与 Rubin GPUs 协调起来。

这使 AMD 和 Cerebras 的合作不止是一项有趣的工程安排。它构成了针对竞争对手的替代联盟；该竞争对手能够将专用推理硬件与成熟的数据中心技术栈相结合。

AMD 贡献了若干战略资产。EPYC CPUs 已在服务器领域占据相当大的份额。ROCm 为客户提供开源软件基础，而 Helios 则将加速器和网络打包为机架级蓝图。

Helios 规格包括 72 个 MI455X GPUs 和 260 TB/s 的聚合 scale-up 带宽。AMD 还围绕 OCP、UALink 和 Ultra Ethernet 标准设计了该平台。

Helios 是一项参考设计，而非 AMD 直接销售的单一机架产品。原始设备制造商和设计合作伙伴可以根据该蓝图构建系统。

这种模式可以扩大供应商选择范围，但也可能引入配置差异，使性能比较更加复杂。该合作关系提出的五倍估算指出，系统制造商可以采用不同配置。

Cerebras 也带来了自身的战略杠杆。其硬件采用独特架构，并已拥有云服务，使该合作关系能够在广泛的本地部署成熟之前先行落地。

根据公司披露，AMD 还参与了 Cerebras 2026 年的融资。这项投资使技术合作关系置于更紧密的战略关系之中。

这两项事实都不能保证客户采用。企业买家将比较可用性、模型支持、运维工具、可靠性以及整体部署复杂度。峰值性能很少能单独决定基础设施采购。

Nvidia 在软件熟悉度和部署经验方面仍保有重大优势。许多工程团队已经在使用基于 CUDA 的工具、库和运维实践。

AMD 改进了 ROCm 支持，并强调可移植性。不过，这项组合服务现在需要支持跨 AMD GPU 和 Cerebras 处理器的软件，而不再只是支持一个加速器产品家族。

这创造了另一种形式的开放性。客户获得了异构硬件以及潜在的更多供应商选择，但也要依赖两家厂商协调版本发布、调试、产能和服务承诺。

该合作关系通过验证专业化路线向 Nvidia 施压。它表明，最好的预填充引擎与最好的解码引擎不必来自同一家供应商或同一种架构。

Nvidia 对 Groq 的整合则给出了相反回应。它认为，当一家公司控制围绕专业化组件构建的平台时，专业化效果最佳。

这才是核心竞争。AMD 和 Cerebras 提供的是巨头之间的协作；Nvidia 提供的是拥有多个内部引擎的一体化巨头。

五倍能效主张存在一个网络形态的缺口

该合作关系声称的最大收益，取决于 AMD 和 Cerebras 解释最少的那条连接。

两家公司建模认为，与仅使用 WSE 的方案相比，每瓦令牌输出最高可提升五倍。但它们尚未发布包含系统拓扑、流量模式或请求级结果的完整基准测试报告。

多项指标将决定这一估算是否反映生产环境性能。首令牌时间衡量用户在输出开始前需要等待多久；令牌间延迟衡量后续令牌之间的间隔。

整体吞吐量统计跨多位用户交付的令牌数；能效则将这项工作与功耗进行比较。一个系统可能在某项指标上领先，却在另一项上落后。

比较还需要具有代表性的工作负载。长上下文编程代理对预填充的压力不同于简短的对话请求。万亿参数模型的表现也不同于并发度更高的小型模型。

官方测试使用了 Kimi 2.6 万亿参数模型。AMD 和 Cerebras 在相近的交互性水平下评估了每千瓦令牌数。

这是一个相关的大模型场景，但并不能描述所有工作负载。客户需要看到覆盖模型规模、上下文长度、批处理水平、输出长度和服务级目标的结果。

基线同样值得严格审视。两家公司将组合解决方案与仅使用 WSE 的配置进行了比较。在原本由 WSE 资源处理预填充的工作负载中，增加 Helios 容量理应带来改进。

但这并不能说明该混合平台是否优于仅使用 Helios 的系统、Nvidia 部署方案或其他解耦配置，也不能证明其在建模能效之外具有经济优势。

最重要的缺失变量是 KV 缓存移动。预填充会生成解码所需的缓存数据；在机架之间移动这些数据可能增加延迟并消耗网络容量。

Nvidia 自身的指导说明了这种敏感性。其解耦通信文档警告称，生产部署需要高速远程直接内存访问。

同一文档报告称，在一项基于 TCP 的配置中，首令牌时间相较 RDMA 出现了严重劣化。这些数据适用于 Nvidia 的测试环境，而非 AMD-Cerebras 平台。

不过，其中的工程经验可以迁移。只有在数据移动保持快速、可预测且具备拓扑感知能力时，解耦才有效。缓慢的传输可能让专业化处理器彼此等待。

AMD 的 Pensando 网络技术和开放以太网战略提供了可能的构建模块。Cerebras 也拥有在数据中心规模连接 WSE 系统的经验，但两家公司尚未公布联合互连设计。

软件编排带来了另一项风险。平台必须决定由哪些 Helios 容量处理每个提示词，以及由哪个 WSE 负责解码。

它必须移动缓存状态、恢复失败请求、平衡资源利用率并保持流式输出行为。它还必须提供统一的服务接口，避免开发者手动管理这种拆分。

模型兼容性将很重要。受支持的模型需要在两种环境中都获得优化执行。预填充和解码实现的更新必须保持同步。

量化进一步增加了复杂性。低精度格式可以降低内存使用并提升吞吐量，但两个阶段都必须保持兼容的模型行为。

然后是容量规划。预填充和解码的需求增长速度并不相同。大量长提示词可能让 Helios 饱和，而 WSE 容量则处于闲置状态。

长输出则会造成相反的不平衡。该服务需要具备足够的独立扩展能力，避免任何一个资源池变成昂贵的等候室。

可靠性也成为共同责任。当请求变慢时，运维人员必须判断原因究竟出在 Helios、互连、路由软件还是某个 WSE 系统。

因此，客户应将五倍主张视为可检验的假设。它来自设计该配置的公司，且缺乏独立验证。

这种谨慎并不意味着该架构不重要。它指出了该合作关系必须证明自身的确切位置。

这些巨型处理器已经存在，Helios 设计也已有详细的硬件规格。尚未回答的问题是，它们之间的桥梁能否像一台机器的一部分那样运行。

Cerebras Cloud 将决定这些巨头能否协同工作

接下来的三个信号将表明，这项合作关系会成为生产平台，还是停留在架构承诺。

第一个信号是 Cerebras Cloud 的首次发布。两家公司预计将在 2026 年下半年提供服务，这意味着从 7 月公告到发布之间的窗口相对较短。

一次有意义的发布应包含明确列出的支持模型、清晰的服务区域以及易于获取的性能文档，还应提供延迟和可用性的服务级目标。

有限预览仍能验证基本集成。面向广泛客户开放则能更有力地证明，编排和容量模型能够在混合流量下运行。

此次发布还应揭示开发者如何接触这一架构。最佳体验将呈现为一个端点，并在稳定接口之后隐藏硬件切换。

如果用户必须分别管理预填充和解码资源，平台的大部分价值就会重新落到工程团队身上。这将削弱单一集成工作流的主张。

第二个信号是基准测试披露。AMD 和 Cerebras 需要同时公布首令牌时间、令牌间延迟、吞吐量、功耗和利用率。

这些结果应覆盖多种上下文长度和并发水平，并在相同服务目标下比较组合平台、仅 Helios 配置和仅 WSE 配置。

独立测试比又一次公司预测更重要。买家还应关注涉及编程、检索、代理或科学应用的客户工作负载。

AMD 的 MI455X platform 提供了足够的理论容量，使预填充论点具备可信度。生产数据必须证明这些容量能否持续得到高效利用。

若基准测试确认建模中的能效收益，将强化其核心论点。若缓存传输延迟偏高或利用率不均，则表明协调成本正在吞噬这项收益。

第三个信号是 Nvidia 通过 Rubin、Groq 3 LPX 和 Dynamo 作出的回应。Nvidia 无需复制完全相同的 AMD-Cerebras 设计。

它可以以更紧密的集成、更广泛的模型支持或更好的运维工具来应对，也可以利用既有的软件基础来降低采用摩擦。

Nvidia 的强力回应将证明专业化解码已具有战略重要性。它仍可能通过让买家留在 Nvidia 平台内而在商业层面削弱该合作关系。

企业采用最终取决于的不只是基准测试胜利。采购团队将评估供应、服务覆盖、开发者工具、模型支持和故障恢复能力。

开发者应关注常用框架能否无需自定义代码就面向该组合系统。基础设施团队应审查跨两个硬件域的可观测性。

AI 产品负责人应聚焦真实工作负载下的用户侧延迟。当编程代理迭代、机器人响应或研究系统进行多次相互依赖的调用时，快速生成令牌至关重要。

知识工作者同样与这场基础设施竞赛息息相关。更快的代理能够搜索、综合和修订信息，而不会让用户陷入漫长停顿。

构建此类系统的团队仍需要可靠地访问自身的技术上下文。一个可搜索的工程知识库可以整理检索密集型提示词必须处理的文档。

Tom's Hardware 的报道指向了推理设计中更广泛的转变。数据中心正从单一通用加速器池，转向针对不同阶段优化并协调运行的引擎。

AMD 和 Cerebras 已为这一转变提出了清晰机制。Helios 承担长提示词和高请求量；WSE 系统以低延迟返回令牌。

现在，该合作关系必须公开连接方式、发布测量结果，并经受真实客户流量的考验。值得关注云服务发布、完整基准测试以及 Nvidia 的回应。

如果这些信号相互契合，异构推理将成为切实可行的采购选择。若非如此，这些巨头虽已相遇，却尚未学会如何步调一致。