Microsoft Commits to Multi-Gigawatt Maia Deployment Amid Efficiency Metric Skepticism

微软将从2027年起规模化部署Maia系列芯片，Maia 200已用于Copilot等产品，Maia 300专注长上下文推理，不支持训练。其单机架HBM达27.6 TB、聚合带宽1.7 PB/s，TDP 950W。效率指标（如每瓦Token数）缺乏明确定义，引发行业质疑。

Maia 300专为内存密集型推理优化，无训练能力；单机架HBM容量与带宽创AI加速器新高；Maia 200实测能效达领先GPU的1.7倍。

适合AI基础设施工程师、大模型推理系统架构师、云平台硬件选型负责人阅读。

从 2027 年开始，微软将把 Azure Maia 系列的部署规模扩大至数吉瓦级，使其 “成为微软各项产品和服务的主要推理系统”。支撑这一计划的架构设计对数据传输机制作出了相当详细的说明，但作为此次发布核心卖点的效率指标，却缺乏同样明确的定义。业内从业者也对此提出了质疑。

目前 Maia 200 已在生产环境中为微软 Copilot 和 MAI 团队提供算力支持。微软计划在今年年底前，将 GitHub Copilot 和 Microsoft Foundry 也接入 Maia 200。该芯片已部署在美国、欧洲和澳大利亚。微软表示，在 Teams 和 Copilot 的内置 AI 功能中，与领先的 GPU 基础设施相比，Maia 200 每瓦可处理的 Token 数量最高可达后者的 1.7 倍。Maia 300 则将于 2027 年开始正式投入生产环境。

Maia 300 的设计以推理为先，主要面向长上下文、内存密集型和解码负载较重的任务，而非训练。值得注意的是，微软的两篇公告都没有提及训练场景。每颗 Maia 300 加速器配备八组 HBM4 堆栈，内存容量为 288 GB，带宽达到 18 TB/s，热设计功耗（TDP）为 950 瓦。一个机架可容纳 96 颗加速器，总功耗为 167 kW，分装在 24 个托盘中，每个托盘包含四颗加速器。整个机架的 HBM 容量达到 27.6 TB，聚合带宽为 1.7 PB/s。

计算 Chiplet 采用台积电（TSMC）的 N2P 工艺制造，内存控制器和 I/O 功能则部署在独立的芯片上。微软表示，这种设计使计算 FLOPs 提升了 36%，同时将内存带宽提高至 Maia 200 的 2.5 倍，并将每瓦 HBM 带宽提升至后者的约两倍。内存访问方式也发生了变化：Maia 300 不再采用统一的内存访问布局，而是让多个 Chiplet 采用 NUMA 架构。这样，软件就可以将数据放置在更靠近实际执行计算的单元的位置。

网络是这套设计中最能体现微软技术取舍的部分。Maia 的 AI 网络控制器实现了一套基于以太网的定制 AI 传输机制。微软将其描述为“一个统一的网络 Fabric，而不是彼此分离的纵向扩展和横向扩展网络域”。加速器可以直接向 Superpod 中的任意对等节点发起通信，“无需经过主机或独立的横向扩展网卡”。

在具体连接方式上，同一托盘内的两颗加速器通过直连链路通信；机架内的交换式网络 Fabric 将全部 96 颗加速器连接起来；第二级光交换机则可将最多 128 个机架互连，组成一个包含 12,288 颗加速器的 Superpod。

微软在文章中划分了三个延迟域：两颗加速器之间的直连通信、Pod 内经过一跳的通信，以及跨 Pod 经过三跳的通信。微软预计，软件会尽可能将张量并行流量限制在延迟最低的通信域内。

机架内带宽与跨机架带宽的分配比例并不会“在系统设计阶段就固定下来”，而是由作业的打包和放置方式决定。因此，当只有部分通信需要跨机架进行时，单颗加速器仍可向任意对等节点提供最高 750 GB/s 的带宽。

这套网络也支撑着 Maia 300 特定的推理执行模式。Prefill 和 Decode 工作节点可以分别确定规模，并独立部署。Prefill 阶段完成后，KV 状态会“通过同一套纵向扩展网络 Fabric 直接传输给选定的 Decode 工作节点，而不是通过另一条由主机中转的横向扩展路径离开当前网络域”。同一套网络还支持跨机架的故障补偿：如果一个机架中的托盘发生故障，另一个机架中的备用托盘就可以接替其工作，整个过程对软件内核透明，无需软件内核感知底层变化。

微软公布的核心数据是，预计 Maia 300“与领先的 GPU 系统相比，每兆瓦处理的 Token 数量将提高 40%”。此外，其机架级 Token 吞吐量最高可达对比系统的七倍，每瓦性能则超过 Maia 200 的 2.5 倍。

真正引发讨论的是这项效率指标。质疑者针对的并非 40% 这个数字本身，而是指标的计量方式和定义。

Rick Bullotta 在 Satya Nadella 的发布公告下发表了互动量最高的评论：

“每瓦 Token 数”简直是个荒谬的指标。仿佛 Token 有统一、一致的定义，或者 Token 数量与计算量之间存在普遍适用的关联。事实并非如此。而且，这种指标本身就会奖励冗长的输出。

评论者 Michel Floyd 则从量纲角度提出了疑问：“指标难道不应该是每瓦每秒处理的 Token 数，或者每千瓦时处理的 Token 数吗？”UBIQS 创始人 Vinay Bansal 正在开发一款与 Maia 竞争的推理加速器。他质疑微软测量这一指标时所采用的工作负载：

每瓦多处理 40% 的 Token，但测试时使用的上下文长度是多少？你们提到的持续运行、多步骤 Agent 任务都涉及很长的上下文，而且每个 Agent 的工作记忆都会随着执行步骤的增加而不断增长。在这种情况下，真正的瓶颈是内存，而不是计算能力。此次发布中最受关注的规格参数，恰恰也是内存规格。

如果这些反馈能够代表业内的普遍看法，那么相比效率指标本身，Maia 300 的架构设计反而更容易评估。微软没有公布作为比较对象的具体 GPU 系统。与此同时，微软自己将 Maia 300 的目标描述为最大限度地提高“每瓦有用 Token 数量”和“每美元有用 Token 数量”，却没有定义什么样的 Token 才算“有用”。两篇公告在表述上也存在一个值得注意的区别：微软执行副总裁 Scott Guthrie 和工程博客都表示，微软预计 Maia 300 的效率将提升 40%；而纳德拉在自己的公告中，则直接将这一提升表述为已经实现的结果。

另一个问题是，谁能使用 Maia。两篇文章提到的所有工作负载都属于微软自身的产品或团队，包括 Copilot、GitHub Copilot、Foundry、MAI 团队和 Dragon Copilot。但两篇文章都没有说明，客户是否能够直接预配 Maia 算力。

Pexon Consulting 首席执行官 Phillip Pham 用德语提出了相关疑问：这些性能提升能否转化为更便宜的预留吞吐量套餐，还是说这类硬件仍将专供微软自己的服务使用？对于采用承诺容量模式的客户而言，真正决定生产环境收益的，是每个有保障 Token 的价格，而不仅仅是硬件本身的处理效率。

除 Rani Borkar 和 Saurabh Dighe 撰写的工程博客外，微软尚未发布其他技术论文。该博客也是此次公告链接的唯一技术资料。

微软表示，将于下个月在旧金山举行的 Microsoft Ignite 2026 大会上公布更多信息。