Backend Pando của OpenAI giảm độ trễ push Git xuống 5 lần cho lập trình bằng tác nhân AI

OpenAI đã thay thế hạ tầng máy chủ Git tiêu chuẩn bằng một backend tùy chỉnh mang tên Pando nhằm hỗ trợ sự gia tăng khổng lồ về số lượng commit mã nguồn do các nhà phát triển và tác nhân AI tạo ra. Được đưa vào môi trường sản xuất vào tháng 4 năm 2026, hệ thống này được xây dựng chỉ trong mười tuần bằng ngôn ngữ Rust, giúp giảm đáng kể độ trễ khi push đồng thời xử lý gần một petabyte dữ liệu Git mỗi ngày.

Chuyện gì đã xảy ra

Sự chuyển đổi sang Pando bắt nguồn từ thay đổi mạnh mẽ trong cách OpenAI viết mã. Đến cuối năm 2026, số lượng commit theo quý vào monorepo của công ty dự kiến sẽ tăng hơn 2.400% so với quý 1 năm 2024. Sự gia tăng này phần lớn là do việc áp dụng rộng rãi các công cụ lập trình bằng tác nhân (agentic coding), vốn tạo ra mã nguồn với tốc độ vượt xa các đội ngũ phát triển thuần con người. Hạ tầng Git hiện tại gặp khó khăn trong việc theo kịp, với độ tin cậy giảm xuống dưới 90% do các thao tác fetch chậm và merge thất bại.

Trong khi một số công ty như Anthropic đã chọn từ bỏ hoàn toàn Git để ưu tiên các kiến trúc mới, OpenAI quyết định vẫn ở lại trong hệ sinh thái Git. Đội ngũ kỹ thuật, bao gồm Aaron Friel, Taylor Blau và Ted Nyman, xác định rằng nút thắt cổ chai không nằm ở giao thức Git mà là cách các máy chủ Git truyền thống quản lý trạng thái và phối hợp ghi dữ liệu. Họ tìm kiếm một giải pháp giữ nguyên khả năng tương thích với các công cụ dành cho nhà phát triển hiện có, đồng thời loại bỏ những giới hạn hiệu suất do thiết kế máy chủ truyền thống gây ra.

Kết quả là Pando, một backend tách biệt việc phối hợp nhánh và loại bỏ nhu cầu tạo các packfile tùy chỉnh cho từng yêu cầu từ client. Hệ thống này đi vào hoạt động từ tháng 4 năm 2026 và hiện phục vụ gần một petabyte dữ liệu Git mỗi ngày. OpenAI báo cáo rằng độ trễ khi push đã giảm gần năm lần, cho phép cả nhà phát triển con người lẫn tác nhân AI làm việc mà không gặp phải những trở ngại trước đây vốn gây phiền toái cho quy trình làm việc của họ.

Cách thức hoạt động

Pando thay đổi cơ bản hai giả định mà các máy chủ Git tiêu chuẩn thường dựa vào. Thứ nhất, nó không yêu cầu mọi nhánh trong kho lưu trữ phải ở trạng thái nhất quán cùng lúc. Thứ hai, nó ngừng xây dựng một packfile nén độc đáo cho từng yêu cầu fetch từ client. Trong Git truyền thống, một nhánh chỉ là con trỏ đến commit mới nhất, nhưng các máy chủ thường sắp xếp thứ tự cập nhật trên toàn bộ kho lưu trữ. Điều này có nghĩa là một thao tác push vào một nhánh có thể chặn một nhánh khác nếu chúng không liên quan. Pando xử lý mỗi nhánh một cách độc lập, vì vậy các thao tác push vào các nhánh khác nhau không phải chờ đợi lẫn nhau. Đổi lại, một client xem nhiều nhánh có thể thấy chúng ở các thời điểm hơi khác nhau, nhưng OpenAI lập luận rằng điều này chấp nhận được vì người dùng chủ yếu quan tâm đến lịch sử tuyến tính của một nhánh duy nhất.

Khi một client push mã, Pando xác thực packfile đầu vào khi nó được stream trực tiếp vào blob storage, mà không cần giải nén vào một repository cục bộ. Nó ghi lại tip nhánh mới và metadata trong một key-value store. Theo mặc định, Pando chỉ quảng bá nhánh trunk làm base cho các feature branch. Chiến lược này đảm bảo rằng hầu hết các packfile đều có thể tái sử dụng bởi các client khác đã có sẵn lịch sử của trunk. Khi một client fetch mã, Pando chọn các pack đã lưu trữ cần thiết dựa trên lịch sử hiện có của client và trả về các link tải xuống bằng tính năng giao thức packfile-uri của Git.

Một dịch vụ cache tên là Express phục vụ các pack này từ các cache khu vực, đạt tỷ lệ hit rate trên 99%. Để ngăn client tải xuống hàng chục nghìn pack nhỏ, các worker chạy nền gộp chúng thành các file lớn hơn theo thời gian, tương tự như cách các database log-structured nén dữ liệu. Điều này cho phép Pando xác định các pack mà client cần trong thời gian logarithmic. Trên các VM cloud tiêu chuẩn, kiến trúc này cho phép clone và fetch tận dụng tối đa băng thông mạng 10 Gbps, một cải tiến đáng kể so với việc repack và garbage collection nặng nề về tài nguyên tính toán mà các máy chủ truyền thống đòi hỏi.

Chi tiết chính

• Pando giảm độ trễ push xuống gần 5 lần so với hạ tầng trước đó.
• Hệ thống hiện phục vụ gần một petabyte dữ liệu Git mỗi ngày.
• Số lượng commit theo quý vào monorepo của OpenAI dự kiến tăng hơn 2.400% vào cuối năm 2026 so với Q1 2024.
• Backend được xây dựng bằng Rust chỉ trong 10 tuần, với thiết kế cốt lõi do một kỹ sư thực hiện và phần cài đặt được hỗ trợ bởi các tác nhân Codex.
• Pando đạt tỷ lệ cache hit rate trên 99% nhờ dịch vụ cache Express.
• OpenAI đang đóng góp một số bản vá phía client trở lại dự án Git mã nguồn mở, mặc dù bản thân Pando vẫn là độc quyền.

Tại sao điều này quan trọng

Đối với các lãnh đạo kỹ thuật và đội ngũ hạ tầng, Pando chứng minh rằng Git vẫn có thể mở rộng quy mô để đáp ứng nhu cầu của phát triển hỗ trợ bởi AI nếu kiến trúc máy chủ được suy nghĩ lại. Niềm tin phổ biến rằng Git vốn không phù hợp với các monorepo khổng lồ hoặc commit tự động tần suất cao bị thách thức ở đây. Nút thắt cổ chai không phải là hệ thống kiểm soát phiên bản, mà là mô hình máy chủ truyền thống ưu tiên tính nhất quán toàn cục và nén dữ liệu ngay tức thì. Bằng cách nới lỏng các yêu cầu về tính nhất quán giữa các nhánh không liên quan và tận dụng blob storage bất biến, OpenAI đã đạt được mức thông lượng tăng vọt mà không buộc nhà phát triển phải học một công cụ mới.

Cách tiếp cận này cũng làm nổi bật vai trò đang thay đổi của AI trong việc xây dựng hạ tầng. Việc một hệ thống nội bộ quan trọng được cài đặt trong mười tuần với sự hỗ trợ đáng kể từ các tác nhân AI gợi ý một tương lai nơi các công cụ nền tảng có thể được lặp lại nhanh hơn nhiều. Tuy nhiên, nó cũng nhấn mạnh áp lực tức thì mà các công cụ này đặt lên các hệ thống hiện có. Khi ngày càng nhiều tổ chức áp dụng lập trình bằng tác nhân, họ có thể sẽ đối mặt với những bức tường khả năng mở rộng tương tự. Hiểu cách tách biệt phối hợp ghi và tối ưu hóa đường dẫn đọc sẽ trở thành kiến thức thiết yếu cho các kỹ sư nền tảng.

Bạn có thể làm gì

• Đánh giá hiệu suất máy chủ Git hiện tại của bạn dưới tải ghi đồng thời cao, đặc biệt nếu bạn đang giới thiệu các trợ lý lập trình AI.
• Tìm hiểu tính năng giao thức packfile-uri trong các client Git của bạn để kích hoạt tải xuống và caching pack hiệu quả hơn.
• Cân nhắc xem đội ngũ của bạn có thực sự cần tính nhất quán nhánh toàn cục hay không, hoặc nếu việc xử lý nhánh độc lập có thể giảm bớt xung đột.
• Giám sát kích thước của các quảng bá tham chiếu (reference advertisements); nếu việc liệt kê tất cả các nhánh tạo ra payload lớn, hãy cân nhắc chỉ quảng bá các nhánh main hoặc trunk.
• Nghiên cứu các chiến lược gộp log-structured cho lưu trữ artifact của bạn để giảm số lượng file nhỏ được phục vụ trong quá trình fetch.
• Xem xét tracker patch công khai của OpenAI cho các cải tiến client Git liên quan đến tải xuống đồng thời và truy vết truyền tải.