Як за шість місяців ми створили систему реального часу для голосового ШІ

Для голосового ШІ визначити, коли слід говорити, складніше, ніж здається. Люди без зусиль передають слово одне одному за частку секунди, але попередні голосові системи ШІ не встигали за цим ритмом. Їхня архітектура з почерговою взаємодією покладалася на невеликі моделі — детектори завершення репліки. Вони мали невдячне завдання: визначиш момент зарано — переб’єш користувача; запізно — відповідь здаватиметься загальмованою. Значно більша LLM могла почати роботу лише після рішення детектора.

GPT‑Live⁠, наша голосова система третього покоління, усуває детектор завершення репліки з аудіотракту. Її голосова модель повнодуплексна, тобто може слухати й говорити одночасно. Це усуває потребу в окремому детекторі й робить розмову безпосереднішою та природнішою. Коли потрібні глибші міркування або інструменти, GPT‑Live може звертатися до наших передових моделей, як-от GPT‑5.5, не перериваючи розмови. Разом ці можливості надають GPT‑Live безпрецедентне поєднання швидкої реакції в розмові та інтелектуальності.

Щоб реалізувати ці можливості у великому масштабі, знадобилася нова системна архітектура, оптимізована для низької затримки. На відміну від звичайного інференсу за схемою «запит — відповідь», наша система потоково передає вхідне аудіо до голосової моделі, а згенероване мовлення — назад користувачеві, тоді як делегування відбувається окремим асинхронним шляхом. За останні шість місяців ми переробили інференс моделі, керування контекстом і передавання медіа, щоб мовлення безперешкодно проходило через усю систему.

Ця архітектура також створює чітку межу між основним голосовим контуром і логікою застосунку. Завдяки цьому поведінку застосунку легко налаштовувати, не впливаючи на швидкість реакції. Ця основа забезпечує дедалі більше можливостей ChatGPT Voice, зокрема нещодавно запущене керування комп’ютером і координацію агентів у настільному застосунку ChatGPT.

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

Попередні голосові архітектури успадкували почерговий характер текстових LLM, але кожна репліка була представлена окремим аудіоблоком, а не текстом. У каскадних системах розпізнавання мовлення, LLM і синтез мовлення виконувалися послідовно. Така послідовність збільшувала затримку й ігнорувала сигнали на кшталт тону та темпу мовлення.

Моделі «мова-в-мову» поліпшили цей підхід завдяки безпосередній обробці аудіо. Навчання моделі безпосередньо розуміти й генерувати мовлення дало змогу зберігати деталі, що губляться під час транскрибування, і відповідати швидше. Проте система й далі покладалася на детектор завершення репліки, який визначав, коли можна починати інференс. Модель опрацьовувала більшу частину взаємодії, але вона все одно залишалася почерговою.

GPT‑Live передає керування розмовою голосовій моделі: аудіо безперервно надходить до моделі й виходить із неї, а глибші міркування та використання інструментів відбуваються асинхронно. Головне завдання системи — підтримувати безперервний медіацикл. Інша робота, як-от звернення до передових моделей і збереження розмови, виконується поза контуром реального часу.

Підтримувати цей медіацикл безперервним не завжди просто. Будь-яка затримка під час передавання, обробки чи інференсу може перетворитися на чутну паузу або спотворення. Попередня система з почерговою взаємодією могла витримувати певні відхилення в часі надходження аудіоблоку. Однак система живого передавання медіа має доставляти кожен аудіокадр вчасно.

Попередня робота над ChatGPT Voice і Realtime API створила для нас важливу основу. Ми вже перебудували свою голосову інфраструктуру⁠, щоб передавати аудіо й відео потоками безпосередньо до наших систем і з них із нижчою та передбачуванішою затримкою. GPT‑Live розвинув цю архітектуру: медіа передається потоком аж до моделі через нову систему інференсу зі збереженням стану, створену для безперервних розмов.

Однак потоковий інференс був лише частиною рішення. Для надійної роботи у виробничому середовищі потрібно було також забезпечити доставлення аудіо від клієнта до стеку інференсу та розв’язати проблеми, пов’язані зі збереженням стану.

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

Таке розділення також створює в системі чітку межу для налаштування. Застосунки можуть змінювати свої інструменти, правила й поведінку бекенду, не впливаючи на медіафронтенд, що відповідає за безперервне передавання аудіо. Контур реального часу залишається компактним, передбачуваним і зосередженим на роботі, яку потрібно виконувати негайно.

Медіафронтенд і логіку інференсу ми написали мовою Go, замінивши попередню реалізацію на Python із asyncio. Це значно підвищило плавність доставлення кадрів: показник p95 нової системи зрівнявся з p50 попередньої.

WebRTC слугує транспортною основою. Цей протокол призначений для медіа з низькою затримкою й може продовжувати роботу в разі втрати пакетів, розсинхронізації годинників і змін підключення клієнта. Якщо пакети надходять із запізненням, WebRTC може непомітно розтягнути аудіо, щоб запобігти розривам, а потім ненадовго прискорити відтворення й наздогнати реальний час.

Мінімізуючи буферизацію та блокування в усій системі, ми забезпечуємо реакцію менш ніж за секунду — саме такої швидкості люди очікують від розмови.

Інференс зі збереженням стану має власні експлуатаційні компроміси. Голосовий сеанс може довго залишатися активним, але його контекст постійно зростає, а екземпляри моделі запускаються й вимикаються залежно від попиту.

Щоб розв’язати ці проблеми, ми створили механізм непомітного перемикання між екземплярами моделі. Коли потрібен перехід, ми можемо прогріти новий екземпляр моделі паралельно з наявним, попередньо заповнити його поточним контекстом сеансу, виконувати інференс на обох одночасно й перемкнутися, щойно новий екземпляр буде повністю готовий.

Той самий базовий механізм підтримує й динамічне ущільнення контексту. З плином розмови накопичений контекст зрештою може перевищити контекстний ліміт моделі. Ущільнення може зменшити контекст до допустимого розміру, але ця операція потребує часу. Оскільки вона змінює попередній контекст, то також робить недійсним кеш ключів і значень (KV) моделі, де зберігаються ключі та значення уваги з раніше оброблених токенів. Відновлення цього стану потребує нового попереднього заповнення, що спричиняє додаткову затримку.

Натомість ми розглядаємо ущільнення як ще один керований перехід. Поки початковий екземпляр моделі продовжує розмову, система ущільнює контекст і готує новий екземпляр моделі з оновленим контекстом. Коли цей екземпляр готовий, ми можемо перемкнутися на нього без переривання медіапотоку. Завдяки цьому система підтримує тривалі виклики, виконуючи ущільнення за потреби.

Ресурсомістка робота виконується поза контуром реального часу, тому навіть під час перемикання розмова не збивається з ритму.

Здатність GPT‑Live звертатися до наявних передових моделей надає системі значних можливостей, фактично відокремлюючи «розмову» від глибшого «мислення». Але щоб ця архітектура з двох моделей сприймалася як єдина система, потрібно було розв’язати дві пов’язані інженерні проблеми.

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

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

Перша оптимізація — підготувати передову модель і всі потрібні їй інструменти ще до запиту на делегування. На початку голосового сеансу сервер застосунку створює сеанс інференсу для передової моделі й попередньо заповнює його початковим контекстом розмови, щоб запит був повністю оброблений до першого делегованого звернення.

Потім ми зберігаємо цей сеанс інференсу протягом усієї голосової розмови й використовуємо стабільне закріплення наступних запитів за ним. Разом із кешуванням запитів ці методи зменшують затримку, водночас даючи змогу легко відновитися після збою робочого процесу.

Зусилля на міркування, обмеження виводу, схеми інструментів і цикли взаємодії моделі з інструментами також впливають на час отримання корисного результату, тому ми відрегулювали ці параметри для швидших відповідей. Мінімізувавши обсяг роботи на шляху делегування, ми дали голосовій моделі змогу швидко долучати результати наших передових моделей.

Хоча голосова модель працює з безперервними потоками мовлення, багато навколишніх систем досі оперують репліками користувача й асистента, зокрема інтерфейс розмов ChatGPT і частини нашої інфраструктури аналітики та безпеки. Тому сервер застосунку розділяє взаємно накладену й подекуди неоднозначну розмову на окремі повідомлення.

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

Одночасне мовлення ускладнює це завдання. Коротке підтвердження від асистента, поки говорить користувач (наприклад, “mm hmm” або “okay”), не обов’язково має ставати окремим повідомленням. Однак змістовна репліка асистента часто має бути окремою. Так само ми віддаємо перевагу зв’язності показаних відповідей асистента, навіть якщо користувач починає говорити посеред відповіді.

Будь-яка політика сегментації передбачає компроміс між оперативністю та певністю. Надто рання фіксація призводить до фрагментованої історії та нестабільного порядку, а надто довге очікування затримує транскрипти й залежні від них функції. Тому система підтримує два пов’язані представлення розмови: попередній вигляд поточного стану й остаточний запис сказаного. Подання розмови в інтерфейсі застосунку підтримує оновлення, тому використовує попередній вигляд. Однак для журналювання в аналітичному конвеєрі потрібен остаточний транскрипт.

Завдяки цьому решта ChatGPT отримує стабільне представлення розмови без нав’язування почерговості в голосовому контурі реального часу.

Швидкість реакції має значення від моменту, коли користувач натискає кнопку. У GPT‑Live система має встановити медіамаршрут і почати подавати аудіо через модель ще до початку розмови. Тому кожна частина послідовності запуску опиняється на критичному шляху.

Як зазначено вище, WebRTC створює надійну основу для роботи в реальному часі, але запуск стандартного сеансу WebRTC потребує несподівано великої кількості протокольних узгоджень і циклів мережевого обміну. WebRTC з’явився до того, як прагнення мінімізувати кількість циклів обміну визначило архітектуру пізніших протоколів, як-от QUIC. Тому під час спільного використання його базові протоколи іноді дублюють роботу. Наприклад, кожен протокол мав власний механізм захисту від DoS, навіть коли в контексті повного стеку WebRTC він був непотрібний.

Ми проаналізували стек і розробили скорочений протокол циклу обміну 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. Вона заздалегідь узгоджує ці параметри без резервування серверних ресурсів і без жодних змін до наявних реалізацій WebRTC.

Instant Connect працює паралельно зі стандартним сигнальним потоком. Якщо попередньо узгоджені параметри дійсні, сервер може створити сеанс після надходження першого медіапакета. Якщо вони застарілі або недійсні, сигнальний обмін уже триває, тож клієнт може перейти до резервного варіанта без додаткової затримки.

Разом Instant Connect і WARP значно скорочують час від наміру користувача до початку живого медіапотоку. Коли обмін SDP вилучено з критичного шляху, а WARP скорочує узгодження транспортного з’єднання, клієнт може запустити сеанс одним пакетом UDP. Сервер може відповісти негайно, а решта системи — почати роботу, яка справді важлива для користувача: слухати й відповідати.

На папері система може здаватися швидкою, але гальмувати під реальним голосовим трафіком. Перш ніж дозволити GPT‑Live спілкуватися з користувачами, ми провели фонове тестування: невелику частку робочих сеансів ChatGPT Voice, яку поступово збільшували, спрямовували одночасно до наявного розширеного голосового режиму й нашої нової системи. Розширений голосовий режим і далі обслуговував користувачів як зазвичай, а тіньовий контур виконував інференс у режимі лише для читання. Так система працювала з реальними клієнтами, мережами, тривалістю сеансів і географічним розподілом, не змінюючи того, що чули користувачі.

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

Тест також показав, що географію слід враховувати насамперед. Спрямування сеансу до віддалених обчислювальних ресурсів може спричинити затримки на кількох етапах запуску й потокової передачі. Ми почали перевіряти розгортання моделей разом із регіональними потужностями й налаштуваннями керування трафіком, а також аналізувати затримку за географією джерела. Перенесення інференсу ближче до користувачів допомогло, але водночас підтвердило ширший висновок: швидкість реакції всієї системи залежить від кожного сервісу на шляху, а не лише від сервера моделі.

Інші збої проявлялися лише протягом реалістичного життєвого циклу сеансу. Тривалі сеанси виявили навантаження на пам’ять і механізми збереження даних. Повторні підключення перевіряли ущільнення та відновлення стану. Звичайні відключення клієнтів виявили стани гонитви в процедурі узгодженого завершення роботи. Ці проблеми рідко виникали під час коротких навантажувальних тестів, оскільки залежали від часу, накопиченого стану та взаємодії на межах сервісів.

Зрештою, тестування у робочому середовищі змусило нас поліпшити спостережуваність і контроль розгортання. Ми виявили метрики, що змішували різні джерела затримки, інформаційні панелі, де агреговані дані приховували окремі несправні рушії, а також розбіжності конфігурацій між протестованими й розгорнутими системами. Тому ми додали детальнішу телеметрію, перевірку за еталонними конфігураціями, поетапне нарощування навантаження та можливість швидко ізолювати або вимикати окремі маршрути. Фонове тестування стало ранньою репетицією запуску: воно показало не лише те, скільки трафіку може прийняти система, а й те, як швидко ми здатні виявити й локалізувати збій та відновити роботу.

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

Архітектура GPT‑Live уже перетворюється на ширшу платформу для взаємодії в реальному часі. Вона забезпечує роботу ChatGPT Voice, що розширюється від розмов до агентної координації, а також стане основою майбутнього API GPT‑Live. Згодом вона дасть змогу охопити голосовою взаємодією більше пристроїв, застосунків і модальностей, не втрачаючи безпосередності, завдяки якій розмова звучить наживо.

Якщо ви хочете розв’язувати такі інженерні завдання, приєднуйтеся до нашої команди⁠.