AMD Helion Agentic AI 机架以开放路线实现规模扩展
AMD 推出了 AMD Helion agentic AI 机架，为基础设施竞赛给出了不同答案：并非每项 AI 任务都适合交给 GPU。该公司的新蓝图可在单个机架中部署多达 32,768 个 CPU 核心。另一种配置则将 CPU 与 GPU 结合，面向希望在同一系统中运行智能体执行与模型推理的企业。
这一差异很重要，因为 AI 智能体的工作不只是生成 token。它们还会检索记录、调用工具、运行代码、查询数据库、管理状态并协调工作流。模型推理依然重要，但它只是这条链路中的一个环节。AMD 押注于高密度、可配置的 CPU 容量值得拥有独立的机架级架构。
与 Nvidia 的对比不可避免。Nvidia 的 Vera Rubin 平台将 CPU、GPU、网络、存储和软件整合进高度协同的 AI 工厂。相比之下，Helion 更强调开放标准和针对工作负载的组件。当智能体部署走向生产环境时，核心问题在于：客户会更偏好 AMD 的模块化方案，还是 Nvidia 的集成方案。
AMD Helion Agentic AI 机架将执行与推理解耦
Helion 将围绕 AI 模型展开的工作，视为一项一等基础设施问题。
AMD 于 2026 年 10 月 12 日发布 Helion，并将其描述为面向 agentic AI 的开放机架蓝图。该设计采用 Open Compute Project 标准，以及 AMD 的处理器、加速器、网络和软件。生态合作伙伴正基于该规范开发系统，计划于 2026 年 11 月推出。
AMD Helion 公告介绍了两种主要配置。纯 CPU 版本面向超大规模云厂商、neocloud 和主权 AI 运营商。企业版本则在一个机架中整合 CPU、GPU、存储、数据库和技术计算节点。
纯 CPU 配置最多可搭载来自第六代 AMD EPYC 9006 Series 处理器的 32,768 个核心。AMD 将这些核心定位为用于执行智能体的算力，而非承载最大的模型。该机架可连接负责模型推理的独立加速器系统。
这种解耦式设计将不同类型的工作部署在专用基础设施上。解耦意味着将执行与推理放在不同系统中，而不是将其视为不可分割的单一计算模块。大型运营商可以将 Helion CPU 机架与现有 GPU 集群配对，包括 AMD Helios 系统。
AMD 的企业配置则采取另一条路线。它将 EPYC CPU 刀片与最多 16 块 AMD Instinct MI350P GPU 混合部署。这些加速器位于两台独立的八 GPU 服务器中，而不是处于一个覆盖整个机架的纵向扩展域中。
这一差异明确了产品预期。Helion 不是前沿训练集群的替代品。它旨在运行智能体、路由请求、服务特定模型，并支持这些智能体所使用的数据库。
该机架还可包含用于存储、数据服务和技术计算的通用刀片。这些支持系统很重要，因为生产环境中的智能体很少仅通过模型调用来运作。它必须读取权限、维护记忆、搜索企业数据并记录操作。
AMD 列出的该设计网络带宽最高可达每秒 102 太比特。客户可根据配置选择风冷或直接液冷。物理系统采用配备 44 个 Open Rack 单元的 21 英寸 ORv3 机架。
Helion 还集成了 token 路由器。token 路由器会将模型请求导向合适的推理端点。该端点可能是云端的前沿模型，也可能是机架内运行的开放模型。
该路由器将 AMD 的模块化主张扩展至软件层面。企业可以将昂贵模型留给复杂请求，同时将可预测的工作发送至本地模型。这一概念颇具吸引力，但 AMD 尚未公布能够展示该路由器在成本、延迟或质量方面影响的生产基准测试结果。
因此，Helion 改变了竞争单位。AMD 并非在推出另一款独立的服务器处理器或加速器，而是在围绕智能体任务的完整生命周期组织 CPU、GPU、网络和支持服务。
为什么 Agentic AI 正在催生新的 CPU 市场
智能体基础设施竞赛正在超越 GPU，因为模型推理并不能执行完整工作流。
聊天机器人通常向模型发送一次请求，并返回一次响应。智能体则可以生成计划、搜索多个系统、调用外部工具、评估结果并修正方法。一次用户请求可能触发许多独立操作。
这些操作会产生 CPU 需求。工具容器必须启动，应用逻辑必须运行，数据库必须响应查询。安全策略必须在整个过程中得到检查。模型加速器可以快速生成 token，但无法替代这些外围功能。
代码智能体提供了一个有用示例。模型提出修改建议，但另一个系统会检出代码仓库并安装依赖项。它可能编译软件、运行测试、检查日志，并提交修订后的提示词。这些步骤需要通用计算、内存、存储和网络访问。
客户服务智能体也呈现类似模式。它们可以检索账户记录、检查库存、更新支持工单，并为敏感操作请求授权。语言模型引导交互，而传统系统则完成实际工作中的很大一部分。
AMD 将智能体工作负载分为个人、企业和技术三类。个人智能体优先考虑每瓦可运行的智能体数量。企业部署需要在大量并发用户之间取得均衡性能。技术智能体则需要更快的核心，以处理编译和仿真等任务。
Helion 的 CPU 刀片选择反映了这些差异。高密度刀片采用 256 核处理器，配置功耗为 400 瓦。均衡系统同样提供 256 个核心，工作功耗点为 600 瓦。性能刀片采用 96 个更高频率的核心，最高达到 5.0 GHz。
这些是配置目标，而非应用性能证明。仅凭核心数量无法预测智能体完成任务的速度。软件设计、内存访问、工具延迟、模型响应时间和网络争用都可能主导最终结果。
不过，这一架构反映了更广泛的市场转变。Nvidia 推出了搭载 256 颗处理器、面向智能体工作负载的独立 Vera CPU 机架。该公司表示，其 CPU 可支持环境运行、强化学习、数据处理以及 GPU 推理周边的其他任务。
Intel 同样瞄准这一类别。其 2026 年机架级战略将 Xeon 处理器与 SambaNova 加速器结合，用于推理和智能体工作负载。Intel 还单独推广可使用不同加速器类型的解耦式系统。
这些竞争动态支持了 AMD 的前提：agentic AI 正在为加速器机架之外的基础设施创造市场。分歧在于，客户应当以多高的紧密程度将这些组件绑定在一起。
CPU 机遇并不会降低 GPU 的重要性，反而源于 GPU 使用范围的扩大。更多模型调用会在其周围带来更多编排、数据移动和应用执行需求。
对于 AMD 而言，这提供了进入 AI 数据中心的另一条路径。Nvidia 凭借 GPU 硬件和 CUDA 软件控制了加速器市场的大部分份额。AMD 可以在加速器领域竞争，同时也能守住企业系统中已广泛部署的 x86 服务器基础。
Helion 将这种既有装机基础优势打包为机架级方案。客户可以在 EPYC 处理器上运行更多外围工作流，随后将模型调用导向 AMD GPU、其他本地加速器或外部服务。
其商业价值仍取决于具体工作负载。运行简单检索助手的企业可能不需要专用机架。运营数千个并发智能体的超大规模云厂商则面临不同的测算。Helion 瞄准的是这些后台操作成为容量规划问题的节点。
AMD 的开放蓝图挑战 Nvidia 的集成式 AI 工厂
主要竞争并非 AMD 与 Nvidia 在单一基准测试上的较量，而是模块化基础设施与纵向协同平台之间的较量。
Nvidia 的 Vera Rubin 平台结合了多个专用系统。其产品组合包括 Rubin GPU 机架、Vera CPU 机架、网络、数据处理单元和存储基础设施。Nvidia 将这些元素设计为协同运作的大型 AI 工厂。
这种集成可以简化性能工程。一家供应商控制处理器、互连、系统架构以及大部分软件。客户可获得明确的部署路径，以及组件之间经过优化的通信。
同样的方式也会提高对平台的依赖。当设计假定整个系统都使用 Nvidia 硬件和软件时，替换其中一层会变得更加困难。买家将现有基础设施与多家供应商组件结合的空间也更小。
AMD Helion 则作出了相反的承诺。它采用 Open Compute Project 机架格式，并将自身定位为制造商可进行适配的蓝图。AMD 计划将该规范贡献给该组织，以供社区开发。
Open Rack 项目为数据中心设备提供共享的机械与电力规范。Helion 在不同层面引用了 ORv3、DC-MHS、DC-SCM、HPRv2、OCP NIC 3.0 和 Caliptra。这些标准涵盖机架尺寸、模块化主机、管理、电源、网络和硬件安全等领域。
这种合规程度的重要性远大于为机柜贴上“开放”标签。标准化接口可以让制造商构建兼容的刀片、电源系统和管理组件，也可以减少为特定客户适配机架所需的工程工作。
AMD 已吸引了一批规模可观的制造合作伙伴。Dell、Foxconn、HPE、Lenovo、QCT、Supermicro 和 Wiwynn 均出现在已公布的支持者名单中。Cisco 也在支持更广泛的基础设施方案。
广泛的合作伙伴阵容有助于 Helion 作为蓝图显得可信，但并不能证明客户需求。许多相同的制造商也在生产 Nvidia 系统，公开支持并不意味着已承诺的部署规模。
Nvidia 同样将 MGX 描述为由庞大制造网络支持的开放系统架构。因此，选择并非简单的开放 AMD 对封闭 Nvidia。两家公司都通过设备制造商分发参考设计。
差异在于各个平台将控制权集中于何处。Nvidia 围绕其加速器互连、网络栈、处理器和软件环境构建。AMD 则更强调可互换配置和成熟的 OCP 接口。
Helion 的纯 CPU 选项尤其清楚地体现了这一差别。超大规模云厂商可以将智能体执行能力与其推理集群分开部署。加速器集群无需占据同一机架，也无需遵循相同的更新周期。
这种分离提供了运营灵活性。当工具执行成为瓶颈时，CPU 容量可以扩展；当模型流量增加时，GPU 容量可以扩展。每个资源池都可以依据自身的经济性进行选择和替换。
它也会产生协调工作。运营人员必须在不同系统之间管理网络、部署位置、调度、可观测性和故障处理。开放式蓝图可以提供更多选择，但也会将更多集成责任转移给客户。
企业配置通过将 CPU 与 MI350P GPU 集成在一起，减轻了这一负担。不过，其两个 GPU 节点独立运行。Helion 缺少专为最大规模模型设计的系统中所采用的全机架横向扩展互连。
AMD 表示这是有意为之，因为该机架面向企业级智能体，而非前沿模型训练。这一解释与其架构相符，但也界定了买家需要理解的一项限制。
Helion 可以在本地运行开放模型，但并非旨在将 16 块 GPU 组合成一个巨型加速器。需要统一 GPU 域的工作负载，应部署在 AMD Helios 或 Nvidia GPU 机架等基础设施上。Helion 的角色是协调、执行和特定推理任务。
因此，AMD Helion 智能体 AI 机架要求买家接受一种权衡。他们获得模块化能力和多种部署路径；作为回报，他们必须决定哪些工作负载应由各个组件承担，并管理组件之间的边界。
AMD Helion 如何路由不同的智能体工作负载
Helion 的核心机制是工作负载部署，即为智能体任务的每个阶段匹配合适的计算资源。
设想一个企业研究智能体需要评估某家供应商。该智能体首先理解请求并制定计划，随后搜索内部文档、查询业务系统、阅读外部来源，并计算风险指标。
云端模型可以处理最初的规划步骤。本地模型可以对包含机密信息的检索文档进行分类。CPU 节点可运行搜索、数据库、解析和计算服务。存储系统则提供整个流程中使用的记录。
令牌路由器能够在这些目标之间分发单个模型请求。这类似于推理流量控制器，但这一决策的分量远超简单的负载均衡。不同模型在质量、延迟、隐私性、上下文容量和运营成本上各不相同。
例如，常规提取任务可能会被发送到机架内的紧凑型模型。复杂的推理请求可能会交给前沿服务。即使本地模型耗时更长，敏感数据也可能仍保留在本地。
AMD 尚未披露足够细节来评估这些路由决策。该公告没有提供路由选择准确率或开销的公开测量数据，也未说明管理员如何审计在多个模型之间流转的请求。
在受监管环境中，这些问题尤为重要。路由层需要遵守数据位置、访问权限和获批模型政策，还必须生成记录，说明每项请求由哪个端点处理。
模型路由仅代表其中一层调度机制。该平台还必须部署智能体启动的非模型任务。有些作业适合大量高能效核心，而技术任务则需要较少核心但更高的单线程性能。
AMD 的三种处理器配置针对这种差异而设计。高密度刀片可最大化并发容量。均衡型刀片在相同核心数量下提供更高功率。高频刀片则面向对延迟敏感的代码和技术计算。
企业机架在这些 CPU 选项旁增加了 MI350P 推理节点。因此，它能够支持完整工作流，而无需将每一次模型请求都发送到系统外部。对于具有数据治理或延迟要求的组织而言，这种设计可能颇具吸引力。
通用刀片完善了整体架构。它们支持智能体所依赖的数据库、存储服务和技术应用。这实际承认了：智能体平台不仅依赖模型，也依赖企业系统。
知识密集型工作流说明了这种关联。员工可能先使用个人知识库寻找相关上下文，再要求智能体执行操作。在组织规模下，同样的模式需要身份控制、检索服务、数据库和可追溯的操作。
开发者不应假定基础设施能够修复糟糕的智能体设计。更多核心无法解决权限不清、工具不可靠或模型行为评估不充分的问题。Helion 可以提供容量，但应用仍然需要限制机制和恢复路径。
买家应改为梳理完整工作流。他们需要测量模型推理、工具执行、检索、等待和验证所耗费的时间。这些测量结果决定了以 CPU 为主的机架、混合系统还是现有服务器是否合理。
这正是 AMD 的论点可被检验之处。如果生产环境中的智能体将大量时间花在模型推理之外，Helion 就为客户提供了独立扩展这些工作的方式。如果推理占据主导地位，以加速器为中心的系统仍更具吸引力。
规格参数无法证明什么
Helion 是一项仍在开发中的参考设计，因此其最大数字描述的是容量，而非已经验证的生产结果。
32,768 核这一醒目数字很容易理解，但它并不是智能体性能指标。客户需要了解的是每瓦完成任务数、每个工作流耗时、模型延迟、故障率，以及真实流量下的利用率。
AMD 的产品资料讨论了如何最大化每瓦智能体数量和单个智能体性能，但尚未提供这些指标的标准化结果。若没有工作负载定义，“智能体”一词就无法作为一致的基准单位。
一个智能体可能对一封简短电子邮件进行分类，另一个可能运行长达 30 分钟的软件测试套件，第三个则可能协调数百次工具调用和多个模型。将它们各自计为一个智能体，会掩盖工作量上的巨大差异。
AMD 也尚未公布 Helion 与传统服务器机列之间的完整比较。机架密度可以减少对机房面积的需求，但也会集中电力、散热和网络需求。运营人员必须评估对整个设施的影响。
102 Tbps 网络数字同样需要更多背景。汇总的网络容量无法揭示应用吞吐量。流量模式、交换机配置、协议开销、存储访问和外部模型调用都会影响实际观测到的性能。
可用性是另一个悬而未决的问题。AMD 表示，合作伙伴配置仍在开发中，计划于 2026 年 11 月推出。这意味着公告与预期上市之间的时间很短。具体型号、区域可用性、认证时间表和客户部署情况仍不明确。
Tom’s Hardware 报道的一项日期更正说明了这种变化性。该媒体最初收到的指引指向 2027 年，随后在 AMD 将可用时间修订为 2026 年 11 月后，更新了时间表。买家应直接向系统合作伙伴确认交付时间。
软件成熟度带来了另一项风险。硬件开放并不会自动为不同制造商打造一致的运营体验。固件、编排工具、可观测性、安全控制和支持实践可能因具体实现而异。
令牌路由器尤其需要严格审查。在云端与本地模型之间路由可以提高资源利用率，但错误可能影响质量或数据治理。当信息存在驻留地或保密性限制时，企业需要能够覆盖自动化决策的政策。
目前也没有公开证据表明，组织希望用一个混合企业机架承载所有智能体服务。一些买家已经运行共享 GPU 集群和大规模 x86 机群。他们可能更倾向于在这些现有资源池之间实施软件编排，而不是部署专用 Helion。
Nvidia 从另一个方向带来了竞争压力。Vera Rubin 在 Helion 公告发布前已进入全面生产。Nvidia 表示，其平台在一个协调一致的系统内连接了专用 CPU、GPU、存储和网络机架。
这些是 Nvidia 自己提出的性能和采用情况主张，相关比较仍需要独立复现的测试。不过，产品可用性和软件集成可能比架构灵活性更重要。客户无法将开放性作为一种抽象特质进行部署。
Intel 为 AMD 增添了更多不确定性。其 Xeon 已广泛存在于数据中心，并正在推广配备多种加速器的智能体机架解决方案。因此，Helion 不仅要与 Nvidia 的集成平台竞争，也必须赢过既有的 x86 基础设施。
AMD 论点最有力的版本，并不依赖于宣称其具有普遍优势。它取决于证明：存在一类可衡量的智能体工作负载，能够从分离式执行容量中受益。公开客户结果将比最大核心数更重要。
三项信号将显示 AMD 的策略是否奏效
Helion 的成功将取决于实际交付的系统、可复现的工作负载结果，以及客户是否在实践中使用其模块化设计。
第一个信号是 11 月的可用性。Dell、HPE、Lenovo、Supermicro、QCT、Foxconn 和 Wiwynn 需要将支持声明转化为可订购的配置。买家应关注完整规格、交付区域、服务条款和认证指引。
按时交付的系统将加强 AMD 的主张：基于 OCP 的协作能够缩短从蓝图到产品的路径。延迟或有限的可用性则意味着，该公告发布时生态系统尚未准备就绪。
第二个信号是应用层基准测试。AMD 及其合作伙伴需要针对真实工作流报告已完成的智能体任务、延迟分布、功耗和利用率。测试应将模型耗时与 CPU 执行、检索、存储和网络活动分开。
最有价值的比较应包括传统服务器、Helion 的纯 CPU 机架及其混合企业配置，也应清晰定义每个工作流。若不说明任务复杂度和质量控制，笼统的“每瓦智能体数量”结果价值有限。
独立测试将增强这些结果的可信度，也有助于买家将 Helion 与 Nvidia Vera CPU 机架、Intel Xeon 部署以及已经投入生产的软件编排基础设施进行比较。
第三个信号是客户如何使用解耦架构。若某家超大规模云服务商将 Helion 与多个加速器平台配对使用，将验证 AMD 的核心论点。这将表明，智能体执行能够成为一个独立扩展的基础设施层。
企业采用将检验另一项前提。买家必须证明，在单个机架中结合 CPU 执行与有限 GPU 推理能够简化部署。如果他们仅将 Helion 用作高密度通用计算，其面向智能体的定位将显得不那么突出。
AMD Helion 智能体 AI 机架以一个可信的架构理念进入市场。智能体工作流不仅包含模型推理，其周边操作同样需要大量基础设施。AMD 围绕这一观察设计了一个机架。
然而，蓝图只是开局之举。其价值将取决于合作伙伴整合组件的效果，以及客户衡量结果的清晰程度。开放标准可以扩大选择范围，但无法消除构建可靠智能体平台所需的工作。
对开发者和企业采购方而言，当务之急很明确：在选择硬件之前，先对完整工作流进行分析。评估智能体将时间花在何处、哪些数据必须保留在本地，以及故障出现在哪些环节。随后依据这些需求，将 Helion 的模块化方案与一体化替代方案进行比较。若 11 月推出的系统能够提供透明的基准测试结果和真实部署案例，AMD 将有证据表明，智能体计算需要一个独立的机架级层。
