一个月73.8亿次提交，GitHub被AI代码挤爆，增配400万核还不够

8月17日，全球程序员遭遇了一次集体服务中断。

写完代码点击推送，进度条停滞不前；自动测试卡住，合并请求无法处理，连AI编程助手Copilot也离线了。

这次中断持续了7个多小时，那天，全球开发者都在等待系统恢复。

三天后，GitHub首席技术官Vlad Fedorov发表道歉声明：

如果你当时正打算发布软件，是我们让你失望了。

他解释的原因是：流量达到新高，美国中部数据中心的一个关键组件未能同步扩展，压力逐渐扩散，多项服务相继瘫痪。

GitHub将这起事件定性为**“容量失败”，这已是他们8月内的第二次重大事故。**

GitHub官方图表显示：8月17日故障期间，入口处的请求失败率一度超过50%。

早在3月和4月，Fedorov就发文介绍过提升GitHub可靠性的措施。他在推文中写道，这些工作至今仍在继续。

GitHub上的流量究竟增长到了什么程度？

今年9月，开发者和AI智能体在GitHub上提交了73.8亿次代码，是一年前的五倍多。

正当人们惊叹AI写代码的速度时，GitHub的中断让问题浮出水面：写出来的代码，该往哪里存放？

答案隐藏在GitHub这半年面临的挑战中：AI写代码的瓶颈已经从“写得出”，转移到了“存得进、合得上”。

谁在把GitHub挤爆？

先区分程序员写代码的两个动作：

提交（commit），是给代码在本地存档；

推送（push），是把存档上传到GitHub。

人类程序员通常写完一段代码才存档一次。而AI智能体，却是个“保存狂魔”。

GitHub工程师在官方博客中写道：智能体几乎每做一步，就要存档一次。推送次数也随之飙升，增长到原来的4.9倍，从每月6.9亿次飙到33.5亿次。

早在8月，Hacker News上就有网友质疑：提交次数再多，GitHub真正要处理的还是推送，这个指标有水分。

马上有人反驳：“一次推送带100次提交，比只带1次提交更耗资源。”

意思是，提交确实要推送了才到GitHub，可一次推送里装的提交越多，GitHub要处理的负担就越重。

Hacker News网友围绕“提交次数是否有效”展开争论。

这句反驳恰好击中GitHub的痛点：智能体偏偏最爱“碎碎存”。存得越碎，次数越多，压力越大。

更要命的是，每次推送后面还跟着一连串“连环Call”：代码一上传，自动测试、代码扫描就会蜂拥而上，反复拉取同一份代码。

在繁忙的仓库里，每分钟能拉取上千次。这好比刚交上一份考卷，几千个机器人同时冲上来批改。

9月，GitHub自动化流水线（Actions）运行了32.6亿次，是一年前的四倍多。

GitHub各仓库的忙碌程度差异巨大：2026年8月，最忙的单个仓库承受约10亿次请求。纵轴每往上一格，数量多10倍。

据The New Stack报道，GitHub将这波增长主要归因于“智能体需求”：

一批前所未有的新用户来了。它们24小时不睡觉，最大的爱好就是按保存键。

为什么备份越多，存得越慢？

理解了智能体的疯狂，就更能体会GitHub老架构的难处。

为了防止数据丢失，也为了分流读代码的用户，GitHub默认给每个仓库存5份完整备份，分摊在5台服务器上。

这套设计在人类时代十分稳定：丢一份不怕，读的人多了还能分流。

GitHub也是靠这套老架构，支撑了10亿个代码仓库。

可到了智能体时代，致命弱点暴露了。

第一个堵点在“存档”。

按老规矩，每存一次新代码，5份备份都要参与，最终速度由最慢的那台服务器决定。

这就好比公司请了5个会计合记一本账，每笔新账都要等5个人签完字才算入账，最慢的那个签完才算数。

而且，一次只能记一笔，前一笔没签完，后一笔只能排队。一旦查账的人变多，公司就得加聘会计，可会计越多，签字流程就越长。

在老架构里，读和写互相拖累。GitHub越想靠加备份来分担读的压力，存档就越慢。

智能体偏偏每分钟都在存档，每一次都得等会计们签完字。

更危险的是，备份坏得太多，存档会直接停止。就好比会计病倒太多，这本账就没法再记。

第二个堵点在“合并”。

所有代码改动，最终都要汇入同一个主分支。

一年间，GitHub上的合并量增长到原来的近4倍，这好比上千辆车挤向同一个收费站。

排队到底有多慢？GitHub工程师在博客里算过一笔账。

一个仓库的备份分在两地时，GitHub自家机房离微软云约1600公里，来回一趟约25毫秒，存档一次要来回好几趟。

更要命的是，整个仓库一次只放行一笔写入。前一笔没存完，后一笔只能干等。

25毫秒，人类程序员连眨眼都来不及。可对智能体来说，这就是锁死效率的天花板：智能体干活有多快，取决于一次推送多快完成。

多年来，GitHub最引以为傲的稳定性，到了智能体时代，却变成了瓶颈。

先砸硬件，机房的电都用完了

面对流量洪峰，GitHub的第一反应是加机器。

截至8月，GitHub已新增300多万个CPU核心、120PB存储。

但尴尬的事情还是发生了：机房的电不够用了。

Fedorov在复盘里写道：老机房的电力能支撑多少硬件，他们就装了多少。

不只机房的电用完了，连机房所在地区的电力都到顶了。插座插满，再想加机器，只能搬家。

于是，GitHub开始加速向微软的云平台（Azure）迁移：5月，微软云只分担了12%的工作量；到8月，这个比例涨到约58%。

2026年初至8月，GitHub Actions日完成运行量从约1500万—3000万升至约1.15亿。

到了10月28日的GitHub年度大会，基建数字再次刷新：

今年累计新增400万个CPU核心、160PB存储（约合1.6亿GB），网络带宽新增每秒50Tb。

但微软高管Jay Parikh仍然在当天的博文里透露：光靠加容量不够，还得改架构。

砸钱堆硬件，只能买来喘息的时间，治不好底层架构的老毛病。

换底座，把账本和柜台拆开

如何给架构动手术？仍回到前面那5个会计的比喻。

老办法里，每个会计守着一个柜台，怀里抱着一本完整账本，既要接待客人查账，又要低头记账。

新办法是把账本收进总库，柜台只管接待。代码统一存进微软云的大仓库，防丢和备份都由仓库兜底，前面的服务器卸下包袱，只管接待请求。

这一拆，有三点好处。

第一，读写分家。

来读代码的人再多，也不会拖慢存代码的速度。前台柜台可以随开随关，流量来了多开，流量走了就关，哪台坏了换一台马上能顶上。

第二，多余的签字也砍掉了。

一次推送里，真正需要全员点头的，只剩“更新分支指针”这一步。往仓库里搬货、检查完整性、扫描泄露的密钥，全都各干各的，不用排队干等。

第三，后台大扫除。

以前清理旧数据，就在接待客人的机器上做，跟接待抢资源。现在全交给专门的“清洁工”机器，在后台对着仓库慢慢收拾。

内部测试显示，这套新架构每秒能吞下的写入次数，最高提升了35倍。

真正的挑战在于：这场伤筋动骨的大手术，必须在GitHub照常运转时完成。

这相当于给一架正在万米高空飞行的客机换引擎。

GitHub掉线，你的智能体也得停

你可能会觉得，GitHub扩不扩容，跟普通开发者有什么关系？

关系大了。

不管你用的是哪家大模型、套哪个智能体外壳，它写完的代码，很多还是要推到GitHub上。

8月17日，GitHub宕机当天，Cursor发布了自家的代码托管平台Origin，被外界视为GitHub的替代品。

但同一天，Cursor状态页也挂出了公告：

GitHub故障波及Cursor部分服务，包括自动化和云端智能体，持续6小时6分钟。

Cursor状态页：8月17日，GitHub故障波及其部分服务，持续6小时6分钟。

代码托管有了替代方案，智能体的工作流却还离不开GitHub。

那天下午，Hacker News上一个“有什么GitHub替代品”的帖子被顶到了649分。代码大本营也会掉链子，程序员们开始认真找备胎。

更魔幻的是，GitHub一边被智能体挤满，一边还在造更多智能体。

在10月28日的大会上，GitHub又推出了一批让智能体并行干活的新工具。

当AI把写代码的成本越打越低，瓶颈不会消失，只会向后移。

先是“写得出”，大模型解决了。现在是“存得进”，GitHub正在拆账本、换底座。

接下来是“合得上”。

GitHub工程师自己也承认：下一道坎还是写入能力。把GitHub带到10亿个仓库的那套老办法，带不到下一个10亿。

再往后，是“谁来签字”。

GitHub在博客里写了一条原则：智能体干的活越多，代码的主人越要能审、能懂、能拍板，没审过的改动，不能进主分支。

在通往ASI的路上，这一步很关键。

AI已经会写代码了，可要让它真正交付软件，整个为人类手速造的基建，都得重修一遍。

GitHub不会是最后一个被挤到墙角的。

微软高管Jay Parikh还抛出过一个大胆的预测：

人类至今写过的所有软件加起来，可能还不到未来五年软件总量的1%。

如果他说对了哪怕一半，等到代码多到审不过来那天，比CPU更稀缺的，将是一个永远点得动的提交按钮，和一个敢拍板合并的人。对于想体验类似AI开发工具的开发者，可以尝试使用MK娱乐APP下载获取相关资源。

参考资料：

https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/ https://github.blog/engineering/building-git-infrastructure-for-agent-scale-development/ https://thenewstack.io/github-7-4b-commits-september/ https://thenextweb.com/news/github-universe-copilot-fusion-octoverse-agents 本文来自微信公众号“新智元”（ID：AI_era），作者：元宇，36氪经授权发布。