Chia sẻ đam mê công nghệ
Chuyên sâu

GitHub phải mở rộng hạ tầng khi AI agent đẩy commit lên 7,38 tỷ mỗi tháng

GitHub ghi nhận 7,38 tỷ commit trong tháng 9/2026, cao hơn năm lần cùng kỳ. Áp lực không nằm riêng ở việc tạo mã: mỗi lần ghi, kiểm thử và đọc lại kho mã đều kéo theo tải lớn lên hạ tầng.

Minh họa lập trình viên làm việc với giao diện phát triển phần mềm
Làn sóng agent làm việc trên mã nguồn khiến hạ tầng Git phải xử lý nhiều hoạt động đồng thời hơn.

Tóm tắt nhanh

  • GitHub ghi nhận 7,38 tỷ commit trong tháng 9/2026, hơn năm lần so với cùng kỳ năm trước.
  • Trong năm 2026, nền tảng bổ sung 4 triệu nhân CPU, 160 PB lưu trữ tốc độ cao và 50 Tb/s năng lực mạng.
  • Nút thắt nằm ở lượng ghi đồng thời và các tác vụ đọc, kiểm thử phát sinh quanh mỗi thay đổi mã.
  • GitHub đang tách tầng lưu trữ khỏi tầng tính toán để mở rộng đọc và ghi độc lập hơn.

GitHub ghi nhận 7,38 tỷ commit trong tháng 9/2026, cao hơn năm lần cùng kỳ năm trước, trong lúc GitHub Actions chạy 3,26 tỷ lượt. Quy mô hoạt động mới khiến nền tảng phải bổ sung hàng triệu nhân CPU và thay đổi cách lưu trữ, phân phối dữ liệu Git; tác động của AI agent vì thế không dừng ở chi phí GPU để tạo mã.

Con số hạ tầng được GitHub công bố tại sự kiện Universe 2026: từ đầu năm, công ty đã thêm 4 triệu nhân CPU, 160 petabyte lưu trữ tốc độ cao và 50 Tb/s năng lực mạng. Đây là tài nguyên cho toàn nền tảng, phục vụ việc tiếp nhận, lưu trữ và xử lý hoạt động phát triển phần mềm đang tăng lên.

Mỗi thay đổi do agent tạo ra kéo theo nhiều lượt đọc và kiểm thử

Commit chỉ là dấu mốc dễ đếm; phần tải phía sau mới giải thích vì sao hoạt động tăng nhanh có thể làm nghẽn dịch vụ. Một agent thường tạo nhiều checkpoint trong vòng lặp làm việc. Sau đó, hệ thống CI, quét mã và các công cụ khác có thể cùng đọc lại nhánh vừa cập nhật để kiểm tra thay đổi.

GitHub Actions xử lý 3,26 tỷ lượt chạy trong tháng 9, hơn bốn lần một năm trước. Với quy trình tự động, một lần push không tương đương một lần đọc: nhiều job có thể lấy cùng một phiên bản mã gần như đồng thời. Bởi vậy, tăng số máy chủ đọc dữ liệu không giải quyết hết áp lực nếu mỗi máy lại phải tham gia vào cơ chế ghi bền vững.

Pull request cũng cho thấy công việc đang dịch chuyển. Tom’s Hardware dẫn số liệu GitHub cho biết hơn 40% pull request trong tháng 9 được agent khởi tạo, so với 17% vào tháng 3. Tỷ lệ này phản ánh mức độ agent tham gia quy trình, chứ không có nghĩa từng pull request được tự động chấp nhận hay thay thế khâu review của con người.

Cách nhân bản kho mã cũ khiến việc tăng tải đọc làm chậm ghi

Trong kiến trúc Spokes hiện tại, mỗi repository có các bản sao đầy đủ trên đĩa cục bộ của nhiều máy chủ fileserver, mặc định là năm. Các bản sao giúp phân tán lượt đọc và dự phòng; khi một lần push cập nhật tham chiếu, giao thức commit ba pha dùng quorum để các dịch vụ như CI, giao diện web và API nhìn thấy trạng thái nhất quán.

Đổi lại, bản sao trên đĩa vừa là nơi giữ dữ liệu bền vững vừa là năng lực phục vụ truy vấn. Thêm replica để chịu nhiều lượt đọc đồng nghĩa thêm thành phần phải tham gia vào lần ghi. Một push vì vậy có thể phải đợi replica chậm nhất trong nhóm; nếu mất quorum, việc ghi cũng dừng. Mô hình này phù hợp với phần lớn kho mã, nhưng trở thành giới hạn khi hàng nghìn agent và pipeline cùng hoạt động trên một repository.

Đây là một khác biệt quan trọng so với bài toán chỉ tăng tốc suy luận AI. Agent có thể sinh mã nhanh hơn, nhưng thay đổi đó vẫn phải được lưu bền vững, kiểm tra, nhân bản và cung cấp cho các job tiếp theo. Nếu vòng lặp commit nhanh hơn khả năng xử lý của kho mã và CI, tốc độ tạo mã không chuyển thành tốc độ giao phần mềm.

Tách lưu trữ khỏi tính toán giúp GitHub mở rộng từng tầng

Kiến trúc mới của GitHub đặt dữ liệu repository có thẩm quyền trong Azure Blob Storage, còn các worker tính toán đảm nhiệm xử lý yêu cầu và lưu cache. Khi đó, mất một worker gần với việc cache bị mất hơn là mất một bản sao dữ liệu đầy đủ; worker thay thế có thể lấy dữ liệu từ tầng lưu trữ bền vững.

Việc tách hai tầng còn cho phép tăng năng lực đọc khi CI hoặc agent tạo đột biến lưu lượng mà không buộc mọi lượt ghi phải chờ thêm một bản sao bền vững. GitHub cho biết nguyên tắc thiết kế là giảm phần cần phối hợp đồng bộ: cập nhật tham chiếu vẫn cần sự thống nhất, trong khi một số công việc như lưu đối tượng, kiểm tra kết nối và quét bí mật có thể diễn ra song song.

GitHub cũng muốn chuyển các tác vụ bảo trì nặng như compact dữ liệu và garbage collection sang worker riêng, thay vì để chúng tranh tài nguyên với máy chủ đang trả lời yêu cầu Git. Trong benchmark nội bộ, công ty cho biết kiến trúc mới đạt thông lượng ghi cao hơn tới 35 lần so với Spokes truyền thống; đây là kết quả thử nghiệm của GitHub, không phải cam kết mọi repository sẽ nhanh hơn đúng mức đó.

Độ tin cậy của nền tảng quan trọng hơn số commit kỷ lục

Với lập trình viên và doanh nghiệp Việt Nam, hệ quả dễ thấy không phải là cần tự mua thêm CPU chỉ vì đội ngũ dùng Copilot hay agent. GitHub vận hành phần hạ tầng này; điều đáng theo dõi là độ ổn định của dịch vụ, thời gian chờ pipeline và chi phí CI khi một nhóm chuyển sang tạo nhiều thay đổi song song.

Doanh nghiệp có thể kiểm soát phần việc của mình bằng cách tránh chạy kiểm thử trùng lặp trên cùng commit, giới hạn mức song song của workflow khi tài nguyên runner có hạn, và đặt quy tắc review phù hợp trước khi merge. Các biện pháp đó không thay thế hạ tầng của GitHub, nhưng giúp đội ngũ không biến tốc độ tạo mã thành hàng đợi kiểm thử dài hơn.

GitHub cho biết đang chuyển sang triển khai đa vùng trên Azure và dự kiến hoàn tất vào đầu năm sau. Khi agent tạo thêm thay đổi, phép thử quan trọng sẽ là liệu nền tảng có giữ được khả năng ghi nhất quán và phục vụ CI ổn định hay không — chứ không đơn thuần là đạt thêm một kỷ lục commit.

Nguồn tham khảo: GitHub Blog; GitHub Engineering Blog; Tom’s Hardware

Bài này thế nào?

Hoá đơn của bài này

Tek viết bài này bằng cà phê. Mời Tek một ly nha?

Theo dõi TekCafe: Facebook · YouTube

Bài viết mới nhất