Microsoft 利用 AWS 应对 GitHub AI 容量紧缺问题

Microsoft 集成 AWS 容量以稳定 GitHub

Microsoft 正在为 GitHub 的基础设施添加 Amazon Web Services (AWS) 容量，以防止由 AI 驱动的代码编写活动前所未有的激增而导致的业务中断。这一战略转变发生之际，“智能体开发”（agentic development）工作流——即 AI 智能体自主生成代码、提交（commits）和拉取请求（pull requests）——已经使 GitHub 的基础设施超出了其计划向 Microsoft Azure 迁移的极限。

虽然 Microsoft originally intended to move GitHub fully to Azure by 2027，但机器生成活动的量级已迫使公司采用多云策略，以确保弹性和扩展性。Microsoft 已确认将向多云基础设施进行更广泛的转变，尽管其在官方声明中并未明确提及 AWS。

智能体开发对基础设施的影响

GitHub 正在经历一条超过传统有机增长曲线的增长曲线，这主要是由以机器速度而非人类速度运行的 AI 智能体驱动的。

提交（commits）的指数级增长

GitHub COO Kyle Daigle 报告称，commits 在 2026 年有望达到 140 亿次，较 2025 年的 10 亿次大幅增加。这种规模会直接给平台的存储代码、处理 pull requests、更新搜索索引以及触发自动化任务的能力带来压力。

容量需求快速扩展

GitHub CTO Vlad Fedorov 指出，平台的容量需求在短时间内发生了剧烈变化：

• 2025 年 10 月： GitHub 开始了一项将容量增加 10 倍的计划。
• 2026 年 2 月： 公司确定需要按 30 倍规模进行设计。

这种加速归因于在 2025 年 12 月下旬激增的智能体开发工作流。尽管做出了这些努力，GitHub 2026 年 5 月的可用性报告指出，发生了九起导致服务降级的事件，其中包括 5 月 4 日发生的一次重大中断，该中断是由数据库模式迁移（database schema migration）引发的，并波及了 pull requests、issues 和 Git 操作。

Azure 容量限制与战略风险

尽管 Microsoft 投入了巨额资本支出——计划在 2026 日历年投入约 1900 亿美元——但 Azure 的容量并非无穷无尽。它需要在 OpenAI 需求、Microsoft Copilot、安全工作负载以及外部 Azure 客户之间进行分配。

基础设施作为瓶颈

Microsoft CFO Amy Hood 表示，公司预计在 2026 年之前将一直处于容量受限状态。这种内部稀缺性意味着，即使是像 GitHub 的战略资产，也必须在 GPU、CPU 和存储资源方面进行竞争。使用 AWS 的决定是一个承认，即 AI 基础设施的内部需求已经超过了 Microsoft 自身的云部署时间表。

AI 原生竞争对手的威胁

可靠性问题已从技术上的小麻烦转变为产品威胁。知名开发者，例如 HashiCorp 联合创始人 Mitchell Hashimoto，已公开批评 GitHub 的可靠性，称在经历重大停机后，该平台“不再是一个进行严肃工作的地方”。

这这种不稳定性为 Cursor 和 Anthropic 的 Claude Code 等 AI 原生开发者工具创造了机会。如果 GitHub cannot maintain a stable control plane for AI-assisted development，它面临着风险，即失去构成其网络效应核心的高信号量维护者和企业用户。

行业内“桥接容量”的趋势

GitHub-AWS 的安排反映了一个更广泛的行业趋势，即超大规模厂商（hyperscalers）向竞争对手购买容量以满足突发的 AI 需求。

• Google 和 SpaceX： 据报道，Google 已同意从 2026 年 10 月至 2029 年 6 月期间，每月向 SpaceX 支付 9.2 亿美元以获取计算容量。

这些交易表明，AI 需求目前正跑在世界最大数据中心规划和建设周期的前面，迫使即使是主要的云服务商也必须寻求外部“桥接容量”以维持服务稳定性。