Pando: így skálázza a Gitet az OpenAI a Codex korában

Mi történt?

Az OpenAI mérnöki blogján bemutatta a Pandót, egy saját fejlesztésű, Git-kompatibilis backendet (OpenAI). Ma már ez szolgálja ki a cég teljes monorepóját. A fejlesztők, illetve az agentek ugyanúgy használják a Gitet, mint korábban, csak a szerveroldal cserélődött ki alattuk.

Az ok egyszerű: a Codex miatt egy mérnök egyszerre több változtatást visz párhuzamosan. Több a branch, a push, a merge, ráadásul minden push több CI jobot indít, amelyek ugyanazt a commitot húzzák le. Tavaly év végétől a régi rendszer nem bírta a tempót, a megbízhatóság időnként 90 százalék alá esett.

Miben más a Pando?

A Pando két dolgot optimalizál: a sok író párhuzamos pushát különböző branchekre, illetve a sok olvasó gyors fetchét ugyanarról a historyról. Ehhez két hagyományos elvárást lazít.

• Nincs repó szintű konzisztencia. Minden branch külön frissül, így a független branchekre érkező pushok nem várnak egymásra. Ütközés csak akkor van, ha ketten ugyanazt a refet frissítik egyszerre. Ezt az OpenAI causal consistencynek hívja.
• Nincs minden kliensnek egyedi packfile. A push során beérkező packfile változatlanul blob storage-ba kerül, a szerver pedig később ugyanezeket a packeket adja oda a fetchelő klienseknek. Néha így olyan objektum is lejön, ami már megvan, cserébe a szervernek alig kell számolnia.
• Push esetén a szerver alapból csak a trunk branchet mutatja a kliensnek. Így a pack csak a trunktól függ, bárki újra tudja használni. Az OpenAI monorepójában a medián pack 20 KiB alatt, a 99. percentilis 3 MiB alatt maradt.
• A fetch a Git kevéssé ismert packfile-uri funkciójára épül: a szerver linkeket ad vissza, a packeket pedig az Express nevű regionális cache szolgálja ki, 99 százalék feletti találati aránnyal.
• A sok apró packet háttérben futó compaction vonja össze, a log-structured merge-tree mintájára, L0-tól jelenleg L4 szintig. Ettől a fetch tervezése logaritmikus időben megy.

Mit hozott élesben?

A medián push késleltetése közel 80 százalékkal csökkent, a merge-ek megbízhatóbbak lettek. A Pando naponta közel egy petabájt Git adatot szállít néhány CPU maggal, egy óra alatt már 57 terabájt fölött is járt. Szabványos felhős VM-ekkel a clone és a fetch kitölti a 10 Gbps-os hálózati linket.

A cikkben szereplő interaktív szimuláció a háromfázisú commitra (3PC), illetve a write-ahead logra (WAL) épülő megoldásokkal hasonlítja össze a Pandót. Az OpenAI hangsúlyozza, hogy ezek oktatási célú modellek, nem éles benchmarkok.

Hogyan épült?

A Pando Rustban készült, nulláról, legacy függőségek nélkül. Az indulástól az élesítésig 10 hét telt el: a magot egyetlen mérnök tervezte, az implementációt agentcsapatok írták, a deployt pár mérnök vitte. Áprilisban kezdte kiszolgálni az éles forgalmat.

A validáláshoz Git konformancia tesztcsomag, determinisztikus szimulációs tesztek, illetve formális módszerek kellettek: a GPT-6 Astrával dolgozó agentek Lean és TLA+ nyelven formalizálták a rendszert, ebből több hibát is találtak. Az átállás proxyként indult a régi rendszer előtt, a fejlesztők pedig a Codextől egyszerűen kérhették, hogy költöztesse át a környezetüket.

Mi jön most?

Az OpenAI több fejlesztést, például a packfile-uri körüli javításokat, már visszaküldte az upstream Gitbe, a többi a saját nyilvános Git buildjükben érhető el. A cég azt írja, vizsgálja, hogyan oszthatná meg a Pando mögötti technológiát a felhasználóival.

A tanulság szélesebb körben is érvényes: ha a csapat agentekkel dolgozik, a verziókezelés hamar szűk keresztmetszet lesz. Aki egy nagy monorepón sok párhuzamos agentet futtat, annak érdemes már most mérnie a push és fetch késleltetést.