Ako sme za šesť mesiacov vybudovali systém v reálnom čase pre responzívnu hlasovú AI

Pre hlasovú AI je vedieť, kedy prehovoriť, ťažšie, než sa zdá. Ľudskí rečníci si bez námahy odovzdávajú slovo v zlomku sekundy, no predchádzajúce systémy hlasovej AI nedokázali držať krok s týmto rytmom. Ich architektúra založená na striedaní replík sa spoliehala na drobné modely známe ako detektory replík, ktoré čelili nezávideniahodnej úlohe: ak odhadli príliš skoro, používateľa prerušili. Ak odhadli príliš neskoro, odpoveď pôsobila zdĺhavo. Až po rozhodnutí detektora sa mohol oveľa väčší model LLM pustiť do práce.

GPT‑Live⁠, náš hlasový systém tretej generácie, odstraňuje detektor replík zo zvukovej cesty. Jeho hlasový model je plne duplexný, čo znamená, že dokáže počúvať aj hovoriť súčasne. Tým odpadá potreba samostatného detektora a konverzácia pôsobí bezprostrednejšie a prirodzenejšie. Keď je potrebné hlbšie uvažovanie alebo použitie nástrojov, GPT‑Live sa môže obrátiť aj na naše prelomové modely, ako je GPT‑5.5, bez prerušenia plynutia konverzácie. Spolu tieto schopnosti dávajú modelu GPT‑Live bezprecedentnú kombináciu konverzačnej pohotovosti a inteligencie.

Poskytovanie tejto používateľskej skúsenosti vo veľkom rozsahu si vyžadovalo novú systémovú architektúru optimalizovanú na nízku latenciu. Na rozdiel od typickej inferencie typu požiadavka-odpoveď náš systém streamuje prichádzajúci zvuk do hlasového modelu a výstupnú reč späť používateľovi, pričom delegáciu spracúva v samostatnej asynchrónnej vetve. Za posledných šesť mesiacov sme prepracovali inferenciu modelu, správu kontextu a prenos médií, aby reč hladko plynula od začiatku až do konca.

Architektúra tiež vytvára jasnú hranicu medzi základnou hlasovou cestou a aplikačnou logikou. Vďaka tomu je jednoduché prispôsobiť správanie aplikácie bez vplyvu na jej odozvu. Tento základ poháňa čoraz širšiu škálu funkcií v rámci modelu Chat GPT Voice vrátane novospustenej možnosti ovládať váš počítač a koordinovať vašich agentov v aplikácii ChatGPT pre stolné počítače.

V tomto príspevku vysvetlíme, prečo predchádzajúce ťahové systémy nedokázali splniť naše požiadavky a ako sme navrhli a vyvinuli nový systém na rýchlu odozvu na každej vrstve. Budeme sa venovať stavovej inferencii, dynamickej správe kontextu, asynchrónnej delegácii a optimalizácii na úrovni protokolu, ktoré spoločne zabezpečujú, aby model GPT‑Live pôsobil naozaj živo.

Staršie hlasové architektúry zdedili povahu striedania replík z textových modelov LLM, pričom každá replika bola zastúpená samostatným zvukovým blobom, nie textom. V kaskádových systémoch prevod reči na text, LLM a prevod textu na reč fungovali postupne za sebou. Táto sekvencia zvyšovala latenciu a ignorovala narážky, ako sú tón hlasu a tempo.

Modely prekladu z reči do reči vylepšili tento prístup priamym spracovaním zvuku. Trénovanie modelu tak, aby natívne rozumel reči a generoval ju, mu umožnilo zachovať detaily, ktoré sa pri prepise strácajú, a rýchlejšie odpovedať. Systém sa však stále spoliehal na detektor prejavov, ktorý rozhodoval o tom, kedy sa môže začať inferencia. Model prevzal väčšiu časť interakcie, ale táto interakcia naďalej prebiehala so striedaním replík.

GPT‑Live zveruje riadenie konverzácie hlasovému modelu: zvuk prúdi do modelu aj z neho, zatiaľ čo hlbšie uvažovanie a používanie nástrojov prebiehajú asynchrónne. Primárnou úlohou systému je udržiavať nepretržitú slučku prehrávania médií. Ďalšia práca, ako napríklad vyvolávanie prelomových modelov a ukladanie konverzácie, prebieha mimo živého procesu.

Udržať túto mediálnu slučku bez prerušenia nie je vždy jednoduché. Akékoľvek oneskorenie pri prenose, spracovaní alebo inferencii sa môže prejaviť ako badateľná pauza alebo artefakt. Predchádzajúci systém založený na ťahoch dokázal tolerovať určitú odchýlku v tom, kedy dorazil zvukový blob. Systém pre živé médiá však musí doručiť každý zvukový rámec načas.

Predchádzajúca práca na modeli Chat GPT Voice a rozhraní Realtime API nám poskytla dôležitý základ. Už sme prestavali našu hlasovú infraštruktúru⁠ tak, aby bolo možné streamovať zvuk a video priamo do našich systémov aj z nich s nižšou a predvídateľnejšou latenciou. GPT‑Live posunul tento návrh ešte ďalej, a to streamovaním médií až priamo do modelu prostredníctvom nového stavového inferenčného systému vytvoreného na nepretržitú konverzáciu.

Inferencia streamovania však bola len časťou riešenia. Aby to dobre fungovalo v produkčnom prostredí, museli sme tiež zabezpečiť spoľahlivý prenos zvuku z klienta do inferenčného zásobníka a vyriešiť problémy súvisiace so stavovosťou.

Jedným z prvých rozhodnutí, ktoré sme urobili, bolo zámerne oddeliť tok médií od aplikačnej a obchodnej logiky. Zvuk sa medzi klientom a hlasovým modelom prenáša po vyhradenej rýchlej trase. Delegovanie, používanie nástrojov a ďalšie aplikačné činnosti prebiehajú za hranicou asynchrónneho RPC. Pomalé vyvolávanie nástrojov alebo backendová služba môžu oneskoriť svoj vlastný výsledok, ale nemôžu zdržať tok médií.

Toto oddelenie zároveň systému poskytuje jasne vymedzenú hranicu na prispôsobenie. Aplikácie môžu meniť svoje nástroje, zásady a backendové správanie bez toho, aby ovplyvnili mediálny frontend, ktorý zabezpečuje plynulý tok zvuku. Živá cesta zostáva úzka, predvídateľná a zameraná na prácu, ktorá musí prebiehať v reálnom čase.

Mediálny frontend a inferenčnú logiku sme napísali v jazyku Go, čím nahradil predchádzajúcu implementáciu v jazyku Python využívajúcu asyncio. To výrazne zlepšilo plynulosť doručovania snímok, pričom hodnota p95 nového systému zodpovedala hodnote p50 predchádzajúceho systému.

WebRTC poskytuje základ pre transport. Je navrhnuté pre médiá s nízkou latenciou a dokáže pokračovať v činnosti aj pri strate paketov, odchýlke hodín a zmenách pripojenia klienta. Ak pakety dorazia oneskorene, WebRTC môže mierne natiahnuť zvuk, aby zabránilo výpadkom, a potom nakrátko zrýchliť prehrávanie, aby dobehlo reálny čas.

Minimalizáciou ukladania do medzipamäte a blokovania v celom systéme dokážeme zabezpečiť odozvu kratšiu ako jedna sekunda, akú ľudia pri konverzácii očakávajú.

Stavová inferencia má svoje vlastné prevádzkové kompromisy. Hlasová relácia môže zostať aktívna dlho, jej kontext sa však neustále rozrastá a inštancie modelu sa podľa potreby spúšťajú a ukončujú.

Na riešenie týchto obáv sme vytvorili plynulý mechanizmus odovzdávania medzi inštanciami modelu. Keď je potrebný prechod, môžeme popri existujúcej inštancii zahriať náhradnú inštanciu modelu, vopred v nej vyplniť aktuálny kontext relácie, spúšťať inferenciu paralelne na oboch zložkách a prepnúť na novú inštanciu, keď bude úplne pripravená.

Ten istý základný mechanizmus podporuje aj dynamickú kompakciu kontextu. Ako konverzácia pokračuje, jej nahromadený kontext môže časom prekročiť limit kontextu modelu. Kompakcia môže zmenšiť kontext tak, aby sa zmestila do limitu, ale operácia chvíľu trvá. A keďže mení predchádzajúci kontext, zároveň zneplatňuje vyrovnávaciu pamäť modelu kľúč-hodnota (KV), ktorá ukladá kľúče a hodnoty mechanizmu pozornosti z predtým spracovaných tokenov. Opätovné vytvorenie tohto stavu vyžaduje nové predbežné vyplnenie, čo spôsobuje dodatočné oneskorenie.

Namiesto toho pristupujeme ku kompakcii ako k ďalšiemu riadenému prechodu. Kým pôvodná inštancia modelu ďalej chatuje, systém vykoná kompakciu kontextu a pripraví náhradnú inštanciu modelu s novým kontextom. Keď bude daná inštancia pripravená, môžeme na ňu prepnúť bez akéhokoľvek prerušenia prehrávania médií. To umožní systému podporovať dlhotrvajúce volania a podľa potreby vykonať kompakciu.

Náročné operácie sa držia mimo živej cesty, takže ani počas odovzdania konverzácia nestratí rytmus.

Schopnosť modelu GPT‑Live vyvolávať existujúce prelomové modely mu dodáva veľkú silu, pretože v podstate oddeľuje „rozprávanie“ od hlbšieho „premýšľania“. Aby však táto architektúra s dvoma modelmi pôsobila ako jeden systém, bolo potrebné vyriešiť dva súvisiace technické problémy.

Po prvé, výsledky sa musia vrátiť dostatočne rýchlo na to, aby boli užitočné v prebiehajúcej interakcii, preto sme museli minimalizovať latenciu v celej ceste delegovania, od smerovania a spracovania príkazu cez inferenciu až po vyvolávanie nástrojov. Zároveň však systémy v iných častiach produktu stále potrebujú samostatné správy, takže sme museli prebiehajúcu konverzáciu znázorniť vo forme, ktorej dokážu porozumieť.

Keď je delegácia odoslaná, optimalizujeme čas do momentu, kým prelomový model nevytvorí niečo užitočné pre konverzáciu. Hlasový model môže krátko udržiavať výmenu v prevádzke, kým prelomový model uvažuje alebo používa nástroje, ale nedokáže skryť ľubovoľne pomalú odozvu. Preto sme celý cyklus delegácie – smerovanie, spracovanie príkazu, inferenciu a vyvolávanie nástrojov – považovali za súčasť časového rozpočtu na odozvu.

Prvou optimalizáciou je nastaviť prelomový model a všetky nástroje, ktoré potrebuje, skôr než sa požiada o delegáciu. Keď sa začne hlasová relácia, aplikačný server vytvorí reláciu inferencie pre prelomový model a vopred v nej vyplní počiatočný kontext konverzácie, čím zabezpečí, že príkaz bol pred prvou delegovanou požiadavkou úplne spracovaný.

Následne ponecháme túto inferenčnú reláciu dostupnú počas trvania hlasovej konverzácie a pre po sebe nasledujúce požiadavky používame stabilnú afinitu relácie. Spolu s ukladaním príkazov do vyrovnávacej pamäte tieto techniky zlepšujú latenciu, pričom zotavenie po zlyhaní pracovníka je naďalej jednoduché.

Intenzita uvažovania, limity výstupu, schémy nástrojov a kolá komunikácie medzi modelom a nástrojom tiež ovplyvňujú, kedy sa v konverzácii dosiahne užitočný výsledok, a tieto parametre sme upravili tak, aby odpovede prichádzali rýchlejšie. Minimalizovaním práce potrebnej v rámci procesu delegácie sme hlasovému modelu umožnili rýchlo začleňovať výsledky z našich prelomových modelov.

Aj keď hlasový model pracuje s nepretržitými prúdmi reči, mnohé systémy okolo neho stále fungujú na základe replík používateľa a asistenta vrátane konverzačného používateľského rozhrania ChatGPT a častí našej analytickej a bezpečnostnej infraštruktúry. Aplikačný server teda rozpletá a rozdeľuje prekrývajúcu sa, občas nejednoznačnú konverzáciu na samostatné správy.

Keď príde zvuk, server použije priebežné prepisy a časové signály na určenie toho, ktorý hovoriaci má práve slovo, a na zostavenie frontu správ. Najnovšia správa zostáva predbežná. Jej text, načasovanie aj priradenie hovoriaceho sa môžu meniť s pribúdajúcou rečou. Keď má hovoriaci slovo dosť dlho na to, aby bolo priradenie hovoriaceho spoľahlivé, server finalizuje príslušnú správu.

Prekrývanie hovoriacich to komplikuje. Stručné potvrdenie od asistenta, kým používateľ hovorí (napr. „uhm“ alebo „dobre“) nemusí nevyhnutne tvoriť samostatnú správu. Avšak významný vstup asistenta by často mal. Podobne uprednostňujeme kohéziu zobrazených odpovedí asistenta, aj keď používateľ prehovorí uprostred výpovede.

Každé zásady segmentácie obetujú aktuálnosť v prospech istoty. Príliš skoré potvrdenie zmien vedie k roztrieštenej histórii a nestabilnému zoradeniu. Príliš dlhé čakanie zase oneskoruje prepisy a funkcie, ktoré od nich závisia. Systém preto udržiava dva súvisiace pohľady na konverzáciu: špekulatívny pohľad na aktuálny stav a smerodajný záznam toho, čo bolo povedané. Zobrazenie konverzácie v používateľskom rozhraní aplikácie dokáže spracovávať aktualizácie, preto používa špekulatívne zobrazenie. Zaznamenávanie do analytického kanála však vyžaduje finálny prepis.

Tým sa zvyšku modelu ChatGPT poskytne stabilný pohľad na výmenu bez toho, aby sa na živej hlasovej ceste vynucovalo striedanie replík.

Odozva sa začína, len čo používateľ klikne na tlačidlo. V prípade modelu GPT‑Live musí systém vytvoriť mediálnu cestu a začať posielať zvuk cez model skôr, kým sa môže začať konverzácia. Tým sa každá časť sekvencie spustenia dostáva na kritickú cestu.

Ako bolo uvedené vyššie, WebRTC poskytuje silný základ na komunikáciu v reálnom čase, no spustenie štandardnej relácie WebRTC si vyžaduje prekvapivo veľa vzájomných procesov protokolu a úplných sieťových kôl. WebRTC vzniklo ešte pred dôrazom na minimalizáciu obojsmerných sieťových kôl, ktorý formoval neskoršie protokoly, ako je QUIC. V dôsledku toho jeho podkladové protokoly pri spoločnom použití niekedy vykonávajú duplicitnú prácu. Každý protokol napríklad obsahoval vlastný mechanizmus ochrany proti odmietnutiu služby (DoS), aj keď v kontexte celého zásobníka WebRTC nebol potrebný.

Analyzovali sme technologický zásobník a vyvinuli sme WebRTC Abridged Roundtrip Protocol (WARP⁠(otvorí sa v novom okne)), ktorý znižuje počet sieťových obojsmerných kôl potrebných na spúšťanie médií a dát zo šiestich na jediné. WARP to dosahuje pomocou súboru spätne kompatibilných vylepšení protokolu: pripojením vzájomného procesu DTLS cez ICE (SPED⁠(otvorí sa v novom okne)), použitím rýchlejšieho vzájomného procesu DTLS 1.3⁠(otvorí sa v novom okne), predbežným vyjednaním vzájomného procesu SCTP (SNAP⁠(otvorí sa v novom okne)) a predbežným vyjednaním dátových kanálov namiesto použitia DCEP⁠(otvorí sa v novom okne).

WARP sme navrhli ako súbor otvorených špecifikácií v spolupráci so spolupracovníkmi z komunity WebRTC, aby z tejto práce mohol mať prospech širší ekosystém. Návrhy posúvame cez pracovnú skupinu TSVWG organizácie IETF, a podpora WARP už bola pridaná do libwebrtc aj Pion, pričom v ďalších implementáciách WebRTC práce stále prebiehajú.

Po optimalizácii vzájomného procesu médií zostalo jedno výrazné oneskorenie: signalizačná výmena používaná na zdieľanie parametrov SDP predtým, ako sa WebRTC môže pripojiť. Aby sme túto výmenu odstránili z kritickej cesty, vyvinuli sme riešenie, ktoré nazývame Okamžité pripojenie. Tieto parametre dohodne vopred bez rezervovania kapacity servera a bez akýchkoľvek zmien existujúcich implementácií WebRTC.

Okamžité pripojenie funguje súbežne so štandardným procesom signalizácie. Ak sú vopred dohodnuté parametre platné, server môže vytvoriť reláciu, keď dorazí prvý mediálny paket. Ak sú neaktuálne alebo neplatné, signalizačný proces už prebieha, takže klient môže prejsť na záložný mechanizmus bez dodatočnej latencie.

Okamžité pripojenie a WARP spoločne výrazne skracujú čas od zámeru používateľa po živý mediálny proces. Keďže výmena SDP je mimo kritickej cesty a WARP zredukoval transportné nadviazanie spojenia, klient teraz môže spustiť reláciu jediným paketom UDP. Server môže odpovedať okamžite, čím zvyšku systému umožní začať vykonávať prácu, na ktorej používateľovi skutočne záleží: počúvať a reagovať.

Systém môže na papieri pôsobiť rýchlo, no napriek tomu sa pri skutočnej hlasovej prevádzke zasekáva. Skôr než sme modelu GPT‑Live umožnili chatovať s používateľmi, spustili sme tichý test, ktorý smeroval malý, postupne sa zvyšujúci podiel produkčných relácií Chat GPT Voice do existujúceho prostredia pokročilého hlasového režimu aj do nášho nového systému. Pokročilý hlasový režim naďalej slúžil používateľom ako zvyčajne, zatiaľ čo tieňová cesta vykonávala vyhodnocovanie v režime iba na čítanie. To vystavilo systém reálnym klientom, sieťam, dĺžkam relácií a geografickému rozloženiu bez toho, aby sa zmenilo to, čo používatelia počuli.

Jednou z prvých lekcií bolo, že kapacitu nebolo možné zredukovať na priepustnosť GPU. Hlasové relácie zostávajú otvorené a nepretržite odosielajú snímky, takže obslužné streamovacie rutiny na strane CPU, fronty a sieťové cesty sa musia škálovať spolu s inferenciou. Pri reálnej záťaži dosiahol podporný komponent saturáciu, skôr než predpovedali naše odhady zo záťažových testov, čo spôsobilo nahromadenie požiadaviek na inferenciu a znásobenie latencie. Otázku kapacity sme zmenili z „Koľko požiadaviek zvládne GPU?“ na „Koľko súbežných relácií dokáže systém udržať a zároveň zachovať plán pre každú snímku?“

Test tiež urobil z geografického pôvodu prvoradú prioritu. Smerovanie relácie do vzdialenej kapacity môže navýšiť oneskorenie na viacerých úsekoch počas spúšťania a streamovania. Začali sme overovať nasadzovanie modelov spolu s regionálnou kapacitou a konfiguráciou smerovania prevádzky a následne sme rozdelili latenciu podľa geografického pôvodu zdroja. Presunutie inferencie bližšie k používateľom pomohlo, no zároveň ešte umocnilo širšie ponaučenie: celková odozva závisí od každej služby na trase, nielen od servera modelu.

Ďalšie zlyhania sa objavili iba pri realistických životných cykloch relácií. Dlhotrvajúce relácie spôsobili preťaženie pamäte a úložiska. Opätovné pripojenia preverili kompakciu a obnovenie stavu. Bežné odpojenia klientov odhalili súbežné podmienky pri vypínaní. Tieto problémy sa v krátkych záťažových testoch objavovali len zriedka, pretože záviseli od času, nahromadeného stavu a správania naprieč hranicami služieb.

Napokon nás testovanie v produkčnom prostredí prinútilo zlepšiť pozorovateľnosť a riadenie zavádzania. Našli sme metriky, ktoré zlučovali rôzne zdroje latencie, panely, ktorých agregované hodnoty skrývali jednotlivé moduly v nevyhovujúcom stave, a odchýlky konfigurácie medzi testovanými a nasadenými systémami. V reakcii na to sme pridali podrobnejšiu telemetriu, overovanie vzhľadom na známe funkčné konfigurácie, fázované postupné nasadzovanie a možnosť rýchlo izolovať alebo zakázať jednotlivé cesty. Z tichého testu sa stala skorá generálka na spustenie, nielen z hľadiska toho, akú veľkú prevádzku systém dokáže prijať, ale aj toho, ako rýchlo dokážeme odhaliť, izolovať a zotaviť sa zo zlyhania.

Dostať GPT‑Live na škálu modelu ChatGPT si vyžadovalo úplne nový systém postavený na jednom základnom princípe: plynulosť hlasu. Inferencia streamovania priebežne dodáva úplne duplexnému modelu zvuk. Vyhradená cesta pre médiá zabezpečuje spoľahlivú dodávku snímok. Asynchrónne delegovanie umožňuje, aby hlbšie uvažovanie prebiehalo paralelne. Optimalizovaný prenos udržiava rýchlu odozvu až k používateľovi.

Architektúra stojaca za modelom GPT‑Live je už čoraz širšou platformou na interakciu v reálnom čase. Poháňa Chat GPT Voice pri jeho rozširovaní od konverzácie smerom k agentskej koordinácii a bude základom pripravovaného rozhrania GPT‑Live API. Časom to umožní, aby hlasové zážitky zahŕňali viac zariadení, aplikácií a modalít bez toho, aby tým utrpela bezprostrednosť, vďaka ktorej hlasové konverzácie pôsobia živo.

Ak chcete riešiť práve takéto technické problémy, pridajte sa k nám⁠.