Pando divise par cinq la latence de push du monorepo d'OpenAI
OpenAI publie le 2 novembre 2026 la description de Pando, le backend qui sert désormais tout le développement de son monorepo. Le système garde le protocole et le client Git, abandonne l'instantané cohérent de toutes les branches et le packfile fabriqué pour chaque client, et réutilise les packs déjà reçus. En production depuis avril, il ramène la latence médiane du push à un cinquième de la précédente et sert près d'un pétaoctet de données Git par jour.
par Gyom 3 novembre 2026 à 13:04 6 min de lecture rubrique : Code
etiquettes : En entreprise · Hébergé
Le monorepo d'OpenAI a cessé de tenir. À partir de la fin 2025, les lectures et les écritures ralentissent, des fusions échouent, et la fiabilité passe par moments sous 90 %. La cause n'est pas un défaut de Git mais le nombre d'écritures simultanées : un ingénieur assisté par Codex prépare plusieurs changements à la fois, et chaque push déclenche plusieurs tâches d'intégration qui vont chercher le même commit. Pando, le backend qui remplace le service précédent, sert depuis avril 2026 tout le développement du monorepo.
La fiabilité est tombée sous 90 % à force de pushes parallèles
L'équipe pose la bonne question avant de coder : la limite vient-elle de Git, ou de la manière de servir le dépôt ? Git a été écrit pour un noyau Linux dont les patchs circulaient par courriel, et vingt ans de changements d'usage se sont réglés côté outil, pas côté serveur. La réponse retenue est de reconstruire le serveur en gardant le protocole et le client, pour que les ingénieurs et les agents n'aient rien à changer à leur façon de travailler.
Deux dimensions se scalent séparément : beaucoup d'auteurs qui poussent sur des branches différentes, et beaucoup de lecteurs qui tirent la même histoire. Le service précédent perdait sur les deux, et l'article décrit deux architectures modelées puis écartées.
Deux approches écartées : le quorum et le journal partagé
La première garde une copie complète du dépôt sur plusieurs répliques, copie le pack entrant vers toutes en parallèle, et exige qu'une majorité accepte la mise à jour de la référence avant de publier. Le temps d'attente d'un quorum met la performance disque des répliques et la latence du réseau sur le chemin du push, et chaque réplique doit absorber les écritures entrantes en plus du trafic de lecture.
La seconde range les packs dans un stockage d'objets et ordonne les mises à jour par un manifeste partagé, remplacé par une opération atomique de comparaison et d'échange. Les packs montent en parallèle, mais deux pushes sur des branches sans rapport se disputent le même manifeste, et le temps d'un aller-retour réussi plafonne la cadence de publication. Chaque réplique doit encore lire et indexer les packs avant de pouvoir les servir : quand les écritures dépassent ce travail, les lecteurs attendent.
Deux garanties abandonnées : l'instantané global et le packfile par client
Pando renonce à deux propriétés que la plupart des serveurs Git tiennent pour acquises. La première est la cohérence sur tout le dépôt : donner à un lecteur une photographie unique de toutes les références oblige à coordonner chaque mise à jour, et cette coordination devient le point de contention. La seconde est le packfile taillé pour chaque client : deux clients partis d'histoires différentes reçoivent deux paquets différents, ce qui coûte du processeur et des entrées-sorties à chaque lecture.
Le système fournit à la place une cohérence causale. Un lecteur qui tire une référence observe l'histoire de l'auteur qui l'a produite, et les mises à jour d'une même référence restent sérialisées. Deux clients qui clonent au même moment peuvent voir une branche en version 1 et l'autre en version 2, puis l'inverse. C'est un vrai renoncement : l'ordre global des références n'existe plus pendant un clone.
Un push dépose un pack immuable, une branche tient une liste de versions
À chaque push, Pando valide le pack entrant en une seule passe et l'envoie tel quel dans un stockage d'objets. Il écrit ensuite dans un magasin de métadonnées une version de référence qui retient la nouvelle tête de branche, le pack qui l'a fournie et les versions dont ce pack dépend, puis déplace le pointeur de la branche dans la même transaction. L'écriture demande un nombre constant de lectures et d'écritures, quelle que soit la taille du push, et le client peut relire immédiatement ce qu'il vient d'envoyer.
La lecture suit le chemin inverse. Le client annonce ce qu'il a et ce qu'il veut, le serveur traduit ces commits en versions de référence, chacune pointant vers un pack déjà reçu, et retient les packs qui couvrent le manque. Le coût en métadonnées est logarithmique en nombre de versions à parcourir. Les packs partent par un service de livraison, Express, mis en cache par région, avec un routage par hachage cohérent et un taux de succès de cache supérieur à 99 %.
Un seul embranchement annoncé : 20 Kio en médiane par push
Un serveur Git classique montre toutes ses branches au client qui pousse, et le client s'en sert pour exclure du paquet ce que le serveur possède déjà. Avec des millions de branches, la seule annonce des références dépasse 100 Mio. Pando n'annonce donc que l'embranchement principal. Le pack produit est plus gros et plus facile à réutiliser : n'importe quel lecteur qui a déjà cet embranchement récupère la branche avec ce seul pack.
Le prix se paie côté client. Une branche empilée sur une autre doit renvoyer tout ce qui n'est pas dans l'embranchement annoncé. Dans le monorepo, le packfile médian reste sous 20 Kio et le 99e centile sous 3 Mio, ce qu'OpenAI juge acceptable pour la réutilisation obtenue.
Mille clients simulés, 57 To servis en une heure
La validation croise un simulateur déterministe et le banc de production. Dans la simulation, mille clients choisissent chacun une branche distincte et poussent des commits uniques en boucle, sur du matériel allant de la machine virtuelle d'entrée de gamme au stockage haut de gamme. Le modèle à quorum s'écroule en écriture quand les disques saturent, le modèle à journal s'écroule en lecture quand les serveurs courent après le journal.
En production, Pando sert plus de 57 To de packs Git en une heure, dont plus de 99 % des octets viennent du cache disque local, et près d'un pétaoctet par jour avec quelques cœurs de processeur. Le mécanisme tient à un détail de rangement : les packs successifs d'une branche sont regroupés en couvertures compactées, qui servent aussi d'index de saut et permettent de choisir les packs à envoyer en temps logarithmique.
Les agents ont écrit la spécification formelle avant les tests
Le service est écrit en Rust, sans dépendance héritée. L'équipe ajoute une suite de conformité pour que les agents vérifient leurs changements contre le comportement Git standard, et des bancs de simulation déterministe pour traquer les courses critiques dans la négociation et la sélection des packs. Des agents pilotés par GPT-6 Astra ont écrit en Lean et en TLA+ une théorie de Pando, employée à trouver et corriger des bogues puis à prouver des propriétés du système, sur des sessions continues de plusieurs centaines d'heures. D'autres agents attaquent Git et Pando en continu.
Le déploiement s'est fait en proxys de lecture et d'écriture devant l'ancien système, gardés synchronisés, puis par migration des charges une à une. Pando déduplique et regroupe les requêtes avant de les transmettre, ce qui a aussi soulagé le backend précédent pendant la bascule. Côté Git, les correctifs remontent : téléchargement et indexation de packs indépendants en parallèle, traçage des transferts par URI de pack, et la notion de commits explicitement détenus qui permet à un client de pousser contre l'embranchement seul tout en vérifiant qu'une branche n'a pas bougé avec force-with-lease.
La suite annoncée reste ouverte : d'autres usages internes, dont des dépôts partagés par un grand nombre d'agents qui collaborent, et une réflexion sur la mise à disposition de la technologie. Le chiffre à retenir tient en une ligne, et il vient de l'exploitant lui-même : la latence médiane du push baisse de près de 80 %, sur un dépôt qui pèse désormais un pétaoctet de trafic par jour.
Source primaire OpenAI, « Scaling Git at OpenAI », 2 novembre 2026