Mục lục
TL;DR: OpenAI cho biết đã đưa Pando (backend mới tương thích Git) vào vận hành cho toàn bộ monorepo để đáp ứng lượng công việc song song tăng do Codex, giúp giảm gần 5 lần độ trễ push.
Sự gia tăng của AI hỗ trợ lập trình đang tạo áp lực lên một lớp hạ tầng ít được chú ý hơn mô hình AI: hệ thống quản lý phiên bản mã nguồn. Theo OpenAI, monorepo, tức kho mã nguồn tập trung chứa nhiều thành phần của tổ chức, đã tăng nhanh cả về quy mô lẫn nhu cầu sử dụng trong năm qua.
Công ty xây Pando mà không làm gián đoạn công việc kỹ thuật hoặc buộc đội ngũ thay đổi cách dùng Git. Hệ thống vẫn tương thích với giao thức và client Git hiện có, để kỹ sư lẫn agent có thể tiếp tục làm việc theo quy trình quen thuộc.
Trong môi trường production, OpenAI cho biết Pando phục vụ gần một petabyte dữ liệu Git mỗi ngày. Hệ thống được thiết kế để nhận nhiều lượt push đồng thời trên các nhánh khác nhau, đồng thời đẩy tốc độ fetch và clone lên gần giới hạn kết nối mạng sẵn có của client.
Tải Git tăng khi Codex tạo thêm công việc song song
Theo OpenAI, Codex, trợ lý AI làm việc với mã nguồn, cho phép kỹ sư chuẩn bị nhiều thay đổi để chạy CI cùng lúc. CI, hay tích hợp liên tục, là các tác vụ tự động kiểm tra mã sau khi có thay đổi. Mỗi lần push có thể kích hoạt nhiều job cùng fetch một commit, trong khi môi trường phát triển và các tác vụ nghiên cứu cũng liên tục clone hoặc tải dữ liệu từ kho mã.
Vì vậy, số nhánh, lượt push, merge, fetch và clone đều tăng. OpenAI cho biết từ khoảng cuối năm trước, hạ tầng cũ bắt đầu gặp fetch và push chậm, merge thất bại; độ tin cậy có lúc xuống dưới 90%.
Vấn đề không chỉ là tốc độ của một lệnh Git. Hệ thống phải phục vụ đồng thời nhiều người hoặc agent ghi thay đổi vào nhiều nhánh, trong lúc nhiều máy khác đọc cùng một phần lịch sử mã nguồn. Đây là kiểu tải đặc trưng của môi trường phát triển được tự động hóa mạnh.
Pando đánh đổi tính nhất quán toàn cục để tăng tốc ghi
Để mở rộng khả năng ghi, Pando không duy trì một ảnh chụp đồng bộ tại cùng thời điểm cho toàn bộ repository trong mọi thao tác Git. Thay vào đó, hệ thống dùng causal consistency, có thể hiểu là người đọc sẽ nhận được lịch sử cần thiết để hiểu thay đổi mà người ghi đã tạo ra, đồng thời các cập nhật trên từng ref vẫn được xử lý tuần tự.
Ref là con trỏ của Git, chẳng hạn một nhánh trỏ tới commit mới nhất. Với Pando, cập nhật ở các ref không liên quan có thể diễn ra song song; xung đột chủ yếu xảy ra khi hai bên cùng push vào một ref. Đổi lại, client đang đọc nhiều nhánh không được bảo đảm rằng mọi nhánh phản ánh cùng một thời điểm của repository.
OpenAI cho rằng đánh đổi này phù hợp vì kỹ sư và agent thường cần thứ tự cập nhật của nhánh đang dùng hơn là trạng thái đồng bộ tuyệt đối của mọi nhánh. Đây là giới hạn thiết kế cần lưu ý, không chỉ là một tối ưu hiệu năng.
Khi nhận push, Pando lưu packfile, định dạng Git đóng gói và nén nhiều đối tượng dữ liệu, dưới dạng dữ liệu bất biến trong blob storage. Sau đó, hệ thống ghi phiên bản ref vào kho metadata. Theo mô tả của OpenAI, máy chủ không cần giải nén rồi đóng gói lại dữ liệu vào repository cục bộ, nên chủ yếu làm nhiệm vụ xác thực, thương lượng và chọn packfile cần gửi.
Khác hai hướng mở rộng Git phổ biến
OpenAI đối chiếu Pando với hai hướng kiến trúc phổ biến. Hướng thứ nhất là three-phase commit, giao thức phối hợp nhiều bản sao repository để xác nhận cập nhật. Cách này có thể cung cấp góc nhìn nhất quán trên mọi ref, nhưng mỗi push phải qua nhiều vòng trao đổi giữa máy chủ và chờ đa số bản sao phản hồi.
Hướng thứ hai là write-ahead log, trong đó các cập nhật được sắp thứ tự qua một nhật ký dùng chung. Packfile có thể được tải lên song song, nhưng các lần push vào nhánh không liên quan vẫn cạnh tranh để cập nhật cùng một manifest. Các bản sao cũng phải đọc và lập chỉ mục dữ liệu mới trước khi phục vụ được, điều có thể làm chậm thao tác đọc khi lượng ghi tăng.
Trong mô phỏng do OpenAI thực hiện với 1.000 client, mỗi client lặp lại việc push commit riêng lên một nhánh riêng, công ty cho biết mô hình three-phase commit có độ trễ ghi cao hơn khi đĩa bão hòa. Mô hình write-ahead log có độ trễ đọc cao hơn khi máy chủ không theo kịp việc đọc nhật ký. Đây là kết quả mô phỏng và thử nghiệm trên monorepo của OpenAI, không phải benchmark độc lập.
Tái sử dụng packfile để phục vụ fetch và clone
Ở Git thông thường, server thường tính riêng tập đối tượng mà từng client còn thiếu rồi tạo packfile phù hợp. Cách này giúp giảm dữ liệu tải dư thừa, nhưng tốn CPU và I/O, đồng thời khó tận dụng cache khi nhiều client cần lịch sử tương tự.
Pando tái sử dụng packfile đã nhận từ các lần push. Khi client fetch, hệ thống đối chiếu commit client đã có và commit cần lấy với các phiên bản ref đã lưu, rồi chọn các packfile cần thiết. Git hỗ trợ cơ chế packfile-uri để client tải thêm packfile riêng; Pando dùng cơ chế này cùng Express, dịch vụ phân phối có cache cục bộ.
OpenAI cho biết tỷ lệ cache hit của Express vượt 99%, còn clone hoặc fetch có thể bão hòa đường truyền 10 Gbps trên hạ tầng cloud tiêu chuẩn. Để packfile có thể tái sử dụng, Pando chỉ quảng bá cho client một tập ref chọn lọc khi push, mặc định là một nhánh trunk làm cơ sở cho nhánh tính năng mới.
Đánh đổi là những lần push liên tiếp hoặc các nhánh xếp chồng có thể phải gửi lại một số đối tượng. Theo OpenAI, packfile trung vị trong monorepo của họ vẫn dưới 20 KiB, còn phân vị 99 dưới 3 MiB.
Vì sao đáng chú ý?
Pando cho thấy ảnh hưởng của AI lập trình không dừng ở việc tạo mã nhanh hơn. Khi số tác nhân có thể tạo thay đổi tăng lên, hạ tầng nền như quản lý phiên bản, CI, lưu trữ và mạng cũng phải xử lý mức độ song song lớn hơn.
Việc giữ tương thích Git cũng là một lựa chọn thực dụng: OpenAI thay phần vận hành phía sau thay vì thay toàn bộ công cụ quen thuộc của kỹ sư. Công ty cho biết đã đóng góp các cải tiến liên quan đến packfile-uri cho Git, với mục tiêu để một phần thay đổi ở client có thể hữu ích cho cộng đồng rộng hơn.
- Nguồn chính thức: Scaling Git at OpenAI, OpenAI, 02/11/2026
