一个月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亿次，是一年前的4倍多。 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核心