Kako smo u šest mjeseci izgradili responzivan sustav za glasovni AI u stvarnom vremenu

Za glasovnu umjetnu inteligenciju teže je nego što se čini znati kada treba govoriti. Ljudi bez napora prepuštaju riječ jedni drugima u djeliću sekunde, no prethodni glasovni sustavi umjetne inteligencije nisu mogli pratiti taj ritam. Njihova arhitektura koja se temeljila na izmjenama govornika oslanjala se na sićušne modele poznate kao detektori izmjene govornika, koji su imali nezahvalan zadatak: pogriješe li prerano, prekidaju korisnika; pogriješe li prekasno, odgovor djeluje tromo. Tek nakon odluke detektora mnogo veći LLM mogao je započeti s radom.

GPT‑Live⁠, naš glasovni sustav treće generacije, uklanja detektor izmjene iz zvučne putanje. Njegov je glasovni model potpuno dvosmjeran, što znači da istodobno može slušati i govoriti. Time nestaje potreba za zasebnim detektorom, a razgovor djeluje neposrednije i prirodnije. Kada su potrebni dublje rasuđivanje ili upotreba alata, GPT‑Live se može posavjetovati i s našim naprednim modelima, poput GPT‑5.5, bez prekidanja tijeka razgovora. Te mogućnosti zajedno GPT‑Liveu pružaju dosad neviđenu kombinaciju brzog odziva u razgovoru i inteligencije.

Pružanje takvog iskustva u velikom opsegu zahtijevalo je novu arhitekturu sustava optimiziranu za malo kašnjenje. Za razliku od uobičajene inferencije po načelu zahtjev–odgovor, naš sustav struji dolazni zvuk u glasovni model, a izlazni govor natrag korisniku, dok delegiranje obrađuje zasebnom asinkronom putanjom. Tijekom posljednjih šest mjeseci preradili smo inferenciju modela, upravljanje kontekstom i prijenos medija kako bi govor tekao glatko od početka do kraja.

Arhitektura također stvara jasnu granicu između osnovne glasovne putanje i aplikacijske logike. Tako se ponašanje aplikacije može lako prilagoditi bez utjecaja na brzinu odziva. Taj temelj pokreće sve veći skup mogućnosti usluge ChatGPT Glas, uključujući nedavno uvedenu mogućnost upravljanja računalom i koordiniranja agenata u stolnoj aplikaciji ChatGPT.

U ovom ćemo članku objasniti zašto prethodni sustavi s izmjenom redoslijeda nisu mogli ispuniti naše potrebe i kako smo novi sustav projektirali za brz odziv na svakom sloju. Opisat ćemo inferenciju sa stanjem, dinamičko upravljanje kontekstom, asinkrono delegiranje i optimizaciju na razini protokola, koji zajedno čine da GPT‑Live doista djeluje uživo.

Ranije glasovne arhitekture naslijedile su način rada tekstnih LLM-ova temeljen na izmjenama govornika, pri čemu je svaka izmjena bila predstavljena zasebnim zvučnim blokom umjesto tekstom. U kaskadnim sustavima pretvaranje govora u tekst, LLM i pretvaranje teksta u govor izvodili su se uzastopno. Takav je slijed povećavao kašnjenje i zanemarivao signale poput tona i ritma govora.

Modeli za pretvaranje govora u govor poboljšali su taj pristup izravnom obradom zvuka. Uvježbavanje modela da izvorno razumije i stvara govor omogućilo mu je očuvanje pojedinosti izgubljenih u prijepisu i brže odgovaranje. No sustav se i dalje oslanjao na detektor izmjene govornika kako bi odredio kad inferencija može započeti. Model je preuzeo veći dio interakcije, ali ona se i dalje temeljila na izmjenama govornika.

GPT‑Live glasovnom modelu daje kontrolu nad razgovorom: zvuk ulazi u model i izlazi iz njega, dok se dublje rasuđivanje i upotreba alata odvijaju asinkrono. Glavna je zadaća sustava održavati neprekinutu medijsku petlju. Ostali poslovi, poput pozivanja naprednih modela i trajne pohrane razgovora, odvijaju se izvan putanje uživo.

Održavanje ove medijske petlje bez prekida nije uvijek jednostavno. Svako kašnjenje u prijenosu, obradi ili inferenciji može se pretvoriti u čujnu stanku ili smetnju. Prethodni sustav koji se temeljio na izmjenama govornika mogao je podnijeti određena odstupanja u vremenu pristizanja zvučnog bloka.

Raniji rad na uslugama ChatGPT Glas i Realtime API pružio nam je važan temelj. Već smo iznova izgradili svoju glasovnu infrastrukturu⁠ kako bismo strujali zvuk i video izravno u svoje sustave i iz njih, uz manje i predvidljivije kašnjenje. GPT‑Live dodatno je unaprijedio taj dizajn strujanjem medija sve do modela kroz novi sustav inferencije sa stanjem, izgrađen za neprekidan razgovor.

No strujanje inferencije bilo je samo dio rješenja. Za pouzdan rad u produkciji morali smo osigurati i pouzdanu isporuku zvuka od klijenta do sustava za inferenciju te riješiti izazove povezane s održavanjem stanja.

Jedna od prvih odluka bila je jasno odvojiti protok medija od aplikacijske i poslovne logike. Zvuk se između klijenta i glasovnog modela prenosi namjenskom brzom putanjom. Delegiranje, upotreba alata i ostali aplikacijski poslovi odvijaju se iza asinkrone RPC granice. Spor poziv alata ili pozadinska usluga mogu odgoditi vlastiti rezultat, ali ne mogu zaustaviti protok medija.

Ovo razdvajanje sustavu pruža i jasnu granicu za prilagodbu. Aplikacije mogu mijenjati svoje alate, pravila i ponašanje pozadinskog sustava bez utjecaja na medijsko sučelje koje održava protok zvuka. Putanja uživo ostaje mala, predvidljiva i usredotočena na posao koji se mora obaviti u stvarnom vremenu.

Medijsko sučelje i logiku inferencije napisali smo u jeziku Go, zamijenivši prethodnu implementaciju u Pythonu s bibliotekom asyncio. Time je znatno poboljšana ujednačenost isporuke okvira: p95 novog sustava odgovara p50 prethodnog sustava.

WebRTC pruža temelj za prijenos. Osmišljen je za medije s malim kašnjenjem i može nastaviti raditi unatoč gubitku paketa, odstupanju sata i promjenama veze klijenta. Ako paketi zakasne, WebRTC može neprimjetno rastegnuti zvuk kako bi spriječio praznine, a zatim nakratko ubrzati reprodukciju radi povratka u stvarno vrijeme.

Smanjivanjem međuspremnika i blokiranja u cijelom sustavu možemo postići odziv kraći od sekunde, kakav ljudi očekuju od razgovora.

Inferencija sa stanjem donosi vlastite operativne kompromise. Glasovna sesija može dugo ostati aktivna, ali njezin kontekst neprekidno raste, dok se instance modela pokreću i zaustavljaju ovisno o potražnji.

Kako bismo riješili te izazove, izgradili smo mehanizam za neprimjetno prebacivanje između instanci modela. Kada je prijelaz potreban, možemo zagrijati zamjensku instancu modela uz postojeću, unaprijed je ispuniti trenutačnim kontekstom sesije, paralelno izvoditi inferenciju na objema te se prebaciti kada nova instanca bude potpuno spremna.

Isti osnovni mehanizam podržava i dinamičko sažimanje konteksta. Kako razgovor napreduje, njegov nakupljeni kontekst naposljetku može premašiti ograničenje konteksta modela. Sažimanje može smanjiti kontekst kako bi stao unutar ograničenja, ali taj postupak traje. Budući da mijenja prethodni kontekst, poništava i predmemoriju ključ–vrijednost (KV) modela, koja pohranjuje ključeve i vrijednosti pažnje iz prethodno obrađenih tokena. Ponovna izgradnja tog stanja zahtijeva novo početno ispunjavanje, što stvara dodatno kašnjenje.

Umjesto toga, sažimanje tretiramo kao još jedan upravljani prijelaz. Dok izvorna instanca modela nastavlja razgovor, sustav sažima kontekst i priprema zamjensku instancu modela s novim kontekstom. Kada ta instanca bude spremna, možemo se prebaciti bez prekida medija. Tako sustav može podržavati dugotrajne pozive i sažimati kontekst kad god je potrebno.

Zahtjevna obrada ostaje izvan putanje uživo, pa razgovor ne zastaje čak ni tijekom prebacivanja.

Mogućnost GPT‑Livea da poziva postojeće napredne modele pruža mu veliku moć jer učinkovito razdvaja „govorenje“ od dubljeg „razmišljanja“. No da bi ova arhitektura s dva modela djelovala kao jedinstven sustav, trebalo je riješiti dva povezana inženjerska problema.

Prvo, rezultati se moraju vratiti dovoljno brzo da bi bili korisni u tekućem razgovoru, pa smo morali smanjiti kašnjenje duž cijele putanje delegiranja — od usmjeravanja i obrade upita do inferencije i poziva alata. Istodobno, drugi sustavi u proizvodu i dalje trebaju zasebne poruke, pa smo tekući razgovor morali prikazati u obliku koji mogu razumjeti.

Kada se delegiranje pošalje, optimiziramo vrijeme potrebno da napredni model proizvede nešto korisno za razgovor. Glasovni model može nakratko održavati razgovor dok napredni model rasuđuje ili upotrebljava alate, ali ne može prikriti proizvoljno spor odgovor. Zato smo cijelu petlju delegiranja — usmjeravanje, obradu upita, inferenciju i pozive alata — uključili u dopušteno vrijeme odziva.

Prva je optimizacija pripremiti napredni model i sve potrebne alate prije nego što se zatraži delegiranje. Kada započne glasovna sesija, aplikacijski poslužitelj stvara sesiju inferencije za napredni model i unaprijed je ispunjava početnim kontekstom razgovora, čime osigurava da je upit potpuno obrađen prije prvog delegiranog zahtjeva.

Tu sesiju inferencije zatim održavamo dostupnom tijekom cijelog glasovnog razgovora i za uzastopne zahtjeve primjenjujemo stabilnu povezanost sa sesijom. Zajedno s predmemoriranjem upita, te tehnike smanjuju kašnjenje, a oporavak od kvara izvršitelja ostaje jednostavan.

Napor rasuđivanja, ograničenja izlaza, sheme alata i povratna putovanja između modela i alata također utječu na to kada će razgovor dobiti koristan rezultat, pa smo te postavke prilagodili radi bržih odgovora. Smanjivanjem posla potrebnog na putanji delegiranja omogućili smo glasovnom modelu da brzo uključi rezultate naših naprednih modela.

Iako glasovni model obrađuje neprekidne tokove govora, mnogi okolni sustavi i dalje rade s izmjenama korisnika i asistenta, uključujući sučelje za razgovor usluge ChatGPT te dijelove naše analitičke i sigurnosne infrastrukture. Aplikacijski poslužitelj zato raščlanjuje preklapajući i povremeno dvosmislen razgovor u zasebne poruke.

Dok zvuk pristiže, poslužitelj se koristi djelomičnim prijepisima i vremenskim signalima kako bi utvrdio tko govori i sastavio red poruka. Najnovija poruka ostaje privremena; njezin tekst, vremenski podaci i dodijeljeni govornik mogu se promijeniti kako pristiže još govora. Kada govornik dovoljno dugo zadrži riječ da bi pripisivanje bilo pouzdano, poslužitelj dovršava odgovarajuću poruku.

Preklapanje govornika dodatno usložnjava postupak. Kratka potvrda asistenta dok korisnik govori (npr. “mm hmm,” ili “okay”) ne mora nužno postati zasebna poruka. No sadržajna upadica asistenta često bi trebala. Slično tome, dajemo prednost koherentnosti prikazanih odgovora asistenta čak i kada korisnik progovori usred odgovora.

Svako pravilo segmentacije traži kompromis između ažurnosti i sigurnosti. Prerano zaključivanje stvara rascjepkanu povijest i nestabilan redoslijed, dok predugo čekanje odgađa prijepise i značajke koje o njima ovise. Sustav zato održava dva povezana prikaza razgovora: pretpostavljeni prikaz trenutačnog stanja i mjerodavan zapis izgovorenog. Prikaz razgovora u korisničkom sučelju aplikacije može obrađivati ažuriranja, pa se koristi pretpostavljenim prikazom. No bilježenje u analitički kanal zahtijeva konačan prijepis.

Tako ostatak usluge ChatGPT dobiva stabilan prikaz razgovora bez nametanja izmjena govornika glasovnoj putanji uživo.

Brz odziv počinje čim korisnik klikne gumb. Uz GPT‑Live sustav mora uspostaviti medijsku putanju i početi slati zvuk kroz model prije početka razgovora. Zato se svaki dio slijeda pokretanja nalazi na kritičnoj putanji.

Kao što je prethodno navedeno, WebRTC pruža čvrst temelj za rad u stvarnom vremenu, ali pokretanje standardne WebRTC sesije zahtijeva iznenađujuće mnogo protokolskih dogovora i povratnih mrežnih prijenosa. WebRTC je nastao prije nego što je smanjivanje povratnih mrežnih prijenosa postalo prioritet koji je oblikovao novije protokole poput QUIC-a. Zbog toga njegovi temeljni protokoli katkad ponavljaju isti posao kada se upotrebljavaju zajedno. Primjerice, svaki je protokol uključivao vlastiti mehanizam protiv DoS napada, čak i kada nije bio potreban u kontekstu cijelog WebRTC sustava.

Analizirali smo sustav i razvili WebRTC Abridged Roundtrip Protocol (WARP⁠(otvara se u novom prozoru)), koji pokretanje medija i podataka smanjuje sa šest povratnih mrežnih prijenosa na samo jedan. WARP to postiže skupom protokolskih poboljšanja kompatibilnih s prethodnim verzijama: prijenosom DTLS dogovora preko ICE-a (SPED⁠(otvara se u novom prozoru)), upotrebom bržeg dogovora DTLS 1.3⁠(otvara se u novom prozoru), prethodnim dogovaranjem SCTP veze (SNAP⁠(otvara se u novom prozoru)) te prethodnim dogovaranjem podatkovnih kanala umjesto upotrebe protokola DCEP⁠(otvara se u novom prozoru).

WARP smo osmislili kao skup otvorenih specifikacija, surađujući s članovima WebRTC zajednice kako bi širi ekosustav imao koristi od ovog rada. Prijedloge razvijamo kroz radnu skupinu TSVWG organizacije IETF, a podrška za WARP već je dodana u libwebrtc i Pion te se radi na drugim implementacijama WebRTC-a.

Nakon optimizacije medijskog dogovora preostalo je još jedno primjetno kašnjenje: signalizacijska razmjena za dijeljenje parametara SDP-a prije povezivanja WebRTC-a. Kako bismo tu razmjenu uklonili s kritične putanje, razvili smo rješenje koje nazivamo Instant Connect. Ono unaprijed dogovara te parametre bez rezerviranja kapaciteta poslužitelja i bez promjena postojećih implementacija WebRTC-a.

Instant Connect radi usporedno sa standardnim signalizacijskim tijekom. Ako su unaprijed dogovoreni parametri valjani, poslužitelj može uspostaviti sesiju kada stigne prvi medijski paket. Ako su zastarjeli ili nevaljani, signalizacijski je tijek već u tijeku, pa se klijent može vratiti na njega bez dodatnog kašnjenja.

Instant Connect i WARP zajedno drastično skraćuju vrijeme od korisnikove namjere do protoka medija uživo. Budući da je razmjena SDP-a uklonjena s kritične putanje, a WARP sažima dogovor prijenosa, klijent sada može pokrenuti sesiju jednim UDP paketom. Poslužitelj može odmah odgovoriti, pa ostatak sustava može početi raditi ono što je korisniku doista važno: slušati i odgovarati.

Sustav na papiru može djelovati brzo, a ipak zastajati pod stvarnim glasovnim prometom. Prije nego što smo GPT‑Liveu omogućili razgovor s korisnicima, proveli smo neprimjetan test u kojem smo mali, postupno rastući udio produkcijskih sesija usluge ChatGPT Glas usmjeravali i na postojeći napredni glasovni način rada i na naš novi sustav. Napredni glasovni način rada nastavio je uobičajeno posluživati korisnike, dok je paralelna putanja izvodila inferenciju samo za čitanje. Tako smo sustav izložili stvarnim klijentima, mrežama, trajanjima sesija i geografskoj raspodjeli bez promjene onoga što su korisnici čuli.

Jedna od prvih spoznaja bila je da se kapacitet ne može svesti na propusnost GPU-a. Glasovne sesije ostaju otvorene i neprekidno šalju okvire, pa se obrađivači tokova na CPU-u, redovi čekanja i mrežne putanje moraju skalirati zajedno s inferencijom. Pod stvarnim opterećenjem pomoćna se komponenta zasitila prije nego što su predviđale procjene iz testova opterećenja, zbog čega su se zahtjevi za inferenciju gomilali, a kašnjenje dodatno povećavalo. Pitanje o kapacitetu promijenili smo iz „Koliko zahtjeva može obraditi GPU?“ u „Koliko istodobnih sesija sustav može održavati uz pravodobnu obradu svakog okvira?“

Test je također pokazao da geografija mora biti jedan od glavnih čimbenika. Usmjeravanje sesije prema udaljenom kapacitetu može povećati kašnjenje na više mjesta tijekom pokretanja i strujanja. Uvođenja modela počeli smo provjeravati zajedno s regionalnim kapacitetom i konfiguracijom usmjeravanja prometa, a zatim analizirati kašnjenje prema izvorišnoj geografskoj lokaciji. Približavanje inferencije korisnicima pomoglo je, ali je potvrdilo i širu pouku: odziv cijelog sustava ovisi o svakoj usluzi na putanji, a ne samo o poslužitelju modela.

Drugi kvarovi pojavljivali su se tek tijekom realističnih životnih ciklusa sesija. Dugotrajne sesije otkrile su opterećenje memorije i trajne pohrane. Ponovna povezivanja stavljala su na kušnju sažimanje i obnovu stanja. Uobičajeni prekidi veze klijenta otkrili su uvjete utrke u procesu dogovorenog zatvaranja. Ti su se problemi rijetko pojavljivali u kratkim testovima opterećenja jer su ovisili o vremenu, nakupljenom stanju i ponašanju preko granica usluga.

Naposljetku, produkcijsko testiranje prisililo nas je da poboljšamo nadzor sustava i kontrole uvođenja. Otkrili smo metrike koje su spajale različite izvore kašnjenja, nadzorne ploče čiji su zbirni podaci skrivali pojedinačne neispravne pogone te odstupanja konfiguracije između testiranih i uvedenih sustava. Zato smo uveli detaljniju telemetriju, provjeru prema dokazano ispravnim konfiguracijama, postupno povećavanje prometa te mogućnost brze izolacije ili isključivanja pojedinačnih putanja. Neprimjetan test postao je rana generalna proba pokretanja — ne samo za količinu prometa koju sustav može prihvatiti nego i za brzinu kojom možemo otkriti i ograničiti kvar te oporaviti sustav.

Dovođenje GPT‑Livea na razinu usluge ChatGPT zahtijevalo je potpuno nov sustav izgrađen oko jednog temeljnog načela: glas mora teći. Strujanje inferencije neprekidno opskrbljuje dvosmjerni model zvukom. Namjenska medijska putanja osigurava pouzdanu isporuku okvira. Asinkrono delegiranje omogućuje paralelno izvođenje dubljeg razmišljanja. Optimizirani prijenos održava brz odziv sve do korisnika.

Arhitektura GPT‑Livea već postaje šira platforma za interakciju u stvarnom vremenu. Pokreće ChatGPT Glas dok se on iz razgovora širi na koordinaciju agenata, a bit će i temelj nadolazećeg GPT‑Live API-ja. S vremenom će omogućiti glasovna iskustva na više uređaja, u više aplikacija i modaliteta, bez gubitka neposrednosti zbog koje glasovni razgovor djeluje kao da se odvija uživo.

Ako želite rješavati ovakve inženjerske probleme, pridružite nam se⁠.