Яндекс Realtime против OpenAI Realtime: разработчик замерил задержку и перенёс прод

6 июля 2026 года OpenAI выпустил gpt-realtime — движок «речь в речь» с поддержкой перебиваний и естественной интонацией. Разработчик, строящий голосового ИИ-приёмщика для бизнеса на российском стеке, за один вечер собрал прототип, сравнил три подхода по задержке и перенёс продакшн на Яндекс Realtime.

Что показали замеры задержки?

Автор измерил сквозную задержку одним и тем же методом у трёх вариантов и получил чёткую картину.

• Яндекс Realtime — ~330 мс (прямое подключение в РФ без VPN)
• OpenAI gpt-realtime — ~740 мс (только через VPN; напрямую из России недоступен)
• Старая трёхзвенка (STT → LLM → TTS) — ~4,4 секунды

Яндекс выигрывает у OpenAI в два раза исключительно за счёт географии: VPN добавляет несколько сотен миллисекунд, которые не убрать никакими оптимизациями кода. Трёхзвенная схема проигрывает обоим с разгромным счётом — разница в 13 раз против Яндекса слишком велика для голосового интерфейса, где пауза длиннее 500 мс ощущается как «тупит».

Где спотыкаются оба движка

У OpenAI разработчик сразу столкнулся с 400-й ошибкой эндпоинта — она возникает при неверной структуре WebSocket-запроса и практически нигде не задокументирована. Отладка заняла значительную часть вечера.

Вторая проблема серьёзнее: движок плохо справляется с русским акцентом. Языковая модель тренировалась преимущественно на английском, и это не лечится настройками системного промпта — ограничение архитектурное.

У Яндекса порог входа выше на уровне авторизации: три роли доступа и закрытый обмен OAuth→IAM, который нигде подробно не описан. Документация предполагает, что разработчик уже работает внутри экосистемы Яндекс.Облака. Без понимания этой схемы получить первый рабочий токен нетривиально.

«Яндекс умеет в русский язык нативно.

OpenAI — нет, и это фундаментальная проблема для голосового продукта на российском рынке», — резюмирует автор.

Как прошёл переезд на Яндекс Realtime

После замеров решение оказалось очевидным: автор переписал продакшн по трём ключевым направлениям.

WebSocket-мост вместо REST. Яндекс Realtime работает через постоянное WebSocket-соединение, а не разовые HTTP-запросы. Это потребовало переписать логику отправки аудио: вместо chunked-upload — живой стриминг PCM.

Живой PCM-плеер вместо MP3. Предыдущая схема кодировала ответы в MP3 перед воспроизведением, что добавляло задержку. Прямая работа с PCM убрала этот шаг и устранила артефакты при перебиваниях — MP3-кодек не успевал «закрыть» фрейм при внезапной остановке.

Перебивание без наушников. Яндекс Realtime поддерживает эхоподавление на уровне движка, поэтому бот корректно реагирует на перебивание даже через обычные динамики. В старой трёхзвенке это было принципиально невозможно.

Самым трудоёмким оказалась авторизация: пришлось вручную разобраться с обменом токенов OAuth→IAM, потому что готовых примеров на Python почти нет.

Что это значит

Для голосовых продуктов на российском рынке выбор между OpenAI Realtime и Яндекс Realtime — это прежде всего выбор между удобством первого прототипа и качеством русского языка в продакшне. Яндекс выигрывает по задержке и произношению, но требует разобраться с IAM. Старая трёхзвенка уходит в прошлое: 4,4 секунды ожидания — это уже не разговор, а автоответчик из 2005 года.

Частые вопросы

Можно ли использовать OpenAI Realtime в России без VPN?

Нет: по состоянию на июль 2026 года сервис недоступен напрямую с российских IP-адресов. VPN неизбежно добавляет задержку и поднимает её с потенциальных ~400 мс до ~740 мс в реальных условиях.

Чем Яндекс Realtime отличается от обычного SpeechKit?

Яндекс Realtime — полный duplex-движок «речь в речь» на одном постоянном WebSocket-соединении с поддержкой перебиваний. SpeechKit — раздельные STT и TTS-сервисы, которые нужно самостоятельно склеивать в трёхзвенку с задержкой 4+ секунды.