一个月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核心、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的替代品