Подробный разбор · Около 6 мин чтения
Как OpenAI перестроила Habitat: общая ёмкость, региональные кэши и условное ускорение чтения в 12 раз
OpenAI описывает контейнеры Cosmos DB, инвалидацию через CDC и Rust; снижение медианы объединяет несколько изменений.
- Опубликовано здесь
- Дата источника
- Источник проверен
В инженерной статье от 23 октября OpenAI объясняет изменения хранилища Azure Cosmos DB и пути чтения Habitat. Это рассказ об эксплуатационных компромиссах и измерениях компании, а не выпуск модели или общедоступного сервиса хранения.
Слушать новости
Прослушайте эту статью или включите новости подряд.
Подготовка чтения…
Голос устройства
Речь обрабатывает браузер или устройство. AISubHub не отправляет текст в аудио-API. Доступные голоса и работа при заблокированном экране зависят от устройства.
При продолжении короткая фраза может повториться.
Кратко
- OpenAI связывает снижение глобального p50 чтения примерно со 120 до 10 мс с размещением данных, региональными кэшами и переписыванием на Rust вместе; медленные промахи кэша по-прежнему обращаются к удалённому хранилищу.
- Habitat перешла от общих контейнеров к изоляции, а после совместной разработки с Azure — обратно к совместному использованию по умолчанию. Отдельная эксабайтная система ещё разрабатывается.
Почему общее хранилище ограничивало несвязанные функции
OpenAI описывает Habitat как слой с более чем 500 петабайтами данных для продуктов, обслуживающих свыше миллиарда пользователей в 40 географических регионах. Это заявленный автором масштаб, не независимый подсчёт пользователей и не сообщение о таком числе новых регистраций. Практический вопрос — объединить ресурсы, не позволяя одной функции вредить другой. Изначально каждый аккаунт Cosmos DB использовал один контейнер по умолчанию, а клиенты выбирали логические ключи партиционирования. Обычные идентификаторы могли заставить разные сценарии делить ограничения одного ключа.
RU/s означает единицы запросов в секунду, а не фиксированное количество обращений. Начальный проект рассчитывал на объявленный предел 10 000 RU/s для логического ключа как источник обратного давления, но ограничения применяются на общих физических разделах. Там конкурируют и несвязанные ключи. Есть ещё ловушка: если рост данных делит физический раздел, а суммарная пропускная способность контейнера не растёт, каждому дочернему разделу достаётся меньше. Большие объекты могут вызвать ограничения даже при постоянной частоте запросов. Схемы объясняют механизм; их пропорции не являются производственными измерениями.
Изоляция уменьшила ущерб и усложнила планирование
Выделенные контейнеры дали критическим сервисам отдельные физические разделы и ограничили влияние шумных соседей. Команда также согласовывала выделенную пропускную способность с количеством разделов для борьбы со слабыми разделами. Взамен на каждой границе сервиса потребовалось планировать ресурсы. Переход от внутренних тестов к массовому публичному трафику мог перегрузить маленький изолированный контейнер, тогда как та же прибавка почти не меняла большой общий пул. Изоляция перенесла границы отказа, но не устранила прогнозирование спроса перед запуском.
Habitat вернулась к общим контейнерам по умолчанию с ограничением горячих ключей, низким приоритетом массовых операций и serverless-вариантом, созданным с Azure. Статья сравнивает прежний потолок 5 000 RU/s на физический раздел со специальным режимом до 10 000 RU/s, где деление вызывают и использование RU, и объём данных. Это конкретная совместная разработка, не доказательство доступности настройки всем клиентам Azure. Наш анализ: объединение вновь становится надёжным, когда контроль защищает интерактивную работу, а управление мощностью реагирует на спрос.
Почему управляемому сервису понадобились общие испытания отказов
По словам OpenAI, её крупнейший аккаунт Cosmos DB хранит десятки петабайт и обслуживает более 20 миллионов запросов в секунду. Отключение питания в конце 2024 года и происшествие при возврате примерно месяц спустя выявили непроверенные допущения масштаба. Отключение питания показало, что крупнейшим аккаунтам потребуются часы для перехода в резервный регион; примерно месяц спустя возврат вызвал лавину подключений, перегрузившую исходный шлюз. Клиенты подключались до возвращения всех нужных физических разделов. Это два отказа на разных стадиях восстановления, а не один непрерывный простой.
Ответ не ограничился покупкой ресурсов. Habitat и Azure совместно наблюдают за слоями, тестируют непродукционный аккаунт производственного размера, дорабатывают SDK и поддерживают прямую инженерную эскалацию. Упомянуты также кэш метаданных шлюза, защита от нагрузки, повторное использование соединений и разделение критических и офлайн-задач. Мы делаем вывод, что другим командам следует проверять как переключение, так и возврат при характерном масштабе. Управление базой со стороны поставщика само по себе не подтверждает поведение клиентских соединений, срок восстановления или допустимую область ущерба.
Что на самом деле входит в ускорение чтения в 12 раз
Согласно OpenAI, чтение составляет более 90% запросов Habitat. Стратегия размещает данные ближе к пользователям, когда хватает ресурсов, широко реплицирует несколько небольших наборов, чувствительных к задержкам, и использует близкие кэши Valkey для остальных популярных объектов и связей. Некоторые критические аккаунты реплицируются во все 40 обслуживаемых регионов Azure; это не означает полную репликацию всех данных повсюду. Хранение и вычисления конкурируют за электричество, охлаждение и место. Размещение остаётся продуктовым и ресурсным компромиссом, а не безусловной гарантией близости.
Инвалидация использует поток изменений Cosmos DB: потребители CDC сбрасывают локальные копии после обновления, а следующее чтение заполняет кэш заново. OpenAI сообщает о глобальном распространении за секунды, позволяющем не полагаться только на истечение TTL; это не мгновенная согласованность. Переписывание на Rust также уменьшило накладные расходы сервиса. Вместе изменения снизили глобальный p50 примерно со 120 до 10 мс. График разделяет близкую репликацию, региональный кэш и Rust. Коэффициент 12 нельзя приписывать только Rust, переносить на запись или на полное время ответа ChatGPT каждому пользователю.
Масштаб CDC и граница между работающим и разрабатываемым
CDC также питает вторичные индексы, перенос данных и аналитику. OpenAI сообщает о миллионах изменений в секунду из тысяч контейнеров и миллионов разделов через более ста топиков Kafka. Управляющий слой распределяет регионы и исполнителей; чтение реплик с низким приоритетом защищает интерактивный трафик. Изоляция потоков, управление арендой, очереди неудачных сообщений и смена читателей при региональных отказах решают разные проблемы. Отделение постоянно неудачной доставки не даёт заблокировать поток, но не доказывает актуальность каждого последующего потребителя.
Ограничения сохраняются: медленные промахи кэша идут в удалённое хранилище, а статья не даёт контролируемого сравнения отдельных улучшений или общей гарантии хвостовых задержек. OpenAI разрабатывает эксабайтную систему с ядром RocksDB Cloud от Rockset, репликацией Raft и Cosmos-совместимой моделью документов. Разделённое хранилище и физическая репликация должны уменьшить потребность во флеш-памяти ценой меньшего пикового QPS. Система ещё разрабатывается, замена Cosmos не завершена. Мы прочли вторую часть и график чтения, но независимо не проверяли первую часть, код SDK или гарантии сервиса по ссылкам.
Почему это важно
Инфраструктурным командам полезно сопоставить изоляцию, общий запас мощности и эксплуатационные обязанности. Актуальность кэша, восстановление и хвостовые задержки требуют отдельных критериев приёмки.
Ограничения и доступность
Это утверждения OpenAI, не воспроизведение AISubHub и не гарантия Azure. Статья не доказывает общедоступность специального serverless-режима, новые права подписчиков или ускорение всего приложения.
Источники и подтверждения
Дата источника: · Источник проверен:
Материалы подготовлены с помощью ИИ и сверены с указанными первоисточниками. Заявления поставщиков атрибутированы; публикация не означает рекомендацию.