OpenAI-Backend Pando senkt Git-Push-Latenz um Faktor 5 für agentisches Coden

OpenAI hat seine Standard-Git-Serverinfrastruktur durch ein eigenes Backend namens Pando ersetzt, um den massiven Anstieg der Code-Commits zu unterstützen, die von seinen Entwicklern und KI-Agenten generiert werden. Das im April 2026 produktiv gesetzte System wurde in nur zehn Wochen mit Rust entwickelt und reduziert die Push-Latenz erheblich, während es täglich nahezu ein Petabyte an Git-Daten verarbeitet.

Was passiert ist

Der Wechsel zu Pando wurde durch eine dramatische Veränderung in der Art und Weise ausgelöst, wie OpenAI Code schreibt. Bis Ende 2026 wird erwartet, dass die quartalsweisen Commits in das Monorepo des Unternehmens um über 2.400 % gegenüber dem ersten Quartal 2024 steigen. Dieser Anstieg ist größtenteils auf die weit verbreitete Einführung von Tools für agentisches Coden zurückzuführen, die Code in einem Tempo generieren, das menschliche Entwicklungsteams bei weitem übertrifft. Die bestehende Git-Infrastruktur hatte Mühe, Schritt zu halten; die Zuverlässigkeit fiel aufgrund langsamer Abrufe und fehlgeschlagener Merges unter 90 %.

Während einige Unternehmen wie Anthropic sich entschieden haben, Git vollständig zugunsten neuer Architekturen aufzugeben, beschloss OpenAI, im Git-Ökosystem zu bleiben. Das Engineering-Team, darunter Aaron Friel, Taylor Blau und Ted Nyman, stellte fest, dass der Engpass nicht das Git-Protokoll selbst war, sondern die Art und Weise, wie konventionelle Git-Server Zustände verwalten und Schreibvorgänge koordinieren. Sie suchten nach einer Lösung, die die Kompatibilität mit bestehenden Entwickler-Tools beibehält, aber die Leistungsdeckel entfernt, die durch traditionelle Serverdesigns auferlegt werden.

Das Ergebnis ist Pando, ein Backend, das die Branch-Koordination entkoppelt und die Notwendigkeit eliminiert, für jede Client-Anfrage benutzerdefinierte Packfiles zu generieren. Das System ging im April 2026 live und bedient nun täglich fast ein Petabyte an Git-Daten. OpenAI meldet, dass die Push-Latenz um fast das Fünffache gesenkt wurde, sodass sowohl menschliche Entwickler als auch KI-Agenten ohne die Reibung arbeiten können, die ihren Workflow zuvor plagte.

Wie es funktioniert

Pando ändert grundlegend zwei Annahmen, die von Standard-Git-Servern getroffen werden. Erstens erfordert es nicht, dass jeder Branch im Repository gleichzeitig in einem konsistenten Zustand ist. Zweitens stoppt es das Erstellen eines eindeutigen, komprimierten Packfiles für jeden einzelnen Client-Abruf. Im traditionellen Git ist ein Branch lediglich ein Zeiger auf den neuesten Commit, aber Server ordnen Updates normalerweise über das gesamte Repository hinweg. Das bedeutet, dass ein Push auf einen Branch einen anderen blockieren kann, wenn sie unrelated sind. Pando behandelt jeden Branch unabhängig voneinander, sodass Pushes auf verschiedene Branches nicht aufeinander warten müssen. Der Kompromiss besteht darin, dass ein Client, der mehrere Branches betrachtet, diese möglicherweise zu leicht unterschiedlichen Zeitpunkten sieht, aber OpenAI argumentiert, dass dies akzeptabel ist, da Benutzer primär an der linearen Historie eines einzelnen Branches interessiert sind.

Wenn ein Client Code pusht, validiert Pando das eingehende Packfile, während es direkt in den Blob-Speicher streamt, ohne es in ein lokales Repository zu entpacken. Es zeichnet die neue Branch-Spitze und Metadaten in einem Key-Value-Store auf. Standardmäßig bewirbt Pando nur den Trunk-Branch als Basis für Feature-Branches. Diese Strategie stellt sicher, dass die meisten Packfiles von anderen Clients wiederverwendet werden können, die bereits die Trunk-Historie besitzen. Wenn ein Client Code abruft, wählt Pando die erforderlichen gespeicherten Packs basierend auf der bestehenden Historie des Clients aus und gibt Download-Links unter Verwendung der Git-Protokollfunktion packfile-uri zurück.

Ein Caching-Dienst namens Express liefert diese Packs aus regionalen Caches und erreicht eine Trefferquote von über 99 %. Um zu verhindern, dass Clients zehntausende kleiner Packs herunterladen, fassen Hintergrund-Worker diese im Laufe der Zeit zu größeren Dateien zusammen, ähnlich wie log-strukturierte Datenbanken Daten komprimieren. Dies ermöglicht es Pando, in logarithmischer Zeit zu bestimmen, welche Packs ein Client benötigt. Auf Standard-Cloud-VMs ermöglicht diese Architektur, dass Clones und Fetches eine 10-Gbps-Netzwerkverbindung voll auslasten – eine erhebliche Verbesserung gegenüber dem rechenintensiven Repacking und der Garbage Collection, die von traditionellen Servern erforderlich sind.

Wichtige Details

• Pando reduzierte die Push-Latenz im Vergleich zur vorherigen Infrastruktur um fast das 5-fache.
• Das System bedient derzeit täglich fast ein Petabyte an Git-Daten.
• Quartalsweise Commits in OpenAIs Monorepo sollen bis Ende 2026 um über 2.400 % gegenüber Q1 2024 steigen.
• Das Backend wurde in nur 10 Wochen in Rust gebaut, wobei das Kerndesign von einem Ingenieur stammte und die Implementierung durch Codex-Agenten unterstützt wurde.
• Pando erreicht eine Cache-Trefferquote von über 99 % unter Verwendung seines Express-Caching-Dienstes.
• OpenAI steuert mehrere clientseitige Korrekturen zum Open-Source-Projekt Git bei, obwohl Pando selbst proprietär bleibt.

Warum es wichtig ist

Für Engineering-Leiter und Infrastruktur-Teams demonstriert Pando, dass Git weiterhin skalieren kann, um den Anforderungen KI-gestützter Entwicklung gerecht zu werden, wenn die Serverarchitektur überdacht wird. Die gängige Annahme, dass Git für massive Monorepos oder hochfrequente automatisierte Commits grundsätzlich ungeeignet ist, wird hier herausgefordert. Der Engpass war nicht das Versionskontrollsystem selbst, sondern das traditionelle Servermodell, das globale Konsistenz und On-the-Fly-Kompression priorisiert. Durch die Lockerung der Konsistenzanforderungen über unrelated Branches hinweg und die Nutzung unveränderlicher Blob-Speicherung erzielte OpenAI massive Durchsatzgewinne, ohne Entwickler zu zwingen, ein neues Tool zu lernen.

Dieser Ansatz hebt auch die sich wandelnde Rolle von KI beim Aufbau von Infrastruktur hervor. Die Tatsache, dass ein kritisches internes System in zehn Wochen mit erheblicher Unterstützung durch KI-Agenten implementiert wurde, deutet auf eine Zukunft hin, in der grundlegende Tools viel schneller iteriert werden können. Es unterstreicht jedoch auch den unmittelbaren Druck, den diese Tools auf bestehende Systeme ausüben. Da mehr Organisationen agentisches Coden einführen, werden sie wahrscheinlich ähnliche Skalierbarkeitswände erfahren. Zu verstehen, wie man Schreibkoordinierung entkoppelt und Lesezugriffe optimiert, wird essenzielles Wissen für Plattform-Ingenieure werden.

Was Sie tun können

• Bewerten Sie die Leistung Ihres aktuellen Git-Servers unter hoher paralleler Last bei Schreibvorgängen, insbesondere wenn Sie KI-Coding-Assistenten einführen.
• Untersuchen Sie die Protokollfunktion packfile-uri in Ihren Git-Clients, um effizientere Pack-Downloads und Caching zu ermöglichen.
• Überlegen Sie, ob Ihr Team wirklich globale Branch-Konsistenz benötigt oder ob unabhängige Branch-Behandlung Kontention reduzieren könnte.
• Überwachen Sie die Größe Ihrer Referenz-Werbung; wenn das Auflisten aller Branches große Payloads erzeugt, erwägen Sie, nur Main- oder Trunk-Branches zu bewerben.
• Recherchieren Sie Strategien für log-strukturiertes Merging für Ihre Artefakt-Speicherung, um die Anzahl der kleinen Dateien zu reduzieren, die während Fetches bereitgestellt werden.
• Prüfen Sie OpenAIs öffentlichen Patch-Tracker für Git-Client-Verbesserungen im Zusammenhang mit parallelen Downloads und Transfer-Tracing.