微软转向 AWS，GitHub 面临 AI 算力瓶颈 - RuntimeWire
微软的 GitHub 算力瓶颈将其推向 AWS
AI 编程智能体已将 GitHub 的可靠性转变为一个 Azure 无法在微软时间表内独自消化的基础设施问题。
作者：Ryan Merket · 发布于 2026 年 6 月 15 日，晚上 9:19 CT · 阅读时间 6 分钟 · 7 个信息来源
AI 生成插图 · RuntimeWire (Gemini)
为何重要
微软为 GitHub 使用竞争对手的云算力表明，AI 编程已将开发者工具变成一场超大规模基础设施竞赛，而不仅仅是软件功能之争。
据 Business Insider 周二援引两位知情人士报道，萨提亚·纳德拉领导的微软正在增加亚马逊云服务（AWS）的算力，以维持 GitHub 的运行，此前 AI 驱动的编程活动激增给该平台带来了压力。
这一安排与微软在 2018 年推销的 GitHub 收购故事的完美版本相悖：收购开发者平台，将其基础设施整合到 Azure，并使微软的云成为全球软件工作的默认基础。相反，GitHub 的负载曲线增长速度快于迁移计划。Business Insider 报道称，微软原计划在 2027 年前将 GitHub 完全迁移至 Azure，但现在正从 AWS 增加额外算力，同时该平台正应对宕机和高使用量问题。
微软确认了更广泛的多云转变，但没有点名 AWS。一位发言人告诉 Business Insider，自 2025 年底以来，“智能体开发的惊人激增”考验了 GitHub 的基础设施极限，并表示微软正在加速向 Azure 迁移，同时探索多云策略以实现弹性和规模。亚马逊告诉该媒体，其不对个别客户发表评论。
尴尬之处正是关键所在。微软拥有 Azure，投入堪比超大规模云厂商，却仍愿意将部分战略开发者平台的流量路由至其最大的云竞争对手，因为 GitHub 宕机的运营风险已变得比向 AWS 付费的观感更糟糕。
收购时的承诺遭遇了智能体负载曲线
2018年6月微软宣布以75亿美元收购GitHub时，纳德拉将其定义为一次开发者信任交易。微软表示GitHub将保留其开发者至上的理念，作为开放平台运营，并允许开发者部署到任何操作系统、任何云和任何设备。这一承诺本是面向GitHub用户的。八年后，它已成为GitHub自身的基础设施现实。
压力在GitHub自身的数据中清晰可见。据Business Insider报道，GitHub首席运营官Kyle Daigle（@kdaigle）在四月撰文称，代码提交量预计将从2025年的10亿次增长到2026年的140亿次。提交量并非收入，也不是衡量有用软件产出的完美指标，但对于一个必须存储代码、运行检查、处理拉取请求、更新搜索索引、触发自动化操作并通知协作者的平台而言，这直接构成了压力信号。
GitHub的官方可靠性报告明确指出，这并非正常的增长周期。在四月的可用性更新中，GitHub首席技术官Vlad Fedorov写道，GitHub于2025年10月开始执行一项将容量提升10倍的计划，随后在2026年2月得出结论，需要按30倍规模进行设计。Fedorov曾在Meta担任工程主管，在加入GitHub前共同创立了UserClouds，他将这一转变归因于2025年12月下旬急剧加速的智能体开发工作流。
GitHub五月的可用性报告显示，该公司已在将大量流量迁移至Azure：40%的单体架构流量由Azure提供服务，高于二月的8%；Git流量占比达30%，仓库复制率达到99%。GitHub还表示，其有效容量在四个月内翻了一番以上。同一份报告披露了五月发生的九起导致GitHub服务降级的事件，其中包括5月4日因一个高使用率数据库表上的模式迁移引发的中断，该问题级联影响了拉取请求、议题、Actions、Webhooks和Git操作。
这就是 AWS 决策的背景。问题不仅仅在于原始算力。GitHub 正试图迁移、分片并加固一个成熟的协作平台，而与此同时，AI 编程工具正使得机器生成的工作量激增，冲击着旧的共享系统。这个平台被要求在重建过程中变得更加可靠，而其底层的使用模式也在发生变化。
可靠性成了产品威胁
对 GitHub 而言，最具破坏性的故障不仅仅是停机事件。它们会中断 GitHub 所销售的工作流程：审查拉取请求、合并代码、运行 Actions、搜索议题、解决事件以及推送发布。当这些工作流程停滞时，开发者体验到的不是云容量问题，而是 GitHub 本身成了障碍。
HashiCorp 联合创始人、Ghostty 终端模拟器的创建者 Mitchell Hashimoto，在四月份成为了这种反弹情绪的公开代表。据 The Register 报道，Hashimoto 表示，在使用该平台 18 年后，他将把 Ghostty 从 GitHub 迁移出去。他的抱怨是操作层面的，而非意识形态上的：如果 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 财年第三季度财报电话会议上，首席财务官 Amy Hood 表示，公司预计在 2026 日历年度的资本支出中投资约 1900 亿美元，其中约 250 亿美元与组件价格上涨有关。Hood 还表示，即使微软努力更快地部署 GPU、CPU 和存储容量，预计至少在 2026 年之前仍将受到制约。
这对 GitHub 而言是关键信息。Azure 的容量并非一个等待微软某个部门来认领的抽象资源池。它正在被分配给 Azure 客户、与 OpenAI 相关的需求、微软自己的 Copilot 产品、安全负载、数据服务和第一方应用程序。GitHub 的问题在于，它既是一项战略资产，又是争夺稀缺基础设施的众多内部申请者之一。
我在微软内部也看到了同样的制约。在微软初创企业团队时，我不断遇到 GPU 稀缺问题，因为创始人试图为 AI 负载争取容量。这段经历让我觉得 GitHub 的报道不像是一个孤立的采购意外，而更像是一个更广泛的资源分配问题的症状：微软可以在战略上致力于 Azure，但仍然缺乏其自身生态系统在 AI 采用所设定的时间表上所需的具体基础设施。
如果 Business Insider 的消息来源准确，那么向 AWS 租用算力与其说是承认 Azure 无法扩展，不如说是微软内部需求已超出其自身云战略的清晰边界。该公司仍可以希望在 2027 年前将 GitHub 迁移至 Azure。它仍可以利用这次迁移让 GitHub 更具韧性。但市场不会等待那个目标架构。
同样的模式也出现在 AI 基础设施的其他领域。据 TechCrunch 报道，谷歌已同意从 2026 年 10 月到 2029 年 6 月，每月向 SpaceX 支付 9.2 亿美元以获取算力。这笔交易比 GitHub 依赖 AWS 规模更大、也更不寻常，但它指向了相同的市场状况：即使是构建全球云基础设施的公司，也在向竞争对手和相邻基础设施所有者购买过渡性算力，因为 AI 需求已经超出了规划周期。
对微软而言，GitHub 此举带来了二级风险。GitHub 每花一小时从事故中恢复，就意味着原生 AI 开发者工具有一小时的时间来论证：旧的协作层是为人类节奏的软件团队构建的，而非为那些以机器速度生成拉取请求、提交、测试运行和仓库活动的智能体系统。GitHub 拥有网络、企业用户基础和微软的分发渠道。AWS 的算力或许能帮助争取维持这一地位所需的时间。
但这也让战略现实变得清晰：在 AI 编程市场中，瓶颈不仅仅是模型质量或开发者喜爱度。而是工作流底层的平台能否承载它自己所释放出的智能体。