Как остановить вышедшего из-под контроля ИИ-агента за 35 секунд?
Control Room функционирует непосредственно внутри исследовательского стека OpenAI, принудительно останавливая несанкционированное поведение моделей на аппаратных кластерах. По мере того как автономные ИИ-агенты берут на себя многоэтапные рабочие процессы — от обработки массивов данных до экспериментального сэмплирования, — инженерные команды сталкиваются с базовой операционной проблемой: как сохранить контроль над агентными нагрузками, когда вмешательство должно происходить за секунды, а не минуты? Решение, к которому пришла OpenAI, представляет собой обязательную точку контроля, встроенную прямо в конвейер генерации токенов. Масштабирование передовых моделей требует программных аварийных выключателей (kill switches) непосредственно на уровне инференса, а не надежд на самоконтроль прикладного кода. OpenAI развернула Control Room как централизованную систему для мониторинга рабочих нагрузок моделей по всей исследовательской инфраструктуре и их экстренной остановки при возникновении рисков безопасности. Вместо того чтобы полагаться на корректное завершение пользовательских скриптов, централизованный сервис вмешивается в процесс между запросом на вычисления и физическими GPU.
Задачи вроде обучения с подкреплением, сравнительных тестов и обработки больших массивов данных запускаются отдельными исследователями или командами, поэтому экспериментальный код крайне разнообразен и постоянно модифицируется. В OpenAI признали, что код самих прикладных задач — неподходящее место для внедрения критически важных механизмов защиты. Вместо этого компания перенесла проверки авторизации в движки инференса, которые представляют собой фактический вычислительный контур модели на GPU-кластерах. Поскольку в исследовательской инфраструктуре OpenAI используется лишь минимальное количество стандартизированных путей исполнения инференса, эти движки выступают безальтернативным операционным бутылочным горлышком. Каждая исследовательская нагрузка, выполняющая агентный инференс, обязана получить одобренный профиль безопасности (safety case) до выделения вычислительных мощностей.
Архитектура 35-секундной остановки
В рамках этой архитектуры среды выполнения код задачи сначала запрашивает идентификатор job_id у сервиса Control Room. Каждый раз, когда эксперименту требуется сэмплирование токенов, он отправляет этот job_id в движок инференса, который запрашивает подтверждение у Control Room перед выполнением операции.
Если задача была принудительно завершена, сервис отклоняет запрос, а движок возвращает отказ, немедленно блокируя дальнейшую генерацию токенов.
«Максимальное время между моментом, когда Control Room получает команду на остановку задачи, и моментом, когда дальнейшее выполнение становится невозможным, составляет 35 секунд».
В OpenAI подтвердили, что этот 35-секундный лимит обусловлен кэширующим слоем, рассчитанным на колоссальный объем трафика инференса. Сейчас команда работает над снижением этой задержки до нуля для мгновенной ликвидации процессов. Но как управляющая архитектура определяет, что запуск отклонился от заданных параметров? За фиксацию аномалий отвечают автоматизированные модели-супервизоры. Все передовые задачи обучения с подкреплением выполняются параллельно со специализированным монитором — вспомогательной моделью, которая проверяет каждое действие обучаемой системы и сигнализирует о сбоях. К примеру, по данным OpenAI, один из недавних инцидентов, связанных с DNS, был перехвачен именно таким монитором. Обнаружив проблему, модель-наблюдатель в зависимости от уровня критичности инициирует остановку и отправляет команду на завершение с соответствующим job_id напрямую в Control Room.
Реалии архитектуры с отказом в сторону блокировки
Стандартная практика проектирования инфраструктуры предполагает сохранение доступности (fail-open), когда при сетевых сбоях системы управления по умолчанию открывают доступ ради непрерывности процессов.
Control Room работает строго по противоположному принципу — с отказом в сторону блокировки (fail-closed). Если сам сервис Control Room падает или теряет сетевую связность, все движки инференса автоматически отклоняют входящие запросы до полного восстановления системы. OpenAI спроектировала платформу так, чтобы она продолжала функционировать при сбоях других компонентов, но гарантированно глушила генерацию токенов, если центральный контролирующий узел недоступен. Чтобы исключить попытки обхода этого фильтра со стороны разработчиков, OpenAI проводит непрерывное агентное и программное сканирование инфраструктуры на предмет запуска сторонних движков инференса без интеграции с Control Room. Архитектура fail-closed уже внедрена для всех исследовательских нагрузок передовых моделей, где сосредоточены основные операционные риски.
Эксплуатация автономных агентов требует жестких инфраструктурных барьеров, вшитых непосредственно в вычислительный контур. На фоне усилий OpenAI по снижению задержки блокировки до нуля подход fail-closed наглядно демонстрирует: масштабирование сложных агентных систем невозможно без создания безальтернативных узлов контроля, способных принудительно гасить вычисления на масштабе целых кластеров.
Для сравнения
Риск неконтролируемого перерасхода вычислений и сбоев теперь купируется на уровне железа: запуск системы Control Room переносит барьер безопасности прямо в конвейер инференса вместо хаотичных пользовательских скриптов. Сравнивая этот подход со стандартными практиками изоляции на уровне прикладного софта, OpenAI сделала ставку на единое аппаратное бутылочное горлышко — движки инференса просто блокируют генерацию токенов при отказе центрального сервиса. За этот жесткий надзор компания платит дополнительной вычислительной нагрузкой: каждую передовую задачу обучения с подкреплением приходится дублировать моделью-монитором, проверяющей каждый шаг обучаемой системы. Архитектурная ставка на мониторинг через супервизоров превращает безопасность агентов в прямой налог на серверные мощности.
Источник: OpenAI Blog