Jak jsme za šest měsíců vybudovali systém pro pohotovou hlasovou AI v reálném čase

Vědět, kdy má mluvit, je pro hlasovou AI těžší, než by se mohlo zdát. Lidé si bez námahy předávají slovo během hovoru ve zlomku sekundy, ale dřívější systémy hlasové AI tomuto rytmu nestačily. Jejich tahová architektura využívala velmi malé modely známé jako detektory tahů, které měly nezáviděníhodný úkol: když to odhadly příliš brzy, uživateli se skočilo do řeči; když to odhadly příliš pozdě, odpověď působila pomalu. Mnohem větší LLM mohl začít pracovat, až když detektor rozhodl.

GPT‑Live⁠, náš hlasový systém třetí generace, detektor tahů ze zvukové cesty odstraňuje. Jeho hlasový model je plně duplexní, takže může současně poslouchat i mluvit. Samostatný detektor tak již není potřeba a konverzace působí bezprostředněji a přirozeněji. Když je potřeba hlubší uvažování nebo použití nástrojů, GPT‑Live se může bez přerušení toku konverzace obrátit také na naše průkopnické modely, například GPT‑5.5. Díky těmto funkcím nabízí GPT‑Live dosud nevídanou kombinaci pohotové konverzace a inteligence.

Nabízet tuto zkušenost ve velkém měřítku si vyžádalo novou systémovou architekturu optimalizovanou pro nízkou latenci. Na rozdíl od běžné inference typu požadavek–odpověď náš systém streamuje příchozí zvuk do hlasového modelu a výstupní řeč zpět k uživateli, zatímco delegování zpracovává samostatnou asynchronní cestou. Během posledních šesti měsíců jsme přepracovali inferenci modelu, správu kontextu a přenos médií, aby řeč plynula hladce od jednoho konce ke druhému.

Architektura zároveň vytváří jasnou hranici mezi základní hlasovou cestou a aplikační logikou. Chování aplikace tak lze snadno přizpůsobit, aniž se zhorší rychlost odezvy. Tento základ pohání rostoucí škálu funkcí ChatGPT Voice, včetně nově spuštěné možnosti ovládat počítač a koordinovat agenty v desktopové aplikaci ChatGPT.

V tomto článku vysvětlíme, proč dřívější tahové systémy nesplňovaly naše potřeby a jak jsme novou architekturu navrhli tak, aby pohotově reagovala v každé vrstvě. Popíšeme stavovou inferenci, dynamickou správu kontextu, asynchronní delegování a optimalizaci na úrovni protokolu, které společně zajišťují, že GPT‑Live působí skutečně živě.

Dřívější hlasové architektury převzaly tahový princip textových LLM, každý tah však namísto textu představoval samostatný zvukový blok. V kaskádových systémech probíhal převod řeči na text, zpracování v LLM a převod textu na řeč postupně za sebou. Tato posloupnost zvyšovala latenci a ignorovala signály, jako jsou tón hlasu a tempo.

Modely s řečovým vstupem i výstupem tento přístup zlepšily přímým zpracováním zvuku. Díky nativnímu porozumění řeči a její tvorbě dokázal model zachovat podrobnosti ztracené při přepisu a reagovat rychleji. Systém však stále spoléhal na detektor tahů, který určoval, kdy může inference začít. Model zvládal větší část interakce, ta však stále probíhala po tazích.

GPT‑Live svěřuje řízení konverzace hlasovému modelu: zvuk proudí do modelu i z něj, zatímco hlubší uvažování a používání nástrojů probíhá asynchronně. Hlavním úkolem systému je udržovat nepřerušenou mediální smyčku. Ostatní úlohy, například spouštění průkopnických modelů a trvalé ukládání konverzace, probíhají mimo živou cestu.

Udržet tuto mediální smyčku bez přerušení není vždy snadné. Každé malé zpoždění přenosu, zpracování nebo inference může způsobit slyšitelnou pauzu či rušivý artefakt. Dřívější tahový systém dokázal tolerovat určité rozdíly v době příchodu zvukového bloku. Živý mediální systém však musí každý zvukový rámec doručit včas.

Dřívější práce na ChatGPT Voice a Realtime API nám poskytla důležitý základ. Už dříve jsme přepracovali naši hlasovou infrastrukturu⁠ tak, aby přenášela zvuk a video přímo do našich systémů i z nich s nižší a předvídatelnější latencí. GPT‑Live tuto koncepci dále rozvinul a prostřednictvím nového stavového inferenčního systému navrženého pro nepřetržitou konverzaci streamuje média až do modelu.

Streamovaná inference však byla jen částí řešení. Aby systém dobře fungoval v produkci, museli jsme také zajistit spolehlivý přenos zvuku od klienta k inferenčnímu stacku a vyřešit problémy spojené se stavovostí.

Jedním z našich prvních rozhodnutí bylo důsledně oddělit tok médií od aplikační a obchodní logiky. Zvuk se mezi klientem a hlasovým modelem přenáší po vyhrazené rychlé cestě. Delegování, používání nástrojů a další aplikační úlohy probíhají za asynchronní hranicí RPC. Pomalé volání nástroje nebo backendová služba mohou zpozdit vlastní výsledek, ale nemohou zastavit tok médií.

Toto oddělení zároveň systému poskytuje jasnou hranici pro přizpůsobení. Aplikace mohou měnit své nástroje, zásady i chování backendu, aniž ovlivní mediální frontend, který zajišťuje plynulý tok zvuku. Živá cesta zůstává malá, předvídatelná a zaměřená na úlohy, které musí probíhat v reálném čase.

Mediální frontend a inferenční logiku jsme napsali v jazyce Go a nahradili jimi předchozí implementaci v Pythonu využívající asyncio. Plynulost doručování rámců se tím výrazně zlepšila: p95 nového systému odpovídá p50 předchozího systému.

Přenosový základ poskytuje WebRTC. Je navržené pro média s nízkou latencí a dokáže pokračovat v provozu i při ztrátě paketů, odchylkách hodin či změnách připojení klienta. Když pakety dorazí pozdě, WebRTC může zvuk nepatrně protáhnout, aby nevznikly mezery, a poté přehrávání krátce zrychlit, aby se vrátilo do reálného času.

Minimalizací ukládání do vyrovnávací paměti a blokování v celém systému dokážeme zajistit odezvu pod jednu sekundu, kterou lidé od konverzace očekávají.

Stavová inference přináší vlastní provozní kompromisy. Hlasová relace může zůstat aktivní dlouhou dobu, její kontext však neustále roste a instance modelu se podle potřeby spouštějí a ukončují.

Tyto problémy jsme vyřešili mechanismem plynulého předávání mezi instancemi modelu. Když je nutný přechod, můžeme vedle stávající instance modelu předehřát náhradní instanci, předvyplnit ji aktuálním kontextem relace, souběžně provádět inferenci na obou a přepnout až ve chvíli, kdy je nová instance zcela připravena.

Stejný základní mechanismus podporuje také dynamickou kompakci kontextu. Jak konverzace pokračuje, její nahromaděný kontext může v určité fázi překročit kontextový limit modelu. Kompakce může kontext zmenšit tak, aby se do limitu vešel, tato operace však nějakou dobu trvá. Protože navíc mění předchozí kontext, zneplatní také mezipaměť klíčů a hodnot (key-value, KV) modelu, která uchovává klíče a hodnoty pozornosti z dříve zpracovaných tokenů. Obnovení tohoto stavu vyžaduje nové předvyplnění, což přináší další zpoždění.

S kompakcí proto zacházíme jako s dalším řízeným přechodem. Zatímco původní instance modelu pokračuje v konverzaci, systém zkompaktní kontext a připraví s novým kontextem náhradní instanci modelu. Jakmile je tato instance připravena, můžeme na ni přepnout bez přerušení médií. Systém tak může podporovat dlouhé hovory a kdykoli je potřeba, provádět kompakci.

Náročná práce probíhá mimo živou cestu, takže konverzace neztratí rytmus ani během předávání.

Schopnost GPT‑Live využívat stávající průkopnické modely mu dává značné možnosti a fakticky odděluje „mluvení“ od hlubšího „přemýšlení“. Aby však tato architektura se dvěma modely působila jako jediný systém, museli jsme vyřešit dva související technické problémy.

Za prvé se výsledky musí vracet dostatečně rychle, aby byly v probíhající konverzaci užitečné. Museli jsme proto minimalizovat latenci celé cesty delegování, od směrování a zpracování promptu přes inferenci až po volání nástrojů. Ostatní systémy v produktu zároveň stále potřebují samostatné zprávy, takže jsme museli probíhající konverzaci převést do podoby, které rozumějí.

Při odeslání delegované úlohy optimalizujeme dobu, než průkopnický model vytvoří něco užitečného pro konverzaci. Hlasový model může krátce udržovat konverzaci v chodu, zatímco průkopnický model uvažuje nebo používá nástroje, nedokáže však skrýt libovolně pomalou odezvu. Celou smyčku delegování – směrování, zpracování promptu, inferenci a volání nástrojů – jsme proto zahrnuli do časového rozpočtu odezvy.

První optimalizací je připravit průkopnický model a všechny potřebné nástroje ještě před vyžádáním delegování. Při zahájení hlasové relace vytvoří aplikační server inferenční relaci pro průkopnický model a předvyplní ji počátečním kontextem konverzace. Prompt je tak plně zpracován ještě před prvním delegovaným požadavkem.

Tuto inferenční relaci pak udržujeme dostupnou po celou dobu hlasové konverzace a pro následné požadavky používáme stabilní afinitu relace. Společně s ukládáním promptů do mezipaměti tyto postupy zlepšují latenci, zatímco případné selhání pracovního procesu lze stále snadno napravit.

Dobu, za kterou konverzace obdrží užitečný výsledek, ovlivňuje také míra uvažování, limity výstupu, schémata nástrojů a zpáteční komunikace mezi modelem a nástroji. Tyto parametry jsme proto vyladili pro rychlejší odezvu. Minimalizací práce potřebné na cestě delegování jsme hlasovému modelu umožnili rychle zapracovávat výsledky našich průkopnických modelů.

Přestože hlasový model zpracovává nepřetržité proudy řeči, mnoho okolních systémů stále pracuje s tahy uživatele a asistenta. Patří mezi ně konverzační rozhraní ChatGPT i části naší analytické a bezpečnostní infrastruktury. Aplikační server proto rozplétá překrývající se a někdy nejednoznačnou konverzaci do samostatných zpráv.

S přicházejícím zvukem server využívá průběžné přepisy a časové signály, aby odhadl, kdo právě mluví, a sestavil frontu zpráv. Nejnovější zpráva zůstává předběžná. Její text, časování i přiřazení mluvčího se mohou s příchodem další řeči měnit. Jakmile mluvčí hovoří dostatečně dlouho, aby bylo přiřazení spolehlivé, server příslušnou zprávu dokončí.

Překrývání mluvčích tento proces komplikuje. Krátké přitakání asistenta během řeči uživatele (například „mhm“ nebo „dobře“) nemusí nutně tvořit samostatnou zprávu. Významná vsuvka asistenta by jí však často být měla. Podobně upřednostňujeme souvislost zobrazených odpovědí asistenta, i když uprostřed nich mluví uživatel.

Každá zásada segmentace hledá kompromis mezi aktuálností a jistotou. Když se segment ukončí příliš brzy, vede to k roztříštěné historii a nestabilnímu pořadí, zatímco příliš dlouhé čekání zpožďuje přepisy i funkce, které na nich závisejí. Systém proto udržuje dva související pohledy na konverzaci: spekulativní pohled na aktuální stav a autoritativní záznam toho, co zaznělo. Zobrazení konverzace v uživatelském rozhraní aplikace umí zapracovávat nové informace, a proto používá spekulativní pohled. Pro protokolování do analytického datového toku je však nutný konečný přepis.

Zbytek ChatGPT tak získává stabilní pohled na konverzaci, aniž se živé hlasové cestě vnucuje střídání tahů.

Pohotová odezva začíná už ve chvíli, kdy uživatel klikne na tlačítko. Než může konverzace v GPT‑Live začít, systém musí vytvořit mediální cestu a začít přes model přenášet zvuk. Každá část spouštěcí sekvence se tak ocitá na kritické cestě.

Jak jsme uvedli výše, WebRTC poskytuje kvalitní základ pro komunikaci v reálném čase, ale zahájení standardní relace WebRTC vyžaduje překvapivé množství navazování spojení mezi protokoly a přenosů po síti tam a zpět. WebRTC vzniklo dříve, než se pozdější protokoly jako QUIC začaly zaměřovat na minimalizaci počtu přenosů tam a zpět. Jeho základní protokoly proto při společném použití někdy opakují tutéž práci. Každý protokol například obsahoval vlastní ochranu proti DoS, i když v kontextu celého stacku WebRTC nebyla potřeba.

Stack jsme analyzovali a vyvinuli WebRTC Abridged Roundtrip Protocol (WARP⁠(otevře se v novém okně)), který zkracuje spuštění médií a dat ze šesti přenosů tam a zpět po síti na jediný. WARP toho dosahuje sadou zpětně kompatibilních vylepšení protokolů: přenosem navazování spojení DTLS společně s ICE (SPED⁠(otevře se v novém okně)), použitím rychlejšího navazování spojení DTLS 1.3⁠(otevře se v novém okně), předběžným sjednáním spojení SCTP (SNAP⁠(otevře se v novém okně)) a předběžným sjednáním datových kanálů namísto použití DCEP⁠(otevře se v novém okně).

WARP jsme ve spolupráci s členy komunity WebRTC navrhli jako sadu otevřených specifikací, aby z této práce mohl těžit celý ekosystém. Návrhy prosazujeme v pracovní skupině TSVWG organizace IETF. Podpora WARP již byla přidána do libwebrtc i Pionu a pracuje se na ní také v dalších implementacích WebRTC.

Po optimalizaci navazování mediálního spojení zbývalo jedno výrazné zpoždění: výměna signalizačních zpráv sloužící ke sdílení parametrů SDP před připojením WebRTC. Abychom tuto výměnu odstranili z kritické cesty, vyvinuli jsme řešení, kterému říkáme Instant Connect. Tyto parametry sjednává předem, aniž rezervuje kapacitu serveru nebo vyžaduje změny stávajících implementací WebRTC.

Instant Connect funguje souběžně se standardním signalizačním tokem. Pokud jsou předem sjednané parametry platné, server může relaci vytvořit při příchodu prvního mediálního paketu. Pokud jsou zastaralé nebo neplatné, signalizační tok již probíhá, takže klient může přejít na záložní postup bez dalšího zpoždění.

Instant Connect a WARP společně výrazně zkracují dobu od záměru uživatele do spuštění živého toku médií. Díky přesunutí výměny SDP mimo kritickou cestu a sloučení navazování přenosového spojení pomocí WARP nyní klient může zahájit relaci jediným paketem UDP. Server může okamžitě odpovědět a zbytek systému tak může začít dělat to, na čem uživateli skutečně záleží: poslouchat a odpovídat.

Systém může na papíře vypadat rychle, ale při skutečném hlasovém provozu i přesto zadrhávat. Než jsme GPT‑Live nechali komunikovat s uživateli, provedli jsme tichý test, při kterém jsme malou, postupně rostoucí část produkčních relací ChatGPT Voice směrovali současně do stávajícího pokročilého hlasového režimu i do našeho nového systému. Pokročilý hlasový režim dál obsluhoval uživatele jako obvykle, zatímco stínová cesta prováděla inferenci v režimu pouze pro čtení. Systém tak byl vystaven skutečným klientům, sítím, délkám relací i geografickému rozložení, aniž se změnilo, co uživatelé slyšeli.

Jedním z prvních poznatků bylo, že kapacitu nelze redukovat na výkon GPU. Hlasové relace zůstávají otevřené a nepřetržitě odesílají rámce, takže obslužné procesy streamů na straně CPU, fronty i síťové cesty se musí škálovat společně s inferencí. Při skutečné zátěži dosahovala jedna podpůrná komponenta nasycení dříve, než předpovídaly naše zátěžové testy. Požadavky na inferenci se začaly hromadit a latence narůstala. Otázku kapacity jsme proto změnili z: „Kolik požadavků zvládne GPU?“ na: „Kolik souběžných relací systém zvládne, aniž by se kterýkoli rámec zpozdil?“

Test také ukázal, že za prvořadý faktor musíme považovat geografii. Směrování relace ke vzdálené kapacitě může přidat prodlevu v několika fázích spouštění i streamování. Nasazování modelů jsme začali ověřovat společně s regionální kapacitou a konfigurací směrování provozu. Latenci jsme následně rozkládali podle zeměpisného původu. Přesunutí inference blíže k uživatelům pomohlo, ale zároveň potvrdilo obecnější poznatek: celková odezva závisí na každé službě v cestě, nejen na serveru modelu.

Jiné poruchy se objevily až během realistických životních cyklů relací. Dlouho běžící relace odhalily tlak na paměť a trvalé ukládání dat. Opětovná připojení po odpojení prověřila kompakci a obnovení stavu. Běžná odpojení klientů odhalila souběhy při potvrzování ukončení. V krátkých zátěžových testech se tyto problémy objevovaly jen zřídka, protože závisely na čase, nahromaděném stavu a chování napříč hranicemi služeb.

A konečně, testování v produkci nás přimělo zlepšit pozorovatelnost a řízení nasazování. Narazili jsme na metriky, které směšovaly různé zdroje latence, řídicí panely, jejichž agregované údaje skrývaly jednotlivé problematické enginy, i na rozdíly mezi konfigurací testovaných a nasazených systémů. V reakci na to jsme zavedli podrobnější telemetrii, validaci ve srovnání se známými funkčními konfiguracemi, postupné zvyšování provozu a možnost rychle izolovat nebo vypnout jednotlivé cesty. Tichý test se stal předběžnou generální zkouškou spuštění: neověřoval jen objem provozu, který systém dokáže přijmout, ale také rychlost, s jakou umíme odhalit, omezit a napravit poruchu.

Rozšíření GPT‑Live na úroveň ChatGPT vyžadovalo zcela nový systém postavený na jedné základní zásadě: hlas musí plynout bez přerušení. Streamovaná inference průběžně zásobuje plně duplexní model zvukem. Vyhrazená mediální cesta zajišťuje spolehlivé doručování rámců. Asynchronní delegování umožňuje souběžné hlubší uvažování. Optimalizovaný přenos zachovává pohotovou odezvu až k uživateli.

Architektura GPT‑Live se již stává širší platformou pro interakce v reálném čase. Pohání ChatGPT Voice při jeho rozšiřování od konverzace k agentní koordinaci a stane se základem připravovaného rozhraní GPT‑Live API. Postupně umožní rozšířit hlasové prostředí na více zařízení, aplikací a modalit, aniž se vytratí bezprostřednost, díky níž hlasová konverzace působí živě.

Pokud chcete řešit právě takové technické problémy, přidejte se k nám⁠.