Как OpenAI масштабировала Git: знакомьтесь, Pando

Когда сотни AI-агентов одновременно пишут код и делают коммиты в один и тот же репозиторий, стандартный Git начинает трещать по швам. OpenAI столкнулась с этой проблемой вплотную — и создала собственное решение, не потревожив при этом ни одного инженера.

Команда построила Pando — новый бэкенд (серверную часть) для Git-репозиториев, не прерывая работу инженеров и не меняя привычных инструментов. Сегодня Pando обеспечивает всю разработку в монорепозитории (monorepo — едином большом репозитории) OpenAI.

ℹ Что такое монорепозиторий?
Монорепозиторий — это подход, при котором весь код компании хранится в одном Git-репозитории. Его используют Google, Meta, Microsoft и теперь OpenAI. Преимущества: единые зависимости, сквозные изменения, общая история. Недостаток: при большом числе разработчиков и агентов Git начинает работать крайне медленно.

Почему стандартный Git перестал справляться

OpenAI работает в едином гигантском монорепозитории и столкнулась с серьёзными проблемами производительности Git при своих масштабах и темпах разработки.

Главный катализатор — взрывной рост Codex, AI-агента для написания кода. К марту 2026 года у Codex насчитывалось более двух миллионов еженедельных активных пользователей. Каждая задача выполняется в изолированной песочнице с собственным git worktree (рабочим деревом), поэтому параллельные агенты не конфликтуют между собой.

Но именно это параллелизм и создаёт инфраструктурную проблему: сотни агентов одновременно делают push (отправку изменений) в репозиторий. Классический Git-сервер не рассчитан на такую нагрузку — он обрабатывает записи последовательно и генерирует packfile (архивный файл с объектами Git) для каждого клиента индивидуально.

Обычный Git-сервер похож на кассира в супермаркете, который обслуживает покупателей строго по одному. Pando — это уже целый параллельный конвейер.

Архитектура Pando: как это работает

Pando проектировался с двумя амбициозными целями: горизонтально масштабируемые записи, оптимизированные под одновременные push-операции в множество веток.

При этом сохранялась полная совместимость с протоколом и клиентом Git, что позволило инженерам и агентам бесшовно перейти на Pando без изменения привычных рабочих процессов.

Хранение данных: immutable blobs и ref versions

Когда клиент делает push в ветку, Pando сохраняет входящий packfile как неизменяемый блоб (blob) в хранилище объектов. Каждый раз, когда ветка перемещается, Pando записывает ref version (версию ссылки) — содержащую новую верхушку, пакет, её предоставивший, и все предыдущие версии, от которых этот пакет зависит, — в хранилище метаданных.

Packfile записывается в объектное хранилище, а ref version фиксируется в Turtle — внутреннем хранилище метаданных OpenAI.


graph LR
    A[Клиент делает push] --> B[Pando сервер]
    B --> C[Валидация packfile]
    C --> D[Blob Store\nхранилище объектов]
    C --> E[Turtle\nметаданные ref version]
    D --> F[Express\nкэш blob store]
    E --> G[Кэш метаданных]
    F --> H[Клиент делает fetch]
    G --> H

Умное переиспользование packfile

Одно из ключевых архитектурных решений Pando — отказ от генерации уникального packfile для каждого клиента при каждом запросе.

Pando повторно использует packfile (формат Git для сжатия нескольких объектов вместе) между разными fetch-запросами (запросами на получение изменений) вместо того, чтобы генерировать отдельный packfile для каждого клиента.

Поскольку серверы Pando в основном занимаются переговорами (negotiation) и выбором packfile, они могут работать на стандартном «железе» без специализированных вычислительных ресурсов.

Иерархия packfile: от L0 до L4

Каждый push создаёт так называемый «L0» packfile — наименьшую единицу данных, которую Pando может передать.

В быстро развивающемся репозитории вроде монорепозитория OpenAI нецелесообразно отправлять отдельный packfile URI для каждого push, произошедшего с момента последнего fetch. Поэтому Pando агрегирует их в «covers» — укрупнённые пакеты более высоких уровней.

Сегодня монорепозиторий OpenAI использует covers вплоть до уровня L4.

В монорепозитории медианный packfile, сформированный таким образом, занимал менее 20 КБ, а 99-й перцентиль — менее 3 МБ.

Производительность: цифры впечатляют

💡 Ключевая метрика
Pando передаёт почти петабайт Git-данных в день — при минимальном числе CPU-ядер. Это результат архитектурных решений, а не брутфорса железом.

Pando способен доставлять петабайт Git-данных в день, используя лишь горстку CPU-ядер.

Сегодня система доставляет почти петабайт Git-данных ежедневно.

Горизонтальное масштабирование

Важно, что серверы Pando могут независимо принимать push-операции в несвязанные ветки. Масштабировать пропускную способность записи можно, добавляя серверы Pando, единицы хранилища метаданных или blob store.

Как blob store, так и metadata store масштабируются горизонтально.

Сравнение подходов к масштабированию Git

ПараметрКлассический Git-серверVirtual Filesystem (VFS)Pando
Горизонтальное масштабирование записей❌⚠️ Частично✅
Совместимость с Git-клиентом✅⚠️ Требует патч✅
Повторное использование packfile❌❌✅
Commodity-железо (обычные серверы)✅❌ Дорогое железо✅
Параллельный push в разные ветки❌⚠️✅
Производительность при петабайтных нагрузках❌❌✅

Развёртывание без остановки работы

Один из самых интересных аспектов проекта — как OpenAI перешла на новый бэкенд без единого простоя.

Для оптимизации производительности при работе с Pando OpenAI начала распространять собственную сборку Git на машины разработчиков и внутри десктопного приложения ChatGPT.

Для миграции клиентов на Pando использовалась внутренняя обёртка над Git CLI, позволявшая переводить клиентов на новую систему поэтапно.

По мере переноса рабочих нагрузок на Pando их push-операции заполняли кэш системы и улучшали надёжность предыдущего бэкенда.

📝 Поэтапная миграция
OpenAI мигрировала на Pando постепенно: сначала небольшие команды, потом CI/CD-пайплайны, затем агенты Codex. Каждый новый рабочий поток не только переходил на новую систему, но и «прогревал» её кэши, делая следующий шаг ещё надёжнее.

Red-teaming системы с помощью AI-агентов

Команда запускает агентов круглосуточно для red-team тестирования (проверки на устойчивость к атакам) Git и Pando с использованием моделей Daybreak. Это показательный пример того, как OpenAI использует собственные AI-инструменты для укрепления инфраструктуры.

Вклад в open-source сообщество Git

OpenAI не стала держать все находки при себе.

Построение Pando поверх протокола и клиента Git помогло выявить баги и возможности для улучшения производительности самого Git.

В собственной сборке Git от OpenAI клиент может загружать и индексировать независимые пакеты параллельно.

Улучшения производительности, корректности и тестирования передаются из форка openai/git в основную ветку проекта.

Pando опирается на двадцатилетний опыт пользователей и операторов Git-репозиториев. OpenAI планирует продолжать развивать Pando, одновременно взаимодействуя с open-source сообществом Git для передачи улучшений, полезных более широкой аудитории.

⚠ Урок для индустрии
Pando демонстрирует важную закономерность: AI-агенты — это не просто новые пользователи инструментов, они меняют профиль нагрузки до неузнаваемости. Инфраструктура, спроектированная для людей, может не справиться с агентами — даже если формально поддерживает те же протоколы.

Итог: что означает Pando для индустрии

История Pando — это не просто инженерный кейс OpenAI. Это сигнал для всей индустрии разработки ПО.

Codex приносит возможности топового инженера каждому, кто хочет создавать ПО. Еженедельная аудитория Codex более чем утроилась с начала года и достигла 1,6 миллиона человек. Всё больше людей создают, автоматизируют и выпускают программное обеспечение, которое прежде требовало целой инженерной команды.

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

Архитектурные принципы, которые OpenAI воплотила в Pando, — горизонтальное масштабирование, immutable storage, иерархическое кэширование packfile — скорее всего, станут шаблоном для следующего поколения систем контроля версий в эпоху AI-first разработки.