GitHub 面臨 AI 造成的運算容量吃緊，微軟轉向 AWS 求援 （★ 106 分）
這篇報導聚焦 Microsoft 在 GitHub 面臨 AI（人工智慧）帶來的運算容量壓力時，轉向 AWS（Amazon Web Services，Amazon 的雲端運算平台）尋求協助。討論中引用的關鍵數字指出，GitHub 的 commit（程式碼提交）量預估在 2026 年可能達到 140 億次，遠高於 2025 年的 10 億次，顯示 AI 程式輔助工具、自動化機器人與大量程式碼變更流程，正在快速推高平台後端負載。原始頁面的快照未呈現完整正文，但核心脈絡指向 GitHub 的成長速度已超出 Microsoft Azure（Microsoft 的雲端平台）可即時承接的範圍，因此需要借助 AWS 的容量。
討論者普遍認為，commit 數量本身未必能完整解釋壓力來源，因為單次 commit 的資料量可能很小；真正耗費資源的是每次提交背後引發的一連串作業，包括 Git 儲存庫複寫、重新打包、雜湊計算、Pull Request（PR，合併請求）差異比對、GitHub Actions 工作流程，以及 CI（Continuous Integration，持續整合）建置與測試。也有人指出，pull、clone、爬蟲、濫用或低效率的自動化流程，可能比文字形式的程式碼提交更容易造成 I/O（輸入輸出）與運算壓力。
不少開發者分享自身經驗，認為 AI 工具與機器人不只增加程式碼量，也放大了工程流程的浪費。例如有人提到團隊常在 PR 開啟後連續推送 10 到 20 個 commit，卻每次都觸發完整 CI；也有人把 CI 當成遠端測試環境而非在本機先跑測試，導致雲端運算資源被大量消耗。部分公司會用冷卻時間、自動取消舊 CI 作業、限制分支規則等方式控管成本。對於「commit 成長 14 倍」的解讀，許多留言也提醒，這不等於功能產出增加 14 倍，可能只是 AI 讓人更快地產生、修改、重做或修補程式碼。
技術層面上，討論也延伸到 Azure 與 AWS 在高 I/O 工作負載上的差異。有留言回憶早期 Microsoft 與 GitHub 互動時，GitHub 共同創辦人曾明確表示 IOPS（Input/Output Operations Per Second，每秒輸入輸出操作次數）非常重要，而虛擬磁碟速度不足會是遷移到 Azure 的障礙。這讓一些人把此事類比為 Microsoft 早年收購 Hotmail 後，試圖將原本技術堆疊遷往 Windows NT 卻進展不順的「Hotmail 時刻」。也有人藉此反駁「各家雲端平台都差不多」的說法，認為大型程式碼託管平台的底層儲存與 I/O 能力，會直接決定可承受的規模。
整體來看，社群對 Microsoft 使用 AWS 的看法不完全負面：有人嘲諷 Microsoft 自家雲端無法完全承接 GitHub 的需求，也有人認為這很可能只是短期補強；但也有意見認為，比起讓 GitHub 在 AI 浪潮下因容量不足而服務品質下滑，跨雲調度是務實選擇。另有留言批評原始網站本身品質不佳，例如前端頁面結構空洞、無限捲動體驗差、標題標籤異常等，但這些評論主要影響資訊來源觀感，並不改變討論核心：AI 程式開發正在把 GitHub 這類基礎設施推向新的容量與成本壓力測試。
👥 33 則討論、評論 💬
https://news.ycombinator.com/item?id=48549918