The AI / news

Anthropic, Cursor, GitHub и OpenAI : четыре подхода к масштабированию Git для агентного использования

Anthropic, Cursor, GitHub и OpenAI : четыре подхода к масштабированию Git для агентного использования
3 мин чтения
, ,

Anthropic, Cursor, GitHub и OpenAI модернизируют свои системы контроля версий для работы на агентном уровне, где программные агенты параллельно работают с одним кодом. Каждый по-своему отходит от чисто децентрализованной модели Git, в которой каждый узел хранит полную автономную копию истории.

Anthropic заменяет Git на Scion

В своем внутреннем монорепозитории, едином хранилище кода, Anthropic перешла с примерно 2500 слияний (merges) в день в мае 2026 года на более чем 30 000 в сентябре. Основная история приближается к 100 ГБ, и ежедневно выполняется около 25 миллионов извлечений для непрерывной интеграции (CI). По словам компании, классическое использование Git потребовало бы передачи более 600 ПБ данных в день. Запуск сотен зеркал и снимков репозитория в объектном хранилище стал неуправляемым.

Поэтому Anthropic заменила Git собственной системой под названием Scion, разработанной за 5 месяцев. Сервер берет на себя тяжелые операции, такие как слияния, перебазирование и создание коммитов, в то время как локальный клиент ограничивается легким слоем, который управляет ограниченным кэшем и материализацией файлов на диске по запросу.

Набор изменений Scion хранит только список измененных файлов относительно первого родителя, в отличие от коммита Git, который указывает на полное дерево объектов. Scion также устраняет packfiles — сжатые архивы, используемые Git. По данным Anthropic, инфраструктура потребляет в 200 раз меньше вычислительных ресурсов и памяти, чем прежний парк Git, а CI получила 25% дополнительной мощности CPU.

Cursor полагается на журнал записи в S3

Cursor сохранила формат хранения и нативные инструменты Git на локальных дисках NVMe. Чтобы преодолеть ограничения Spokes, исторической архитектуры репликации GitHub, компания разработала альтернативный движок под названием Continuity, применяемый к ее монорепозиторию и флоту микрорепозиториев.

Эта архитектура основана на журналах упреждающей записи (WAL, Write-Ahead Logs), которые хранят несколько объектов последовательно в одном файле. Каждый push формирует отдельную запись в этом журнале, и ни один push не подтверждается, пока не будет сохранен в S3. Файл индекса, обновляемый с помощью CAS (compare-and-swap, атомарная операция условного обновления), упорядочивает каждую транзакцию. Реплики на дисках NVMe являются лишь кэшами, пересоздаваемыми из журнала, и любой узел может принимать запись.

Continuity достигает 120 пушей в секунду на S3 Standard и более 300 на S3 Express One Zone. За этим пределом вступает в силу внутреннее ограничение скорости компрессии Git на диске. При чтении система показала линейное масштабирование до 100 реплик без влияния на операции записи.

OpenAI и GitHub корректируют свои архитектуры

За два года объем коммитов, поступающих в ветку master монорепозитория OpenAI, вырос примерно в 25 раз, а надежность контроля версий упала ниже 90%. За 10 недель компания разработала Pando. Этот бэкенд отказывается предоставлять согласованное состояние всех веток в данный момент времени и принимает причинную согласованность: клиент соблюдает историю автора ветки без глобального порядка с несвязанными ветками. Серверы повторно используют неизменяемые packfiles и хранят данные в объектном хранилище без локальной распаковки при пушах. OpenAI сообщает, что Pando сократил медианную задержку пушей почти на 80% и позволяет доставлять почти 1 ПБ данных Git в день с « горсткой » ядер CPU.

Со своей стороны, GitHub зафиксировала 7,38 миллиарда коммитов в сентябре 2026 года при 3,35 миллиарда пушей — объем, выросший более чем в пять раз за год. Ее архитектура, развертываемая в производственной среде, ограничивает кворум и протокол 3PC отдельными ссылками, а не всем репозиторием. Внутренние тесты показали в 3–4 раза более высокую пропускную способность записи для конкурирующих репозиториев. Авторитетные данные передаются в объектное хранилище Azure, и GitHub заявляет о потенциальном увеличении пропускной способности записи до 35 раз с автономным масштабированием уровня чтения.

S’abonner
Notification pour
guest

0 Commentaires
Le plus ancien
Le plus récent Le plus populaire
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x