OpenAI представляет Pando: Git-бэкенд, сокращающий медианную задержку push примерно на 80%
OpenAI представила Pando — новый серверный бэкенд Git, который теперь обслуживает всю разработку в её монорепозитории. Серверный бэкенд OpenAI Pando для Git сохраняет стандартные клиент Git и протокол. Инженеры и агенты Codex по-прежнему выполняют команды git push и git fetch, как и раньше. Изменился только сервер. По данным команды OpenAI, медианная задержка push сократилась почти на 80%. Теперь Pando передаёт почти петабайт данных Git в день.
Кратко
- Масштаб: Почти 1 ПБ данных Git в день; пиковое значение — более 57 ТБ за 1 час.
- Работает на: Обычном оборудовании; стандартные облачные виртуальные машины полностью загружают каналы 10 Гбит/с при клонировании и fetch.
- Производительность: Тысячи параллельных отправителей без снижения производительности, согласно собственным тестам OpenAI.
- Лучший результат: Медианная задержка push снизилась почти на 80% (примерно в 5 раз).
- Худший результат: Не имеет открытого исходного кода; повторные отправки веток повторно передают историю вне trunk (пакет p99 — менее 3 МиБ).
Что такое OpenAI Pando?
Pando — совместимый с Git серверный бэкенд от OpenAI, предназначенный для масштабирования параллельных операций push и fetch в монорепозитории. Он написан на Rust и достиг промышленной эксплуатации за 10 недель. Один инженер разработал ядро, а команды агентов Codex реализовали его. Он обслуживает производственный трафик с апреля 2026 года.
Зачем OpenAI понадобился новый серверный бэкенд Git?
Codex увеличил объём параллельной работы. На графике коммитов OpenAI видно, что число коммитов, добавленных в master, в третьем квартале 2026 года выросло на 1 378% по сравнению с первым кварталом 2024 года. Оценка на четвёртый квартал 2026 года составляет +2 442%. Теперь каждый push запускает множество операций CI fetch. К концу 2025 года fetch и push замедлились, слияния завершались с ошибками, а надёжность временами падала ниже 90%. OpenAI пришла к выводу, что узким местом был способ обслуживания Git, а не сам Git.
Как работает Pando?
Pando отказывается от 2 предположений, которые большинство серверов Git считает обязательными:
1. Согласованность на уровне всего репозитория: Традиционные серверы упорядочивают обновления всех ref во всём репозитории, поэтому несвязанные push ожидают своей очереди. Вместо этого Pando использует причинную согласованность. Каждая ветка сериализуется отдельно, а конфликты возникают у клиентов только при отправке в один и тот же ref. Компромисс заключается в том, что читатель, просматривающий несколько веток, может видеть их на разных временных срезах.
2. Уникальный packfile для каждого клиента: Стандартные серверы создают новый pack для каждого fetch. Pando хранит каждый отправленный pack как неизменяемый blob. «Версия ref» помещается в масштабируемое хранилище метаданных. Для push нужны O(1) операций чтения и записи метаданных. Для fetch нужны O(log Δ) операций чтения, где Δ — разрыв между версиями ref, который необходимо закрыть.
Как push остаются небольшими и пригодными для повторного использования?
При наличии миллионов веток полное объявление ref может превышать 100 МиБ. Pando объявляет только ветку trunk в качестве базы для новых отправок веток функций. После этого любой читатель с историей trunk может получить эту ветку из 1 сохранённого pack. В монорепозитории OpenAI медианный размер pack составлял менее 20 КиБ.
Как fetch обслуживаются на скорости канала?
Pando возвращает ссылки на скачивание через packfile-uri — существующую функцию протокола Git. Он отправляет пустой встроенный pack. Сервис доставки под названием Express кэширует pack регионально, используя согласованное хеширование, при доле попаданий выше 99%.
Что заменяет сборку мусора?
Каждый push создаёт pack «L0». Фоновые рабочие процессы объединяют pack в геометрически увеличивающиеся покрытия, подобно компакции LSM-дерева. В настоящее время монорепозиторий использует покрытия вплоть до L4. Покрытия действуют как список пропусков, поэтому выбор pack выполняется за логарифмическое время.
Каковы производственные показатели?
Все приведённые ниже показатели предоставлены самой OpenAI.
- Медианная задержка push сократилась почти на 80%.
- Почти 1 ПБ данных Git в день при использовании всего нескольких ядер CPU.
- Более 57 ТБ pack обслужено за один час, причём более 99% — из локального дискового кэша.
- Клонирование и fetch полностью загружают каналы 10 Гбит/с на стандартных облачных виртуальных машинах.
OpenAI также провела симуляцию с 1 000 записывающих участников для архитектур с трёхфазной фиксацией и журналом предварительной записи. Компания называет эти модели учебными, а не бенчмарками.
Как Pando сравнивается с другими подходами?
| OpenAI Pando | GitHub Spokes | Anthropic Scion | |
|---|---|---|---|
| Совместимость с клиентом Git | Да | Да | Нет, собственный клиент scn |
| Координация записи | Причинная согласованность для каждой ветки | Трёхфазная фиксация с кворумом | Коммиты на стороне сервера; refs через compare-and-swap |
| Реплики по умолчанию | Не раскрываются (хранилища blob и метаданных) | 5 полных копий | Нет полностью материализованной копии репозитория |
| Путь чтения | Повторно используемые pack через packfile-uri, кэш Express | Ближайшая синхронизированная реплика | Многоуровневые кэши деревьев/blob |
| Доля попаданий в кэш | Более 99% | Не раскрывается | Более 99% на каждом уровне |
| Главный результат | Медианная задержка push снизилась примерно на 80% | Обслуживает около 1 миллиарда репозиториев | В 200 раз меньший объём используемых CPU и памяти |
| Затраты на разработку | 10 недель, Rust | Не раскрываются | 7 человек, 5 месяцев |
| Доступно другим | Нет | Да, используется GitHub | Нет |
Как создавался и разворачивался Pando?
OpenAI написала набор тестов на соответствие Git для агентов и добавила детерминированное тестирование с помощью симуляций. Агенты, использующие GPT-6 Astra, писали спецификации на Lean и TLA+, чтобы находить ошибки.
Сначала Pando работал как прокси для чтения и записи, поэтому трафик был перенесён без простоя. OpenAI поставляет собственную сборку Git на компьютеры разработчиков и в настольное приложение ChatGPT.
Что возвращается в основной репозиторий Git?
OpenAI исправила обработку клиентом параллельных, прерванных и возобновлённых скачиваний pack, а также добавила трассировку packfile-uri. В её сборке добавлены параллельная индексация pack и «явные haves». Некоторые исправления уже переданы в основной репозиторий. Остальные находятся в публичном трекере исправлений.
Каковы ограничения?
- Pando не имеет открытого исходного кода; команда OpenAI заявляет, что изучает способы поделиться этой технологией.
- Чтение между ветками не имеет единого снимка на определённый момент времени.
- Повторные или последовательные отправки веток повторно передают всё, что находится вне trunk. Pack p99 имел размер менее 3 МиБ.
- Все показатели производительности предоставлены самой компанией, независимых бенчмарков пока нет.
Ключевые выводы
- Pando сохраняет Git, но перестраивает сервер для параллельного трафика от агентов.
- Причинная согласованность для каждой ветки устраняет конкуренцию за запись на уровне всего репозитория.
- Сохранённые pack, пригодные для повторного использования, заменяют создание pack для каждого клиента.
- Медианная задержка push снизилась почти на 80%; ежедневный трафик приближается к 1 ПБ.
- Исправления клиента передаются в основной репозиторий; бэкенд пока остаётся внутренним.
Ознакомьтесь с полной инженерной публикацией OpenAI, репозиторием Git OpenAI и трекером исправлений. Также подписывайтесь на нас в Twitter и не забудьте присоединиться к нашему сабреддиту с более чем 150 тысячами участников и подписаться на нашу рассылку. Стоп! Вы есть в Telegram? теперь вы также можете присоединиться к нам в Telegram.
Хотите стать нашим партнёром для продвижения вашего репозитория GitHub, страницы Hugging Face, выпуска продукта, вебинара и т. д.? Свяжитесь с нами
Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.