微软旗下GitHub遭遇AI算力短缺，转而向AWS寻求支持

微软转向 AWS，因 GitHub 面临 AI 容量危机 - RuntimeWire

微软的 GitHub 容量危机促使其转向 AWS

AI 编程智能体已将 GitHub 的可靠性问题变成了一项基础设施难题，而 Azure 无法按微软的时间表独自消化。

作者Ryan Merket•发布于 2026 年 6 月 15 日晚 9:19（中部时间）•6 分钟阅读•7 个来源

AI 生成插图 · RuntimeWire（Gemini）

为何重要

微软为 GitHub 使用竞争对手的云容量，这表明 AI 编程已将开发者工具变成了一场超大规模基础设施竞赛，而不仅仅是软件功能之争。

萨提亚·纳德拉执掌的微软正在引入 Amazon Web Services 的容量，以维持 GitHub 的运行，此前 AI 驱动的编程活动激增使该平台不堪重负，Business Insider 周二报道，援引两位知情人士的说法。

这一安排与微软在 2018 年兜售的那套简洁版 GitHub 收购叙事背道而驰：买下这个开发者平台，把它的基础设施并入 Azure，让微软的云成为全球软件工作的默认底座。然而，GitHub 的负载曲线跑得比迁移计划更快。Business Insider 报道称，微软原计划在 2027 年前将 GitHub 完全迁至 Azure，但如今在该平台应对宕机和更高使用量之际，却从 AWS 增加额外容量。

微软确认了更广泛的多云转向，但没有点名确认 AWS。一位发言人告诉 Business Insider，自 2025 年末以来“智能体开发的惊人激增”已考验到 GitHub 的基础设施极限，并表示微软正在加速 Azure 迁移，同时探索多云策略以实现弹性和规模。亚马逊对该媒体表示，其不对单个客户置评。

尴尬之处正是关键所在。微软拥有 Azure，像超大规模云厂商一样大手笔投入，却似乎仍愿意让一个战略性开发者平台的一部分流量经由其最大的云竞争对手，因为 GitHub 宕机带来的运营风险已经比向 AWS 付费的观感更糟。

收购承诺撞上了智能体负载曲线

当微软在 2018 年 6 月宣布这笔 75 亿美元的 GitHub 交易时，Nadella 将其框定为一场开发者信任交易。微软表示，GitHub 将保留其开发者优先的精神，作为开放平台运营，并让开发者可以部署到任何操作系统、任何云和任何设备。这一承诺本是为 GitHub 用户而作。八年之后，它却成了 GitHub 自身的基础设施现实。

压力在 GitHub 自己的数据中清晰可见。据 Business Insider 报道，GitHub 首席运营官 Kyle Daigle（@kdaigle） 在 4 月写道，提交量有望在 2026 年达到 140 亿次，而 2025 年为 10 亿次。提交量不是收入，也不是衡量有用软件产出的完美指标，但对于一个必须存储代码、运行检查、处理拉取请求、更新搜索索引、触发自动化并通知协作者的平台来说，它们是一个直接的承压信号。

GitHub 官方的可靠性公告清楚表明，这不是一个正常的增长周期。在一份 4 月可用性更新中，GitHub CTO Vlad Fedorov 写道，GitHub 于 2025 年 10 月开始执行一项将容量提升 10 倍的计划，随后在 2026 年 2 月得出结论，需要按照 30 倍规模来设计。Fedorov 曾是 Meta 的工程负责人，在加入 GitHub 之前联合创立了 UserClouds，他将这一转变与 2025 年 12 月下半月急剧加速的智能体开发工作流联系在一起。

GitHub 的 5 月可用性报告显示，该公司已经在将大量流量迁移到 Azure：40% 的单体流量由 Azure 提供服务，高于 2 月的 8%，Git 流量为 30%，仓库复制为 99%。GitHub 还表示，其在四个月内将有效容量提升了一倍以上。同一份报告披露了 5 月发生的九起导致 GitHub 服务降级的事件，其中包括 5 月 4 日因一张高频使用的数据库表进行 schema 迁移而引发的中断，该中断级联影响到拉取请求、issues、actions、webhooks 和 Git 操作。

这就是 AWS 这一决策的背景。问题不只是原始算力。GitHub 正试图迁移、分片并加固一个成熟的协作平台，与此同时，AI 编程工具让机器生成的工作量激增，不断冲击着旧的共享系统。这个平台被要求在重建的同时、在使用模式于其底层不断变化的同时，变得比以往更可靠。

可靠性成了产品的威胁

对 GitHub 而言，最具破坏性的故障不只是宕机事件。它们会打断 GitHub 所售卖的工作流：审查 pull request、合并代码、运行 Actions、搜索 issue、解决事故以及推送发布。当这些工作流停滞时，开发者感受到的并不是一个云容量问题。他们感受到的是 GitHub 成了那个拦路者。

HashiCorp 联合创始人、Ghostty 终端模拟器作者 Mitchell Hashimoto 在 4 月成了这种反弹情绪的公开代表。Hashimoto 表示，在使用该平台 18 年后，他将把 Ghostty 迁出 GitHub，据 The Register 报道。他的抱怨是运营层面的，而非意识形态层面的：如果 GitHub 每天把他挡在外面数小时，那它"就不再是一个适合严肃工作的地方"。

这种离开之所以重要，是因为 Hashimoto 恰恰是 GitHub 无法将其斥为随意批评者的那类用户。他创办过开发者基础设施公司，参与打造了 Vagrant 和 Terraform 等工具，代表着那类高信噪比的开源维护者——他们的项目塑造了其他所有人的习惯。如果这些用户开始把 GitHub 的可靠性视为一种负担，那么竞争对手无需在整体上击败 GitHub 的网络效应。他们只需变得足够可信，能够承接 GitHub 未能保持顺畅的那些工作流即可。

Business Insider 报道称，GitHub 面临着来自 Cursor 和 Anthropic 的 Claude Code 等 AI 工具日益激烈的竞争，并且微软去年年底的一次内部会议讨论了彻底改造 GitHub 以与这些产品竞争。这种竞争压力改变了宕机的含义。GitHub 不再只是开发者存储和审查代码的地方。它本应是微软在 AI 辅助软件开发方面的控制平面。在这种背景下，平台宕机同时是 Copilot 的问题、Azure 的问题和微软开发者战略的问题。

Azure 的约束就是微软的约束

微软的支出规模本应让 GitHub 绕道 AWS 显得多此一举。但事实并非如此。在微软 2026 财年第三季度财报电话会议上，CFO Amy Hood 表示，公司预计在 2026 自然年的资本支出约为 $190 billion，其中包括约 $25 billion 与组件价格上涨相关的支出。Hood 还表示，微软预计至少到 2026 年仍将受到产能约束，即便公司正在努力加快 GPU、CPU 和存储容量的上线。

这对 GitHub 来说是关键所在。Azure 的容量并不是一个等待微软某个业务部门来认领的抽象资源池。它正在被分配给 Azure 客户、与 OpenAI 相关的需求、微软自家的 Copilot 产品、安全工作负载、数据服务和第一方应用。GitHub 的问题在于，它既是一项战略资产，又是争夺稀缺基础设施的又一个内部申领方。

我在微软内部也看到了同样的制约。在 Microsoft for Startups 团队时，我不断遇到 GPU 短缺问题，因为创始人们试图为 AI 工作负载锁定算力。这段经历让 GitHub 的报道感觉不再像一次孤立的采购意外，而更像是更广泛的分配问题的一个症状：微软可以在战略上全力投入 Azure，却仍然缺少其自身生态在 AI 采用所设定的时间表上所需的特定基础设施。

因此，如果 Business Insider 的消息来源准确，那么从 AWS 租用算力与其说是承认 Azure 无法扩展，不如说是承认微软的内部需求如今已超出其自身云战略的整齐边界。该公司仍然可以希望到 2027 年将 GitHub 迁至 Azure。它仍然可以利用这次迁移让 GitHub 更具韧性。但市场不会等待目标架构。

同样的模式正在 AI 基础设施的其他地方出现。据 TechCrunch 报道，Google 同意从 2026 年 10 月到 2029 年 6 月每月向 SpaceX 支付 9.2 亿美元，以获取算力。这笔交易比 GitHub 依赖 AWS 规模更大、也更奇怪，但它指向同样的市场状况：即便是那些建设全球云基础设施的公司，也在从竞争对手和相邻基础设施所有者那里购买过渡算力，因为 AI 需求已经跑赢了规划周期。

对 Microsoft 而言，GitHub 此举还带来二阶风险。GitHub 每花一小时从故障中恢复，就有一小时让 AI 原生开发者工具得以主张：旧的协作层是为人类节奏的软件团队构建的，而非为以机器速度生成 pull request、commit、测试运行和仓库活动的智能体系统而建。GitHub 拥有网络效应、企业覆盖面和 Microsoft 的分发能力。AWS 的容量或许有助于争取到保住这一地位所需的时间。

但这也让战略现实变得一目了然：在 AI 编程市场，瓶颈不只是模型质量或开发者的喜爱。关键在于工作流底层的平台能否承载它自己助推释放出的那些智能体。