施耐德电气让 Helios 具备部署条件，AMD Google 基础设施竞赛随之转向

施耐德电气与 AMD 发布了首个 Helios 基础设施设计，支持 246 千瓦机架及 IT 负载最高达 10.4 兆瓦的集群。这以务实的方式改变了 amd google 基础设施竞争。AMD 现在拥有了一条从加速器规格走向可运行高密度数据中心的明确路径。

这项公告并未让 AMD 突然在性能上战胜 Google、Nvidia 或其他平台供应商。它解决的是另一项竞争弱点。当每个机架还需要专门的配电、液冷、控制系统和设施级建模时，购买加速器只是开始。

Google 多年来一直围绕其 Tensor Processing Units（TPU）开发这些系统；TPU 是针对机器学习工作负载优化的处理器。Nvidia 也曾与施耐德电气合作，为其加速计算系统建设物理基础设施。AMD 必须让运营商相信，Helios 能成为可投入运行的集群，而不必由他们自行设计配套设施。

这正是该参考设计的重要性所在。它让施耐德电气不再只是设备供应商，而是 AMD 应对垂直整合 AI 基础设施竞争的一部分。

Helios 蓝图将芯片连接至一座 10.4 MW 设施

AMD 与施耐德电气定义了 Helios 周边的物理系统，而不只是其机架内部的处理器布局。

两家公司于 2026 年 7 月 23 日在旧金山宣布了这项联合开发的设计。根据 Helios 蓝图，该方案支持 IT 容量最高达 10.4 兆瓦的模块化 AI 集群。

每个高密度机架最高可能需要 246 千瓦功率。处于这一水平的机架，其用电量是许多传统企业级部署的数倍；同时，几乎全部电力输入都会转化为必须持续移除的热量。

Helios 集成了 AMD Instinct MI455X 加速器、第六代 EPYC 处理器、Pensando Vulcano 网络接口卡以及 ROCm 软件环境。ROCm 是 AMD 用于编程和运行其加速器的开放软件栈。

这些计算组件仅代表其中一层。该参考设计覆盖设施供电、设施冷却、IT 空间和生命周期软件，并规定这些层级应如何围绕 Helios 的需求协同工作。

施耐德电气表示，其 Motivair 冷却系统可通过基于液体及空气-液体混合方式移除高达 84% 的热量。冷却液分配单元（CDU）则在机架回路与建筑冷却系统之间传递热量。

该设计还通过 EcoStruxure IT Design 使用 ETAP 电气建模和计算流体动力学。计算流体动力学可在设备进场前模拟气流和温度表现。

运营商可利用电气数字孪生来模拟基础设施运行状况。AVEVA 的 Unified Operations Center 则在部署后提供监控与运营可视性。这些工具旨在让电气或热管理冲突在建设流程的更早阶段暴露出来。

施耐德电气表示，完整配置在满负载下的电源使用效率（PUE）可达到约 1.12。PUE 比较设施总能耗与交付给计算设备的能耗。该数值越接近 1，意味着额外开销越低，但实际结果仍取决于气候、利用率和运营选择。

初始设计遵循适用于美国部署的美国国家标准协会要求。施耐德电气计划为其他市场开发符合国际电工委员会标准的版本。

这一地域限制很重要。该公告提供的是经过验证的起点，而非一种能够绕过当地电气规范或公用事业条件的通用设计。客户仍需根据自身站点开展工程设计工作。

据 独立报道，该蓝图无需客户另行付费。它的真正价值在于减少集成过程中的不确定性，而非文档本身的获取成本。

参考设计不会输送电力，也无法确保电网连接。它不能浇筑混凝土、获得用水权或解决当地许可问题。但在具备合适站点后，它能缩小尚待解决的工程问题范围。

这一区分确立了本文的核心张力。AMD 已推出具有竞争力的处理器和机架级架构；如今，它需要一种可重复的方法，将这一架构安装进受现实物理条件约束的设施中。

为何 AMD Google 竞争正在超越芯片本身

随着高密度 AI 系统作为完整的电力、热管理、网络和软件平台展开竞争，amd google 的比较越来越取决于设施工程能力。

Google 运营定制化 AI 基础设施已约十年。它在同一组织内设计 TPU、Pod 级网络、冷却系统、软件框架以及许多配套数据中心组件。

这种经验带来的优势，并非原始加速器规格所能完全体现。Google 可以协调处理器路线图与承载这些处理器的建筑设施；在通过 Google Cloud 提供容量之前，也能先在庞大的内部机群中测试基础设施变更。

Google 表示，其在七年间已为超过 2,000 个 TPU Pod 部署了吉瓦级液冷，并报告这些冷却部署的正常运行时间约为 99.999%。该公司在介绍 一兆瓦机架设计 时谈及了这一经验。

这些是公司自行报告的数据，并非与 AMD Helios 进行的独立比较。尽管如此，它们仍体现出竞争性基础设施平台需要应对的运营成熟度。

Google 还开发了 Brazos，这是一种用于在风冷设施内部部署液冷硬件的机架式液体-空气冷却系统。Brazos 系统 通过封闭液体回路吸收热量，再将其释放至现有热通道中。

Brazos 和施耐德电气的 Helios 设计面向不同的部署情境，但两者都反映出同一种行业压力：当目标建筑无法提供所需的液体回路、电力馈线或散热能力时，AI 硬件采用就会停滞。

AMD 并不拥有可与 Google 相比的超大规模数据中心机群。因此，它需要基础设施合作伙伴、服务器制造商、云服务商和网络供应商，共同为客户打造一条相当的部署路径。

施耐德电气填补了其中的重要部分。它将配电、冷却设备、建模软件和设施工程引入 AMD 的机架级项目。HPE 则通过将 Helios 纳入商业系统，提供了另一条路径。

这种合作伙伴模式可以带来灵活性。客户不会被限制在单一云运营商的处理器或设施架构中。运营商可将开放设计调整用于托管机房、私有云、主权 AI 和专用计算项目。

不过，合作伙伴主导的模式也带来协调风险。加速器、交换机、CDU、电气母线或软件版本的变化，都可能影响多家公司。验证工作必须跟上每一项主要组件路线图的节奏。

Google 的整合模式缩短了部分组织间距离。该公司可通过内部规划协调其 TPU、网络、软件和设施团队，也可将自身基础设施预留给符合其经济效益的工作负载。

代价则是客户控制权。Google Cloud 客户主要以托管服务的形式使用该平台；Helios 买家则可对计算环境、设施设计和运营模式获得更直接的控制。

这并不意味着 AMD 与 Google 在每一项采购中都可直接互相替代。Google 销售云服务并使用定制芯片，而 AMD 则通过行业网络销售处理器和平台技术。

但企业买家仍会比较最终获得的算力。他们会考察部署时间、模型兼容性、可用区域、运营控制、性能与能耗。竞争单元正从单颗芯片转变为能够正常运行的 AI 集群。

Nvidia 仍是该市场最主要的参照对象。施耐德电气于 2024 年宣布与 Nvidia 开展基础设施合作，重点是面向高密度加速器集群的高功率配电和液冷。此前的 Nvidia 合作 表明，施耐德并未选择单一加速器平台。

相反，随着多种架构需要新的设施设计，施耐德电气将从中获益。对 AMD 而言，这一关系提供了基础设施信誉；对客户而言，它在云原生 TPU 和以 Nvidia 为中心的系统之外，创造了另一种工程化选择。

电力与冷却如今定义竞争机制

施耐德电气的贡献之所以重要，是因为一台 246 千瓦机架对设施的改变速度，快于它对采购电子表格的影响。

传统服务器规划通常将数据中心视为稳定的容器。买家选择服务器、分配机架位置，并检查现有供电和冷却能力是否足够。

高密度 AI 颠倒了这一顺序。工作负载和加速器路线图如今会决定电气拓扑、管道、机房布局、冗余模型和建设进度。为上一代服务器设计的建筑，无法自动容纳下一代机架。

在 246 千瓦的水平下，Helios 机架需要计算设备与设施系统直接协同。电气设计必须处理稳定负载、瞬态行为、保护设置、维护状态和故障情景。

冷却设计必须向每块冷板输送足够的液体，还必须通过 CDU 和设施回路传递热量，且不能造成不可接受的温度变化或流量失衡。

风冷仍是设计的一部分，因为部分组件及周边设备仍会将热量排放到机房内。因此，施耐德电气描述的是混合方案，而非声称液冷能消除所有空气侧需求。

该公司的参考设计库说明了为何建模必须覆盖电气行为、气流和液体流动。每种模型都能捕捉不同类别的故障；将它们结合起来，可在运营商为集群通电前识别交互影响。

以局部冷却故障为例。其余设备必须吸收额外热量，或者计算负载必须迅速下降。这一事件会影响设施控制、集群调度，并可能影响模型训练进度。

电力中断会带来另一项跨层问题。备用系统必须支撑预期的运行状态，而软件环境则要处理被中断的任务。设施韧性与计算韧性无法彼此独立地规划。

这正是 Helios 合作背后的机制。AMD 定义计算平台的行为和要求。Schneider Electric 则将这些要求转化为项目团队可评估的基础设施配置。

模块化的 10.4 兆瓦集群设计又增加了一层优势。运营商可以按可重复的模块规划容量，而不必从零开始设计每一次部署。标准化能够简化采购，并减少工程师、承包商和技术供应商之间的分歧。

可重复性也有助于供应商预测设备需求。CDU、开关设备、监控系统和预制模块均可围绕已知的集群配置进行规划。然而，即使是重复使用的模块，仍需要进行站点级集成。

公用事业容量仍是最棘手的边界。一套完善的设计并不能保证公用事业公司能按预期时间表额外提供 10.4 兆瓦电力。并网排队和变电站工程的周期，可能比计算硬件的部署时间表更长。

用水和散热方式也因地点而异。设施可能需要根据气候和当地限制，采用冷水机组、干冷器、冷却塔或其他配置。参考设计无法消除这些环境差异。

约 1.12 的 PUE 声称同样需要结合背景理解。PUE 会随利用率、天气、冗余配置、冷却方式和测量边界而变化。建模得出的满载数值不应被视为有保证的年度结果。

运营商还必须决定为维护和故障预留多少容量。在正常运行期间，将冗余基础设施用于额外计算可提高利用率；但这也会减少设备离线时可用的余量。

Schneider Electric 将这一选择描述为额外计算产出与原始冗余策略之间的竞争。该决定应当明确，因为闲置的备用容量并不会自动成为免费的生产容量。

尽管采用一体化模式，Google 仍面临同样的物理限制。其液冷工作表明，定制芯片并不能消除设施工程的需求。相反，组织必须随着每一代计算硬件，同步开发冷却和供电系统。

因此，amd google 的竞争揭示了针对同一机制的两种路径。Google 在内部协调了大部分技术栈。AMD 则围绕 Helios 构建开放的合作伙伴网络，并由 Schneider Electric 负责关键的设施层。

已验证的设计不等于已验证的部署

核心不确定性在于，客户能否在真实站点、工作负载、供应商和运行条件下复现该蓝图的建模结果。

Schneider Electric 和 AMD 表示，该设计由双方联合开发并完成验证。这种验证表明，各组件和工程假设曾被一并评估。但这并不能证明其在大规模已安装基础上的现场性能。

7 月公告没有附带公开的客户部署结果。两家公司未披露任何一座已完成的 Helios 设施，能够按照新设计以每机架 246 千瓦持续运行。

对于新发布的架构而言，这种缺口很常见。但它仍限制了买方对调试时间、故障表现、组件可用性和长期维护情况的判断。

Helios 平台还依赖硬件按计划到位。其设计包括 MI455X 加速器、第六代 EPYC 处理器和 Vulcano 网络接口。延迟或规格变更可能迫使系统进入新一轮验证周期。

网络是其中一项特定风险。Helios 采用开放、面向 Ethernet 的方案，旨在提供 Nvidia 高度集成的 NVLink 环境之外的替代选择。这赋予买方更多供应商灵活性，但也使新兴合作伙伴生态系统变得尤为重要。

HPE 已宣布计划提供基于 Helios 的系统，为 AMD 提供一条重要的商业路径。其实现方案采用高带宽加速器网络和专用交换机。

一份详细的 Helios 系统分析描述了一种计划配置，其中包含 72 个 MI455X 加速器。该报道还提到，AMD 的目标是每机架配备 31 TB HBM4 内存和 2.9 exaFLOPS 的 FP4 算力。

这些数字是与未来硬件相关的目标，并非经过独立验证的量产结果。FP4 是一种用于部分 AI 推理任务的低精度数值格式，不应与所有训练或科学计算工作负载直接比较。

软件仍是另一项变量。ROCm 已扩展对框架和模型的支持，但硬件可用性本身并不保证等效的应用性能。买方必须测试其实际模型、算子、编译器和分布式训练行为。

Google 可以通过 JAX、XLA 及其内部软件环境，为 TPU 优化重要工作负载。Nvidia 则拥有长期建立的 CUDA 开发者基础。AMD 必须证明，其开放技术栈能够在不将过多集成工作转移给客户的前提下减少依赖。

参考设计可以解决设施蓝图问题，却可能仍未解决应用迁移问题。对于评估切换加速器平台总成本的企业团队而言，这一边界至关重要。

维护构成另一项考验。液冷回路在昂贵的计算设备附近增加了泵、连接件、传感器、歧管和维护流程。运营商需要了解有关泄漏、过滤、冷却液质量、组件更换和员工培训的证据。

84% 的散热比例同样需要谨慎解读。Schneider Electric 表示，其提议的冷却方案能够通过液冷移除这一比例的热量。剩余热负载和运行条件仍会影响机房级冷却需求。

部署速度同样需要保持谨慎。预先工程化的设计可以缩短规划时间并减少重复工作，但当变压器、开关设备、冷水机组、加速器或公用事业升级仍受限制时，它无法保证更快的建设速度。

这还涉及商业问题。买方必须决定，增加的架构选择是否足以证明运营更分散的供应商关系是合理的。有些客户会更偏好通过云服务使用资源，由 API 隐藏底层设施。

另一些客户则会看重直接控制权、本地数据驻留能力，或摆脱单一云平台的独立性。主权 AI 项目和专业云服务商尤其可能研究这一选择。

这种张力让 AMD 的战略显得可信，但尚未完成。Schneider Electric 已减少了一类不确定性。如今，客户部署必须证明，这一组合系统能否在建模环境之外保持一致表现。

三项信号将表明 AMD 能否弥合基础设施差距

下一阶段取决于运行证据、合作伙伴交付能力和可重复的客户采用，而非又一轮架构层面的宣称。

第一项信号是采用 Schneider Electric 设计完成的客户部署。最有力的证据将包括在真实工作负载变化下测得的机架密度、调试时间、冷却性能、可用性和 PUE。

一个试点项目可以确认蓝图能够走出设计环境。多个覆盖不同气候和设施类型的部署，则能为其可重复性提供更有力的结论。

接近所述 1.12 满载 PUE 的结果，将强化两家公司关于效率的论点。远高于该数值的结果并不会自动否定该设计，但会凸显站点条件的重要性。

买方还应关注运营商如何处理故障和维护。当 CDU、泵、电气组件或计算托盘需要检修时，高密度集群必须仍可维护。

第二项信号是 AMD 的硬件和网络合作伙伴能否协调交付。MI455X 加速器、新一代 EPYC 处理器、Vulcano 接口、交换机、服务器和设施设备，必须按兼容的时间表抵达项目现场。

如果某个关键组件造成长时间延误，参考架构就会失去价值。相反，同步可用性将表明，AMD 的合作伙伴模式能够像一个连贯的平台一样运行。

互操作性测试将尤其重要。客户需要证据证明，服务器、交换机、软件、电力和冷却方面的变更不会引发反复的重新设计周期。

HPE 的商业 Helios 系统将提供早期检验。若有更多服务器制造商或云运营商采用相同的机架级假设，标准化将得到进一步强化。

第三项信号是相对于 Google TPU 和 Nvidia 系统的工作负载采用情况。AMD 无需让每一位买方都替换这些平台；它需要足够多的生产工作负载，来确立 Helios 作为可靠替代方案的地位。

这些证据应包括训练和推理应用，而不只是峰值基准测试结果。运营商将考察可用性能、软件投入、集群可用性、能耗和容量扩展速度。

Google 自身的基础设施开发提供了有用的参考。其长期的液冷历史表明，运营知识会跨越硬件世代不断积累。AMD 和 Schneider Electric 必须通过客户和合作伙伴开始建立可比的记录。

由于两家公司在市场中所处位置不同，amd google 的比较仍将并不完全对等。Google 运营一体化云平台和定制芯片平台。AMD 则提供由其他公司部署的开放架构。

但这种差异恰恰是新设计的重要之处。它让买方可以在使用一体化平台与在自身控制下组装经过验证的合作伙伴系统之间作出选择。

Nvidia 也将影响结果。其机架级系统、软件基础和基础设施合作关系，为部署成熟度设定了基准。如果 Nvidia 推进得更快，AMD 的开放架构就必须通过灵活性、可用性或工作负载经济性加以弥补。

Schneider Electric 有动力支持每一个主要平台。这种中立立场能够帮助客户比较设施要求，而不必将某一条加速器路线图视为永久方案。

对于技术和采购团队而言，眼下的行动很具体：先对目标工作负载建模，然后测试所选站点能否满足其电力、散热、网络和韧性要求。

评估大型基础设施公告的团队，也需要一种持久的方法，将工程假设与后续运营证据联系起来。可搜索的技术知识库能够在项目变化时，让设计文档、测试结果和供应商决策保持可访问。

Schneider Electric 的设计并未终结加速器竞赛。它将 AMD 推入了更艰难的阶段：机架规格必须经受公用事业限制、建设进度、冷却故障和生产工作负载的考验。

Helios 客户是否会公布与蓝图相符的实测结果，合作伙伴又能否按时交付每一层？这才是如今关键的检验。在宣布 AMD Google 基础设施竞赛的赢家之前，请关注首批运营站点、协调一致的硬件可用性和工作负载采用情况。