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 пришлось вернуться к цепочке из нескольких компонентов). Цифры, задержки и архитектурные решения в этой статье — из реальных проектов, а не из теоретических рассуждений.

Если вы планируете запустить голосового агента в 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, при котором модель сама определяет по контексту, закончил ли пользователь говорить. У каждого варианта свои последствия для пользовательского опыта — выбор мы подробно разбираем в §8.

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

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

Speech- to-speech против последовательного пайплайна

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

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

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

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

У Realtime API три транспортных режима. Каждый идеально подходит под свой сценарий использования, и неправильный выбор неизбежно приведёт к проблемам с задержками или соответствием требованиям — которые никак нельзя решить с помощью prompt-инжиниринга.

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

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

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

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

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

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

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

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

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

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 при самохостинге — итого около 41 200–45 000 ₽ в месяц «всё включено».

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

Точка перехода против Vapi/Retell. Комиссия Vapi — 3,7–8,2 ₽/мин, но с учётом предпочтительной связки 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-ин отмена. Когда пользователь начинает говорить посреди реплики агента, агент должен немедленно замолчать, сбросить буфер уже отправленного аудио и перейти в режим прослушивания. Realtime API поддерживает событие response.cancel, которое выполняет эту операцию на сервере; клиент при этом обязан остановить воспроизведение уже полученного аудио. Незакрытый клиентский буфер — самая частая ошибка в реализации прерываний, с которой мы сталкиваемся на прототипах.

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

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

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

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

3. Аудитируйте каждый вызов. Соответствие требованиям, отладка и аналитика продукта — всем нужна история действий. Логируйте 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. Гибридный пайплайн. Пропускайте аудио через STT-систему, совместимую с HIPAA (например, Azure Speech с BAA, Google Cloud Speech-to-Text с BAA, AWS Transcribe Medical), передавайте обработанный текст в GPT-4 (через Azure с BAA), а затем — обратно через TTS, также совместимый с HIPAA (Azure Speech, Google TTS, AWS Polly). Задержка при преобразовании речи в речь исчезает, но цепочка с соглашением BAA остаётся целостной. Именно так была построена наша телемедицинская система в 2025 году.

2. Self-hiped всё. HIPAA-совместимая пара STT/ТТС (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 тыс. минут в месяц и проверяете соответствие продукта рынку — начинайте с 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: постепенный запуск параллельно с текущим сервисом, затем полный переход с возможностью отката на 4 рабочих часа.

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

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

В1. Касается ли разговор PHI или других регулируемых данных? Если да — аудио-обработка в реальном времени пока недоступна. Используйте последовательный пайплайн с 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. Нужен клонированный голос? Если да — пайплайн с 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 клиента из чужого тенанта. Перед каждым инструментом, который работает с деньгами или персональными данными, мы добавляем проверку политик.

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

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

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

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

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

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

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

Жёсткий потолок стоимости — меньше 7,5 ₽/мин. Даже с кэшем реальная стоимость в продакшене на Realtime составляет 18–26,2 ₽/мин all-in. Если проект требует расходов ниже 7,5 ₽/мин, остаётся только цепочка из 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, с пайплайном на основе chaining.

FAQ

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

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

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

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