GPT-Realtime-2.1 и 2.1-Mini: Решение по маршрутизации голосового трафика, которое операторам нужно принять прямо сейчас

6 июля OpenAI выпустил две новые модели для работы в реальном времени: GPT-Realtime-2.1 и GPT-Realtime-2.1-mini. Обновление вводит двухуровневую архитектуру для голосовых workload — полноразмерная модель с расширенным reasoning и более быстрая, менее затратная дистиллированная версия — а также настраиваемый reasoning effort, позволяющий балансировать между задержкой и качеством ответа. Для операторов, строящих голосовых агентов или маршрутизирующих голосовой трафик через AI gateway, этот релиз меняет сразу три вещи: выбор модели, структуру затрат и допустимый диапазон задержки.

Что изменилось

GPT-Realtime-2.1 — обновлённая модель реального времени с reasoning: улучшена точность распознавания буквенно-цифровых последовательностей, обработка тишины и шума, а также поведение при перебиваниях. GPT-Realtime-2.1-mini — дистиллированный вариант, оптимизированный под скорость и стоимость, ориентированный на высоконагруженные голосовые приложения с жёсткими требованиями к задержке.

Обе модели доступны через Realtime API (v1/realtime). Ценообразование GPT-Realtime-2.1:

• Текстовые токены: $4,00 входящие / $24,00 исходящие за 1M токенов (кешированный ввод: $0,40)
• Аудиотокены: $32,00 входящие / $64,00 исходящие за 1M токенов (кешированный ввод: $0,40)
• Токены изображений: $5,00 входящие за 1M токенов (кешированный ввод: $0,50)

GPT-Realtime-2.1 поддерживает настраиваемый reasoning effort: операторы могут выбирать между быстрыми ответами при низком effort и более медленным, но качественным reasoning при высоком. Повышенный reasoning effort увеличивает задержку и потребление выходных токенов — прямой компромисс между ценой и качеством, который теперь управляется на уровне маршрутизации.

GPT-Realtime-2.1-mini — дистиллированная модель: быстрее, дешевле, рассчитана на голосовые приложения с ответами быстрее секунды, где скорость смены реплик важнее глубокого reasoning.

Почему это важно для AI-инженерных команд

Двухмодельная структура означает, что «использовать Realtime API» больше не является единственным решением по маршрутизации. Команды должны теперь решить:

1. Полная версия vs. mini по типу workload. GPT-Realtime-2.1 подходит для голосовых агентов, обрабатывающих сложные запросы: финансовые или медицинские вопросы, многошаговые инструкции, любые сценарии, где критична точность и отслеживание контекста. GPT-Realtime-2.1-mini подходит для высоконагруженных, чувствительных к задержке потоков: IVR-диспетчеризация, транскрипция и маршрутизация в реальном времени, FAQ в диалоговом режиме, сценарии с интенсивной сменой реплик.

2. Reasoning effort как параметр маршрутизации. Настраиваемый reasoning effort в GPT-Realtime-2.1 фактически является селектором уровня качества внутри одной модели. Операторы с mixed voice workloads могут маршрутизировать низкосложные реплики с effort low и эскалировать до high при обнаружении сложного намерения — без смены endpoint. Это новый паттерн, который голосовые routing policies должны учитывать.

3. Ценообразование аудиотокенов в масштабе. Аудиовввод по $32,00/MTok и аудиовывод по $64,00/MTok — основные статьи затрат для голосовых workload реального времени. Политика по умолчанию для всего трафика на GPT-Realtime-2.1 будет существенно дороже, чем маршрутизация рутинных взаимодействий через 2.1-mini. Для команд, обрабатывающих миллионы голосовых реплик в день, routing policy напрямую определяет ежемесячный счёт.

4. Улучшения распознавания буквенно-цифровых данных и обработки перебиваний. Обновление 2.1 явно упоминает точность распознавания буквенно-цифровых последовательностей — критично для голосовых агентов, работающих с ID, номерами заказов, телефонными номерами и кодами, — а также улучшенную обработку перебиваний. Это повышение надёжности, влияющее на то, какой уровень качества заслуживает production-трафика.

Взгляд со стороны operator'а и router'а

Для команд, маршрутизирующих голосовой трафик через AI gateway, релиз 2.1 создаёт многоуровневую модель маршрутизации, аналогичную уже существующей для текстовых workloads:

Фреймворк принятия решений:

Параметр reasoning effort заслуживает особого внимания. В отличие от разделения full/mini, требующего маршрутизации на разные model ID, reasoning effort — это параметр запроса для GPT-Realtime-2.1. Голосовой gateway может реализовать определение сложности намерения (по транскрипции или контексту сессии) и передавать соответствующий уровень effort без изменения downstream endpoint. Это полезный паттерн для операторов, желающих сохранить единый endpoint при дифференциации стоимости и качества по типу реплики.

Моделирование затрат перед миграцией: До обновления routing policies рассчитайте текущий объём аудиотокенов по базису ценообразования 2.1. Если существующие workloads работают на GPT-Realtime-2 и вы рассматриваете переход на 2.1, сравните поаудиотокенные ставки и оцените, оправдывают ли улучшения в распознавании и обработке перебиваний возможную разницу в стоимости.

Планирование rate limit: GPT-Realtime-2.1 и GPT-Realtime-2.1-mini, вероятно, работают с раздельными пулами rate limit. Операторам следует проектировать fallback-логику соответственно: при достижении rate limit 2.1 переключаться на 2.1-mini, а не возвращать ошибку — для большинства реплик 2.1-mini обеспечивает приемлемое качество.

Что стоит проверить и попробовать пользователям TheRouter

Если вы маршрутизируете трафик голосовых агентов через TheRouter, релиз 2.1 — повод пересмотреть provider routing policy. Проверьте текущую конфигурацию model ID и определите, имеет ли смысл разделение 2.1 и 2.1-mini для вашего mix workloads. Каталог моделей отслеживает доступные model ID; прежде чем обновлять production routing rules, убедитесь, что обе новые модели отображаются в списке.

Параметр reasoning effort — не традиционный routing flag, а атрибут на уровне запроса. Командам голосовых gateway стоит оценить, может ли routing layer передавать подсказки по уровню effort от вышестоящей классификации намерений, или достаточно более простой политики (полная модель для всех реплик выше порогового значения длины).

Наконец, проверьте fallback chain для голосовых workloads. С двухуровневым семейством realtime-моделей приоритет fallback должен быть: основной уровень (2.1 или 2.1-mini, согласно политике) → противоположный уровень → graceful degradation.