11 сентября 2026 года OpenAI опубликовала инженерный разбор Habitat — своей платформы онлайн-хранения, которая обслуживает продукты компании на масштабе более миллиарда пользователей. По данным OpenAI, система уже обрабатывает свыше 70 миллионов запросов в секунду, работает почти в 40 географических регионах и управляет более чем 500 петабайтами данных.
Самая заметная часть истории — эволюция серверного слоя. Habitat начинался как Python-клиент вокруг Azure Cosmos DB, затем превратился в самостоятельный сервис, а во втором квартале 2026 года его основной production-сервис был переписан на Rust.
Что такое Habitat у OpenAI
Habitat — не одна база данных и не отдельный продукт для пользователей. OpenAI описывает его как слой онлайн-хранения, который предоставляет приложениям единый интерфейс к распределённым данным. Под ним остаются специализированные системы хранения, а Habitat берёт на себя маршрутизацию, изоляцию, управление трафиком и часть логики масштабирования.
Такой слой нужен, когда число сервисов и регионов растёт быстрее, чем команды готовы поддерживать множество прямых интеграций с хранилищами. Вместо того чтобы каждое приложение самостоятельно знало, где находятся данные и как к ним подключаться, общая инфраструктура скрывает значительную часть этой сложности.
Масштаб, который называет OpenAI
- более 70 млн запросов в секунду;
- более 500 ПБ данных;
- почти 40 географических регионов;
- продукты, которыми еженедельно пользуется более 1 млрд человек.
Эти цифры важны не как абстрактный рекорд. Они объясняют, почему решения, приемлемые на ранней стадии, перестают быть достаточными после многократного роста нагрузки.
С чего начиналась архитектура на Python
По словам OpenAI, Habitat появился в середине 2024 года как Python-библиотека-клиент вокруг Azure Cosmos DB. На первом этапе это позволяло быстро дать разработчикам более удобный слой доступа к данным, не строя отдельный сетевой сервис.
Позже Habitat стал самостоятельным сервисом. Python-версия на пике обслуживала более 20 млн запросов в секунду. То есть переход на Rust не был реакцией на то, что Python «не работал»: существующая система уже выдерживала очень большую реальную нагрузку.
Почему OpenAI решила переписать сервис на Rust
Когда нагрузка продолжила расти, цена каждого дополнительного процента CPU, памяти и задержки стала существенной. OpenAI пишет, что во втором квартале 2026 года два инженера вместе с Codex и GPT-5.5 переписали весь сервис на Rust.
По опубликованным результатам, Rust-реализация оказалась примерно в 6 раз эффективнее по CPU и в 15 раз эффективнее по памяти относительно Python-сервиса. OpenAI также сообщает о снижении средней и хвостовой задержки.
Сейчас Rust-сервис обрабатывает около 95% production-запросов Habitat, а старую Python-реализацию планируется вывести из эксплуатации.
Это не история «Rust всегда лучше Python»
Из материала OpenAI следует более полезный вывод: язык нужно оценивать в контексте стадии проекта. Python позволил быстро построить и развить платформу до десятков миллионов запросов в секунду. Переписывание стало оправданным уже тогда, когда инфраструктура выросла настолько, что эффективность исполнения напрямую влияла на стоимость и запас по масштабированию.
Для большинства бизнес-сайтов и интеграций подобные масштабы не нужны. Поэтому копировать технологический стек OpenAI без причины бессмысленно. Гораздо важнее понимать, где находится реальное узкое место конкретной системы.
Что полезно взять из архитектуры Habitat
1. Отделять приложение от физического хранилища
Единый сервисный слой упрощает смену маршрутов, регионов и внутренних реализаций. Приложению не обязательно знать все детали инфраструктуры.
2. Делать идентификаторы и API стабильными
Если контракт между приложением и storage layer стабилен, внутреннюю реализацию можно менять постепенно. Именно это делает крупные миграции управляемее.
3. Измерять CPU, память и tail latency отдельно
Средняя задержка не показывает всю картину. Для высоконагруженных API особенно важны редкие медленные ответы, которые пользователь замечает как зависание.
4. Не начинать с дорогого переписывания
Habitat показывает обратный путь: сначала рабочая Python-архитектура, затем отдельный сервис и только после доказанного масштаба — переход на более эффективную реализацию.
Где этот подход пересекается с обычной веб-разработкой
В WordPress, WooCommerce и бизнес-автоматизациях масштабы меньше на много порядков, но логика похожа. Когда сайт начинает напрямую обращаться к нескольким CRM, API, складам и AI-сервисам, полезно выделять интеграционный слой, очереди, кэш и контролируемые retry-механизмы вместо того, чтобы размещать всю логику внутри одного пользовательского запроса.
Это снижает связанность и позволяет менять внешние сервисы без полного переписывания сайта. Для таких задач A.S Groups занимается AI-автоматизацией и интеграциями, а также доработкой WordPress.
Что Habitat показывает про AI в разработке
Отдельно интересен процесс миграции: OpenAI прямо указывает, что два инженера работали вместе с Codex и GPT-5.5. Но опубликованный материал не говорит, что AI самостоятельно выполнил переписывание или заменил инженерную проверку.
Практический вывод — AI может ускорять работу с большой кодовой базой, но архитектурные границы, тестирование, rollout и наблюдаемость всё равно остаются частью инженерного процесса.
Когда переписывание действительно имеет смысл
- профилирование показывает устойчивое узкое место в runtime, а не в базе или внешнем API;
- стоимость CPU и памяти стала заметной частью инфраструктурных расходов;
- есть измеримые требования по latency;
- существующий контракт API позволяет мигрировать поэтапно;
- есть нагрузочные тесты и метрики для сравнения до и после;
- команда способна поддерживать новый стек после миграции.
Как A.S Groups может помочь
Для большинства коммерческих проектов задача не в том, чтобы строить Habitat, а в том, чтобы не допускать архитектурных проблем раньше времени: тяжёлых синхронных интеграций, отсутствия кэша, неконтролируемых retry, дублирующих запросов и зависимостей от одного внешнего API.
Можно разобрать текущую схему сайта или автоматизации, определить узкие места и предложить более устойчивую архитектуру. Описать задачу можно через контакты A.S Groups.
Частые вопросы
OpenAI полностью отказалась от Python в Habitat?
На момент публикации OpenAI пишет, что Rust обслуживает около 95% production-запросов Habitat, а Python-версию планируется вывести из эксплуатации в ближайшие недели.
Почему не использовали Rust с самого начала?
OpenAI описывает Habitat как систему, которая эволюционировала из Python-клиента вокруг Cosmos DB. Переход на Rust произошёл уже после значительного роста нагрузки и требований к эффективности.
Сколько запросов обрабатывает Habitat?
В материале OpenAI указано более 70 миллионов запросов в секунду.
Нужно ли обычному API переписывать Python на Rust?
Нет. Сначала нужно профилирование. Часто основное время уходит в базу данных, сеть, сторонние API или неоптимальный алгоритм, а не в сам язык.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.