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

我先联网核实 GitHub 这组数字的原始出处和口径。

官方 Octoverse 报告、GitHub 工程博客和多家外媒已经核对完，几个容易混的数字也拆开了。成稿如下。

GitHub 单月 73.8 亿次提交：一年涨 5 倍，400 万核＋160PB 还不够，动手重写 Git 底座

先把结论摆清楚：2026 年 9 月，开发者和 AI 智能体在 GitHub 上产生了 73.8 亿次提交（commit），是 2025 年 9 月的五倍多；为了扛住这波量，GitHub 今年累计加了 400 万个 CPU 核心、160PB 高速存储、50Tb/s 带宽，结果发现机房电先用完了，于是把底座从 “多副本文件服务器” 改成 “存储与计算分离＋对象存储”，内部压测写入吞吐最高提升 35 倍。这组数字有三个口径必须分开看：73.8 亿是 “9 月单月提交”，不是 Octoverse 年报里的 “12 个月 343 亿次提交”；“提交” 也不等于 “推送”，9 月推送是 33.5 亿次；400 万核是全年累计，8 月时的数字还是 300 万核、120PB。搞混任何一个，判断都会跑偏。

三张表把口径钉住，别让数字互相串味

三个容易踩的坑：

• 73.8 亿是单月，343 亿是年度，两者不能相除得出 “月均 28 亿” 这种误读。
• 提交（commit）是本地存档，推送（push）才是真正上传到 GitHub。Hacker News 上确实有人拿这个质疑 “提交数有水分”，但反方的说法也成立：一次推送里装 100 个提交，比只装 1 个更耗资源 —— 智能体恰恰最爱碎碎存。
• 5 倍和 “暴涨 500%” 是同一个数，只是表述不同，不是两个独立指标。

增长到底从哪来：智能体是台 “每步都按保存键” 的机器

GitHub 官方把原因直接归给 “智能体需求”（agentic demand）：AI 不再只是补全代码，而是自己开分支、改文件、跑测试、提 PR。

还有一个最能说明 “为什么它爱碎碎存” 的数据：今年新建的仓库里，带智能体配置文件的那些，平均提交数是同类无配置文件仓库的 8 倍。Cloud 端的 Copilot agent（派一个任务、它自己跑）同比增长 230%，agent chat 只有 85%—— 人正在从 “提问” 转向 “派活”。

老架构为什么突然撑不住：五个副本和一把写锁

GitHub 原来的 Git 存储模型很朴素：每个仓库默认存 5 份完整副本，分在 5 台服务器上。人类时代这是优点 —— 丢一份不怕，读的人多还能分流。到了智能体时代，它变成三个硬约束：

• 一次写入要 5 份副本全部点头，速度由最慢那台决定，而且一次只放行一笔。
• 读写互相拖累。想靠加副本分担读压力，写入就更慢；副本坏太多，写入直接停。
• 跨地域延迟固定存在。GitHub 自家机房到微软云约 1600 公里，往返约 25 毫秒，一次存档要来回好几趟。人类感觉不到，但智能体的吞吐上限被这 25 毫秒卡死。

再叠上一层放大效应：每次推送都会触发 CI、自动测试、安全扫描、通知等一串 “连环调用”，繁忙仓库里每分钟能被拉取上千次。2026 年 8 月，最忙的单个仓库承受了约 10 亿次请求。

代价已经显性化了。8 月 17 日，GitHub 发生持续 7 个多小时的全球故障，入口请求失败率一度超过 50%，Copilot 也掉线；CTO Vlad Fedorov 三天后发文道歉，官方定性为 “容量失败”，并承认这是 8 月第二次大事故。10 月 7 日又出现一次影响 Actions、PR 和 Issues 的广泛故障。同一场故障还波及 Cursor，其状态页记录受影响 6 小时 6 分钟 —— 代码托管可以换，智能体的工作流当时换不了。

加硬件加到电不够用：这才是迁云的直接推手

Fedorov 的复盘里有一句很实在的话：老机房的电力能撑多少硬件，就装了多少；不只机房电用完，机房所在地区的电力也到顶了，再想加机器只能搬家。这就是为什么扩容最终变成了迁云。

新底座怎么改：把 “账本” 从柜台里拿出来

10 月 6 日和 10 月 21 日两篇工程博客把方案讲得很具体，四件事：

1. 存储与计算分离。代码统一进 Azure 上的对象存储，前台服务器只管接请求。读的人再多也不拖慢写入，前台机器按流量弹性增减。
2. 按引用仲裁（per-reference quorum）。一次推送里真正需要全员确认的只剩 “更新分支指针” 这一步；搬数据、查完整性、扫密钥各自并行，不再排队。10 月 21 日的博客称已把 99.99999% 的仓库副本迁到 Azure。
3. 后台大扫除离场。仓库整理、压缩、清理这类重活挪到专门的机器，不再和实时请求抢资源。
4. 内部压测写入吞吐最高提升 35 倍 —— 注意这是内部基准，不是每个开发者都能感知到的 35 倍加速。

最难的部分不是设计，而是 “边飞边换引擎”：整个迁移必须在 GitHub 照常服务的情况下完成。

这事跟普通开发者有什么关系，五件要提前做的

1. 别把 CI 当免费算力。提交变碎会等比放大 Actions 消耗，团队该收紧触发条件（路径过滤、[skip ci]、合并队列），否则账单和排队时间一起涨。
2. 控制智能体的 push 频率。让它按任务节点提交，而不是每改一个文件就推一次；能本地攒批就攒批。
3. 给关键仓库加镜像或本地缓存。8 月 17 日和 10 月 7 日两次故障说明，托管层不是单点可靠的。
4. 认真评估替代方案，但别急着全量切换。前 CEO Thomas Dohmke 在 10 月 26 日推出了竞品 Entire（含 Trails 评审体系和记忆层，可镜像 GitHub 仓库），Cursor 也在 8 月 17 日发了 Origin；这些都是厂商自测口径，迁移成本要自己算。
5. 把 “谁签字” 写进流程。GitHub 自己的原则是：智能体干得越多，代码的主人越要能审、能懂、能拍板，没审过的改动不进主分支。10 月起 Copilot code review Max 就是为此加的，但官方明确说自动评审不能替代人。

另一面的声音：提交多了，不等于软件变好了

Reddit 的 r/technology 上，最受欢迎的质疑是 “涨了 6 倍，我们每天用的应用还是那些”。也有人举出具体例子：一句并不复杂的指令，工具自己写了约 4000 行解析器，最后承认用现成方案就行。还有人对训练数据污染表示担心 —— 大量 AI 生成代码进入 GitHub，会反过来喂给下一代模型。

这些批评不能直接当成结论，但指向一个真实的问题：提交、推送、PR 都是 “供给端” 指标，而审查、测试、可追溯是 “消费端” 能力。GitHub 的数据自己也显示，智能体 PR 的多文件比例更高（87% 对 79%），审查负担是同步上升的。供给翻了 5 倍，审查能力没有翻 5 倍，中间那道口子就是风险。

【相关 FAQ】

问题 1：GitHub 73.8 亿次提交这个数字具体指什么？

回答 1：GitHub 73.8 亿次提交指 2026 年 9 月单月全平台的 commit 总量，是 2025 年 9 月的五倍以上，包含人类开发者与 AI 智能体的提交；它不等于推送次数（9 月推送为 33.5 亿次），也不等于 Octoverse 年报里的 12 个月 343 亿次提交。

问题 2：GitHub 73.8 亿次提交为什么会让平台需要加 400 万核？

回答 2：GitHub 73.8 亿次提交背后是更碎的写入节奏和更密的连锁负载：每次推送都会触发自动测试、安全扫描与构建，繁忙仓库每分钟被拉取上千次；加上旧架构每个仓库要 5 份副本同步确认、跨地域往返约 25 毫秒、一次只放行一笔写入，容量和延迟同时被顶到极限。

问题 3：GitHub 73.8 亿次提交之后，官方到底改了什么架构？

回答 3：围绕 GitHub 73.8 亿次提交带来的压力，官方把存储与计算分离、把代码放进 Azure 对象存储、用按引用仲裁只让 “更新分支指针” 这一步全员确认、把仓库清理等重活挪到后台专用机器，内部压测写入吞吐最高提升 35 倍。

问题 4：GitHub 73.8 亿次提交里有水分吗，提交数能代表代码量吗？

回答 4：GitHub 73.8 亿次提交不能直接等同于代码产量。commit 是本地存档，push 才上传到平台，智能体几乎每做一步就存档一次，因此提交数会被明显放大；反过来说，一次推送携带上百个提交也会加重平台负担，所以这个指标既不能简单否定，也不能当成 “软件变多了” 的证据。

问题 5：GitHub 73.8 亿次提交会影响到我自己的 CI 和账单吗？

回答 5：会。GitHub 73.8 亿次提交意味着 Actions 用量同步暴涨（9 月 32.6 亿次、全年 454 亿次），团队若不收紧触发条件、控制智能体的推送频率、启用路径过滤或合并队列，自托管 runner 与 Actions 分钟数都会被更快吃掉，排队时间也会变长。

问题 6：GitHub 73.8 亿次提交引发的扩容，对普通用户有什么可见变化？

回答 6：短期内可见的是多区域 Azure 部署推进（预计 2027 年初完成）、故障恢复能力和写入吞吐的提升；同时 GitHub 在推 Copilot code review Max、Copilot Fusion 等工具来应对审查压力，但官方明确自动评审不替代人工签字，代码是否合并仍由人负责。

【参考资料】

[2026-11-08]（一个月 73.8 亿次提交！GitHub 被 AI 代码挤爆，增配 400 万核还不够）新浪财经（转新智元）

[2026-11-05]（Inside GitHub's new Git storage architecture）GitHub Blog

[2026-11-01]（GitHub Boosts Infrastructure to Meet AI Coding Demand）RS Web Solutions

[2026-10-31]（GitHub added 4M CPU cores in 2026 to keep up with AI agents）BizStack

[2026-10-30]（GitHub precisou de 4 milhões de núcleos de CPU extras devido ao enorme influxo de códigos gerados por IA）Hardware.com.br

[2026-10-30]（GitHub のコミット数が 1 年で 5 倍超、月 73 億件に — AI エージェントの急増で Git 自体の再設計を迫られる）TechFeed

[2026-10-30]（GitHub Code Activity Surges 500% Driven by AI Agents）Securityonline

[2026-10-28]（Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents）GitHub Blog

[2026-10-28]（GitHub Hits 7.38 Billion September Commits as Former CEO Launches Rival）TechBooky

[2026-10-21]（The bridge to agent-scale Git infrastructure）GitHub Blog

[2026-10-06]（Building Git infrastructure for agent-scale development）GitHub Blog

【免责声明】

本文依据 GitHub 官方 Octoverse 2026 报告（统计区间 2025 年 10 月 1 日至 2026 年 9 月 30 日）、GitHub 工程博客（10 月 6 日、10 月 21 日、11 月 5 日）、GitHub Universe 2026 公开信息，以及 TechBooky、BizStack、.br、TechFeed、Securityonline、新智元等公开报道整理。所有数字均为 GitHub 官方口径或其对媒体的披露，35 倍写入吞吐提升为 GitHub 内部基准测试结果，不代表终端用户可感知的提升幅度；Azure 多区域部署 “2027 年初完成” 为官方预计时间。竞品 Entire 与 Cursor Origin 的性能与定位表述来自各自公司，属厂商自测口径，本文未做独立验证。Reddit 与 Hacker News 上的讨论为社区观点，不代表事实结论。本文不代表 GitHub 或微软官方立场，不构成采购、迁移或架构决策建议。

核对说明：73.8 亿（9 月单月提交）、343 亿（12 个月提交）、33.5 亿（9 月推送）、179 亿（12 个月推送）、13 亿（合并 PR）、454 亿（Actions 任务）六个数字在表格中分列，并明确标注时间口径，未互相换算。400 万核、160PB、50Tb/s 标注为 “2026 年全年累计”，并列出 8 月时点为 300 万核／120PB，避免被读成单月增量。35 倍已注明为内部压测的写入吞吐，非端到端体验提升。“5 倍” 与 “500%” 合并说明为同一指标，未当作两个独立数据引用。8 月 17 日故障时长与失败率、10 月 7 日故障均按公开信息分别列出，未合并成一次事故。社区质疑与官方数据分开陈述，未把 Reddit 观点写入事实段。