Как мы за шесть месяцев создали систему реального времени для голосового ИИ с быстрым откликом

Голосовому ИИ сложнее определить, когда вступить в разговор, чем может показаться. Люди без усилий передают друг другу слово за доли секунды, но прежние голосовые ИИ-системы не успевали за таким ритмом. Их архитектура с поочерёдным обменом репликами полагалась на небольшие модели, называемые детекторами конца реплики. Перед ними стояла незавидная задача: если детектор срабатывал слишком рано, пользователя перебивали, а если слишком поздно — ответ казался заторможенным. Только после того, как детектор принял решение, гораздо более крупная LLM могла приступить к работе.

Наша голосовая система третьего поколения GPT‑Live⁠ исключает детектор конца реплики из тракта передачи аудио. Голосовая модель работает в полнодуплексном режиме, то есть может слушать и говорить одновременно. Благодаря этому отдельный детектор конца реплики больше не нужен, а общение ощущается более живым и естественным. Когда требуются более глубокие рассуждения или использование инструментов, GPT‑Live также может обращаться к нашим передовым моделям, таким как GPT‑5.5, не прерывая ход разговора. В совокупности эти возможности обеспечивают GPT‑Live беспрецедентное сочетание быстрого отклика и интеллектуальных возможностей в диалоге.

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

Эта архитектура также чётко разделяет основной голосовой тракт и логику приложения. Это упрощает настройку поведения приложения без ущерба для отзывчивости. Эта основа обеспечивает всё более широкий набор возможностей ChatGPT Разговор, в том числе недавно запущенные функции управления компьютером и координации работы ваших агентов в приложении ChatGPT для компьютера.

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

Более ранние голосовые архитектуры унаследовали от текстовых LLM поочерёдный обмен репликами, но каждая реплика представляла собой отдельный аудиофрагмент, а не текст. В каскадных системах преобразование речи в текст, LLM и преобразование текста в речь выполнялись последовательно. Такая последовательная обработка увеличивала задержку и игнорировала такие сигналы, как тон и темп речи.

Модели преобразования речи в речь усовершенствовали этот подход благодаря непосредственной обработке аудио. Обучение модели непосредственному пониманию и генерации речи позволило ей сохранять детали, которые теряются при транскрипции, и быстрее отвечать. Но система по-прежнему полагалась на детектор конца реплики, который определял, когда можно начинать инференс. Модель обрабатывала больше аспектов взаимодействия, но оно по-прежнему строилось на поочерёдном обмене репликами.

GPT‑Live передаёт голосовой модели управление разговором: аудио поступает в модель и выходит из неё, а более глубокие рассуждения и использование инструментов выполняются асинхронно. Основная задача системы — поддерживать непрерывный контур передачи медиаданных. Другая работа — например, обращение к передовым моделям и сохранение диалога — выполняется вне контура реального времени.

Обеспечить непрерывную работу этого контура передачи медиаданных не всегда просто. Любая задержка при передаче, обработке или инференсе может обернуться слышимой паузой или артефактом. Прежняя система с поочерёдным обменом репликами допускала небольшой разброс во времени поступления аудиофрагментов. Однако система обработки медиаданных в реальном времени должна доставлять каждый аудиокадр точно вовремя.

Работа над ChatGPT Разговор и Realtime API уже заложила для нас важную основу. К тому моменту мы уже перестроили нашу голосовую инфраструктуру⁠, чтобы напрямую передавать аудио и видео в наши системы и обратно с меньшей и более предсказуемой задержкой. В GPT‑Live эта архитектура получила дальнейшее развитие: медиаданные потоково передаются непосредственно в модель через новую систему инференса с сохранением состояния, созданную для непрерывного диалога.

Однако потоковый инференс был лишь частью решения. Чтобы потоковый инференс надёжно работал в рабочей среде, нам также пришлось обеспечить надёжную передачу аудио от клиента к стеку инференса и решить проблемы, связанные с сохранением состояния.

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

Такое разделение также чётко отделяет настраиваемую часть системы. Приложения могут менять инструменты, политики и поведение бэкенда, не влияя на фронтенд обработки медиаданных, который отвечает за непрерывный поток аудио. Контур реального времени остаётся компактным и предсказуемым и выполняет только те операции, которые должны происходить в реальном времени.

Мы написали фронтенд обработки медиаданных и логику инференса на Go, заменив прежнюю реализацию на Python с использованием asyncio. Благодаря этому кадры стали поступать значительно плавнее: p95 новой системы соответствует p50 прежней.

WebRTC лежит в основе транспортного уровня. Он предназначен для передачи медиаданных с низкой задержкой и продолжает работать при потере пакетов, рассинхронизации часов и изменениях соединения на стороне клиента. Если пакеты поступают с задержкой, WebRTC может незаметно растягивать аудио, чтобы избежать разрывов, а затем на короткое время ускорять воспроизведение, чтобы снова догнать реальное время.

Сводя к минимуму буферизацию и блокировки во всей системе, мы обеспечиваем время отклика менее секунды, которого люди ожидают от разговора.

У инференса с сохранением состояния есть свои эксплуатационные особенности и компромиссы. Голосовая сессия может оставаться активной в течение длительного времени, но её контекст непрерывно растёт, а экземпляры модели запускаются и останавливаются в зависимости от спроса.

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

Тот же базовый механизм также поддерживает динамическое сжатие контекста. По мере продолжения диалога его накопленный контекст может в конечном итоге превысить лимит контекста модели. Сжатие контекста может уменьшить размер контекста, чтобы уложиться в ограничение, но эта операция занимает время. Поскольку при сжатии меняется предыдущий контекст, оно также аннулирует кэш ключей и значений модели (KV-кэш), где хранятся ключи и значения механизма внимания из ранее обработанных токенов. Повторное формирование этого состояния требует нового предварительного заполнения, что приводит к дополнительной задержке.

Вместо этого мы рассматриваем сжатие контекста как ещё один управляемый переход. Пока исходный экземпляр модели продолжает общение, система сжимает контекст и подготавливает замещающий экземпляр модели с новым контекстом. Когда этот экземпляр будет готов, мы сможем переключиться на него, не прерывая медиапоток. Это позволяет системе поддерживать длительные вызовы, выполняя сжатие при необходимости.

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

Способность GPT‑Live задействовать существующие передовые модели даёт ему значительные возможности, фактически отделяя «разговор» от более глубокого «мышления». Но чтобы эта архитектура из двух моделей воспринималась как единая система, потребовалось решить две взаимосвязанные инженерные задачи.

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

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

Сначала мы заранее подготавливаем передовую модель и все необходимые ей инструменты — ещё до запроса на делегирование. Когда начинается голосовой сеанс, сервер приложения создаёт сеанс инференса для передовой модели и предварительно заполняет его начальным контекстом разговора, чтобы промпт был полностью обработан до первого делегированного запроса.

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

Глубина рассуждений, лимиты выходных данных, схемы инструментов и циклы обмена между моделью и инструментами также влияют на время получения полезного результата, поэтому мы настроили эти параметры так, чтобы ускорить ответы. Сократив объём работы в контуре делегирования, мы позволили голосовой модели быстро использовать результаты наших передовых моделей.

Хотя голосовая модель работает с непрерывными потоками речи, многие связанные с ней системы по-прежнему работают с отдельными репликами пользователя и ассистента, в том числе интерфейс диалогов ChatGPT и отдельные компоненты инфраструктуры аналитики и безопасности. Поэтому сервер приложения разделяет частично накладывающиеся и порой неоднозначные реплики на отдельные сообщения.

По мере поступления аудио сервер использует частичные расшифровки и временные сигналы, чтобы определить, кто говорит в данный момент, и сформировать очередь сообщений. Последнее сообщение остаётся предварительным: его текст, временные параметры и определение говорящего могут изменяться по мере поступления новых фрагментов речи. Когда человек говорит достаточно долго и сервер уже может надёжно определить говорящего, соответствующее сообщение фиксируется.

Когда люди говорят одновременно, задача усложняется. Короткая реплика ассистента, пока говорит пользователь (например, «угу» или «хорошо»), не всегда должна становиться отдельным сообщением. Однако содержательную реплику ассистента часто следует выделить в отдельное сообщение. Кроме того, мы стремимся сохранять связность отображаемых ответов ассистента, даже если пользователь начинает говорить, не дождавшись окончания ответа.

При любой политике сегментации приходится выбирать между оперативностью и достоверностью. Слишком ранняя фиксация создаёт разрозненную историю и нестабильный порядок сообщений, а слишком поздняя задерживает появление расшифровок и работу зависящих от них функций. Поэтому система поддерживает два взаимосвязанных представления диалога: предварительное представление текущего состояния и окончательную запись сказанного. Представление диалога в интерфейсе приложения поддерживает обновления, поэтому использует предварительные данные. Но для записи в аналитический конвейер требуется итоговая расшифровка.

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

Быстрый отклик должен обеспечиваться уже с момента нажатия кнопки. При использовании GPT‑Live система должна установить тракт передачи медиаданных и начать подавать аудио в модель ещё до начала разговора. Поэтому каждый этап запуска входит в критический путь.

Как отмечалось выше, WebRTC служит надёжной основой для работы в реальном времени, однако для запуска стандартного сеанса WebRTC требуется неожиданно много процедур согласования протоколов и сетевых циклов обмена. WebRTC появился до того, как разработчики стали уделять особое внимание минимизации числа сетевых циклов — подходу, повлиявшему на более поздние протоколы, такие как QUIC. В результате лежащие в его основе протоколы иногда дублируют работу при совместном использовании. Например, каждый протокол включал собственный механизм защиты от DoS, даже когда в контексте полного стека WebRTC в нём не было необходимости.

Мы проанализировали стек и разработали WebRTC Abridged Roundtrip Protocol (WARP⁠(открывается в новом окне)), который сокращает число сетевых циклов, необходимых для запуска медиапотока и передачи данных, с шести до одного. WARP достигает этого с помощью набора обратно совместимых улучшений протокола: встраивания рукопожатия DTLS поверх ICE (SPED⁠(открывается в новом окне)), использования более быстрого рукопожатия DTLS 1.3⁠(открывается в новом окне), предварительного согласования рукопожатия SCTP (SNAP⁠(открывается в новом окне)) и предварительного согласования каналов передачи данных вместо использования DCEP⁠(открывается в новом окне).

Мы разработали WARP как набор открытых спецификаций, работая совместно с участниками сообщества WebRTC, чтобы более широкая экосистема могла воспользоваться результатами этой работы. Мы продвигаем эти предложения в рабочей группе TSVWG при IETF. Поддержка WARP уже добавлена в libwebrtc и Pion, а работа над ней ведётся и в других реализациях WebRTC.

После оптимизации согласования медиапотока оставалась ещё одна заметная задержка: обмен служебными сигналами для передачи параметров SDP до установления соединения WebRTC. Чтобы вывести этот обмен из критического пути, мы разработали решение под названием Instant Connect. Instant Connect заранее согласовывает эти параметры, не резервируя серверные ресурсы и не требуя изменений в существующих реализациях WebRTC.

Instant Connect работает параллельно со стандартным потоком сигнализации. Если заранее согласованные параметры корректны, сервер может создать сеанс при поступлении первого медиапакета. Если параметры устарели или недействительны, сигнальный поток уже запущен, поэтому клиент может перейти на стандартный механизм без дополнительной задержки.

Вместе Instant Connect и WARP значительно сокращают время между действием пользователя и началом передачи медиаданных в реальном времени. Поскольку обмен SDP выведен из критического пути, а WARP сводит транспортное рукопожатие к одному этапу, клиент теперь может начать сеанс с помощью одного UDP-пакета. Сервер может сразу отправить ответ, позволяя остальным компонентам системы начать выполнять работу, которая действительно важна пользователю: слушать и отвечать.

Система может казаться быстрой на бумаге, но зависать под реальной голосовой нагрузкой. Прежде чем GPT‑Live начал общаться с пользователями, мы провели незаметное для них тестирование: небольшую и постепенно растущую долю рабочих сеансов ChatGPT Разговор одновременно направляли и в существующую систему расширенного голосового режима, и в новую систему. Расширенный голосовой режим продолжал работать для пользователей как обычно, а по теневому контуру инференс выполнялся в режиме только для чтения. Так мы испытали систему на реальных клиентских устройствах и сетях, а также при реальной продолжительности и географическом распределении сеансов — при этом пользователи не заметили никаких изменений.

Одним из первых выводов стало то, что производительность системы нельзя оценивать только по пропускной способности GPU. Голосовые сеансы остаются открытыми и непрерывно отправляют кадры, поэтому обработчики потоков на стороне CPU, очереди и сетевые тракты должны масштабироваться вместе с инференсом. При реальной нагрузке вспомогательный компонент достиг насыщения раньше, чем предполагали наши оценки по нагрузочному тестированию, из-за чего запросы на инференс начали накапливаться, а задержка — нарастать. Мы перестали формулировать вопрос о производительности как «Сколько запросов может обработать GPU?» и стали спрашивать: «Сколько одновременных сеансов может выдерживать система, не допуская задержки ни одного кадра?»

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

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

Наконец, тестирование в рабочей среде заставило нас улучшить наблюдаемость и механизмы управления развёртыванием. Мы обнаружили метрики, в которых смешивались разные источники задержки, панели мониторинга, где агрегированные показатели скрывали сбои отдельных движков инференса, а также расхождения между конфигурациями протестированных и развёрнутых систем. В ответ мы добавили более детализированную телеметрию, проверку по заведомо корректным конфигурациям, поэтапное увеличение трафика и возможность быстро изолировать или отключать отдельные контуры. Незаметное для пользователей тестирование стало первой репетицией запуска: оно показало не только то, какой объём трафика могла принять система, но и то, насколько быстро мы могли обнаруживать и локализовать сбои и восстанавливаться после них.

Чтобы масштабировать GPT‑Live до уровня ChatGPT, потребовалась совершенно новая система, построенная вокруг одного основополагающего принципа: голосовой поток не должен прерываться. Потоковый инференс обеспечивает непрерывную подачу аудио в полнодуплексную модель. Выделенный медиапоток обеспечивает надёжную доставку кадров. Асинхронное делегирование позволяет параллельно выполнять более глубокие рассуждения. Оптимизированная передача данных обеспечивает быстрый отклик на всем пути до пользователя.

Архитектура GPT‑Live уже становится более универсальной платформой для взаимодействия в реальном времени. Она обеспечивает работу ChatGPT Разговор, возможности которого расширяются от ведения диалога до координации агентов, и ляжет в основу будущего API GPT‑Live. Со временем эта платформа позволит поддерживать голосовое взаимодействие на большем числе устройств, в приложениях и разных модальностях, сохраняя мгновенный отклик, благодаря которому разговор ощущается живым.

Если вам интересны такие инженерные задачи, присоединяйтесь к нашей команде⁠.