Как за шест месеца изградихме система в реално време за гласов AI с бърза реакция

При гласовия AI да знаеш кога да заговориш е по-трудно, отколкото звучи. Хората без усилие си предават думата за части от секундата, но предишните системи за гласов AI не успяваха да следват този ритъм. Архитектурата им с редуващи се реплики разчиташе на малки модели, наречени детектори на реплики, които имаха неблагодарна задача: ако отгатнат твърде рано, прекъсват потребителя; ако закъснеят, отговорът се усеща муден. Едва след като детекторът вземеше решение, много по-големите езикови модели можеха да започнат работа.

GPT‑Live⁠, нашата гласова система от трето поколение, премахва детектора на реплики от аудиомаршрута. Гласовият ѝ модел е пълнодуплексен, което означава, че може да слуша и говори едновременно. Това премахва нуждата от отделен детектор и прави разговора по-непосредствен и естествен. Когато е необходимо по-задълбочено структурирано анализиране или използване на инструменти, GPT‑Live може да се допита и до нашите авангардни модели, като GPT‑5.5, без да прекъсва хода на разговора. Заедно тези възможности дават на GPT‑Live безпрецедентно съчетание от бърза реакция в разговора и интелигентност.

Предоставянето на това изживяване в голям мащаб изискваше нова системна архитектура, оптимизирана за ниска латентност. За разлика от типичната инференция от типа „заявка–отговор“, системата ни предава поточно входящото аудио към гласовия модел и изходящата реч обратно към потребителя, а делегирането се обработва по отделен асинхронен маршрут. През последните шест месеца преработихме инференцията на модела, управлението на контекста и преноса на медии, за да осигурим плавен речеви поток от край до край.

Архитектурата създава и ясна граница между основния гласов маршрут и приложната логика. Това улеснява персонализирането на поведението на приложението, без да се засяга бързината на реакцията. Тази основа задвижва все повече възможности в ChatGPT Voice, включително новата функция за управление на компютъра и координиране на агентите ви в настолното приложение ChatGPT.

В тази публикация ще обясним защо предишните системи с редуващи се реплики не отговаряха на нуждите ни и как проектирахме новата система за бърза реакция на всяко ниво. Ще разгледаме инференцията със състояние, динамичното управление на контекста, асинхронното делегиране и оптимизацията на протоколно ниво, които заедно правят GPT‑Live наистина на живо.

По-ранните гласови архитектури наследиха работата с редуващи се реплики от текстовите големи езикови модели, но всяка реплика беше представена като отделен аудиоблок вместо като текст. В каскадните системи преобразуването на реч в текст, големите езикови модели и преобразуването на текст в реч се изпълняваха последователно. Тази последователност увеличаваше латентността и пренебрегваше сигнали като тона и темпото.

Моделите за реч към реч подобриха този подход, като обработват аудиото директно. Обучението на модела да разбира и генерира реч поначало му позволи да запазва подробности, губещи се при транскрипцията, и да отговаря по-бързо. Системата обаче все още разчиташе на детектора на реплики, за да реши кога може да започне инференцията. Моделът поемаше по-голяма част от взаимодействието, но то оставаше основано на редуващи се реплики.

GPT‑Live поставя гласовия модел начело на разговора: аудиото влиза и излиза от модела, а по-задълбоченото структурирано анализиране и използването на инструменти протичат асинхронно. Основната задача на системата е да поддържа непрекъснат медиен цикъл. Останалата работа, като извикването на авангардни модели и съхраняването на разговора, се извършва извън маршрута на живо.

Поддържането на този медиен цикъл без прекъсване невинаги е лесно. Всяко забавяне при преноса, обработката или инференцията може да се превърне в доловима пауза или звуков артефакт. Предишната система на редуващи се реплики можеше да понесе известни разлики във времето на пристигане на аудиоблока. Медийната система на живо обаче трябва да доставя всеки аудиокадър навреме.

Предишната ни работа по ChatGPT Voice и 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 (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 едновременно към съществуващото изживяване с разширен гласов режим и към новата ни система. Разширеният гласов режим продължи да обслужва потребителите както обикновено, а паралелният маршрут изпълняваше инференция в режим само за четене. Така системата беше изложена на реални клиенти, мрежи, продължителности на сесиите и географско разпределение, без да се променя това, което чуваха потребителите.

Един от първите изводи беше, че капацитетът не може да се сведе до производителността на графичните процесори. Гласовите сесии остават отворени и изпращат кадри непрекъснато, затова обработчиците на потоци от страна на процесора, опашките и мрежовите маршрути трябва да се мащабират заедно с инференцията. При реално натоварване спомагателен компонент достигна пределния си капацитет по-рано от прогнозите на тестовете ни, което доведе до натрупване на заявки за инференция и допълнително увеличаване на латентността. Променихме въпроса за капацитета от „Колко заявки може да обработи един графичен процесор?“ на „Колко едновременни сесии може да поддържа системата, така че всеки кадър да се обработва навреме?“

Тестът показа също, че географското разположение е фактор от първостепенно значение. Насочването на сесия към отдалечен капацитет може да добави забавяне в няколко момента при стартирането и поточното предаване. Започнахме да проверяваме внедряването на модели заедно с регионалния капацитет и конфигурацията за насочване на трафика, след което да анализираме латентността според географския източник. Преместването на инференцията по-близо до потребителите помогна, но затвърди и по-общия извод: бързата реакция от край до край зависи от всяка услуга по маршрута, а не само от сървъра на модела.

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

Накрая, тестването в реална среда ни принуди да подобрим наблюдаемостта и контрола върху внедряването. Открихме показатели, които смесваха различни източници на латентност, табла, чиито обобщени данни скриваха отделни неизправни машини, и разминавания в конфигурацията между тестваните и внедрените системи. В отговор добавихме по-подробна телеметрия, проверка спрямо доказано работещи конфигурации, поетапно увеличаване на натоварването и възможност за бързо изолиране или деактивиране на отделни маршрути. Безшумният тест се превърна в ранна репетиция за пускането — не само за това колко трафик може да поеме системата, но и колко бързо можем да откриваме и ограничаваме неизправностите и да се възстановяваме след тях.

Мащабирането на GPT‑Live до нивото на ChatGPT изискваше изцяло нова система, изградена около един основен принцип: гласът трябва да тече свободно. Поточната инференция непрекъснато подава аудио към пълнодуплексния модел. Специализиран медиен маршрут осигурява надеждно доставяне на кадрите. Асинхронното делегиране позволява по-задълбоченото мислене да протича паралелно. Оптимизираният пренос осигурява бърза реакция по целия път до потребителя.

Архитектурата зад GPT‑Live вече се превръща в по-широка платформа за взаимодействие в реално време. Тя задвижва ChatGPT Voice, който се разраства от разговор към координация между агенти, и ще бъде в основата на предстоящия API за GPT‑Live. С времето тя ще позволи гласовите изживявания да обхванат повече устройства, приложения и модалности, без да губят непосредствеността, която прави гласовия разговор жив.

Ако искате да решавате подобни инженерни проблеми, присъединете се към екипа ни⁠.