OpenAI Realtime API: голосовые агенты в продакшене (2026)

Почему этот плейбук написала Фора Софт

Фора Софт занимается голосовыми и видеопродуктами с 2005 года: из 625+ выпущенных проектов более 200 связаны с аудио в реальном времени. Среди них — TransLinguist (синхронный многоязычный перевод в продакшене у NHS UK), Hospital Phone Interpreter, два развёртывания AI-ресепшен под NDA и тренажёр для продажников, встроенный в платформу для встреч.

За последние двенадцать месяцев мы выпустили в продакшен четырёх голосовых агентов на OpenAI Realtime API и ещё пятерых — на LiveKit Agents с текстовыми моделями OpenAI. Сделали и две миграции: одну с Vapi на самохостинговую связку OpenAI Realtime + LiveKit (мотив — стоимость), и одну в обратную сторону (заказчик из медицины, где из-за HIPAA пришлось вернуться к chained-пайплайну). Цифры, задержки и архитектурные решения в этой статье — из этих проектов, а не из шпаргалки.

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

Что изменилось с выходом gpt-realtime в GA

Большую часть 2024 года Realtime API от OpenAI был доступен в превью под именем gpt-4o-realtime-preview. Цены кусались, задержки скакали, модель часто перебивала пользователя. В конце 2025-го OpenAI выпустила gpt-realtime как продакшен-модель и добавила более лёгкую gpt-realtime-mini для чувствительных к стоимости сценариев. Положение дел в 2026 году такое:

1. Цены упали на 20 %. Аудио на входе — 2 400 ₽ за миллион токенов (около 4,5 ₽/мин), аудио на выходе — 4 800 ₽ за миллион (~18 ₽/мин). Кэшированный ввод — 30 ₽ за миллион токенов; скидка от кэша промптов получается примерно 80×, и правильное её использование — главный рычаг экономии в продакшене.

2. Function calling работает надёжно. Модель вызывает инструменты прямо в разговоре, получает результат как сообщение и продолжает аудио-ответ связно. По нашим замерам, вызов инструмента добавляет 400–800 мс при условии, что сам инструмент отвечает быстрее 200 мс; всё, что медленнее, пользователь слышит как паузу.

3. Определение конца реплики настраивается. По умолчанию работает серверный VAD. Можно переключиться в режим none и управлять репликами с клиента (push-to-talk), либо задействовать семантический VAD, в котором сама модель решает по контексту, закончил ли пользователь говорить. У каждого варианта свои UX-последствия — выбор разбираем в §8.

4. Нативная поддержка WebRTC. Realtime API даёт оба транспорта — WebRTC и WebSocket. WebRTC — правильный выбор для браузеров и мобильных клиентов: вы пропускаете прослойку буферизации WebSocket и получаете воспринимаемую задержку меньше секунды. WebSocket уместнее, когда сервер должен опосредовать соединение ради compliance, наблюдаемости или бизнес-логики.

5. SIP в бете. Можно подключить телефонный номер через SIP-интеграцию OpenAI и поднять голосового агента на линии PSTN, не разворачивая собственный телеком-слой. По нашему опыту это рабочий вариант для небольших задач (ресепшен в стоматологии), но не хватает маршрутизации, записи и пула DID-номеров, которые нужны для контакт-центрового продукта.

Speech-to-speech против chained-пайплайна

Голосовые агенты традиционно выстраивались из трёх моделей — речь-в-текст (STT) вроде Deepgram или Whisper, текстовая LLM и текст-в-речь (TTS) вроде ElevenLabs или Cartesia. Каждый переход добавляет задержку, у каждого свои режимы отказа, а просодия — интонация и эмоция в голосе пользователя — теряется по дороге к LLM.

Realtime API заменяет все три на одну speech-to-speech модель. На вход идёт сырое аудио, на выход — сырое аудио, а рассуждение происходит внутри. Задержка падает, потому что нет ни ожидания финализации STT, ни прогрева TTS; качество просодии растёт, потому что модель слышит эмоцию и сама её воспроизводит.

Бесплатным этот размен не назовёшь. Speech-to-speech модели сложнее отлаживать — текстовое промежуточное представление в них неявное; точность вызова инструментов чуть ниже, чем у chained-пайплайна с текстовой моделью, обученной под tool-use; а голосов у вас меньше — выбор ограничен каталогом OpenAI. Когда важнее клонирование голоса, тонкая настройка просодии или предельно надёжные tool-calls, а не последние 200 мс задержки, chained-пайплайн всё ещё впереди.

WebRTC vs WebSocket vs SIP — выбираем транспорт

У Realtime API три транспортных режима. Каждый чисто ложится на свой кейс, и неверный выбор гарантирует проблемы с задержками или compliance, которые никаким prompt-инжинирингом уже не починить.

В большинстве продакшен-развёртываний мы приходим к схеме LiveKit + WebRTC. Она даёт пользователю задержку WebRTC и одновременно серверный контроль уровня WebSocket: агент крутится в вашей инфраструктуре, открывает WebSocket к OpenAI, опосредует tool-calls, маскирует PII, пишет аудит и пробрасывает аудио пользователю через SFU. Серверной части мы посвятили отдельный плейбук по LiveKit AI Agents.

Эталонная архитектура — как выглядит продакшен

У продакшен-агента шесть слоёв: клиент, edge-медиа, агент-рантайм, API модели, плоскость инструментов и наблюдаемость. Каждый занимается своим делом, а 90 % багов живут на стыках между ними.

Шесть слоёв подробнее

1. Клиент. Браузер, мобильное приложение или телефонная точка. Захват аудио — 16-битный PCM на 24 кГц (нативная частота Realtime API; отправлять 48 кГц — это потерянная полоса и лишняя задержка на ресемплинг). Эхоподавление на клиенте обязательно: без него агент слышит сам себя и постоянно перебивает свою же реплику.

2. Edge / SFU. SFU вроде LiveKit или mediasoup стоит между клиентом и агент-рантаймом. Он отвечает за фан-аут (один пользователь — несколько подписчиков, например, для лайв-коучинга, когда супервайзер слушает разговор), за TURN/STUN для прохождения NAT и за изоляцию между комнатами. Мосты SIP-PSTN заводят телефонию в тот же SFU, и звонящий с телефона подключается к «комнате агента» на тех же правах, что и пользователь из браузера.

3. Агент-рантайм. Долгоживущий процесс — LiveKit Agents, кастомный Node/Python сервис или Pipecat — который забирает аудио из SFU, рулит WebSocket до OpenAI, диспетчеризует tool-calls, маскирует PII и пишет аудит. Здесь живёт ваша бизнес-логика. Здесь же — compliance.

4. API модели. Эндпоинт OpenAI Realtime. Агент-рантайм открывает WebSocket, отправляет session.update с промптом, инструментами и голосом, и начинает стримить аудио. Модель стримит аудио обратно по мере генерации. Никакого «дождёмся целиком» — стрим идёт сразу.

5. Плоскость инструментов. Календарь, CRM, векторное хранилище для RAG, платёжный провайдер, внутренние API. Каждый инструмент описан для модели как JSON-схема; модель в разговоре выбирает один, рантайм его исполняет. Инструменты должны быть идемпотентными (модель может повторить вызов), строго типизированными (модель может галлюцинировать поля) и с аудитом (трейл нужен и для compliance, и для отладки).

6. Плоскость наблюдаемости. Helicone, LangSmith или собственный стек, который пишет каждую сессию: полное аудио, полный транскрипт, все вызовы инструментов, задержку p50/p95 на ход, расход токенов, стоимость сессии. Однажды мы потеряли два дня на отладку продакшен-агента из-за того, что не включили запись аудио — не повторяйте.

Бюджет задержки — как реально уложиться в 800 мс

800 мс voice-to-voice — порог, выше которого разговор начинает заметно тормозить. Люди отвечают примерно за 200 мс; 800 мс — «цифровое, но приемлемое». Выше 1,2 с пользователи начинают говорить поверх агента. Ниже — наш бюджет, по которому мы инженерим целевые 800 мс.

Две ловушки задержки заслуживают отдельного упоминания.

Дрейф в длинных сессиях. И отчёты с форума разработчиков OpenAI, и наши собственные продакшен-данные показывают, что медианная задержка хода растёт примерно с 800 мс в начале сессии до более чем 2 с после 20+ ходов. Лечится подрезанием разговора: либо ротировать сессии каждые 8–12 ходов, перенося контекст в свежую сессию, либо удалять элементы разговора серверной командой и держать активный контекст ограниченным.

Задержка инструментов. Вызов инструмента добавляет к задержке его собственный round-trip. Если запрос в CRM занимает 800 мс, пользователь слышит паузу. Подгружайте часто нужные данные заранее (приветствуйте пользователя уже зная имя), параллельте вызовы, когда модель просит их пачкой, и подумайте о спекулятивных вызовах («скорее всего, дальше понадобится вот это»), пока ещё проигрывается первый ответ.

Модель стоимости — реальная цена минуты, а не заголовок прайса

Цены из заголовка вводят в заблуждение; настоящая стоимость зависит от профиля разговора, доли попаданий в кэш промптов и задержки инструментов. Ниже — рабочая арифметика на примере одного из проектов, выпущенных в этом году.

Опубликованные ставки (gpt-realtime, май 2026): аудио на входе — 2 400 ₽ за миллион токенов, кэшированный аудио-ввод — 30 ₽ за миллион, аудио на выходе — 4 800 ₽ за миллион. Ориентир: 1 минута аудио — это примерно 800–1 200 входных токенов и 1 500–2 000 выходных, в зависимости от темпа речи. То есть типовая минута общения стоит около 4,5 ₽ на вход + 18 ₽ на выход = 22,5 ₽ — без учёта кэша.

Пример из практики: AI-ресепшен для стоматологии. 800 звонков/мес., в среднем 4 минуты на звонок, 60 % времени говорит агент, 40 % — пользователь. Получается примерно 800 × 4 = 3 200 минут разговоров. Стоимость аудио на входе: 3 200 × 0,4 × 4,5 ₽ = 5 700 ₽. Стоимость аудио на выходе: 3 200 × 0,6 × 18 ₽ = 34 500 ₽. Без кэша — 40 300 ₽/мес. С кэшем промптов на системные инструкции и схемы инструментов (кэш в 80× дешевле) входной расход падает примерно на 90 % — до 600 ₽, итого 35 100 ₽. Прибавьте ~2 250 ₽ на телефонию (Twilio или OpenAI SIP), 3 750 ₽ на слой LiveKit/SFU при self-hosting — и выходите примерно на 41 200–45 000 ₽/мес. all-in.

Экономика на звонок: 41 200 ₽ / 800 звонков = 51,7 ₽ за звонок. Стоматология платит живому администратору на ту же ночную смену примерно 1 500–1 875 ₽/час, и агент окупится, даже если возьмёт всего 20 % звонков вне рабочих часов.

Точка перехода против Vapi/Retell. Заголовок Vapi — 3,7–8,2 ₽/мин платформенной комиссии, но all-in (с предпочитаемой связкой LLM, TTS, STT) выходит 15–26,2 ₽/мин — сопоставимо с нашим. У Retell прозрачнее: 5,2 ₽/мин платформа плюс 0,4–4,5 ₽ за LLM. Ниже ~10 000 минут в месяц платформенные сборы и более простая операционка делают Vapi/Retell дешевле. Выше ~10 000 минут связка OpenAI Realtime + LiveKit Agents обгоняет обоих, потому что вы убираете платформенный слой целиком — токенная база у всех одинаковая, но платформенная маржа остаётся у вас.

Прерывания, barge-in и определение конца реплики

Голосовой агент, который не умеет работать с прерываниями, кажется роботом через 30 секунд и невыносимым через три минуты. Три понятия, которые нужно правильно реализовать: voice activity detection (VAD), определение конца реплики и barge-in cancellation.

1. Voice activity detection. Базовый слой — говорит ли пользователь прямо сейчас? Realtime API даёт серверный VAD с настраиваемым порогом. Снизите порог — посыпятся ложные срабатывания (агент решит, что пользователь говорит, когда тот просто прокашлялся). Поднимете — агент будет молчать слишком долго перед ответом. В наших развёртываниях мы держим порог около 0,5 и через аудит-лог следим за частотой ложных срабатываний.

2. Определение конца реплики. Пользователь договорил или просто сделал паузу? Наивный VAD с окном тишины 500 мс перебивает медленных говорящих; окно в 1,5 с быстрым кажется тормозным. Семантическое определение конца реплики — когда сама модель по контексту решает, что пользователь закончил, — устойчивее, но добавляет 100–200 мс. Сегодня его предлагают AssemblyAI, LiveKit и OpenAI; на клиентских развёртываниях мы используем именно его и миримся с задержкой.

3. Barge-in cancellation. Когда пользователь начинает говорить посреди реплики агента, агент должен немедленно замолчать, выкинуть буфер уже отправленного аудио и слушать. Realtime API поддерживает событие response.cancel, которое делает это на сервере; клиент при этом обязан остановить и собственное воспроизведение уже принятого аудио. Незакрытый клиентский буфер — самый частый баг в прерываниях, который мы чиним на прототипах.

Tool-calls и оркестрация побочных эффектов

Голосовой агент, который умеет только говорить, — это демо. Продакшен-агент вызывает инструменты: записывает на приём, ищет клиентов, проводит платежи, ходит в базы знаний. Три правила из практики:

1. Инструменты — детерминированные, идемпотентные, со временем отклика. Модель может повторить вызов инструмента. Модель может по ошибке вызвать один и тот же инструмент дважды подряд. Модель может передать слегка некорректный аргумент. Каждый из этих случаев в продакшене происходит еженедельно. Реализация инструмента обязана валидировать каждый аргумент, возвращать чётко определённые ошибки и укладываться в 800 мс — либо стримить статус «работаю над этим», который агент озвучит.

2. Подгружайте частый контекст заранее. Если пользователь авторизован, агент уже знает его имя, ID и недавнюю активность. Прокидывайте это в системные инструкции при старте сессии — не заставляйте модель вызывать get_user_info при каждом приветствии. Одна эта оптимизация срезала 600 мс задержки на тренажёре для продажников, который мы выпустили.

3. Аудитьте каждый вызов. Compliance, отладка и продуктовая аналитика — всем нужен трейл. Логируйте JSON аргументов, ответ, задержку и контекст решения модели. Helicone или LangSmith делают это почти бесплатно; собственный решение — это спринт, и для HIPAA-задач он того стоит.

Подвох с HIPAA, о котором никто не говорит

По состоянию на май 2026 года аудио-модальность OpenAI Realtime API не покрывается стандартным Business Associate Agreement (BAA) ни OpenAI, ни Microsoft Azure. Текстовый сервис Azure OpenAI — HIPAA-совместим. Путь «аудио в, аудио из» — нет. Сама Microsoft пишет об этом прямо: аудио-модальность Realtime API в списке HIPAA-совместимых сервисов отсутствует, передавать или обрабатывать через неё PHI до её формального добавления нельзя.

Если вы строите голосового агента для здравоохранения, у вас есть три варианта:

1. Гибридный пайплайн. Прогоняйте аудио через HIPAA-совместимый STT (Azure Speech с BAA, Google Cloud Speech-to-Text с BAA, AWS Transcribe Medical), отдавайте редактированный текст GPT-4 (Azure под BAA), а затем — обратно через HIPAA-совместимый TTS (Azure Speech, Google TTS, AWS Polly). Speech-to-speech-задержка теряется, но цепочка BAA — целая. Именно так была устроена наша телемедицинская связка 2025 года.

2. Self-hosted всё. HIPAA-совместимая пара STT/TTS (Whisper.cpp в собственном VPC, Coqui или XTTS для голоса) плюс LLM Azure OpenAI на private endpoint. Полная задержка выше (типично 1,2–1,8 с), зато вы контролируете каждый байт, и цепочка BAA не рвётся.

3. Подождать — и пока запустить агента, не касающегося PHI. Если задача — записывать на приём в клинике, а в разговоре никогда не всплывают диагнозы или симптомы, можно стартовать на Realtime API и в политике конфиденциальности явно зафиксировать, что PHI не собирается. Мы так делали для двух стоматологий — агент назначает и переносит визиты, ни разу не обсуждая медицинскую часть.

Для телемедицинских клиентов мы по умолчанию используем гибридный пайплайн. Архитектура BAA подробно разобрана в нашем гайде по HIPAA-совместимым видеоплатформам, и те же паттерны применимы к голосовым агентам.

OpenAI Realtime vs Vapi vs Retell vs LiveKit Agents

В 2026 году к голосовому агенту ведут четыре серьёзных пути. Вот как они реально соотносятся по стоимости, контролю и времени до релиза.

Практическая эвристика: если вы ниже 10 тыс. минут в месяц и проверяете product-market fit — стартуйте на Vapi или Retell. Переходите на OpenAI Realtime + LiveKit, когда (а) переросли по объёму, (б) нужен контроль над SFU-слоем (видео + голос в одной комнате) или (в) хотите встроить голосового агента в собственную платформу.

Мини-кейс — AI-ресепшен за 8 недель

В конце 2025 года к нам пришла американская стоматологическая группа из семи клиник: нужно было заменить службу приёма звонков в нерабочее время. Сервис стоил 360 000 ₽/мес., в пиковые праздничные периоды терял около 22 % звонков и не давал никакой структурированной выдачи — записи на приём фиксировали на бумаге и наутро вбивали вручную.

Сборка за 8 недель. Недели 1–2: дискавери, проектирование сценария разговора, проработка интеграций (система записи NexHealth, Twilio для телефонного номера). Недели 3–4: агент-рантайм на LiveKit Agents, который ходит в OpenAI Realtime по WebSocket; три инструмента (find_appointment_slots, book_appointment, escalate_to_human). Недели 5–6: работа над промптом, тестирование акцентов и крайних случаев на синтетических звонках. Недели 7–8: shadow-развёртывание за действующим сервисом, затем полный переход с резервным окном на 4 рабочих часа.

Результаты за 90 дней. 1 100 звонков/мес., 86 % завершены без передачи человеку, средняя длительность звонка — 3,4 минуты. Стоимость одного звонка упала с ~300 ₽ (амортизация прежнего сервиса) до 53,2 ₽. Оценка удовлетворённости пациента (SMS-опрос после звонка) выросла с 3,7/5 (старый сервис) до 4,4/5 (агент). Стоматологическая группа уже разворачивает решение ещё в двух клиниках и попросила добавить агента для исходящих звонков по неоплаченным страховым балансам. Хотите такой же — расскажем, как это уложится под вашу отрасль.

Фреймворк решения — выбираем gpt-realtime по пяти вопросам

В1. Касается ли разговор PHI или других регулируемых данных? Если да — аудио-модальность Realtime пока вне игры на аудио-пути. Используйте chained-пайплайн с HIPAA-совместимыми STT/TTS или ограничьте сценарий так, чтобы PHI не появлялись вовсе. Не делайте вид, что разрыва BAA нет.

В2. Какой объём планируете через 12 месяцев? Ниже 10 тыс. минут/мес. Vapi или Retell релизятся быстрее, и разница в стоимости несущественна. Выше 10 тыс. — OpenAI Realtime + LiveKit отбивает дополнительное время на интеграцию за квартал.

В3. Где пользователь — браузер, мобильное приложение или телефон? Браузер/приложение — транспорт WebRTC. Телефон — SIP (или Twilio + WebRTC). Выбор транспорта тянет за собой остальную архитектуру.

В4. Насколько плотно голос связан с видео? Если агент — часть видеовстречи (тренажёр для продажника, AI-модератор, ассистент на лекции), почти наверняка вам нужен LiveKit или mediasoup как SFU и агент в качестве участника комнаты. Если голос — только на телефонной линии, стек можно делать тоньше.

В5. Нужен клонированный голос? Если да — chained-пайплайн с ElevenLabs или Cartesia выигрывает: Realtime API клонирование пока не отдаёт. Если устраивает один из каталожных голосов OpenAI (Alloy, Echo, Fable, Onyx, Nova, Shimmer, Marin, Cedar) — Realtime остаётся лучшим выбором.

Чего не стоит делать

1. Пропустить эхоподавление на клиенте. Без нативного AEC агент слышит собственное аудио через микрофон пользователя, принимает его за речь и перебивает сам себя. Всегда включайте платформенное AEC (по умолчанию у WebRTC в браузерах, AudioSession на iOS/Android). Мы как-то потеряли два дня на отладку «агент говорит сам себе наперебой» — оказалось, AEC выключен в audio constraints.

2. Дать контексту разговора расти бесконтрольно. Длинные сессии тормозят (см. §6 про дрейф) и стоят дороже (каждый ход тянет с собой предыдущий контекст). Ротируйте сессии, удаляйте элементы разговора или каждые N ходов сжимайте старые в одно компактное системное сообщение.

3. Считать инструменты «недоверенными» только на уровне схемы. Модель умеет выдавать технически валидный JSON, который семантически неверен. Валидируйте и на уровне бизнес-логики: даты записи в прошлом, суммы платежа выше разумного порога, ID клиента из чужого тенанта. Мы добавляем policy-проверку перед каждым инструментом, который трогает деньги или PII.

4. Забыть про маскирование в аудит-логе. Записывать каждый транскрипт и каждый аудиофайл — отлично для отладки. И одновременно — нарушение GDPR/HIPAA, если в них попадает PII или PHI, а политика хранения — «вечно». По умолчанию ставьте retention 30 дней; маскируйте email, телефоны, номера карт и SSN на этапе записи.

5. Считать, что демо — это уже продакшен. 5-минутное демо на офисном оптоволокне в понедельник в 9 утра выглядит прекрасно. Тот же агент в пятницу в 19 часов на 4G в шумном автомобиле — другой продукт. До запуска тестируйте синтетическими звонками с потерями пакетов, джиттером и фоновым шумом.

Какие метрики измерять

Качество. Voice-to-voice задержка p50 (цель: < 800 мс) и p95 (цель: < 1,4 с). Word error rate агентского STT (цель: < 8 % на чистом аудио, < 15 % на шумном). Доля успешных вызовов инструментов (цель: > 96 %). Флаги галлюцинаций — частота, с которой агент придумывает факты, отсутствующие в ответах инструментов (цель: < 1 %, измеряется на периодической выборке).

Бизнес. Containment rate — доля звонков, завершённых без передачи человеку (цель: 75 %+ для базовой поддержки, 85 %+ для записи на приём). Среднее время обработки звонка. Стоимость на одну успешно завершённую беседу (цена за минуту, делённая на containment rate). Оценка удовлетворённости из опроса после звонка.

Надёжность. Доля успешных установлений сессии (цель: 99,5 %). Среднее время восстановления после транзитных ошибок OpenAI (цель: < 2 с — от ошибки до момента, когда агент возобновил разговор). Доля успешной доставки записей в аудит-лог (цель: 100 %; пропавшие логи — это compliance-инцидент, что бы там ни почувствовал клиент).

Когда НЕ брать OpenAI Realtime

Жёсткий потолок стоимости меньше 7,5 ₽/мин. Даже с кэшем продакшен-стоимость на Realtime приходит к 18–26,2 ₽/мин all-in. Если экономика проекта требует < 7,5 ₽/мин, остаётся только chained-пайплайн с self-hosted Whisper, текстовым GPT-4o-mini и более дешёвым TTS (Cartesia, OpenVoice). Вы теряете преимущество speech-to-speech по задержке и просодии, но стоимость моделей примерно вдвое ниже.

Мульти-вендорная стратегия — жёсткое требование. Если закупки требуют сохранять опции среди OpenAI, Anthropic, Google и других — не запирайте аудио-путь в Realtime. Chained-пайплайн позволяет менять LLM, не переписывая аудио-поверхность. Используйте Pipecat или LiveKit Agents с независимым от провайдера вызовом LLM.

HIPAA-уровень для медицинского аудио. Уже разобрано выше — аудио-модальность не в списке BAA по состоянию на май 2026. Если уверены, что разговор не касается PHI, можно стартовать; иначе — гибридный пайплайн.

Полностью on-premise развёртывание. Realtime API — это хостинг-сервис. Если LLM обязан крутиться внутри вашего ЦОДа (оборонные, банковские, отдельные госзаказчики), Realtime использовать нельзя; берите self-hosted Llama/Qwen с chained-пайплайном.

FAQ

Соответствует ли OpenAI Realtime API требованиям HIPAA?

По состоянию на май 2026 года — нет. BAA от Microsoft и OpenAI покрывают текстовые эндпоинты Azure OpenAI, но аудио-модальность Realtime API в HIPAA-список явным образом не включена. Если строите голосового агента в здравоохранении, используйте chained-пайплайн с HIPAA-совместимыми STT и TTS (Azure Speech, Google Cloud STT/TTS, AWS Transcribe Medical) и текстовой LLM под BAA — либо проектируйте сценарий так, чтобы PHI не появлялись.

Какова реальная стоимость минуты в продакшене?

Заголовок прайса — 2 400 ₽ за миллион входных и 4 800 ₽ за миллион выходных аудио-токенов, что при типовом разделении 60/40 (агент/пользователь) даёт около 22,5 ₽/мин. Включите кэш промптов на системные инструкции и схемы инструментов — входная часть упадёт примерно на 90 %. Прибавьте инфраструктуру (LiveKit/SFU, телефонию, если нужно), и итог обычно укладывается в 18–26,2 ₽/мин all-in — в зависимости от того, насколько разговорчив агент.

Можно ли использовать OpenAI Realtime со своей SIP/PSTN-инфраструктурой?

Да. Два пути. Путь A: нативная SIP-интеграция OpenAI (в бете) — подключаете телефонный номер напрямую. Подходит для небольших объёмов и простых голосовых агентов; нет маршрутизации, записи, пула DID. Путь B: Twilio или Telnyx терминируют звонок в вашу LiveKit-комнату, и агент участвует в ней как обычный WebRTC-клиент. Это продакшен-паттерн для любых задач уровня контакт-центра.

Как удержать задержку низкой в длинных сессиях?

У Realtime API есть прогрессирующий дрейф задержки в долгих сессиях — это документируется на форуме OpenAI и подтверждается нашими продакшен-данными. Два средства: (1) ротировать сессии каждые 8–12 ходов, перенося контекст в свежую сессию; (2) подрезать историю серверной командой conversation.item.delete, оставляя только несколько последних ходов плюс краткое резюме предыдущих.

Когда лучше брать Vapi или Retell?

Когда вы ниже 10 000 минут в месяц, в команде меньше трёх инженеров, нужно зарелизиться за 2–3 недели или голосовой агент — побочная функция к основному продукту. Платформенный сбор оплачивает оркестрацию, телефонию, мониторинг, инструментарий для prompt-flow и круглосуточную операционку — всё это самим строить недёшево. Выше 10 тыс. минут/мес. либо при кастомных интеграциях связка OpenAI Realtime + LiveKit догоняет и обходит.

Как правильно обрабатывать прерывания?

Три вещи. Во-первых, включите нативное эхоподавление на клиенте — без него агент слышит свой голос и перебивает сам себя. Во-вторых, отправляйте response.cancel в момент, когда детектируете речь пользователя, чтобы модель прекратила генерацию. В-третьих, очищайте клиентский буфер аудио — модель часто стримит на несколько сотен миллисекунд вперёд того, что услышал пользователь, и этот буфер нужно сбросить немедленно.

Поддерживается ли клонирование голоса?

По состоянию на май 2026 — нет. Realtime API даёт фиксированный каталог голосов (Alloy, Echo, Fable, Onyx, Nova, Shimmer, Marin, Cedar). Если клонирование голоса — жёсткое требование, используйте chained-пайплайн с ElevenLabs (лучшее качество), Cartesia (минимальная задержка) или self-hosted XTTS (без поминутной платы, но качество компромиссное).

Сколько обычно занимает продакшен-сборка?

Для сфокусированного сценария (AI-ресепшен, тренажёр для продаж, запись на приём) — 6–10 недель силами одного сеньор-инженера, одного middle и part-time PM. Дискавери и проектирование — 1–2 неделя; агент-рантайм и первый end-to-end звонок — 3–4 неделя; работа над тоном, крайними случаями и надёжностью инструментов — 5–7 неделя; shadow-развёртывание и переход — 8–10 неделя. Для здравоохранения с chained-пайплайном добавьте 2–3 недели на BAA-совместимое аудио.

Читать дальше

Готовы запустить голосового агента за 8 недель?

gpt-realtime — правильный выбор, когда важны задержка и просодия, объём оправдывает операционную надстройку, а данные не содержат PHI. Ниже 10 тыс. минут в месяц или с HIPAA в зоне видимости ответ меняется — иногда это Vapi или Retell, иногда chained-пайплайн с HIPAA-совместимыми STT/TTS. Фреймворк из пяти вопросов выше подскажет, где именно вы.

Сама архитектура к этому моменту уже хорошо понятна: клиент, SFU, агент-рантайм, API модели, плоскость инструментов, наблюдаемость. Большая часть инженерного риска живёт на стыках — barge-in, задержка инструментов, дрейф сессии — и каждый из них мы разобрали выше. Дальше — только исполнение.