OpenAI разбила транскрипцию на четыре модели: решение по маршрутизации для каждого аудиопайплайна

28 июля OpenAI выпустила две новые модели речи в текст — gpt-transcribe и gpt-live-transcribe — и немедленно объявила их рекомендуемыми по умолчанию для новых задач транскрипции. Внешне это выглядит как обновление модели, но по сути является изменением архитектуры маршрутизации: OpenAI разбила транскрипцию на матрицу из четырёх model ID, каждый из которых покрывает определённый набор возможностей, причём две из них больше не доступны в новых defaults.

Если ваш аудиопайплайн построен вокруг gpt-4o-transcribe, код будет работать и сегодня — но таблица маршрутизации, на которую вы опираетесь, уже заменена.

Что изменилось и что теперь покрывает каждый model ID

До 28 июля gpt-4o-transcribe была рекомендуемой моделью для всех задач транскрипции — загрузки файлов, потоковой обработки и прямого аудио. Она принимала endpoint /v1/audio/transcriptions и охватывала большинство сценариев из единого имени модели.

Новая матрица:

Следствие для маршрутизации: вам нужно знать нужную возможность до выбора модели. Старый gpt-4o-transcribe позволял запрашивать функции в параметрах запроса, и endpoint их обрабатывал. Новая архитектура помещает каждую возможность в отдельный model ID.

Разделение endpoint — вот в чём ломающее изменение

gpt-live-transcribe не поддерживает v1/audio/transcriptions. Он работает только через v1/realtime/transcription_sessions — WebSocket-based Realtime API OpenAI. Если ваш пайплайн загружает файл и ожидает синхронного транскрипта, gpt-live-transcribe не обработает такой запрос.

gpt-transcribe, в свою очередь, не поддерживает потоковые дельты через Realtime endpoint. Это модель запрос-ответ: отправь файл, получи текст. Она работает в Realtime endpoint только для одного конкретного сценария — транскрибирования committed turns (того, что пользователь уже сказал в голосовой сессии) — но дельты транскрипта в реальном времени требуют gpt-live-transcribe.

Это важно для операторов, строящих голосовые агенты. Если вы ведёте WebSocket-сессию и нужны частичные транскрипты пока пользователь ещё говорит — нужен gpt-live-transcribe на Realtime endpoint. Если достаточно прочитать, что сказал пользователь после каждого хода — gpt-transcribe на endpoint транскрипции обойдётся дешевле.

Разрыв в цене: 3,8× между файлом и прямым потоком

gpt-transcribe стоит $0.0045 за минуту аудио. gpt-live-transcribe — $0.017 за минуту, примерно в 3,8 раза дороже за те же речевые данные.

Надбавка — за низкую задержку: gpt-live-transcribe транслирует частичные транскрипты по мере поступления аудио, поддерживая состояние соединения на протяжении всей сессии. Если ваш сценарий не требует частичных транскриптов до окончания реплики — если нужен лишь точный транскрипт по завершении — gpt-transcribe даёт правильное решение по маршрутизации при существенной экономии.

Для операторов, запускающих аналитику колл-центров, запись совещаний или транскрипцию подкастов: эти задачи почти никогда не требуют потоковых частичных транскриптов. Работа происходит после захвата аудио. Все такие пайплайны должны маршрутизироваться в gpt-transcribe, а не в gpt-live-transcribe.

Что по-прежнему остаётся только в whisper-1

Ни одна из новых моделей не поддерживает временны́е метки на уровне слов, вывод SRT, субтитры VTT или перевод аудио на английский. Эти возможности по-прежнему есть только в whisper-1. Если вы строите пайплайны субтитрования, рабочие процессы озвучивания или любой вывод, требующий метки времени для каждого слова — новые модели не являются целью миграции.

Это самая частая ошибка при проверке существующей интеграции: команды, использовавшие gpt-4o-transcribe с timestamp_granularities: ["word"] или response_format: "srt", должны оставить whisper-1 для таких вызовов, а не переходить на gpt-transcribe.

Новые параметры контекста повышают точность

gpt-transcribe и gpt-live-transcribe добавляют два параметра, которых не было в gpt-4o-transcribe:

• keywords: массив терминов, которые модель должна предпочитать при неоднозначном аудио — названия моделей, артикулы продуктов, имена собственные, технический жаргон
• languages: список кодов языков для подсказки ожидаемого входного языка; модель умеет работать с переключением кодов в одном клипе

Поле prompt продолжает работать как неструктурированная строка контекста. Новый параметр keywords структурированный и имеет больший вес для конкретных терминов. Для доменно-специфичного аудио — звонки в поддержку с упоминанием ID продуктов, инженерные встречи с именами API — keywords стоит добавить к существующим интеграциям ещё до любой другой работы по миграции.

Путь миграции с gpt-4o-transcribe

Для большинства задач транскрипции файлов:

# Раньше
transcription = client.audio.transcriptions.create(
    model="gpt-4o-transcribe",
    file=audio_file
)

# Теперь
transcription = client.audio.transcriptions.create(
    model="gpt-transcribe",
    file=audio_file,
    keywords=["ваши-доменные-термины"]  # новое, повышает точность
)

Для прямых аудиопотоков меняется сам endpoint:

# gpt-live-transcribe требует v1/realtime/transcription_sessions
# Не v1/audio/transcriptions — это разные WebSocket-сессии

Команды, жёстко прописавшие URL endpoint (а не только имя модели), должны убедиться, что endpoint соответствует модели. Отправка gpt-live-transcribe на /v1/audio/transcriptions завершится ошибкой; отправка gpt-transcribe на /v1/realtime для потоковой транскрипции вернёт только результаты committed-turn, а не дельты в реальном времени.

На что стоит обратить внимание операторам

Запуск GPT Transcribe сигнализирует: OpenAI рассматривает аудио как кластер возможностей, а не единую модель. Ожидайте расширения этой матрицы — диаризация уже в отдельной модели (gpt-4o-transcribe-diarize), перевод остаётся в whisper-1. Планирование голосового пайплайна сегодня означает политику маршрутизации по нескольким model ID, а не единственный alias.

Для команд, маршрутизирующих трафик к OpenAI через AI gateway, соответствие модели и endpoint нужно проверить. Proxy, принимающий любое имя модели и пересылающий его на фиксированный /v1/audio/transcriptions endpoint, будет тихо неверно маршрутизировать запросы gpt-live-transcribe. Правила маршрутизации на уровне оператора для аудио endpoint теперь независимы от маршрутизации текстовых завершений.