OpenAI opisało 2 listopada 2026 roku Pando, wewnętrzny backend Git obsługujący rozwój firmowego monorepo. System zachowuje zgodność z protokołem i klientem Git, a OpenAI podaje, że po jego wdrożeniu mediana opóźnienia operacji push w produkcji spadła o prawie 80%. Wpis inżynieryjny OpenAI opisuje też, jak Pando koordynuje zmiany i ponownie wykorzystuje dane Git.

Pando obsługuje monorepo bez zmiany klienta Git

Pando zaczął obsługiwać ruch produkcyjny w kwietniu 2026 roku, po około 10 tygodniach prac. OpenAI opisuje go jako backend zgodny z protokołem i klientem Git, dzięki czemu dotychczasowy sposób pracy zespołu nie wymagał zmiany. Firma podaje, że system powstał w Rust bez zależności od starszych rozwiązań.

Jak Pando zapisuje i dostarcza dane Git

Przy operacji push Pando weryfikuje napływający packfile, czyli paczkę obiektów Git, podczas strumieniowego zapisu do magazynu obiektów. Osobny magazyn metadanych rejestruje wersje referencji, czyli wskaźników takich jak gałęzie, oraz ich zależności. Pando nie musi przy tym rozpakowywać każdej paczki do lokalnego repozytorium.

Przy fetch system sprawdza, które commity klient już zna i o które prosi, a następnie wybiera zapisane packfile zawierające brakujące obiekty. Zwraca adresy tych paczek, a usługa Express dostarcza je z użyciem regionalnych pamięci podręcznych. Dzięki temu Pando może ponownie wykorzystywać istniejące paczki zamiast tworzyć osobny zestaw danych dla każdego pobrania. W tle kompakcja łączy mniejsze paczki w większe zestawy, zwane pokryciami; w monorepo OpenAI sięgają one poziomu L4.

Ten sposób doboru paczek ma też koszt przy niektórych zmianach. Podczas wysyłania nowej gałęzi funkcyjnej Pando zwykle ogłasza jako podstawę wyznaczoną gałąź główną, trunk. Ogranicza to zależność ogłoszenia od liczby gałęzi i ułatwia ponowne użycie paczek. Jednak kolejne wysyłki tej samej gałęzi lub gałęzi ułożonych jedna na drugiej mogą ponownie przesłać obiekty spoza trunk. W monorepo OpenAI mediana takiej paczki wynosiła poniżej 20 KiB, a 99. percentyl poniżej 3 MiB.

Równoległe zmiany nie tworzą jednej migawki wszystkich gałęzi

Pando porządkuje aktualizacje osobno dla każdej referencji. Zmiany w niezależnych gałęziach mogą zachodzić równolegle, a aktualizacje tej samej referencji mają gwarancję serializowalności, czyli zachowują spójną kolejność. Klienci zachowują też spójność odczytu własnych zapisów.

Odczyt obejmujący kilka gałęzi nie musi jednak przedstawiać ich stanu z tej samej chwili. W trakcie równoległych aktualizacji jedna gałąź może już zawierać nowszy stan, podczas gdy druga odzwierciedla wcześniejszy. Pando nie gwarantuje więc jednej migawki całego repozytorium dla odczytów wielogałęziowych.

Co obejmują wyniki wydajności podane przez OpenAI

OpenAI raportuje prawie 80% niższą medianę opóźnienia push w swoim środowisku produkcyjnym oraz blisko 1 PB danych Git dostarczanych dziennie. Firma podaje również, że w godzinie szczytu system obsłużył ponad 57 TB packfile, z czego ponad 99% bajtów pochodziło z lokalnej pamięci dyskowej. W testach klonowania i pobierania standardowe maszyny wirtualne u dostawców chmurowych wysycały łącza 10 Gbps.

To wyniki dotyczące systemu i obciążenia OpenAI. Interaktywne porównanie Pando z modelami opartymi na trójfazowym zatwierdzaniu oraz dzienniku WAL w magazynie obiektowym firma określa jako syntetyczne modele edukacyjne, a nie benchmarki produkcyjne.

Co OpenAI mówi o udostępnieniu Pando

OpenAI opisało Pando jako system wewnętrzny obsługujący własne monorepo. Wpis z 2 listopada 2026 roku mówi o badaniu sposobów udostępnienia technologii, która umożliwia działanie Pando, ale nie określa terminu ani formatu publicznego wydania samego backendu. OpenAI informuje też, że część usprawnień Git wypracowanych przy tych pracach trafiła już do głównego projektu Git, a inne znajdują się w publicznym repozytorium firmy.