Reason Machines открыла код Aspen — Git-сервера, выдерживающего сотни пушей от ИИ-агентов

Reason Machines открыла исходный код Aspen — Git-сервера, спроектированного для работы с ИИ-агентами. Проект опубликован под лицензией Apache 2.0 и представляет собой независимую реализацию архитектуры Pando, которую OpenAI разработала для внутренних нужд. Aspen написан на Rust, собирается в один бинарник и может работать на ноутбуке, через Docker Compose или в облаке с Helm и Terraform.

Классические Git-серверы плохо справляются с нагрузкой, которую создают агенты. Агент может пушить изменения каждые несколько минут, а CI-системы забирают их после каждого пуша. В традиционной архитектуре все пуши в один репозиторий ставятся в очередь, а для каждого fetch сервер заново перепаковывает данные.

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

Во-первых, каждая ветка хранится как цепочка версий в одной строке PostgreSQL (или SQLite), а пуши обрабатываются через compare-and-swap. Благодаря этому пуши в разные ветки не блокируют друг друга. Если два пуша конкурируют за одну ветку, побеждает один, а второй получает стандартную ошибку Git «сначала сделайте fetch».

Плата за это — ветки могут читаться в слегка разные моменты времени. Во-вторых, Aspen никогда не распаковывает полученные данные. Он проверяет pack-файл, дополняет недостающие базовые объекты и сохраняет его как есть.

При fetch сервер стримит клиенту сохранённые pack-файлы, которые у того отсутствуют, без перепаковки. Для раздачи можно использовать подписанные URL, в том числе через CDN. Чтобы переговоры при пуше оставались компактными даже с миллионом веток, клиенту показывается только основная ветка (trunk).

Фоновая компакция объединяет pack-файлы группами по 16, подобно log-structured merge tree. Клиент, сильно отставший от актуального состояния, получает не тысячи, а несколько десятков pack-файлов. Для CI-джобов с глубиной 1 tip pack собирается один раз и отдаётся всем.

Производительность Aspen разработчики оценивали на одном 8-ядерном сервере с S3 Standard и 4-ядерным PostgreSQL. В качестве тестового репозитория использовали копию git.git — около 4 500 файлов и 75 000 коммитов. Сервер выдержал 567 пушей в секунду в течение пяти минут без ошибок.

Медианная задержка пуша составила 208 мс, 99-й перцентиль — 314 мс. Другой клиент видел каждый пуш в среднем через 30 мс после подтверждения. При шторме fetch глубиной 1 объём переданных данных был в 1,029 раза больше, чем у стандартного git upload-pack.

Для сравнения: Cursor Origin, коммерческая платформа Cursor, по данным самой компании, достигает 120 пушей в секунду на S3 Standard и более 300 на S3 Express One Zone, но это кластер на монорепозитории Cursor, и условия тестирования различаются. OpenAI не раскрывает показателей Pando, а GitHub Spokes — внутренней системы GitHub — также не публикует цифр. В README Aspen подчёркивается, что приведённые цифры носят ориентировочный характер и не являются гарантированными характеристиками.

Развернуть Aspen можно несколькими способами. Сборка из исходников на Rust, команда aspen dev запускает всё с SQLite и локальной директорией. Для команд доступен Docker Compose с PostgreSQL и MinIO, а также Helm-чарт.

Terraform-конфигурации покрывают AWS, Google Cloud, Azure и Hetzner. Режим зеркала позволяет подключить Aspen перед GitHub или GitLab, чтобы опробовать сервер без миграции. В качестве живой демонстрации создан холст 64×64 пикселя, где каждый клик мыши порождает один коммит.

По утверждению Reason Machines, один Reason-агент построил Aspen от первого коммита до публичного репозитория за четыре дня, что потребовало 151 слитого PR. Проект находится на стадии pre-alpha: у него нет релизов, веб-интерфейса, и он не проходит 24-часовой тест на сохранность данных. Однако уже сейчас его можно использовать для экспериментов и оценки подхода.

Исходный код доступен на GitHub, подробности — в сопроводительной публикации.