AI 代理灌爆 GitHub：9 月提交量是去年 5 倍多，Git 儲存底層將重寫

GitHub 9 月提交量達一年前的 5 倍多，故而決定把 Git 儲存底層從頭重做、資料改放 Azure Blob Storage。用戶做法不變，內部測試寫入吞吐量最高提升到 35 倍，但沒給時程。
（前情提要：GitHub Copilot 喊停自助訂閱：AI 用量失控，平價方案經濟學已全面崩潰）
（背景補充：Cursor 新推程式碼託管服務 Origin，想挑戰 GitHub 霸主地位）

本文目錄

全球最大的程式碼託管網站 GitHub，現在決定要把存放程式碼的底層儲存從頭重做，以接住 AI 代理湧進來的流量。GitHub 在工程部落格文章中表示，分支、審查、分支保護與稽核紀錄都照舊，改造期間也不設停機維護時段，也就是說對用戶來說不會感受到差異。至於什麼時候完成，文章沒有說。

GitHub 在 4 月 28 日的說明中提到，2025 年 10 月啟動的計畫原本是把容量擴大 10 倍，到 2026 年 2 月才發現，要為當時規模的 30 倍來設計。期間服務也沒穩住：4 月有 10 起事故、5 月有 9 起事故，造成 GitHub 各項服務效能下降。

AI 代理讓流量漲了多少

以 GitHub 計算的「事件」數來看，整體 Git 活動量從 2025 年 9 月的每月 2,182 億次，成長到 2026 年 8 月的每月 4,733 億次，超過 2 倍。

提交（commit，把修改存成一筆歷史紀錄）的成長更快。2026 年 9 月，開發者與 AI 代理合計在 GitHub 上做了 73.8 億次提交，是一年前的 5 倍多。GitHub 沒有拆分其中多少來自代理，不過它在 4 月的說明中已指出，2025 年 12 月下半起，代理式開發工作流明顯加速，是流量暴增的主要原因。

寫入端的壓力更直接。推送（push，把本機的修改上傳到 GitHub）每月從 6.9 億次增加到 33.5 億次，年增 4.9 倍。

拉取請求（pull request）被合併的數量，接近一年前的 4 倍；GitHub Actions（GitHub 的自動化流程服務）9 月執行 32.6 億次，同樣超過一年前的 4 倍。至於最忙的單一儲存庫（repository，存放一個專案程式碼與歷史的空間），8 月就收到約 10 億次請求。

舊系統卡在哪裡

舊架構叫 Spokes。它的做法是，每個儲存庫在多部檔案伺服器的本機硬碟上各存一份完整副本，預設 5 份。副本一身兼二職：既是備份，也負責分擔讀取。好處是本機硬碟快，Git 操作的延遲低，這套設計目前承載十億個儲存庫。

問題出在寫入。每次推送要更新參照（ref，指向某個分支最新進度的標記）時，系統採用三階段提交協定，要多數副本確認，更新才算數，所以一次推送的速度取決於最慢的那份副本。連鎖的後果有三個：為了扛讀取而加副本，寫入反而變慢；少一份副本，讀取能力就下降；湊不到多數，寫入直接停擺。

對一般儲存庫，這個取捨可以接受。AI 代理把它推到了極限。GitHub 點名的卡點包括：第一，代理幾乎每做一個動作就提交或存一次檢查點，人類察覺不到的延遲，會變成代理的速度上限。第二，上千個代理在同一個儲存庫各開分支，寫入集中到架構中的同一點。第三，合併全擠在主幹的同一個參照上。第四，每次推送後，CI（持續整合，自動測試與建置）與程式碼掃描每分鐘會對同一個分支反覆抓取上千次。

新系統怎麼解，當機問題會好嗎

新架構的核心，是把「保存資料」和「回應請求」拆開。儲存庫的權威資料改放在微軟 Azure 的物件儲存服務 Azure Blob Storage，耐久性與複製交給它處理。讀取則由可隨流量增減的輕量運算節點負責，這些節點只做快取。運算節點掛掉，比較像一次快取沒命中，新節點可以馬上接手，再從儲存層補資料。

寫入端，一次推送只有「更新參照」這一步需要協調。存放物件、檢查資料連貫、掃描有沒有誤傳金鑰等較耗工的步驟，可以和其他寫入並行。壓縮與垃圾回收（清掉不再需要的舊資料）這類維護工作，則移到背景的獨立節點，不再占用回應請求的機器。

效果如何？GitHub 說，在內部基準測試中，寫入吞吐量（同一段時間能處理的寫入量）最高提升到 35 倍，而且讀取容量可以獨立擴充。這是內部測試成績，還不是上線後的數字。

至於能不能止住當機，要分開看。從 4 月到 8 月的月報看，GitHub 寫出的事故起因多半在資料庫、流量限制、服務部署與負載平衡器，沒有一起直接指向 Git 儲存，Git 操作多半是被其他環節連帶拖慢。像 8 月 6 日 GitHub Actions 中斷 10 小時 42 分，起因是 Actions 內部服務部署時一個站點容量下降，流量轉過去後壓垮其他站點，連帶影響 Copilot 程式碼代理、Pages 建置與 Dependabot。

新儲存架構處理的是 Git 寫入的瓶頸，拿掉的是讀寫互相拖累、湊不到多數就停擺這類結構限制。其他環節的穩定，要靠 GitHub 同步進行的另一項工程：把服務搬上微軟 Azure、拆開共用的資料庫。

目前能確定的只有方向：寫入和讀取各自擴充，資料交給 Azure。時程與實際成效，要等 GitHub 的下一篇文章和之後的月報。