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

Кај гласовната ВИ, потешко е отколку што изгледа да се знае кога треба да се зборува. Луѓето без напор си го предаваат зборот за дел од секундата, но претходните гласовни системи со ВИ не можеа да го следат овој ритам. Нивната архитектура заснована на реплики се потпираше на мали модели наречени детектори на реплики, кои имаа незавидна задача: ако погодат прерано, корисникот ќе биде прекинат; ако погодат предоцна, одговорот ќе делува бавно. Дури откако детекторот ќе донесеше одлука, многу поголемите големи јазични модели (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 (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 додека се проширува од разговор кон агентска координација, а ќе биде и основа на претстојниот GPT‑Live API. Со текот на времето, таа ќе овозможи гласовните искуства да опфатат повеќе уреди, апликации и модалитети, без да ја изгубат непосредноста поради која гласовниот разговор делува како да се одвива во живо.

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