OpenAI создала Pando: бэкенд Git, снизивший задержку пуша почти в 5 раз

OpenAI рассказала, как масштабировала систему хранения исходного кода под нагрузку от Codex. По словам компании, за последний год размер монорепозитория и требования к нему выросли стремительно. Codex позволяет инженерам вести гораздо больше работы параллельно: больше веток, пушей, слияний, а также fetch и клонирований из сред разработки, исследовательских задач и CI. Нагрузки множатся: у одного инженера теперь несколько изменений одновременно готовы к CI, а каждый пуш может запускать несколько задач, которые тянут один и тот же коммит.

С конца прошлого года системы вокруг монорепозитория перестали справляться: медленные fetch и пуши, неудавшиеся слияния, надёжность временами падала ниже 90%. В OpenAI задались вопросом, упёрлись ли они в предел самого Git или в способ, которым обслуживается монорепозиторий, и решили сохранить Git как основу. Это значит, что улучшения клиента могут пригодиться и за пределами компании; OpenAI хочет передавать улучшения из своей копии Git в основной проект (upstream).

Результат, Pando, новый бэкенд для Git-репозиториев. Его построили, не прерывая работу инженеров и не меняя то, как команда пользуется Git. Сейчас Pando обслуживает всю разработку в монорепозитории OpenAI. Заявлены две цели: горизонтально масштабируемая запись, оптимизированная под одновременные пуши в множество веток, и максимальная пропускная способность чтения, чтобы клиенты могли загружать данные на всю доступную сетевую скорость. При этом сохранена совместимость с протоколом и клиентом Git, так что и инженеры, и агенты подключаются к Pando в привычных рабочих процессах. В продакшене Pando снизил медианную задержку пуша почти в 5 раз и теперь отдаёт почти петабайт данных Git в сутки.

Как это устроено. Запись масштабируется за счёт того, что Pando координирует обновления каждой ветки независимо: пуши в несвязанные ветки идут параллельно. Цена, читатель, смотрящий на несколько веток сразу, может видеть их в разные моменты времени. Чтение масштабируется за счёт повторного использования пакфайлов (формата Git для сжатого хранения набора объектов) между fetch вместо создания отдельного пакфайла для каждого клиента. Клиент может скачать часть объектов, которые у него уже есть, зато сервер отдаёт одни и те же байты многим клиентам почти без вычислений.

Внутри: входящий пакфайл хранится как неизменяемый блоб в хранилище блобов; при каждом сдвиге ветки в хранилище метаданных записывается версия ссылки (ref) с новой вершиной, пакфайлом-источником и предыдущими версиями ссылок, от которых пакфайл зависит. Оба хранилища горизонтально масштабируемы. Чтобы выдать коммит или ссылку, Pando воспроизводит клиенту набор версий ссылок (пакфайлов). Получается более слабая согласованность по репозиторию в целом (причинная, causal consistency) при сериализуемости обновлений отдельной ссылки: клиенты конфликтуют, только когда одновременно пушат в одну и ту же ссылку. Зато Pando не даёт снимок состояния всех ссылок на один момент времени во время операций Git и не гарантирует порядок обновлений ссылок внутри clone или fetch.

Конкурирующие подходы OpenAI оценивала на моделях. Первый, трёхфазная фиксация (3PC) между репликами репозитория: каждая реплика хранит полную копию, для публикации пуша большинство реплик должно принять обновление ссылки, обновления идут по одному, а каждый пуш требует нескольких обменов между репликами; скорость дисков и задержки связи попадают на путь пуша. Второй, общий журнал упреждающей записи (WAL) в хранилище блобов: пакфайлы грузятся параллельно, но даже пуши в несвязанные ветки обновляют один и тот же манифест, и время обмена для успешной операции compare-and-swap ограничивает частоту публикации. Пакетная обработка ускоряет это за счёт очередей и роста задержки, а простое увеличение ёмкости хранилища блобов узкое место не снимает.

Ключевые факты

Pando, новый бэкенд для Git-репозиториев, который OpenAI построила для своего монорепозитория; сейчас он обслуживает всю разработку в нём.
В продакшене Pando снизил медианную задержку пуша почти в 5 раз и отдаёт почти петабайт данных Git в сутки; до этого надёжность систем монорепозитория временами падала ниже 90%.
Причина, нагрузка от Codex: больше веток, пушей, слияний, fetch и клонов, а несколько изменений от одного инженера одновременно идут в CI.
Запись масштабируется независимой координацией каждой ветки, чтение, повторным использованием пакфайлов; совместимость с протоколом и клиентом Git сохранена.
Цена решения, причинная согласованность вместо единого снимка всех ссылок и пакфайлы, которые могут содержать объекты, уже имеющиеся у клиента.

Почему это важно

Агенты на базе ИИ превращают разработку в поток параллельной работы: OpenAI прямо говорит, что Codex резко увеличил число веток, пушей, слияний, fetch и клонов. Нагрузка растёт мультипликативно: несколько изменений одного инженера в CI, и каждый пуш запускает несколько задач на один и тот же коммит. Пример показывает, что узким местом стал не сам формат Git, а способ обслуживания репозитория на сервере, и что решение возможно без отказа от Git-протокола и клиента.

Кому это важно

Командам платформенной инженерии и инфраструктуры разработки, у которых большие монорепозитории и растущая нагрузка от CI и ИИ-агентов; тем, кто проектирует серверы и хостинг Git; разработчикам и сопровождающим самого Git, поскольку OpenAI заявляет о намерении передавать улучшения своей копии Git в основной проект.

Как это применить

Напрямую воспользоваться Pando нельзя: в доступном тексте не сказано, что он открыт или доступен другим. Полезны сами идеи. Разделяйте нагрузку на запись (много авторов в разные ветки) и на чтение (много читателей одной истории). Проверьте, нужна ли вам согласованность всего репозитория на один момент времени или хватит порядка внутри ветки. Рассмотрите повторное использование пакфайлов между клиентами вместо создания уникального ответа каждому. Разберите узкие места классических схем: у 3PC это несколько обменов на каждый пуш и зависимость от дисков и связи реплик, у общего WAL, единый манифест, который обновляют даже пуши в несвязанные ветки.

Можно ли доверять

Это собственная инженерная публикация OpenAI на openai.com, поэтому цифры (задержка пуша почти в 5 раз ниже, почти петабайт в сутки, надёжность временами ниже 90%), заявления самой компании без независимой проверки. База сравнения для «почти в 5 раз» не названа, абсолютных значений задержек нет, а «ниже 90%» дано как временный показатель без описания способа измерения. Оценки 3PC и WAL относятся к смоделированным вариантам, данных их испытаний в продакшене нет. Доступный текст обрывается на объяснении модели согласованности, поэтому остальные разделы статьи здесь не пересказаны.

Риски и подводные камни

Pando сознательно отказывается от того, что многие системы Git считают обязательным. Читатель, смотрящий на несколько веток, может увидеть их в разные моменты времени; нет снимка всех ссылок на один момент и нет порядка обновлений ссылок внутри clone или fetch. Клиент может скачать объекты, которые у него уже есть. Если ваши инструменты рассчитывают на согласованный вид всего репозитория, такая модель может оказаться неподходящей. Кроме того, в тексте не названы технологии хранилищ блобов и метаданных, не указаны размер монорепозитория и сроки разработки, так что оценить воспроизводимость решения по этой публикации трудно.