11 сентября 2026 года OpenAI опубликовала инженерный пост Rapidly scaling online storage to serve over 1 billion ChatGPT users. Это не новый id модели и не кнопка в чате. Компания разобрала Habitat: слой онлайн-хранилища, через который логин, настройки Codex и новый разговор в ChatGPT вообще доходят до данных.
Авторы: Jon Lee, Chaomin Yu и Ben Ries, Members of Technical Staff. Текст помечен как первая часть из двух. Практический смысл для человека с сайтом, ботом или ключом API простой: ждать Habitat в пикере или в apt не стоит. Имеет смысл смотреть, как лаборатория вытягивала Python-сервис до десятков миллионов запросов в секунду, где у неё ломались хвосты задержки, и как во втором квартале 2026 двое инженеров с Codex и GPT-5.5 переписали этот сервис на Rust.
Что такое Habitat и какие цифры они называют
Habitat, по формулировке OpenAI, платформа онлайн-хранилища. Продуктам не нужно самим решать, куда писать и откуда читать: схема, маршрутизация, авторизация, шифрование, сериализация, shaping запросов и пул соединений спрятаны за одним слоем. Снизу в схеме фигурируют Azure Cosmos DB, Nanobase, кэш Valkey, blob-хранилище, CDC в Databricks, Rockset и Kafka.
Сейчас Habitat держит больше 70 миллионов запросов в секунду, продукты на нём пользуются больше миллиарда людей в неделю, география почти 40 регионов, объём данных больше 500 петабайт. Два года назад это была простая клиентская библиотека на Python к одной базе. В середине 2024 она жила рядом с основным сервером ChatGPT и ходила в Azure Cosmos DB.
В RSS-описании до сих пор крутится старая цифра 22 миллиона запросов в секунду. В теле поста другая: 70 миллионов сейчас, а Python на своём пике держал больше 20 миллионов. Читать лучше тело, не карточку фида.
Рост они описывают так: больше чем в 10 раз год к году три года подряд. Обычно инженер закладывает 10x и надеется, что этого хватит на пару лет. У Habitat запас съедался быстрее, чем успевали делать «правильную» платформу. Отсюда серия тактических решений: выжимать текущий стек и откупать время у упирающихся дисков и CPU, пока дозревают фундаментальные вложения.
Почему библиотеку вытащили в сервис
К середине 2025 клиентская реализация упёрлась. Слой усложнился, сервисов стало больше, обратно совместимые смены протокола перестали быть реалистичными. Показательный эпизод: критичные наборы данных хотели разнести по региональным аккаунтам Azure Cosmos DB, чтобы одна площадка не клала всё сразу. Для этого в клиент добавили маршрутизацию за флагом, раскатили по десяткам сервисов, потом shadowing шардинга, потом фикс. На это уходили дни. Когда флаг наконец включили, одна команда откатила свой сервис по другой причине на старый клиент, и случился как раз тот инцидент, которого старались избежать.
Вывод у них прямой: менять библиотеку на каждом клиенте хрупко. Habitat вынесли в отдельный сервис. Один контур деплоя, наблюдаемости и доработок. Один узкий горловой участок, где можно центрально давить ACL, писать аудит и резать доступ к Cosmos DB. В тексте отдельно сказано, что слой защищает пользовательские данные от внешних, внутренних и агентных акторов. Для контура, где Codex и свои агенты уже ходят по инфраструктуре, это не декоративная фраза.
Python, asyncio и хвосты задержки
Сервис оставили на Python сознательно. Авторы понимали: как сетевой фронт это дороже по CPU, памяти и задержке, чем локальная библиотека, и на следующем 100x Python не выдержит. Это названо стратегическим техдолгом. Приоритет тогда был не экономия железа, а разблокировать продуктовые команды и стабилизировать платформу. Ставка: к моменту вынужденного переписывания Codex и GPT уже помогут. В тексте прямо: ставка в итоге сыграла.
Средний пользовательский запрос у них даёт сотни обращений в базу. Человек чувствует самый медленный вызов, не средний. Главная боль Python-сервиса на этом масштабе, хвостовые задержки.
asyncio даёт конкурентность I/O, но не обходит GIL и не даёт CPU-параллелизма. Habitat кроме прокси ещё жжёт CPU: маршрутизация, сжатие, шифрование, контрольные суммы, health-check, shadowing, hedging. Пока корутина ждёт своей очереди, ответ Cosmos DB уже готов, а хвост p99 растёт. До настройки в трассах это было видно явно. При высокой загрузке джиттер планировщика до сотен миллисекунд, в крайних случаях несколько секунд. Лекарство грубое: мало одновременных запросов на процесс и много процессов.
Один конкретный виновник на старте сервиса, периодический разбор JSON конфигов feature-флагов через Statsig. По умолчанию опрос раз в минуту без jitter, в конфиге все прод-правила всех сервисов, до 8 Python-процессов на под. Раз в минуту все воркеры пода одновременно бросали живые запросы и парсили огромный файл. Починили профилированием CPU: узкий конфиг, длиннее интервал, jitter на фоновые задачи.
Пул соединений тоже умеет работать против вас. Клиентский пул сажает нагрузку на горстку процессов. У них хвост процессов держал в 5-10 раз больше одновременных запросов, чем среднее. После всплеска часть подов не отходила: трафик продолжал липнуть к уже перегруженным. Диагноз: в Python aiohttp TCPConnector по умолчанию берёт соединение LIFO, последнее вернувшееся. Медленный сервер отдаёт сокет позже, его же и выбирают следующим. Петлю разорвали патчем на FIFO. Сейчас пулы и балансировку в основном отдают Istio и Envoy.
Обратная сторона кучи процессов, thundering herd на downstream. Обычный ежедневный деплой без медленной раскатки крутит CPU на пересоздании соединений. Утечка сокетов может забить NAT. Envoy у них поднимает Python HTTP/1 до HTTP/2 с мультиплексом, держит пул дольше и становится местом, где rate limit и circuit breaker работают на весь флот, а не в каждом процессе по отдельности.
Почему Habitat делает меньше, чем SQL
Python удалось растянуть ещё и потому, что API узкий. Произвольного SQL нет: Habitat отдаёт простой NoSQL. Дорогие сканы и джойны по многим таблицам специально не дают собрать «за пять минут». Раньше онлайн-данные жили в Postgres, ревью запросов и схем ещё работало, пока команда была маленькой. Потом один тяжёлый запрос на горячем пути регулярно клал базу. В Habitat дорогой запрос должен быть очевиден уже на стороне клиента.
Модель объектов и рёбер вдохновлена TAO. Клиенты заранее описывают типы объектов и рёбер, но не содержимое каждой записи. Это похоже на граф, но обход как в графовой базе не поддерживается: можно спросить прямые рёбра конкретного объекта. Объект и его рёбра лежат в одной партиции. Объекты на другом конце ребра могут жить в другом аккаунте Cosmos DB и в другом регионе. Горизонтально это хорошо режется, многошаговый обход, нет.
Сложные выборки вынесли в офлайн-вид через Rockset: CDC почти в реальном времени, каждый клиентский team сам масштабирует свой инстанс. Онлайн-хранилище так изолируют от аналитики и поиска.
Rust во втором квартале 2026
К моменту переписывания Habitat был вторым сервисом OpenAI по числу ядер и четвёртым по следу Envoy. Python на пике обслуживал больше 20 миллионов запросов в секунду. Во втором квартале 2026 двое инженеров, Codex и GPT-5.5 переписали сервис на Rust целиком. Новый сервис уже держит 95% продакшен-запросов, Python обещают выключить в ближайшие недели.
Их цифры по эффективности: Rust в 6 раз экономичнее по CPU и в 15 раз по памяти, средняя и хвостовая задержка заметно ниже. Подробности переноса обещают отдельным постом. Вторая часть этой серии должна разобрать слой хранения, мультитенантность, чтение и партнёрство с Azure Cosmos DB на тех же 500 ПБ и 70 миллионах запросов в секунду. На момент публикации part II в блоге ещё нет.
Если у вас сайт, бот или свой Python-сервис
Habitat вам не поставят. Это внутренний слой OpenAI под ChatGPT, API, Codex и свои сервисы, не пакет, не плагин WordPress и не публичный storage-API. Ключ ChatGPT от этого поста не меняется. Весов нет. Self-host Habitat нет.
Полезное лежит рядом. Если у вас FastAPI, aiohttp или любой asyncio-сервис с пулом соединений, история про LIFO и «липкий» хвост процессов читается без перевода на миллиард пользователей. Если feature-флаги раз в минуту парсят гигантский JSON на каждом воркере, p99 будет врать, даже когда база отвечает быстро. Если агенту отдают боевой контур, фраза OpenAI про защиту от agent actors стоит того, чтобы ещё раз пройти ACL, аудит и то, какие секреты процесс видит.
История «двое инженеров переписали гигантский сервис за квартал» легко превращается в аргумент выкинуть ревью и скормить Codex прод. В первоисточнике этого рецепта нет. У них уже были схема, тесты нагрузки, наблюдаемость и год эксплуатации Python-сервиса. Codex и GPT-5.5 здесь инструмент переноса, не замена человеку, который понимает GIL, Envoy и Cosmos DB. Боевой WordPress, SSH и root в такой контур не кладут.
Проверить руками, если проверка уместна, можно на копии своего сервиса, не на проде:
- считаете ли вы задержку event loop, а не только CPU и RAM;
- какой reuse в пуле соединений: последнее вернувшееся или самое старое;
- не синхронизированы ли фоновые парсеры конфигов без jitter;
- не упирается ли NAT или downstream в число соединений, а не в rps;
- есть ли у агента путь к секретам хранилища, который Habitat у них как раз центрально режет.
Про доступ из России в посте ни слова. Гадать не буду. Linux-клиента ChatGPT этот текст тоже не анонсирует: речь про внутренний storage, не про десктоп.
Если завтра этот разбор принесут как доказательство, что «Python для нагруженных сервисов мёртв» или что «агент сам перепишет прод», в первоисточнике обоих лозунгов нет. Там наоборот: Python сознательно оставили на год гиперроста, потом сузили API, починили хвосты и только после этого ушли на Rust, когда сервис уже был вторым по ядрам в компании.
