Microsoft Commits Maia to Multi-Gigawatt Inference, and Its Efficiency Metric Draws Questions
TL;DR · AI 摘要
微软将Azure Maia 300芯片部署至多吉瓦特级推理，其NUMA架构和自定义AI网络设计引发效率指标争议。
核心要点
- Maia 300单芯片配备288GB HBM4，带宽达18TB/s，TDP为950W。
- 微软采用TSMC N2P工艺，计算FLOPs提升36%，内存带宽达Maia 200的2倍。
- 网络设计实现12,288加速器超大规模互联，跨机架带宽由任务调度动态分配。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 微软Azure Maia 300架构
- 硬件规格
- HBM4堆栈/带宽
- TSMC N2P工艺
- 网络设计
- 自定义AI传输
- NUMA布局
- 效率指标
- 能效比争议
- 动态带宽分配
金句 / Highlights
值得收藏与分享的关键句。
Maia 300单芯片提供27.6TB HBM和1.7PB/s聚合带宽，TDP控制在950W。
微软通过NUMA布局实现数据就近计算，内存带宽达Maia 200的2倍。
网络架构支持128个机架互联，跨机架通信延迟分三域管理。
微软将Maia投入多吉瓦推理，其效率指标引发质疑 - InfoQ
InfoQ 首页 News 微软将Maia投入多吉瓦推理，其效率指标引发质疑
云
InfoQ 认证的AI辅助工程计划（在线，10月19日）：构建承载工具。
微软将Maia投入多吉瓦推理，其效率指标引发质疑
2026年10月16日 4分钟阅读
作者：
- Steef-Jan Wiggers
#### 关注我们
YouTube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
21K 喜欢
Bluesky
收听本文 -
0:00
音频准备就绪
您的浏览器不支持音频元素。
正常
1.25x
1.5x
喜欢
新下拉阅读列表
- 阅读列表
微软将从2027年开始将Azure Maia系列扩展到多吉瓦规模部署，使Maia成为"微软产品和服务的主要推理系统"。该承诺背后架构对数据流动的描述异常具体。而引发此次发布的效率主张却并未明确说明，业内人士对此表示质疑。
Maia 200已投入生产，为微软Copilot和MAI团队提供服务，GitHub Copilot和微软Foundry将在年底前上线。该系统已部署在美国、欧洲和澳大利亚，微软称其在Teams和Copilot内置AI中的能效达到领先GPU基础设施的1.7倍。Maia 300将于2027年开始生产部署。
Maia 300以推理为主，针对长上下文、内存密集型和解码密集型任务，而非训练（两项声明均未提及训练）。每个加速器配备8个HBM4堆栈，提供288GB内存和18TB/s带宽，功耗设计为950瓦。一个机架包含96个加速器，分布在167千瓦功率的24个四加速器托盘中，实现27.6TB HBM内存和1.7PB/s聚合带宽。计算芯片采用TSMC N2P工艺制造，内存控制器和I/O功能位于独立芯片上，微软称这使计算FLOPs提升36%，内存带宽达到Maia 200的2.5倍，HBM带宽每瓦特提升约2倍。内存架构从统一访问模式转变为跨芯片的NUMA布局，使软件能够将数据放置在使用它的计算单元附近。
网络架构是设计中最具争议的部分。Maia的AI网络控制器基于以太网实现了定制AI传输协议，微软将其描述为"统一架构而非独立的扩展域"。加速器可直接与超级节点中的任意对等设备通信"无需主机或独立扩展网卡参与"。每个托盘内两个加速器直接连接，交换架构将机架内所有96个加速器互联，光学二级交换机可将最多128个机架连接成包含12,288个加速器的超级节点。架构定义了三个延迟域：直接连接对、节点内单跳、跨节点三跳，并期望软件将张量并行流量限制在最低延迟域。机架内与跨机架带宽的分配"并非在系统设计时固定"，而是由任务打包决定，这使加速器在仅部分跨机架通信时，可向任意对等设备传输高达750GB/s的数据。
该织物承载着特定的推理模式。预填充和解码工作节点独立进行规模配置和部署，预填充完成后，KV状态“会直接通过相同的扩展织物转移到选定的解码工作节点，而不是通过单独的主机中介扩展路径离开域”。同一织物还能让一个机架中的备用托盘透明地抵消另一个机架中出现故障的托盘，软件内核无需感知这一过程。
微软公布的数据显示，Maia 300预计“相比领先的基于GPU的系统，每兆瓦可生成40%更多的token”，同时实现高达7倍的机架级token吞吐量，以及相比Maia 200超过2.5倍的每瓦性能。
这一数据引发了关注，但反对意见针对的是指标单位而非数值本身。Rick Bullotta在Satya Nadella的公告帖子下发表了最活跃的评论：
“每瓦token”；这是一个荒谬的指标。仿佛token有一个统一且一致的定义，或者与计算存在通用的相关性。并非如此。这种指标本质上会奖励冗长的表达。
评论者Michel Floyd用一句话指出维度问题：“难道不应该用‘每秒每瓦token’或‘每千瓦时token’来表述吗？”UBIQS创始人Vinay Bansal正在构建竞争的推理加速器，他质疑该数据所基于的工作负载：
每瓦多生成40%的token，但这是在什么上下文长度下实现的？你提到的工作负载（如持续多步骤代理）需要长上下文，每个代理的工作内存会随着每一步骤增长。此时，限制因素是内存而非计算，而主导此次发布的规格是内存规格。
如果这些反应具有代表性，那么架构的评估将比原始声明更容易。微软从未提及对比的GPU系统，其自身表述强调Maia 300最大化“每瓦有用token和每美元有用token”，但未定义什么使token“有用”。公告的自信程度也存在差异：Scott Guthrie和工程团队的帖子表示微软预计实现40%的提升，而Nadella的帖子则称其已实现该提升。
第二个问题涉及谁将获得访问权限。两篇帖子中提到的所有工作负载均属于微软自身，包括Copilot、GitHub Copilot、Foundry、MAI团队和Dragon Copilot，且两篇帖子均未说明客户能否直接调配Maia的容量。Pexon Consulting首席执行官Phillip Pham用德语提问，询问这些增益是否转化为更便宜的预配吞吐量预留，还是硬件继续保留用于微软自有服务，因为使用承诺容量时，决定生产效益的是每保证token的价格。
微软除了Rani Borkar和Saurabh Dighe的工程博客文章外，尚未发布其他技术论文，公告链接至该文章。微软表示将在下月于旧金山举行的Microsoft Ignite 2026上分享更多信息。
关于作者
作者信息
#### Steef-Jan Wiggers
显示更多
显示更少
#### 本内容属于云主题
##### 相关主题：
- 开发
- 架构与设计
- DevOps
- 人工智能、机器学习与数据工程
- 硬件
- 云
- 性能
- 架构
- 相关编辑
- 相关赞助商
- 赞助商 2026年10月29日，美国东部时间下午1点 从代币到功能：为AI辅助工程构建成本归属架构 演讲者：Martin Reynolds - Harness公司现场首席技术官，Barani Mohandoss - Trimble公司云治理、FinOps及E-Tools部门总监
InfoQ 电子报
每周二发送的InfoQ上周内容精选。加入超过25万名资深开发者的社区。查看示例
我们保护您的隐私。