
微软将 AMD Helios 引入 Azure AI 推理
微软在 Azure 上部署 AMD Helios 机架系统(ND MI455X,192GB HBM3),以提升 AI 推理吞吐量、降低延迟并在规模化下削减成本。
微软正在把 AMD Helios 系统引入 Azure,让 AI 推理在规模化下更快、更稳、更便宜。 如果你运行聊天、图像或视频工作负载,简而言之:更高的吞吐量、更低的延迟,以及 更大的高请求量承载空间。
以下是我会立即记住的要点:
-
Helios 面向生产推理,而不只是实验室测试
-
ND MI455X v7 VM 是大型 LLM 和多模态作业在 Azure 上的主要适配
-
MI455X 上的 192 GB HBM3 内存 为大模型提供更多空间
-
AMD 表示某些 Llama 工作负载可获得高达 8 倍的提升
-
文章指出,在专用配置上约 750 tokens/sec,而标准 H100 端点约为 100–150 tokens/sec
-
Azure 仍在整个技术栈中拆分工作:
-
CPU VM 负责准备工作
-
GPU VM 负责繁重推理
-
AKS、托管端点、批处理和队列 负责各种服务模式
-
-
对于 APIMart 之类的平台,这可能意味着 更短的队列、更稳定的响应时间,以及对流量峰值更好的处理
如果要用一句话概括:Azure 正在增加更多机架级 GPU 容量,让 AI 团队能以更少的延迟和更好的成本控制服务更多的多模态请求。
最重要的不是硬件的名字。而是团队如何把工作负载映射到正确的 Azure 路径,并追踪 延迟、队列深度、并发和每 token 成本。
Helios 是 AMD 首个可与 Nvidia Vera Rubin 抗衡的 AI 系统——我们拿到了独家的首次实测
微软正在部署什么:Azure 上的 AMD Helios 机架系统

微软正在 Azure 上推出 AMD Helios,将其作为一个紧密集成的机架级系统,把计算、网络和存储整合进同一套设计中。
这很重要,因为它减少了节点之间的流量,有助于在规模化下让大模型推理保持稳定。在 Azure 上,微软通过针对 AI 管线不同部分调优的 ND 系列 VM 来呈现这套配置。
Helios 硬件与软件栈
Helios 的核心是 AMD Instinct MI455X GPU。它配备 192 GB HBM3 内存,比前几代 多 1.5 倍,为 LLM 和多模态工作负载提供更多空间 [2]。
AMD EPYC Venice CPU 负责预处理和输入喂送。这减轻了 GPU 层的压力,使其不至于成为瓶颈。
在网络方面,Helios 使用带 InfiniBand 的 AMD Pensando DPU。目标很简单:为高并发推理和分布式工作负载提供低延迟和高带宽。
在软件方面,ROCm 6+ 增加了 FlashAttention、HIPGraph 和 vLLM 支持。AMD 表示它可以将 Llama 工作负载加速 高达 8 倍 [2]。ROCm 还可与 PyTorch、TensorFlow、DeepSpeed 和 ONNX 等框架配合,有助于让模型在 Azure 的 ND 系列 VM 之间保持可移植。
Secure Encrypted Virtualization (SEV) 在这里增加了另一层保护。它有助于在多租户环境中保护 AI 模型权重和敏感的多模态数据 [3]。
Helios 如何融入 Azure AI 基础设施
在 Azure 内部,这套栈作为 ND 系列 阵容的一部分出现。
ND MI455X v7 VM 是 Helios 支持的工作负载的主要适配,尤其是 大规模 LLM 推理 和 多模态生成。与之并列的 ND MI300X v5 仍在 生产推理 和 训练 方面占有一席之地。
对于推理开始之前的工作,Azure 使用以 CPU 为主的系统。由 EPYC 处理器 驱动的 HXv2 和 HDv2 VM 负责 数据准备、预处理 和 HPC 仿真。
下表将每种 Azure 资源映射到其主要任务。
| Azure 资源 | 主要硬件 | 目标工作负载 |
|---|---|---|
| ND MI455X v7 | Instinct MI455X (Helios) | LLM 推理、多模态生成 |
| ND MI300X v5 | Instinct MI300X | 生产推理、训练 |
| HXv2 / HDv2 | EPYC Venice CPU | 预处理、数据准备、HPC 仿真 |
实践中,团队可以让管线的每个阶段对齐正确的 Azure 资源:在 EPYC 支持的 VM 上进行预处理,然后在 MI455X 实例上进行更重的推理。
Azure 上会有什么变化:推理速度、规模与基础设施效率

更快的模型服务与更低延迟的多模态工作负载
只有当 Helios 在实践中让推理变得更好时,它才有意义。而这正是它被设计来做的事。
它减少了节点间延迟,有助于提升跨多个 GPU 分布式推理的吞吐量。用大白话说,系统可以在 GPU 之间以更少的延迟搬移工作。这带来聊天应用中更快的首次响应,以及在视觉与语言需要并肩工作的图像和视频任务中更流畅的表现。
这种跃升可能很大。在 2026 年,专用硬件配置可达到约 750 tokens per second,而标准 H100 端点为 100–150 tokens per second [2]。在生产推理中,这样的差距并不小。它可以改变用户获得答案的速度,以及系统一次能处理多少请求。
为生产 API 和高并发推理提供更多容量
同样的配置在削减延迟之余,也帮助 Azure 处理更多并发请求,而不必把容量切成更小、更没用的碎片。
这为跨聊天、搜索和媒体管线的突发推理流量提供了更多空间。如果请求量激增,系统更有能力跟上节奏。围绕高请求量构建的工作负载在这里受益最大,因为更快的 GPU 互连有助于随着需求增长保持响应时间稳定。
每机架、每瓦、每美元的更佳效率
更高的吞吐量不只影响速度。它也改变了推理的成本一面。
到了这个地步,效率在任务层面就已重要,而不只是在峰值功率上。像 Helios 这样的机架级系统正是围绕这一理念构建的,这意味着 Azure 可以用同样的物理占用空间交付更多 AI 工作。
输出 token 的成本仍远高于输入 token,因此吞吐量的提升可以实质性地改善单位经济效益 [2]。对于在 Azure 上运行稳定、大量推理的企业而言,随着工作负载规模增长,这一优势会不断累积。
企业、开发者和 APIMart 如何利用新增的 Azure 推理容量

Azure 工作负载的企业部署模式
这里的好处来自把每个工作负载与最适合它的 Azure 服务配对。大模型推理属于 ND 系列 GPU 实例。预处理和转码适合 HDv2 或 HXv2。而生产服务在 托管端点 或 AKS 上表现良好。这种拆分不只是纸面上整洁。它在分布式 Azure 部署中也运作良好。
Wayve 使用 Azure Machine Learning 和 AKS,以线性扩展和快速 GPU 互连来扩展分布式深度学习 [1]。同样的配置也适用于构建实时 API、RAG 系统和多模态管线的开发者——这些需要稳定的延迟和增长的空间。
不过,速度只是故事的一部分。部署选择还必须反映数据驻留和安全需求。如果一个团队有严格的驻留或安全规则,Azure AI Foundry 把部署控制集中到一处,而 Confidential Computing 为敏感的 AI 工作负载增加了硬件支持的加密 [1]。
更强 Azure 推理下的 APIMart 用例
对于 API 平台,更多容量通常体现在人们最先感受到的指标上:更稳定的延迟和更短的队列。APIMart 让用户通过一个统一 API 访问 500 多个 AI 模型,因此新增的 Azure 推理容量可以提升文本、图像和视频工作负载的吞吐量。这在生产工具中最重要——在这些工具里,队列深度和延迟每分每秒都在塑造用户体验。
对于像 MiniMax Hailuo 2.3 ($0.025/sec) 和 Sora 2 Preview ($0.08/sec) 这样的视频生成作业,更高的吞吐量可以缩短排队时间,并在流量峰值期间让作业持续推进。而对于更大的模型服务工作负载,高内存 GPU 实例为团队提供了更多余量,以容纳更大的模型和更多的并发请求。
表格:将 Azure 资源匹配到工作负载类型
对于 APIMart 式的工作负载,主要模式是 API 服务、排队生成和批处理管线。以下是这些模式如何与最适合它们的 Azure 服务对齐。
| Azure 资源 / 模式 | 最佳适配工作负载 | 主要收益 |
|---|---|---|
| Managed Endpoints (Azure AI Foundry) | 实时 API、聊天机器人、生产 API | 集中化安全和数据驻留控制 [4] |
| AKS (Kubernetes) | 智能体推理、微服务、RAG | 负载下的延迟 |
| Batch API | 数据管线、视频分析、摘要 | 每完成作业的成本 |
| Event-Driven Queues | 视频/图像生成、多模态管线 | 成功率和队列深度 |
结语:这次 Azure 部署对 2026 年的 AI 团队意味着什么
微软在 Azure 上推出 AMD Helios,显示了云基础设施的走向:大量、低延迟的推理如今已是核心技术栈的一部分。
只有当团队把每个工作负载送上正确的 Azure 路径时,这才有帮助。Helios 为团队提供了更多空间,把预处理、服务和批处理工作分配到合适的资源上——GPU 实例用于大模型,混合路径用于预处理,纯 CPU 路径用于轻量作业。关键很简单:盯住队列深度、延迟和每 token 成本。
对于 APIMart 用户,这种架构转变以一种务实的方式体现出来。吞吐量在负载下更为稳定。用大白话说,APIMart 可以在流量峰值期间让文本、图像和视频工作负载更顺畅地推进。
当这些增益同时削减单位成本时,它们就更有意义了。在规模化下,更佳的效率应体现为每焦耳更多的 token 和更低的作业级成本。
综合来看,这指向一个更加生产就绪的 Azure 推理栈。Helios 强化了一个简单的理念:AI 推理就是基础设施。现在就为异步队列、流式和队列深度做好规划的团队,将在 2026 年剩余时间里随着推理容量持续增长而处于更有利的位置。
常见问题
我如何判断我的工作负载是否需要 ND MI455X v7?
如果你的 AI 工作负载需要用于大规模推理的 GPU 加速基础设施,尤其是大语言模型和复杂的多模态管线,可以考虑 ND MI455X v7 系列。
当你面对以下情况时,它是一个有力的选择:
-
大模型参数带来的高内存需求
-
高并发或对延迟敏感的生产 API
-
视频或图像推理工作负载
Helios 在实践中会降低我的 Azure 推理成本吗?
会。Azure 上的 AMD Helios 机架系统 旨在提升基础设施效率和可扩展性,这在实践中有助于降低推理成本。
简单来说:更好的硬件能用同样的占用空间完成更多工作。这可以带来更强的性价比、更快的模型服务,以及通过更聪明的资源利用为生产 API 提供更多容量。
哪种 Azure 服务最适合实时 AI 与批处理 AI?
对于 实时 AI,把模型直接连接到应用以保持低延迟。这种配置最适合语音智能体和其他需要在 500 毫秒以内 回复的交互式用例。
对于 批处理 AI,使用带队列、任务 ID 和 webhook 的异步管线。这种方式适合像媒体生成这样较长的作业——结果不需要立即返回。对突发性动作使用 serverless functions,对更复杂的多步流程使用 microservices。
去模型市场挑选你想要的模型
在 APIMart 模型市场尝试聊天、图像和视频模型,用统一 API 快速体验模型能力。