OpenAI a conçu Pando : un backend Git qui accélère le push par 5 sous la charge de Codex

Imaginez que chaque ingénieur d'une entreprise reçoive soudain une dizaine d'assistants, chacun poussant du code, ouvrant des branches et lançant la CI. C'est exactement ce qui s'est produit chez OpenAI lorsque Codex a commencé à écrire du code à grande échelle. Le goulot d'étranglement du monorepo n'était plus les humains, mais le serveur Git lui-même.

Ce qui a cédé

Depuis la fin de l'année dernière, les systèmes entourant le monorepo n'arrivaient plus à suivre : fetch et push lents, merges en échec, fiabilité parfois inférieure à 90 %. La charge croît de façon multiplicative : un ingénieur garde plusieurs changements en CI, et chaque push déclenche plusieurs jobs qui récupèrent le même commit.

Les ingénieurs n'ont pas voulu abandonner Git. Ils ont décidé de conserver le protocole et le client, afin que humains et agents n'aient rien à réapprendre et que les améliorations puissent être reversées en amont. Seul le backend a été remplacé, sans interruption de service. C'est ainsi qu'est né Pando.

Pourquoi ni 3PC ni WAL

Les approches classiques pour faire passer Git à l'échelle butent sur un unique point de coordination.

Première option : des réplicas complets et un commit en trois phases. Chaque push exige plusieurs tours d'échanges entre le coordinateur et les réplicas, et les disques et le réseau des réplicas se retrouvent sur le chemin critique de l'écriture. Les refs sont mis à jour un par un.

Deuxième option : un manifeste partagé dans un stockage blob avec un journal d'écriture anticipée. Les packs sont chargés en parallèle, mais chaque mise à jour modifie tout de même un seul manifeste via compare-and-swap. Les pushs vers des branches sans rapport entre elles se bousculent. Le batching aide, mais ajoute de la latence.

Comment fonctionne Pando

Les auteurs ont renoncé à deux hypothèses habituelles.

Première : la cohérence de l'ensemble du dépôt. Pando stocke chaque packfile entrant comme un blob immuable, et place les métadonnées (nouveau sommet de la branche, pack, dépendances vis-à-vis des versions précédentes du ref) dans un stockage à l'échelle horizontale. Chaque branche est mise à jour indépendamment, avec sérialisabilité au sein d'un même ref. Il s'agit d'une cohérence causale : le lecteur voit l'historique de celui qui a écrit le ref, mais pas un instantané unique sur l'ensemble du dépôt.

En pratique, si l'on clone pendant la mise à jour des branches foo et bar, un client peut voir foo en version 1 et bar en version 2, et un autre l'inverse. Les auteurs affirment que, pour les humains comme pour les agents, c'est l'ordre des mises à jour d'une même branche qui compte, pas un ordre global.

Seconde : un pack unique pour chaque client. D'ordinaire, le serveur assemble pour chacun son propre pack afin de n'envoyer rien de superflu, ce qui coûte du CPU et du disque. Pando réutilise les packfiles : le client peut télécharger une partie d'objets qu'il possède déjà, mais le serveur envoie les mêmes octets à de nombreux clients presque sans calcul. Objectif en lecture : saturer toute la bande passante réseau disponible côté client.

Résultats et limites

En production, la latence médiane du push a été réduite de près de 5 fois, et Pando sert près d'un pétaoctet de données par jour. Le prix à payer est clair : pas d'instantané global de tous les refs, et du trafic superflu pour les clients qui possèdent déjà une partie des objets.

L'article comprend aussi une simulation à 1 000 clients comparant trois modèles, mais les auteurs comparent leurs implémentations sur des modèles, et non sur des benchmarks indépendants. Le code de Pando n'est pas publié ; OpenAI promet à la place de faire évoluer le client Git en amont.

Que faire de tout cela

Si vos agents créent beaucoup de branches et de pushs parallèles, le goulot d'étranglement se trouvera bientôt dans l'hébergement Git, et non dans le modèle. Vérifiez quels processus exigent réellement un instantané du dépôt globalement cohérent, et lesquels se contentent d'un ordre au sein d'une branche. Il faut aussi mesurer la push-to-fetch latency : c'est cette métrique qui indique combien de temps un agent attend avant qu'un autre agent ou la CI voie son commit. Et suivez les améliorations de Git en amont : elles finiront probablement par profiter à tous.