本文来自全球最权威的半导体研究机构 SemiAnalysis。SemiAnalysis 使用包括卫星图像在内的多种公开信息来源来监测和追踪数据中心的建设和容量。他们的数据中心行业模型利用计算机视觉技术加速对全球超过 5,000 个数据中心设施的卫星成像分析，以追踪其规模、容量、时间表和进展。
我们最近成为了SemiAnalysis的订阅会员，这是我们继购买全球主流投行研报系统、启用AI研究助理外，在投研方面与全球主流投资机构接轨的重要方式。
报告全文：
微软的 AI 战略拆解——从能源到 Token
在 2023 和 2024 年，微软处于 AI 产业链的最顶端，但大约在一年前，他们突然大幅改变了路线：大幅放缓数据中心建设，明显减缓了对 OpenAI 的承诺。我们在一年前就把这一点提示给了数据中心模型的客户，之后也写了相关的通讯文章。
2025 年的故事，则是 OpenAI 逐步“去微软化”：Oracle、CoreWeave、Nscale、SB Energy、Amazon、Google 等相继直接与 OpenAI 签署了大额算力合约。
表面上看，这对微软像是一种极其不利的局面。今天，我们发布了一篇文章，剖析微软在这一阶段的失误；同时还有一场公开访谈，由 Satya Nadella 与我们的老朋友 Dwarkesh Patel 对谈，我们在访谈中直接质疑了微软的 AI 战略与执行。
如今，微软在 AI 领域的投资又回来了，而且这家 AI 巨头从未面对过如此之高的加速计算需求。来自雷德蒙德的巨人意识到自己正走向一条错误的道路，因而大幅调整了航向。随着最新 OpenAI 协议的公布，我们基于 Tokenomics 模型预计，Azure 的增长将在接下来几个季度重新加速。
微软在整个 AI Token 经济栈的每一层都有布局，正在经历加速增长，我们预计这一趋势会在未来数个季度乃至数年持续。
公司正在积极寻找短期可用产能，抓住一切能拿到手的机会：自建、租赁、Neocloud、新兴云厂商、偏远地区的场址——所有选项都在桌面上，只要有助于加快短期产能扩张（具体数据仅向我们的数据中心模型订阅用户提供）。
在硬件层面，微软甚至可以访问 OpenAI 的定制芯片 IP——这是当前最令人兴奋的一批定制 AI ASIC。在我们看来，OpenAI 的 ASIC 研发路线明显好于微软自研的 Maia，结果很可能是：微软最终用的也是这些芯片来服务 OpenAI 模型。这个动态和他们在模型上的关系非常相似：虽然微软可以访问 OpenAI 的模型，但仍在尝试通过 Microsoft AI 自己训练基础模型。我们认为，微软的目标是成为真正纵向一体化的 AI 巨头，切掉大部分第三方的毛利空间，用更低成本提供比对手更强的智能能力。
在本报告中，我们将深入微软 AI 业务的各个方面。我们首先回顾微软与 OpenAI 的合作历史，梳理 2023-24 年微软前所未有的数据中心投资浪潮，以及为 OpenAI 打造的训练集群从数十兆瓦一路扩张到吉瓦级的过程。接着，我们将分析这段“超级急刹车”（Big Pause）以及微软之后在数据中心市场的强势回归。这其中很大一部分，源于 OpenAI 所有权结构的大幅简化，以及微软越来越聚焦于一件事：提供将模型能力转化为产品用例（和收入）所需的基础设施——通过无状态 API 来实现调用与变现。
随后，我们会逐层分析微软在 AI Token 经济栈中的位置：
应用层（Applications）
大模型层（LLMs）
PaaS 平台层
IaaS 基础设施层
芯片层（Chips）
系统架构层（System architecture）
在每一部分，我们都会深入微软的产品组合、竞争位置以及未来展望。事情并非对微软一片大好——这家软件巨头正面临大量新进入者的挑战，对手既盯着其长期主导的生产力套件，也盯着其 AI 计算平台。
2023–2025 年的微软与 OpenAI：从 All-in AI，到“大暂停”（Big Pause）
2023–2024：自建、租赁，为 OpenAI 打造全球最大的数据中心
ChatGPT 在 2022 年 11 月发布，改变了世界。微软是第一个对这一“ChatGPT 时刻”做出反应的超大规模云厂商，而且方式极其激进。早在 2019 年，微软就向 OpenAI 投了 10 亿美元；但到了 2023 年 1 月，他们又把这笔投资放大了 10 倍。同时，公司开启了史上最激进的数据中心建设周期，而这一切主要是由这家关键的 AI 合作伙伴驱动的。
下图（文中提及）展示了数据中心预租活动情况，这是衡量产能增长和资本开支最好的领先指标之一。从 2023 年一季度到 2024 年二季度，微软的数据中心预租规模远超其它所有超大规模云厂商之和。仅在 2023 年三季度，微软一家的租赁量就接近 2022 年北美整个市场全年总租赁量。
而数据中心租赁只是故事的一部分。我们的“逐楼栋”数据中心行业模型显示，2024–2025 年期间，微软自建产能以空前的 MW 规模增加。同时，他们还与 CoreWeave 和 Oracle 签订了数十亿美元的合同以获取更多产能。
微软与 OpenAI 的训练集群——从“一栋楼的一角”，到“全球最大设施”
这一扩张中最具象征意义的项目，可能就是 “Fairwater” 计划。在 2023–24 年，微软规划并同步建设了地球上规模最大的两座数据中心。我们先稍微回到过去，看一下微软在这一轮之前的第一个主要训练集群，以感受 2023–24 年扩张的尺度。
他们在爱荷华州的园区中，建成了第一个大型训练集群——GPT-3.5 就是在这里训练的。我们估算该集群约部署了 2.5 万块 A100。尽管整座园区本身已经不算小，但我们认为 OpenAI 实际只用了一栋 Ballard 楼中的两个数据大厅，总计约 19 兆瓦 IT 负载。
第二个重要集群位于亚利桑那州，并且是按“楼栋滚动扩建”的方式逐步放量：第一栋 H100 楼在 2023 年完工；2024 年在另一栋楼里部署了 H200；之后又在两座数据中心中部署了 GB200。总体来看，我们估计整个集群横跨四栋楼，总计约 13 万块 GPU。
微软为 OpenAI 打造的下一代集群，被命名为 Fairwater，规模比前一代大得多。每一个 “Fairwater” 区域由两栋楼组成：一栋是标准的 CPU 与存储设施，约 48 兆瓦；另一栋则是超高密度 GPU 楼。这栋 GPU 楼总共两层，总建筑面积约 80 万平方英尺，IT 功率约 300 兆瓦，相当于超过 20 万户美国家庭的用电量。这意味着每栋 GPU 楼可容纳 15 万片以上的 GB200 GPU。下图（文中提及）展示的，是位于威斯康星州、完全为 OpenAI 专用的这座设施。
在佐治亚州，QTS 为微软建设了一个“姐妹”设施，同样服务于 OpenAI。虽然冷却系统不同，但这栋 GPU 楼同样是约 300 兆瓦。文中配图展示了该设施的规模——世界上没有任何一栋楼安装过这么多用于冷却的风冷冷水机组！现场变电站的规模同样非常惊人。
不仅单栋楼是全球最大，它们所在的园区也极其庞大。在亚特兰大，第二座 Fairwater 园区已经在紧锣密鼓建设中。
在威斯康星州，第二座 Fairwater 即将开工，但故事并未结束：微软正为一个更大的第三期做准备。我们认为，微软已经设计了两栋单体功率超过 600 兆瓦的楼宇，每个设施中的 CPU/存储和柴油发电机规模，相当于标准 300 兆瓦 Fairwater 的两倍。下图（文中提及）展示的，是这些 600 兆瓦建筑对应的场地规划。一旦这些楼按计划建成，它们将成为全球功率最大的单体数据中心建筑。
在全部建成后，该园区将成为世界上最大的数据中心校园之一，总 IT 产能超过 2 吉瓦。
更妙的是，微软计划让所有这些大型 AI 区域通过一张超高速 AI WAN 网络相连，其带宽超过 300Tb/s，并具备扩展到 10Pb/s 以上的能力。我们在一年前的文章《多数据中心训练：OpenAI 打败 Google 基础设施的雄心计划》中就强调过这一点。
下图（文中提及）展示了一个假想 5 吉瓦分布式集群的网络设计示意图。我们将在报告后文借助 AI 网络模型，详细讨论 Fairwater 的网络架构。
多吉瓦级的“急刹车”
在“火力全开”之后，微软突然选择了“踩死刹车”——而且是极其夸张的方式。
从整体数据中心预租余额来看，在高峰时刻，微软单独就占据了超过 60% 的预租合同！但在 2024 年二季度（自然年）之后，微软新增预租几乎冻结，而其他超大规模云厂商则明显放量。如今，微软在超大规模云预租总量中的占比已经跌到 25% 以下。
与此同时，微软还退出了多地、合计数吉瓦规模的非约束性 LOI（意向书）：
这些场址最终落到了其它大玩家手里，比如 Oracle、Meta、CoreWeave、Google、Amazon 等。由于这种犹豫和对 AI 的缺乏信心，微软永久性地让出了一大块本可以属于自己的 AI 基础设施份额。
此外，微软也显著放慢了自建项目的推进。我们在文中展示了一些照片，对约 950 兆瓦的“冻结” IT 产能做了标注。这还不包括在弗吉尼亚州、佐治亚州、亚利桑那州以及海外的多个其他数据中心项目。
在同一时期，其他玩家建设的大型数据中心从“破土动工”一路推进到“跑满负载”。总计来看，微软暂停了超过 3.5 吉瓦、原本可以在 2028 年之前建成的产能。细节数据都在我们的数据中心模型中。
微软的 AI 组合拆解：IaaS、PaaS、模型、应用
要理解“大暂停”（Big Pause）的成因和后果，我们需要把微软的 AI 业务拆开来看。我们最喜欢用的框架，是所谓的“AI Token 工厂经济栈”（AI Token Factory Economics Stack）：
从芯片到 token，这条链路上有一整排供应商，都暴露在 AI 基础设施建设这股浪潮之下。
目前，单点毛利最高的环节毫无疑问是芯片层，由英伟达约 75% 的毛利率驱动。
围绕下面这四层，市场对其终局利润率结构仍存在激烈争论：
应用层（Application layer，例如 ChatGPT、Microsoft Copilot、Claude Code 等）
模型层（Model layer，例如 Claude 4.5 Sonnet、GPT5-Pro、DeepSeek R1 等）
IaaS 层（例如 CoreWeave 把裸金属 GPU 集群租给 Meta，Oracle 把 GPU 租给 OpenAI，Nebius 在多租户集群里租 SLURM 和 K8s 给创业公司……）
PaaS 层（例如 AWS 通过 Bedrock 向某家财富 500 强企业卖 token，Nebius 把一小部分 GPU 集群算力配上 SLURM 和 K8s 卖给初创公司……）
以今天的定价来看，头部模型厂商在其直连 API 业务上的毛利率可以达到 60%+。
Azure 的 AI 裸金属服务——主动离开 1500 亿美元的 OpenAI 毛利池、执行不力与 ROIC 的担忧
在大规模构建 Bare Metal GPU/XPU 集群的生意里，赢家都掌握了一门“搭基础设施”的重工业艺术：执行速度、对市场与终端需求的理解、站址选择、融资能力等等，缺一不可。
我们之前对 Oracle 的深度拆解，就指出它在战略上做出了重大调整，从而赢得了市场。除了科技巨头以外，CoreWeave 是一个典型案例：一开始完全没有规模，但靠着在上述几个维度上近乎完美的执行，硬是卷进了第一梯队。现在轮到看看微软的执行表现。
令人失望的执行、丢掉 Stargate 合同
要评估微软在裸金属上的表现，很有必要重新审视前面提到的 Fairwater 项目。
2024 年年初，市场开始流传微软为 OpenAI 打造的 1000 亿美元级“Stargate”项目的传闻。我们认为，他们原本计划把这个集群放在威斯康星的数据中心园区。如前所述，该园区的规划路线最终会把站点容量推到 2GW 以上。
结果是，第一份 1000 亿美元的 Stargate 合同，最终落在了 Oracle 的怀里，站点位置在得州 Abilene。我们认为，微软缓慢的执行节奏是关键因素之一：在破土动工两年多之后，第一期依然没有投入运行。相比之下，Oracle 在 2024 年 5 月为 Abilene 数据中心破土，在 9 月就开始投产。
我们也认为，微软对这轮 1.5GW 扩容的规划非常糟糕。从输电角度看，满负荷能力要到 最早 2027 年中才能交付，比 Oracle 的 Abilene 集群突破 1GW 晚整整一年。微软无法跟上 OpenAI 对“尽快扩容”的诉求——这暴露出他们对市场需求的误判。这个对算力有着近乎无底洞需求的 AI 实验室，只能被迫去寻找其他合作伙伴。
主动放弃 1500 亿美元 OpenAI 毛利
正如我们今天所看到的，Oracle 已经成为 OpenAI 的主力 GPU 合作伙伴。双方在过去 12 个月签下的合约总额超过 4200 亿美元，折算下来约 1500 亿美元的毛利池；每一份 Neocloud 计算合约及其成本/利润拆分的详细建模，在我们的 AI TCO 模型中都有呈现。
如果我们以典型的 5 年合约期来估算，这相当于每年 300 亿美元的毛利。对微软而言，这本可以让其 FY25 约 1940 亿美元的年度毛利增加 18%+。
公正地说，丢掉 OpenAI 合同并不完全是执行问题，也在某种程度上是一个主动的战略决定。站在微软的视角，如果拿下 OpenAI 的全部大单，会显著拉低 Azure 业务的整体质量，原因包括：
几年内，OpenAI 的收入就会逼近 Azure 总收入的 50%；
其利润率与投入资本回报率（ROIC）远不如 Azure 传统云业务；
和微软整体业务相比，Oracle 的 AI 业务 ROIC 确实更低，大约在 20% 左右，而微软整体 ROIC 目前在 35–40%。但如果我们把微软账面中来自 OpenAI 的分成收入剥离掉（这一分成预期将在 2030–2032 年之间结束），微软自己的 AI ROIC 其实也并不会比 ORCL 的高多少。
问题在于：微软似乎忘了自己最近才学到的一课——他们在过去几年刚刚完成了一次转型：从 AI 里大量依赖裸金属工作负载收入，转向更多依赖 API 与 Token 工厂模式，从而持续抬升了自身的 ROIC 画像。现在，他们很可能是在用自己的机会，去“资助”一个未来的竞争对手进入同一个 AI 工厂赛道。
如果要全面量化 OpenAI、Oracle 与微软三方的经济性，细节都在我们首创的 Tokenomics 模型中。该模型构建在我们的数据中心与加速器追踪体系之上，覆盖每一笔重要算力合约，并拆解其所有关键财务指标：增长、利润、ROIC、资金来源等等。
低估需求、RPO 份额流失、对 Neocloud 产能的急迫依赖
从微软这轮暂停中，我们学到的一个关键教训是：他们严重低估了来自其他玩家的 XPU 云需求规模，例如 Meta。
我们正在见证这次误判的后果：其他玩家在 RPO（合同负债/剩余履约义务）上的新增规模，明显多于微软。
微软如今确实重新回到了市场，但在扩张短期产能方面已经弹尽粮绝，只能被迫选择最差的一种方式：从 Neocloud 手里租 GPU，然后再转租给第三方，要么以裸金属形式，要么通过 Foundry 以 token 的方式卖出去（我们后文会讨论 Foundry）。显然，这种“租裸金属再转租裸金属”的模式，会把 Azure 的利润率压得远低于正常水平。
微软选择不大规模自建数据中心，结果就是在意识到自己犯错之后，只能给 Neocloud 交毛利。
PaaS 层——不是所有 GPU 都在“正确地”部署
曾经的“金牌云”… 正在面临降级风险
在 3 月发布的 ClusterMAX 1.0 中，我们指出 Azure 在网络性能、安全性、最新 GPU 的供给以及获取 OpenAI 大部分算力部署方面处于领先位置。这让它稳居我们评级体系的 “金牌档”（Gold tier），仅次于 CoreWeave，并与 Nebius、Oracle、Crusoe 等公司处于同一梯队。
然而等到 11 月初 ClusterMAX 2.0 发布时，情况已经发生变化：面向 AI 工作负载的新一代 CycleCloud 与 AKS 功能，其开发节奏明显停滞。
在我们的调研中，我们与超过 140 家算力买家进行过深入交流，这些买家涵盖了从 OpenAI、Meta、Snowflake、Cursor 这样的头部 AI 公司，到 Periodic Labs、AdaptiveML、Jua、Nous Research、DatologyAI、Cartesia 等初创公司。调研结果非常清晰：
在托管集群或按需 VM 市场，Azure 根本算不上重要玩家。
Azure 面向大规模集群的 GPU 产能似乎几乎全部直接流向了 OpenAI，剩下零头则被一些传统《财富》500 强企业的内部开发者吃掉。这类企业往往通过长期企业协议，把所有 IaaS 都锁在 Azure 体系内——他们爱做的是内部 RAG 聊天机器人。
在我们的实测中，也能看出为什么 Azure 不在 AI 领域大卖托管 Slurm 或 Kubernetes 集群：我们在 CycleCloud Slurm 集群上发现了大量易用性、监控、可靠性以及健康检查方面的严重缺陷。
Azure 向 OpenAI 提供的那种“批发式裸金属体验”（动辄按整个机房出租），和 CoreWeave、Nebius、Fluidstack 等厂商给终端用户提供的体验，几乎像是两个世界。
行业中典型的 GPU 计算买家，仍然在寻找规模 64–8000 张 GPU 的 H100、H200、B200 或 B300 HGX 服务器。很少有人主动去找 GB200、GB300，或者 AMD 的任何方案。 但微软却投入了巨量的时间与精力，在 AMD GPU 和 GB200/GB300 NVL72 机架级系统上，主要是为了服务他们的最大客户（也就是 OpenAI）。这些投入既体现在工程师薪酬对应的 OPEX 上，也体现在 GPU 采购与新机房建设对应的 CAPEX 里。
从开源社区的维度来看，这一问题同样明显。根据 Hugging Face 的数据（几乎是任何公司发布和下载开源模型的事实标准平台），与微软相关的 IP 所对应的模型每日下载量：
仅为 Amazon 的 1/5；
仅为 Google 的 1/3。
微软把 OpenAI 的大生意推走了，但它并没有在企业客户或长尾市场上“补回来”。就这个指标而言，他们明显落后于其他几家超大规模云厂商。
结果是显而易见的：那些主动寻找 AI 产能的公司，正在集体转向其他平台。 这类客户既包括一年期、仅 64 张 GPU、合同金额约 100 万美元的小单，也包括三年期、8000 张 GPU、合同金额超过 5 亿美元的大单。我们看到，有些初创公司在 3 月还只买了 256 张 H100，而到了 11 月就开始寻找 9000 张 GB300 NVL72。如今，这些增量，大多与 Azure 无关。
要重新赢得这一类客户，我们认为 Azure 必须对其面向 AI 的 CycleCloud 与 AKS 产品进行大幅重构：
简化当前集群部署与监控体验；
内建硬件健康检查功能，并默认部署到所有集群；
主动从硬件故障中恢复；
建立一整套 GTM（销售）、交付与支持团队，真正把这些集群交付到终端用户手上。
我们在 ClusterMAX 2.0 中已经提到：由于在从 A 轮到独角兽阶段的 AI 创业公司体验非常糟糕，Azure 面临被从“金牌”降级到“银牌”（Silver）的风险。
“可互换机队”（Fungible Fleet）与主权 AI（Sovereign AI）——对推理工作负载走向的下注
话虽如此，Azure 仍然有一套足以支撑成功的基础盘：
它在全球拥有 70 个区域、超过 400 座数据中心；
它运营着人类历史上规模最大的 SaaS 业务；
从面向美国情报机构的 “Azure Government Secret”，到面向中国消费者的 Windows PC，微软拥有为全球最大组织销售 IT 的丰富经验。
Azure 战略的关键，是把 AI 拉近到企业客户身边，利用其广泛的地理覆盖。这背后隐含着对 AI 工作负载未来形态的判断：
今天最大规模的推理场景，例如 ChatGPT 和代码助手，并不敏感于延迟，未来随着上下文时间尺度延长，会变得更不敏感。它们大多数情况下也不会直接接触敏感的企业数据。因此，延迟和数据本地性不那么重要——现在的游戏规则是：尽快扩大量、向全世界卖更多 token。
未来，企业级用例很可能会成为增长的重要来源。这些场景必须满足高安全性、数据本地化法规，以及大型企业偏好的环境与约束；同时，它们还会与非 AI 工作负载共存，例如在某个特定 Azure 区域里的 Cosmos DB 存储。缺点是：由于全球多数大都市都面临电力紧张，数据中心选址会更困难，相比那些在“人烟稀少但电力过剩”的地区建厂的玩家，扩容速度会更慢。
构建并利用全球足迹，是微软打造“可互换机队”（fungible fleet）这一主题的核心。他们已经拿到了一些战例。例如，字节跳动的 Seed 团队是在美国亚利桑那训练视频模型的，而不是在中国或马来西亚。 我们认为 ByteDance Seed 在美国本土，向所有主要超大规模云厂商租用算力。虽然这一次跑在的是竞争对手上，但从侧面证明了“机队可互换”在某些场景下是可行的。
这一基础设施策略，与 OpenAI 等头部 AI 实验室的做法有明显差异。对于那些最耗电的工作负载（例如 Deep Research、复杂推理模型），响应时间本来就需要几分钟，网络延迟多几毫秒完全不重要。
随着 AI 任务时间尺度不断拉长，与用户的物理距离越来越不重要。
数据中心可以建在任何可行的地方，然后服务全球流量。更进一步的是，模型训练后的各类工作负载（post-training），计算量也在迅速上升，这些负载同样对延迟不敏感，也不一定需要绑定在某一个集中式算力池里。
折旧周期与 Azure 中 GPU 的未来
如果你试图把这支“可互换机队”拆开来看，有一个关键因素不得不提——最近也被讨论得很多：折旧。
著名的 Michael Burry 最近声称，所有几大云厂商（Meta、Google、Oracle、Microsoft、Amazon）都在通过延长 IT 资产的使用年限来虚增利润。这种调整把“使用寿命”从 2020 年的 3–5 年，拉长到今天的 5–6 年。
Burry 的论点建立在一个前提上：英伟达现在的产品迭代周期是 2–3 年，远短于会计账面上的资产寿命。我们认为，这一前提存在致命缺陷。新的会计处理方式，虽然在短期内对公司账面有利，但它同样是建立在数据中心真实运营经验基础之上的。
回到 2020 年，当微软、Meta、Google 把 IT 资产寿命从 3 年延长到 4 年时，我们还处在 “BC 2 年”（Before ChatGPT，ChatGPT 之前的第 2 年）。如今，在 “AD 3 年”（After Da Launch of ChatGPT，ChatGPT 上线后的第 3 年），延长使用寿命对这些 CAPEX 极度饥渴的云厂商确实帮了大忙。
从 2020 年开始，IT 设备发生了什么变化并延续到 2025？答案是：可靠性与激励结构。
服务器 OEM，比如 Dell、SuperMicro、HPE、联想、Cisco 等，一直在卖附带 3–5 年标准质保的服务器。5 年保修当然更贵，但也有 6 年、7 年的延保选项。只要厂商愿意在仓库里备足备件，就能在节点损耗时派人去维修。
与此同时，网络设备厂商（Cisco、Arista、Aruba、Juniper 等）也在试验对交换机提供“终身保修”。存储厂商也有类似做法——你只需每年付支持费，他们就会持续更换磨损的硬盘。
可以把它想象成汽车市场：高端用户可能每两年就把奔驰换新车，而其他人则开着 20 年前的老破车，只要还能加油、还能买保险。
这一点在全球最大的 HPC 集群和超级计算机上得到了验证。这些系统跑的是市面上最顶级、最热、功耗也最大的处理器。超算中心是最早部署液冷的群体，他们会围绕整套系统来建数据中心，而不是试图把系统塞进一个现有机房里。
IBM Summit（橡树岭国家实验室）曾长期占据 Top500 的世界第一。该系统在 2018 年 6 月投入生产，直到 2024 年 11 月才退役，一共运行了 6.5 年。Summit 使用的是 2016 年发布的 IBM Power9 处理器，其采购流程最早可追溯到 2014 年。
Fugaku 于 2020 年部署在日本理研，目前仍在运行，排名 Top500 第 7。
Sierra 于 2018 年部署在 LLNL，目前仍在运行，排在第 20。
神威·太湖之光于 2016 年部署在无锡的国家超级计算中心，至今仍在运行，排在第 21。
像 El Capitan、Frontier、Aurora 这样的百亿亿次系统（目前 Top500 的第 1、2、3），在 2021–2025 年间陆续投产，预计会一直运行到 2027–2032 年。
最后，Eagle——微软的 NDv5 集群（含 14,400 张 H100）——在 2023 年部署，目前排在 Top500 第 5 名。我们预计该系统目前利用率极高，并将在未来多年持续运行。
把视角切回云厂商，我们仍然可以在 AWS 上买到 p3.16xlarge 实例，里面是 8 张 V100 GPU。通过 Shadeform、Prime Intellect、Runpod 等云市场平台，我们还能从 DataCrunch、Paperspace、Lambda Labs 等底层供应商那里租到类似的实例。
V100 于 2017 年 5 月发布，同年秋季开始量产出货，直到 2022 年 1 月英伟达才停止最后一批产品发货。换句话说，从发布那天起，英伟达为这代 GPU 提供了 超过 5 年的备件支持。超大规模云厂商和 OEM 有足够时间囤备件，把这些实例一路撑到今天——距离 V100 首次出货已经整整 8 年。
当然，以今天的标准来看，V100 在“每兆瓦收入”这一指标上的表现已经不算好。我们已经看到一些云厂商，开始从旧数据中心里拆掉 V100、A100，甚至早期的 H100，只为腾出电力和机房空间，去装更新一代的 GPU。
关键在于：他们这么做，并不是因为这些 GPU 用到“自然寿命结束”而不得不报废，而只是因为：在电力和面积紧张的约束下，要用更高单 MW 收入的资产替换旧资产。
优化 GPU 云经济性的关键，是最大化 GPU 的经济寿命。我们的 AI Cloud TCO 模型提供了一个有用的框架。以 H100 集群为例，在摊销掉资本成本之后，剩余运营成本约为 0.30–0.40 美元 / GPU / 小时。问题就变成：
在第 5 年以后，这张 GPU 是否仍然有能力以高于这个价格的水平实现变现？
这，才是折旧年限之争背后真正的核心问题。
这部分的运行成本，必须和每块 GPU 能带来的收入相匹配。很自然地，GPU 的“定价权”会快速衰减，因为英伟达不断推出新芯片，大幅提升 每美元吞吐量 和 每瓦吞吐量。我们的 AI Cloud TCO 模型 被全球绝大多数 GPU 大买家及其资金提供方所采用，用于对 Nvidia、AMD、TPUv7 & v8 以及 Trainium 2 & 3 全系列 SKU 做长期租赁价格预测，并且还提供详细的集群物料清单（BOM）分析。
我们的历史命中率一向相当高！但从 Azure 这类公司的视角看，目标是：相对于全市场拥有更高的定价权。这一点仍不确定，但大致可能演变为几种路径：
通过利用自身的企业客户关系、PaaS 层以及纵向一体化能力（应用、模型、tokens 等），Azure 或许能从已经服役 6 年的 GPU 上榨取足够多的价值，从而避免提前退役这些设备。
另一条路径，同样与企业业务相关，是在加速计算之上，叠加销售更高毛利的服务（例如非 AI 的数据库等）。即便这些服役 6 年的 GPU 单独来看已经不再赚钱，只要它们是推动客户购买高毛利服务的关键因素，继续运营它们依然是有经济意义的。
在我们看来，这正是 Azure 的“可互换机队（fungible fleet）”战略可能成立，并使其长期 ROIC 高于其他玩家 的原因之一。最大的未知数仍然是：企业级 AI 采用的实际规模，以及 Azure 能否成功向这些企业客户加售更高价值的服务。
未来会怎样？Vera Rubin 是否真的能实现宣称的性能，从而像 Burry 所说那样，迫使云厂商在 GPU 服役 2–3 年后就拆掉这批本来还能创造收入的设备？还是说，我们在 H100 上测得的价格底部，能在未来继续站得住？这些问题尚无定论，而我们的 TCO 模型给出了目前为止我们最好的估计。借助我们对 GPU 云的专有测试项目（ClusterMAX），以及通过 InferenceMAX 进行的每日基准测试，我们的目标是提供全市场最有洞见的数据。我们的免费开源平台 InferenceMAX 展示了类似 Nvidia GB200 BVL72 这样在系统级的创新，在某些特定用例与配置下，相比传统基于 HGX 的 GPU，可以带来数量级的性能提升。
Azure Foundry：面向企业的 Token 工厂
Azure Foundry 是微软的 “Token-as-a-Service” 业务：
它提供多种模型，既为内部服务（如 M365 Copilot、GitHub Copilot）提供 token（1P tokens），也通过推理端点向外部客户提供模型调用（3P tokens）。Azure Foundry 的市场打法与 OpenAI API 类似，主要竞争对象就是各类个人与企业级模型使用场景。由于微软对 OpenAI 模型权重拥有 IP 权利，它在定价上也可以独立决策。
目前，大部分 GPT API 的 token 仍然是直接通过 OpenAI 处理，但我们预计 Foundry 将成为微软未来重要的增长引擎，拿回一部分份额。对微软来说，有一个关键事实：不论调用是通过 OpenAI API 还是 Azure Foundry，只要是这些 API 推理算力，直到 2032 年前 100% 都在 Azure 上跑。
不过，我们认为，向企业销售 token 的这门生意仍处在非常早期的阶段。Alphabet CEO Sundar Pichai 在 2025 年三季度财报电话会上提供的披露，很好地印证了我们的判断：
在过去 12 个月中，接近 150 家 Google Cloud 客户，各自使用我们的模型处理了约 1 万亿个 token，覆盖各种应用场景。
这项披露意味着，这 150 家企业购买的 Gemini tokens，在 GCP 整体业务里占比还不到 0.5%。
把 token 变成收入这件事，远比表面看起来复杂得多。我们经常看到分析师在如下方面犯大错：
忽略输入 / 输出 token 比例；
忽略缓存 token 带来的影响；
错算价格结构等等。
我们的 Tokenomics 模型 提供了一个完整的框架，用来理解“生成 token 的经济学”，以及如何将 tokens 与功耗（watts） 进一步转化为收入、利润和 RPO。
应用层：GitHub Copilot 的护城河正在被蚕食
在代码辅助的应用层，微软曾凭 GitHub Copilot 处于绝对统治地位：
它是第一个“行内补全”（in-line）代码模型，现在通常被称为 “tab 模型”；
依托其对 OpenAI 模型 IP 的独家访问，很早就把 GPT-4 集成进了 Copilot。
从外部看，微软的堡垒几乎固若金汤：
它拥有 VS Code 和 GitHub，这几乎是业界标准工具；
拥有 OpenAI 模型 IP 的独家产品化权限；
拥有庞大的企业销售渠道。
但他们低估了一波初创公司的崛起：这些创业团队 fork 了 VS Code，自行打造更紧耦合、与代码库深度联动的集成体验，使得这些挑战者整体上在体验和能力上超越了 Copilot。一个关键的推动因素是：这些初创公司广泛采用了 Anthropic 的模型。
微软最终在 2025 年初不得不把 Anthropic 加入 GitHub Copilot 的模型选项中，但这对其毛利率的打击很大：
GitHub Copilot 从几乎 100% 使用内部 1P token，变成必须大量向 Anthropic 购买 token，后者毛利率在 50–60%。
各大实验室也自己做产品。用户必须绑定在某一家的模型上，但这些模型是用与生产环境一模一样的 harness 和环境训练的，体验非常优化。从 Codex 和 Claude Code 的收入爬坡可以看出，这种体验非常受欢迎。
此后，微软加倍押注所谓的“模型超市生态”，最近推出了 Agent HQ，可以接入来自多家实验室的 Agent，包括 Google 和 xAI 等。
但鉴于他们对 OpenAI 模型权重的访问时间只延续到 2032 年，微软必须为其当前毛利最高的 OpenAI 模型产品准备一套备用方案。
微软自研模型：MAI
微软已经发布了 3 个 MAI 模型，覆盖文本、图像和语音：
文本模型 MAI-1 在 LMArena 排名大约在 38 名左右，但目前尚未通过 Chat 或 API 公开放出。它是一个大型 MoE（专家混合）模型，使用了 15,000 张 H100 训练。下一代模型将是一款更大规模的多模态大模型。
另外两个分别是图像与语音模型。图像模型目前仍然位列 LMArena Top 10，二者都已经在 Copilot 中可用。
对微软而言，后面这两个模型代表的是一类“低成本 + 质量尚可”的使用场景。它们距离真正的 SOTA（state-of-the-art）还有明显差距，但我们认为，微软正在悄然为更大规模的内部训练项目蓄力，计划在未来几年把年化算力支出提升到接近 160 亿美元 的水平。
Office 365 Copilot
微软的 Copilot 不只是 GitHub Copilot，而是一个更大的“伞”：
其中包括 Sales Copilot、Finance Copilot、Service Copilot、Security Copilot 等多个产品线。这个 Copilot 伞状体系的月活用户数已经超过 1 亿，将是整体 AI 采用的重要驱动因素。
最新的 Office 365 Copilot 工作，集中在所谓的 Office Agent 中，我们在下文主要讨论其中的 Excel Agent。总体目标是：
让这些 Agent 能够在微软生态内跨应用自主地执行动作，既要有用，又要稳定、可操作。
微软的优势：OpenAI IP + Office 用户数据
对 OpenAI 模型、权重和代码库的访问，使微软可以直接从 OpenAI 模型的原始 Chain of Thought（思维链） 中做“蒸馏”。这种蒸馏方式，比事后再去训一个小模型要高效得多，意味着微软可以在 不增加太多算力成本 的情况下，获得相当可观的能力。
获取 OpenAI IP 的访问权，也让微软可以用自己掌握的数据，对这些模型做更细粒度或更基础的微调——这些数据有可能远比外界在 Office 套件之上构建各种 harness 或环境时所能接触到的数据更深入：
“我们绝对会在所有产品中，把 OpenAI 模型用到极致。”
Excel Agent 本质上是对某个 OpenAI 推理模型的后训练版本（post-trained）。微软声称，其效果优于当下的一线实验室模型。
在深入剖析了 Azure 的 AI 业务之后，我们把注意力转向 Azure AI 硬件栈中的两个关键部分：
微软的真实芯片战略：如何在 Nvidia、Maia、OpenAI、AMD 以及其他芯片之间取得平衡；
Azure 的网络架构，以及它对广泛供应商的影响。
Mama Ma-ia!：定制 ASIC 的困境
在定制芯片开发上，微软在几大超大规模云厂商中垫底，而且压根没有表现出要“迎头赶上”的意思。
微软在 2023 年底展示了 Maia 100 加速器，是四大超大规模云厂商中最后一个拿出 AI 加速 ASIC 的。
如同第一代自研芯片常见的情况，Maia 100 并未大规模量产，也没有承担大规模生产负载。它的架构是在 GenAI 爆发之前设计的，在推理所需的内存带宽方面明显不足。一般来说，ASIC 项目需要经历多代迭代，才能真正大规模承接从通用商用系统迁移过来的计算负载。
下一代 Maia 200 的开发也被各种问题拖累，导致设计周期拉长、流片推迟到 2024 年底，量产要到 2025 年才能启动。按计划，Maia 200 在 2025–2026 年间的出货量，只是微软同行（Google、Amazon，甚至 Meta）的一个小分母。这是因为，在内部评估中 Maia 200 被视为失败品，迫使微软不得不重新规划其 AI ASIC 路线图。
微软甚至已经基本放弃了针对 Maia 200 的软件栈开发，而是把精力放到后续的 Maia 迭代上。照目前的规划，到 2027 年底之前，微软最早也只能在 2nm 工艺上拿出 Maia 300，才能达到“接近”内部性能预期的水平。 在那个时间点上，竞争标准会被抬得更高——微软要面对的是 Nvidia Vera Rubin。鉴于目前 Maia 团队的管理状况，我们对他们在 2027 年表现出色并不抱任何信心。
从那之后，还需要多代迭代，才能逼近 Nvidia 在“单位 TCO 性能”（performance per TCO）上的水平。目前，只有 Google 在这条路上跑通了，从而把自研 TPU 做到了这个高度——而且他们已经开始出货第七代 TPU。Satya 的论点是：内部自研芯片的意义，在于软硬件的紧密协同设计，因此他们希望把 Maia 设计成专门用来训练和服务 MAI 模型的芯片。
这实际上把 Maia 的命运绑在 MAI 模型上，问题在于：MAI 能否真正做出一款“领先模型”，这本身就是一个巨大的“如果”（而不是“当……时”）。在这段漫长等待 MAI 做出成绩的时间里，原本可以用于硬件迭代的宝贵时间被白白浪费了。要求 MAI 先准备好，只会多加一个 Microsoft 硬件成功的前置条件。更何况，正如 Amazon 的故事所示，有没有自家 SOTA 模型，本身并不是做定制芯片的“天赋权利”。
从 CoWoS 产能预订的角度看，微软的 AI 自研芯片出货量远低于 Google、Amazon 和 Meta。接下来，我们来看这些同行究竟领先了多远。
由于拿到了 OpenAI IP 的访问权，微软很可能干脆依赖 OpenAI 的芯片。我们也认为，这很可能意味着 Broadcom 又多了一个定制 ASIC 大客户。在 AI 芯片市场的高端价值捕获上，正迅速演变成 Nvidia vs Broadcom 的双雄格局。
借助芯片初创公司
当 Maia vs OpenAI/Broadcom vs Nvidia 的问题悬而未决，而微软又开始在供应商之间分散芯片依赖时，我们认为，他们也会在整个技术栈上更多地转向初创公司寻求帮助。
具体来说，微软的风投基金 MI2 最近发布了一张照片，宣传一场活动，主角包括 Modular、Neurophos 等初创公司：
Modular 是一家软件公司，做的是适配多种加速器（不仅是 Nvidia）的编程框架与推理系统；
Neurophos 是一家芯片初创公司，在做光学处理器（OPU），同样是奔着挑战 Nvidia 去的。
如果这些公司成功，它们将成为挑战 Nvidia 所需“拼图”的一部分：比如 Modular MAX 可以替代 vLLM 和 SGLang 这样的推理运行时，而 Neurophos 则通过其 OPU 芯片来挑战 GPU，并喊出类似“每皮焦耳 1000 倍 FLOPs”这样的口号。
总体来看，紧贴这一领域的初创生态 对微软而言是一个不错的布局方向，我们也预计未来会看到更多类似动作。
但话说回来，这些初创项目更多只是小概率会兑现的“边际赌注”。主线依然在失败中挣扎，管理层听到的更多是“拍脑袋说好”的观点。
其他 ASIC 项目 vs 微软
在几大超大规模云厂商中，Google 在自研芯片上的优势几乎是碾压级的：
他们的第 7 代 TPU 很可能在性能上已经能和 Nvidia Blackwell 同台竞争。TPU 为 Gemini 系列模型 提供支撑，后者的能力正在不断提升，在某些任务上，已经非常接近“每单位成本智能量”的帕累托前沿。尽管 Gemini 在代码任务上不是最强模型，但 Gemini 2.5 Pro 仍然相当能打，而 Gemini 3 即将推出，会把 Google 再往前推一大截。
TPU 不仅满足了 Google 内部搜索、广告、DeepMind 等业务的 AI 需求，如今 Google 也即将迈入类似 Nvidia 的 商用 AI 硬件公司 角色：
外部客户已经在为明年的 TPU 订货，数量非常可观；
其中之一是 Anthropic——他们与 Google 联合宣布，将在明年订购 至少 100 万颗 TPU。我们在这则公告发布前约两个月，就已经向 Accelerator Model 订阅用户提前披露了这一消息。订阅该模型，可以了解其他外部 TPU 大客户及其订货量。
总体来看，Google 仍在为超大规模云厂商 AI 芯片设定标杆。
不再需要商用 GPU 来满足内部负载是一件事，有多个复杂外部客户也愿意使用你的 ASIC，则是另一层级的成就。
Amazon 则在其 Trainium 系列加速器 上出货了数百万颗芯片，其中 Anthropic 是 Trainium2 的锚定客户，几乎吃下了整个 Trainium2 项目。正是 Trainium2 为 Anthropic 部署的这些集群的放量，驱动了 AWS 收入的这波明显再加速，这一点我们此前就判断对了。
有趣的是，这意味着 Amazon 在 Trainium 上的需求几乎都是外部需求。从某种意义上说，这是因为在几大云厂中，Amazon 对自研“前沿模型”的兴趣最小，更满足于扮演一个“纯基础设施提供者”。
而这点，恰好对微软的努力构成了反讽：
Amazon 已经毕业成了一家“商用 AI 系统提供商”。
他们会通过出租自家 AI 硬件赚取大量毛利，而且是在几乎没有太多内部工作负载来“自己吃自己的狗粮”验证软硬件栈的情况下做到的。这直接反驳了 Satya 所谓“你最好有自己的模型来撑起 ASIC 项目需求”的说法：
在 Amazon 的故事里，是 Anthropic 带来了模型，并在系统设计上发挥了重要作用；
Anthropic 也有动力把整个系统折腾到能真正降低 TCO、并提供更多推理和后训练算力为止。
Meta 则处在其 ASIC 路线图上的一个重大拐点。即将推出的 MTIA “Athena” 将是 Meta 第一款更接近现代 GPU 的芯片：一个大型计算核心，与 HBM 封装在一起。目前，这款芯片的出货已经从代工厂出来了。
明年，他们会推出下一代 “Iris”，之后不久是其“中代升级版” “Arke”。Meta 的路线图非常激进，目标是在硬件实现上超越 Nvidia，包括：
为大规模扩展引入 CPO；
使用混合键合（hybrid bonding）；
把 DRAM 放在逻辑芯片之上等等。
结论很清楚：所有超大规模云厂商都将部署能够承载真实工作负载的 ASIC，除了微软。
微软的芯片团队不仅要和其他云厂竞争，更要直面真正的对手——Nvidia。祝好运。
如果微软在加速器上完全依赖出租 Nvidia GPU，因为他们根本没有自己一款能吸引外部需求的加速器，那它就只能和 Oracle、CoreWeave、Nebius 这些玩家去拼。与此同时，Google 和 Amazon 则可以依靠自家差异化技术栈，去赚更高的利润率。
正如我们前面提到的，在构建 AI 基础设施时，加速器芯片是单体成本最大的项目：
以英伟达的高端 GPU 为标准，它自带约 75% 的毛利率；
这相当于在芯片成本之上叠了 4 倍的加价。
设计自研芯片的主要目标之一，就是把这部分毛利吃掉：
由云厂自己设计芯片，
然后直接拿设计去台积电生产。
但现实是，这些云厂并不具备端到端的芯片设计能力，因此必须依赖 Broadcom、Marvell、联发科、Alchip、GUC 等设计伙伴。这些伙伴也要赚自己的毛利，但整体上仍然会比英伟达收得少，即便是 Broadcom 这种“头等舱”级别的服务。
下图（原文）展示的是：在加速器芯片上压低毛利率，如何降低整体成本，从而提高云服务提供商的利润率。这一推演假设自研芯片在性能上与英伟达完全相同——显然这不现实，但足以说明压低芯片成本带来的收益。
若要真正理解部署 AI 系统背后的经济学，可以参考我们的 AI Cloud TCO 模型。
OpenAI 的自研芯片计划
微软在这件事上没有任何借口可找：他们通过早期且前瞻性地投资 OpenAI，对模型架构早就有足够的洞察。但照目前这个节奏发展下去，OpenAI——这家曾参与 Maia 200 设计的公司——很可能在定制芯片上反超微软，尽管他们启动自研芯片的时间要晚好几年。不过，这对微软而言也可能是件好事：微软对 OpenAI 知识产权的权利覆盖到除消费级硬件之外的所有领域，这其中就包括对 OpenAI Titan ASIC 产品线的访问权。鉴于 OpenAI 在 ASIC 上的演进路线要远好于微软的 Maia，很有可能最终是微软直接使用 Titan 来服务 OpenAI 模型。这种局面与微软在 OpenAI 模型上的处境十分相似：即便他们可以访问 OpenAI 模型，仍然要自己通过 Microsoft AI 去训练自家的基础模型。和模型一样，这种对芯片路线图的访问也不是永久性的，因为相关 IP 权利并不会无期限持续下去。依赖 OpenAI 的 ASIC，并不能实现“在硬件上自给自足”这一目标，而这恰恰是所有超大规模云厂自研 ASIC 项目的共同目标之一。
我们也认为，这将造就 Broadcom 的又一位定制 ASIC 大客户。AI 芯片市场高端价值捕获的格局，正迅速演变成两家公司的对决：NVIDIA 对 Broadcom。
网络
从 2,048 块 GPU 到 524,288 块 GPU——微软高基数交换机的魔法
微软在其位于亚特兰大的 Fairwater 2 数据中心中部署的网络方案极具创新性，站在当今 AI 集群部署方式的前沿。Fairwater 2 的网络在“两层 512 基数网络”的理念上更进一步，采用了“纯 rail 拓扑”（rail-only topology），将一套两层、512 基数网络上可连接的 GPU 数量，从 131,072 块提升到了 524,288 块。
在一个使用 k 端口交换机、具有 L 层交换机的无阻塞 Clos 网络中，可连接的 GPU 数量可以用下面的公式计算。如果我们假设使用 Spectrum-X SN5600 交换机构建一个两层网络（L=2），每个交换机提供 64 个 800G 逻辑端口（k=64），那么可以发现，在这样的两层网络上最多可以连接 2,048 块 GPU：
基于一个 64 端口交换机，下表展示了在最多 4 层交换机情况下的 GPU 最大连接数量。随着网络层数增加，“每台交换机对应的 GPU 数量”会下降，使得“每块 GPU 对应的网络成本”变得更高。
但如果我们把每块 GPU 上单个 800G 逻辑端口拆分成 8 个 100G 端口会怎样？CX-8 网卡可以支持拆分为若干条 100G 通道，但并不是所有 51.2T 交换机都支持 512 个 100G 逻辑端口——此时就需要像 Spectrum-5 这种 512 基数交换机。魔法来自于：端口数量 k 会以网络层数 L 为指数进行放大，在这种拆分方案下，我们可以连接多达 131,072 块 GPU——相比没有高基数交换机时的 2,048 块，是一次巨大跃升。
使用 512 个 100G 端口替代 64 个 800G 端口时，最多可连接的 GPU 数量如下所示：
那如何构造这样一张网络？我们可以使用 8 个相互独立的叶交换机平面（leaf-switch plane），去分别连接每块 GPU 上的 8 个 100G 端口。每个平面会包含 256 台脊骨交换机（spine）和 512 台叶交换机（leaf），这 512 台叶交换机通过单条 100G 链路分别连接 256 块独立 GPU，总计 131,072 块 GPU。
但每个平面仅连接到每块 GPU 的一个 100G 逻辑端口，因此我们需要 8 个平面。把 8 个平面乘以每个平面上的 768 台交换机，总计得到 6,144 台交换机。此时的“GPU 与交换机比例”为每台交换机 21.3 块 GPU，相比使用 800G 端口、构建 4 层网络时每台交换机 9 块 GPU 的比例要高效得多。这就是正在 Oracle 的 Stargate 上部署的网络拓扑，也是 Nvidia 和 Broadcom 的 512 基数交换机正在获得实际牵引力的一个典型应用场景。
微软的纯 rail 架构——通往 524,288 块 GPU 的路径
微软在这一思路上更进一步，部署了一种纯 rail 拓扑，用两层网络就能连接多达 524,288 块 GPU！在纯 rail 网络拓扑中，我们把“把每块 GPU 的链路拆分为多端口”的概念，推广为“把整个计算托盘（compute tray）的链路拆分为多端口”。与其把每块 GPU 的 800G 拆成 8 条链路，我们现在是把每个计算托盘上的 3,200G 拆成 32 条链路，每条分别连接到 32 个平面中的一个。
这张网络使用了 24,576 台交换机来连接 524,288 块 GPU，实现的“GPU 与交换机比例”依然是每台交换机 21.3 块 GPU，就像 131,072 块 GPU 的网络一样，但这次连接的 GPU 数量是前者的四倍！
然而，这些平面之间完全相互独立，这意味着同一计算托盘中的各块 GPU 不再能通过这张横向扩展网络进行通信，而必须通过 NVLink 网络上的 PXN 来交换数据。这确实带来了一个挑战：在同一张网络上很难把不同通信重叠在一起[CE1]，不过微软的 MRC 协议就是为优化这类通信、在训练层面为这些流量进行调度而设计的。
AI WAN：走出单栋机房——园区级 Scale-Across
尽管理论上微软可以使用 32 个平面来部署多达 524,288 块 GPU，但在现实中，Fairwater 2 中的每一栋楼（即 A 楼和 B 楼）最高只有 300MW 的容量，对应大约 160,000 块 GPU。与其继续在同一套多平面网络上硬塞更多 GPU，微软选择了另一条路：从脊骨层向外连接一条超卖的上行链路，接入一张 AI 广域网（AI WAN）。
微软专门为 AI WAN 做了架构，使得训练任务的调度方式可以利用并感知广域网的连接特性。其目标，是最终能在两处 Fairwater 园区（亚特兰大与威斯康星）之间，乃至在凤凰城、爱荷华 OpenAI 集群以及 Oracle 的 Abilene 园区之间，开展跨园区的分布式训练任务。
为构建这张网络，微软一方面连接这批相对“较少”的 GPU，一方面在 BT1（脊骨层）交换机上预留端口，以便向 OCS 做上行，并预留一些空闲端口供未来扩展使用。这样一张网络可以采用 32 个平面来构建，每个平面配备 128 台 BT1（脊骨）交换机和 154 台 BT0（叶）交换机，在 BT1 层之上还会有 OCS 交换机。
具体的超卖比例目前尚不清楚，不过 Meta 在其 10 万块以上 GPU 的集群中，跨数据中心连接时采用的是约 3:1 的超卖比。
在 BT1 的下行方向使用 DR 光模块，上行到 OCS 的链路则很可能使用 FR8 光模块，因为这允许把 8 条 100G 通道通过 CWDM 复用在一起，同时可以使用环行器在一根光纤上实现双向传输。由于 OCS 只能在单根光纤上切换光信号，能在这根光纤上挤进越多带宽，每个 OCS 端口所能提供的有效带宽就越高。采用 800G FR8 光模块还能保留 8×100G 的拆分，在接收端会将光信号再次解复用到 8 条独立通道上。
微软在 AI WAN 中使用光路交换机（OCS），以便在不进行复杂重新布线的前提下，灵活重构楼宇之间的光链路。不再需要深缓冲交换机，而是通过一套独立的协议，把报文通过 OCS 转发到不同的集群。Google 已经在其数据中心网络（DCN）中使用 Apollo OCS，理由是它在网络结构扩展、技术更新以及拓扑调整方面提供了极大的灵活性。
AI WAN：远距离 Scale-Across
除了用于 Fairwater 2 园区内连接的 AI WAN 之外，还有一张第二层级的 AI WAN，这是一张长途骨干网络，用来连接 Fairwater 2 园区与其他距离较远的微软区域——包括威斯康星的 Fairwater 1，以及凤凰城集群、爱荷华的 OpenAI 集群以及 Oracle 的 Abilene 园区。这些区域之间的长途链路总带宽为 300Tbps，并预留扩展到 10Pbps 的空间。
虽然 FR 光模块的距离能力足以连接 Fairwater 2 中这两栋 300MW 的机房，但要连接其他距离可达数千公里的园区时，就需要依赖跨洋级转发器（transponder）的功率与距离能力，并配合可重构线路系统（RLS），以便使用密集波分复用（DWDM）。为了更高效地利用长距离光纤，DWDM 会将多种不同波长的光复用在同一对光纤上，每种波长承载 800G 乃至 1.6T 的带宽。如果在 C 波段使用 32 个通道、在 L 波段再使用 32 个通道，把 64 条 800G 链路复用在一起，那么单对光纤就能承载最高 51.2Pbit/s 的带宽。
在下图中，我们展示了 300Tbit/s 的互联需求，是如何需要 375 对光纤（如果在 FR 光模块中使用环行器，则为 188 对）来连接 OCS 与转发器的，而在 C 波段上部署 32 个通道的 DWDM 后，可以将所需光纤对数降到仅 12 对。
ZR 光模块（400ZR 和 800ZR）是另一种可以用于数百公里传输的选择，多个 ZR 链路同样可以通过 DWDM 复用在同一对光纤上。ZR 光模块可以直接插在 AI 路由交换机上，从部署角度来说简单得多，但在跨越数千公里的长距离场景下，通常还是更倾向于使用转发器。事实上，Meta 的 scale-across 部署正在使用 ZR 光模块，而我们也看到了由于这类 scale-across 部署而带动的 ZR 需求的强劲增长。