OpenAI entwickelt Git-Backend Pando und senkt die mediane Push-Latenz um fast das Fünffache

Warum OpenAI sein Backend für die Versionsverwaltung ersetzt hat

OpenAI zufolge sind Größe und Anforderungen des Monorepos im vergangenen Jahr in einem "atemberaubenden Tempo" gewachsen. Das Unternehmen führt dies auf Codex zurück, mit dem Entwicklerinnen und Entwickler deutlich mehr Arbeit parallel erledigen können. Die Folge sind mehr Branches, Pushes und Merges sowie mehr Fetches und Clones aus Entwicklungsumgebungen, Forschungsjobs und CI.

Diese Anforderungen verstärken sich laut OpenAI gegenseitig: Ein einzelner Entwickler kann heute mehrere Änderungen gleichzeitig für die CI bereithalten, und jeder Push kann mehrere Jobs auslösen, die denselben Commit abrufen. Ab etwa Ende des vergangenen Jahres kamen die Systeme hinter dem Monorepo kaum noch hinterher. OpenAI berichtet von langsamen Fetches und Pushes sowie fehlgeschlagenen Merges, die Zuverlässigkeit sei zeitweise unter 90 % gefallen.

Das Team fragte sich, ob es an eine Grenze von Git selbst oder an die Art der Bereitstellung des Monorepos gestoßen war. Es kam zu dem Schluss, dass das Problem im Backend lag, und entschied sich, den vertrauten Git-Workflow beizubehalten und das Backend so neu aufzubauen, dass es Pushes auf verschiedene Branches parallel verarbeiten und dieselbe Historie vielen Lesenden gleichzeitig bereitstellen kann.

So funktioniert Pando

OpenAI nennt zwei Ziele für Pando: horizontal skalierbare Schreibvorgänge, optimiert für gleichzeitige Pushes auf viele Branches, und maximalen Lesedurchsatz, damit Clients Daten schnell genug herunterladen können, um die verfügbare Netzwerkbandbreite voll auszulasten. Pando bleibt mit dem Git-Protokoll und dem Git-Client kompatibel, sodass sowohl Entwicklerinnen und Entwickler als auch Agenten es in bestehenden Workflows nutzen konnten. Die Migration sei laut OpenAI ohne Unterbrechung der Entwicklungsarbeit erfolgt.

Zwei Designentscheidungen fallen besonders auf:

• Koordination pro Branch. Pando koordiniert Aktualisierungen jedes Branches unabhängig, sodass Änderungen an nicht zusammenhängenden Branches parallel ablaufen können. Der Kompromiss, so OpenAI: Wer mehrere Branches gleichzeitig betrachtet, sieht sie möglicherweise zu unterschiedlichen Zeitpunkten.
• Wiederverwendung von Packfiles. Pando verwendet Packfiles, das Git-Format zum gemeinsamen Komprimieren mehrerer Objekte, über mehrere Fetches hinweg erneut, statt für jeden Client ein eigenes Packfile zu erzeugen. Ein Client lädt dadurch womöglich einige Objekte herunter, die er schon besitzt, doch der Server kann dieselben Bytes mit wenig Rechenaufwand an viele Clients ausliefern.

Zusammen ermöglichen diese Entscheidungen laut OpenAI, Schreibvorgänge über Branches hinweg zu skalieren und Lesezugriffe aus Caches zu bedienen.

Alternativen, die OpenAI geprüft hat

Vor dem Bau von Pando hat das Unternehmen zwei gängige Ansätze zur Skalierung von Git durchgerechnet. Der erste koordiniert Ref-Updates über vollständige Repository-Replikate hinweg per Three-Phase Commit (3PC). Eine Mehrheit der Replikate muss jedes Ref-Update akzeptieren, was mehrere Kommunikationsrunden erfordert. OpenAI zufolge bedeutet das, dass Referenzen nacheinander aktualisiert werden und dass das Warten auf ein Quorum die Festplattenleistung der Replikate und die Kommunikationslatenz in den Push-Pfad verlagert.

Der zweite Ansatz nutzt ein gemeinsames Write-Ahead-Log-Manifest (WAL) im Blob-Speicher, um Aktualisierungen im gesamten Repository zu ordnen. Der hier vorliegende Quelltext bricht mitten in der Beschreibung dieses Designs ab, weshalb dessen Kompromisse nicht behandelt werden.

OpenAI weist zudem darauf hin, dass Systeme, die allen Schreibvorgängen eines Repositorys eine einzige Reihenfolge auferlegen, dazu führen können, dass Pushes auf unabhängige Branches aufeinander warten müssen. Genau dieses Problem soll Pandos Ansatz pro Branch vermeiden.

Was das bedeutet

Für OpenAI ergibt sich ein Versionsverwaltungssystem, das für Arbeit im Agenten-Maßstab ausgelegt ist, während Entwicklerinnen und Entwickler weiterhin Standard-Git nutzen. Das Unternehmen sagt, das Festhalten an Git habe bedeutet, dass Verbesserungen am Client auch über OpenAI hinaus nützlich sein könnten, und man wolle Verbesserungen aus der eigenen Git-Version in das Upstream-Projekt einbringen. Außerdem kündigt OpenAI an, darüber zu sprechen, wie es weitergeht und wie das Unternehmen weiterhin zu Git beitragen will, um Arbeit im Agenten-Maßstab zu unterstützen.