OpenAI написала Pando: Git-бэкенд, который ускорил push в 5 раз под нагрузкой Codex

Представьте, что каждый инженер в компании вдруг получил десяток помощников, и каждый из них пушит код, открывает ветки и гоняет CI. Именно это случилось в OpenAI, когда Codex начал массово писать код. Монорепозиторий стал упираться не в людей, а в сам сервер Git.

Что сломалось

С конца прошлого года системы вокруг монорепо перестали справляться: медленные fetch и push, упавшие мерджи, надёжность временами ниже 90%. Нагрузка растёт мультипликативно: один инженер держит несколько изменений в CI, а каждый push запускает несколько джоб, которые тянут один и тот же коммит.

Инженеры не стали отказываться от Git. Они решили оставить протокол и клиент, чтобы люди и агенты ничего не переучивали, а улучшения можно было отдать в апстрим. Заменили только бэкенд, и сделали это без остановки работы. Так появился Pando.

Почему не 3PC и не WAL

Классические способы масштабировать Git упираются в одну точку координации.

Первый вариант: полные реплики и трёхфазный коммит. Каждый push требует нескольких раундов общения между координатором и репликами, а диски и сеть реплик попадают на критический путь записи. Ref'ы обновляются по одному.

Второй вариант: общий манифест в blob-хранилище с журналом упреждающей записи. Паки грузятся параллельно, но каждое обновление всё равно меняет один манифест через compare-and-swap. Пуши в несвязанные ветки толкаются друг с другом. Батчинг помогает, но добавляет задержку.

Как устроен Pando

Авторы отказались от двух привычных допущений.

Первое: согласованность всего репозитория. Pando хранит входящий packfile как неизменяемый blob, а метаданные (новая вершина ветки, пак, зависимости от прошлых версий ref) кладёт в горизонтально масштабируемое хранилище. Каждая ветка обновляется независимо с сериализуемостью внутри одного ref. Это причинная согласованность: читатель видит историю того, кто записал ref, но не единый срез по всему репо.

На практике это значит, что при клонировании в момент обновления веток foo и bar один клиент может увидеть foo версии 1 и bar версии 2, а другой наоборот. Авторы утверждают, что людям и агентам важен порядок обновлений одной ветки, а не глобальный.

Второе: уникальный pack для каждого клиента. Обычно сервер собирает под каждого свой пакет, чтобы не слать лишнего, а это CPU и диск. Pando переиспользует packfile'ы: клиент может скачать часть объектов, которые у него уже есть, зато сервер отдаёт одни и те же байты многим клиентам почти без вычислений. Цель по чтению: забить всю доступную клиенту сетевую полосу.

Результаты и ограничения

В проде медианная задержка push снизилась почти в 5 раз, а Pando отдаёт почти петабайт данных в сутки. Цена вопроса понятна: нет глобального снимка всех ref'ов, и лишний трафик на клиентов, у которых часть объектов уже есть.

В статье также есть симуляция на 1000 клиентов, сравнивающая три модели, но свои реализации сравнений авторы приводят на моделях, а не на независимых бенчмарках. Код Pando не опубликован, вместо этого OpenAI обещает развивать клиент Git в апстриме.

Что с этим делать

Если ваши агенты создают много веток и параллельных пушей, узкое место скоро окажется в Git-хостинге, а не в модели. Проверьте, какие ваши процессы действительно требуют глобально согласованного снимка репо, а каким хватит порядка внутри одной ветки. Ещё стоит замерить push-to-fetch latency: именно эта метрика показывает, сколько ждёт агент, пока другой агент или CI увидит его коммит. И следите за улучшениями Git в апстриме: они, вероятно, дойдут до всех.