近年来，微软将把Azure Maia系列部署规模推进至数吉瓦级，旨在成为其产品与服务的主要推理系统。这一部署计划对数据传输机制进行了详细架构设计，然而核心卖点的效率指标却缺乏明确界定，引发了行业层面的广泛质疑。当前，Maia 200已为微软Copilot与MAI团队提供算力支持，并计划在年底前接入GitHub Copilot与Microsoft Foundry，覆盖美、欧、澳等地区。其中，Maia 300将于2027年正式投入生产，设计以推理为核心，适配长上下文等重负载任务。二者在性能上的关键优势在于：Maia 300在每兆瓦Token处理量上较领先GPU系统提升40%，机架级吞吐量超系统七倍，每瓦性能较Maia 200提升2.5倍。但效率指标的争议核心在于定义与计量方式。质疑方指出，‘每瓦Token数’缺乏统一标准，且该指标本身会强化冗长输出，并质疑其未明确Token有用性的定义。此外，当前性能提升可能局限于微软内部产品场景，客户能否获得更经济的算力套餐仍存疑问。尽管架构设计聚焦高算力，但效率指标的不确定性仍是对该项部署落地效果的重要挑战，未来其技术成熟度与商业化应用前景仍需进一步观察。
--91likeyou---
计算 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 大会上公布更多信息。
查看英文原文：Microsoft Commits Maia to Multi-Gigawatt Inference, and Its Efficiency Metric Draws Questions
🔥 热词：#Maia · #Copilot · #300 · #2027 · #200 · #微软承诺将 · #推向数吉瓦级推理部署 · #但其效率指标引发质疑