Kako smo za šest mjeseci izgradili sistem u stvarnom vremenu za glasovni AI s brzim odzivom

Za glasovnu umjetnu inteligenciju teže je znati kada treba govoriti nego što se čini. Ljudi bez napora prepuštaju riječ jedni drugima u djeliću sekunde, ali raniji glasovni AI sistemi nisu mogli pratiti taj ritam. Njihova arhitektura zasnovana na smjenama oslanjala se na male modele poznate kao detektori smjene, koji su imali nezahvalan zadatak: pogriješe li prerano, prekinut će korisnika; pogriješe li prekasno, odgovor će djelovati tromo. Tek nakon odluke detektora mnogo veći LLM mogao je početi raditi.

GPT‑Live⁠, naš glasovni sistem treće generacije, uklanja detektor smjene iz zvučne putanje. Njegov glasovni model radi dvosmjerno, što znači da može istovremeno slušati i govoriti. Time nestaje potreba za zasebnim detektorom, a razgovor postaje neposredniji i prirodniji. Kada su potrebni dublje rezonovanje ili korištenje alata, GPT‑Live se može obratiti i našim graničnim modelima, poput GPT‑5.5, bez prekidanja toka razgovora. Te mogućnosti zajedno pružaju GPT‑Liveu dosad neviđenu kombinaciju brzog razgovornog odziva i inteligencije.

Pružanje ovog iskustva u velikom obimu zahtijevalo je novu sistemsku arhitekturu optimiziranu za malo kašnjenje. Za razliku od uobičajene inferencije po principu zahtjeva i odgovora, naš sistem prenosi dolazni zvuk u glasovni model, a izlazni govor nazad korisniku, dok delegiranje obrađuje zasebnom asinhronom putanjom. Tokom posljednjih šest mjeseci preradili smo inferenciju modela, upravljanje kontekstom i prijenos medija kako bi govor tekao nesmetano od početka do kraja.

Arhitektura također uspostavlja jasnu granicu između osnovne glasovne putanje i aplikacijske logike. To olakšava prilagođavanje ponašanja aplikacije bez utjecaja na brzinu odziva. Ovaj temelj pokreće sve širi skup mogućnosti usluge ChatGPT Voice, uključujući nedavno uvedenu mogućnost upravljanja računarom i koordiniranja agenata u desktop aplikaciji ChatGPT.

U ovom tekstu objasnit ćemo zašto raniji sistemi zasnovani na smjenama nisu mogli zadovoljiti naše potrebe i kako smo novi sistem projektirali za brz odziv na svakom sloju. Obuhvatit ćemo inferenciju sa stanjem, dinamičko upravljanje kontekstom, asinhrono delegiranje i optimizaciju na nivou protokola, koji zajedno čine da GPT‑Live djeluje zaista uživo.

Ranije glasovne arhitekture naslijedile su smjenjivanje tekstualnih LLM-ova, ali je svaka smjena bila predstavljena zasebnim zvučnim blokom umjesto tekstom. U kaskadnim sistemima pretvaranje govora u tekst, LLM i pretvaranje teksta u govor izvršavali su se jedan za drugim. Takav redoslijed povećavao je kašnjenje i zanemarivao signale poput tona i ritma govora.

Modeli za pretvaranje govora u govor unaprijedili su ovaj pristup izravnom obradom zvuka. Obučavanje modela da izvorno razumije i stvara govor omogućilo mu je da sačuva pojedinosti izgubljene u transkripciji i brže odgovori. Međutim, sistem se i dalje oslanjao na detektor smjene da odluči kada inferencija može početi. Model je preuzeo veći dio interakcije, ali je ona i dalje bila zasnovana na smjenama.

GPT‑Live glasovnom modelu daje kontrolu nad razgovorom: zvuk ulazi u model i izlazi iz njega, dok se dublje rezonovanje i korištenje alata odvijaju asinhrono. Glavni zadatak sistema jeste održavati neprekinutu medijsku petlju. Ostali poslovi, poput pozivanja graničnih modela i trajnog pohranjivanja razgovora, odvijaju se izvan putanje uživo.

Nije uvijek jednostavno održavati ovu medijsku petlju bez prekida. Svako kašnjenje u prijenosu, obradi ili inferenciji može se pretvoriti u čujnu pauzu ili smetnju. Raniji sistem zasnovan na smjenama mogao je tolerirati određena odstupanja u vremenu dolaska zvučnog bloka. Međutim, medijski sistem uživo mora svaki zvučni okvir isporučiti na vrijeme.

Raniji rad na uslugama ChatGPT Voice i Realtime API pružio nam je važan temelj. Već smo iznova izgradili svoju glasovnu infrastrukturu⁠ kako bismo izravno prenosili zvuk i video u svoje sisteme i iz njih, uz manje i predvidljivije kašnjenje. GPT‑Live je dodatno unaprijedio taj dizajn prijenosom medija sve do modela kroz novi sistem inferencije sa stanjem, napravljen za kontinuirani razgovor.

Ipak, inferencija putem prijenosa bila je samo dio rješenja. Da bi dobro radila u produkciji, morali smo osigurati i pouzdanu isporuku zvuka od klijenta do inferencijskog sistema te riješiti izazove održavanja stanja.

Jedna od prvih odluka bila je da tok medija jasno odvojimo od aplikacijske i poslovne logike. Zvuk se između klijenta i glasovnog modela kreće namjenskom brzom putanjom. Delegiranje, korištenje alata i drugi aplikacijski poslovi odvijaju se iza asinhrone RPC granice. Spor poziv alata ili pozadinska usluga mogu odgoditi vlastiti rezultat, ali ne mogu zaustaviti tok medija.

Ovo razdvajanje sistemu pruža i jasnu granicu za prilagođavanje. Aplikacije mogu mijenjati svoje alate, pravila i ponašanje pozadinskog sistema bez utjecaja na medijski prednji sistem zadužen za neprekidan tok zvuka. Putanja uživo ostaje mala, predvidljiva i usmjerena na posao koji se mora odvijati u stvarnom vremenu.

Medijski prednji sistem i logiku inferencije napisali smo u jeziku Go, zamijenivši raniju Python implementaciju zasnovanu na modulu asyncio. Time smo znatno poboljšali ujednačenost isporuke okvira: p95 novog sistema izjednačen je s p50 prethodnog.

WebRTC pruža temelj za prijenos. Namijenjen je medijima s malim kašnjenjem i može nastaviti raditi uprkos gubitku paketa, odstupanju sata i promjenama veze klijenta. Ako paketi kasne, WebRTC može neprimjetno produžiti zvuk kako bi spriječio prekide, a zatim nakratko ubrzati reprodukciju da bi ponovo sustigao stvarno vrijeme.

Smanjivanjem međuspremnika i blokiranja u cijelom sistemu 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 njen kontekst neprekidno raste, dok se instance modela pokreću i gase prema potražnji.

Kako bismo riješili te probleme, izgradili smo mehanizam za neprimjetno prebacivanje između instanci modela. Kada je potreban prijelaz, možemo uz postojeću instancu zagrijati zamjensku instancu modela, unaprijed je popuniti trenutnim kontekstom sesije, paralelno pokrenuti inferenciju na obje i prebaciti se kada nova instanca bude potpuno spremna.

Isti osnovni mehanizam podržava i dinamičku kompakciju konteksta. Kako razgovor napreduje, njegov nagomilani kontekst na kraju može premašiti ograničenje konteksta modela. Kompakcija može smanjiti kontekst tako da stane unutar ograničenja, ali taj postupak traje. Budući da mijenja raniji kontekst, ona poništava i predmemoriju ključeva i vrijednosti (KV) modela, u kojoj se čuvaju ključevi i vrijednosti pažnje iz prethodno obrađenih tokena. Ponovna izgradnja tog stanja zahtijeva novo početno popunjavanje i donosi dodatno kašnjenje.

Umjesto toga, kompakciju tretiramo kao još jedan kontrolirani prijelaz. Dok izvorna instanca modela nastavlja razgovarati, sistem kompaktira kontekst i priprema zamjensku instancu modela s novim kontekstom. Kada ta instanca bude spremna, možemo se prebaciti bez prekidanja medija. Tako sistem može podržavati dugotrajne pozive i po potrebi provoditi kompakciju.

Zahtjevna obrada ostaje izvan putanje uživo, pa razgovor teče bez zastoja čak i tokom prebacivanja.

Mogućnost GPT‑Livea da poziva postojeće granične modele daje mu veliku moć jer djelotvorno razdvaja „govor“ od dubljeg „razmišljanja“. Da bi ova arhitektura s dva modela djelovala kao jedinstven sistem, morali smo riješiti dva povezana inženjerska problema.

Prvo, rezultati se moraju vratiti dovoljno brzo da budu 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. Istovremeno, drugi sistemi u proizvodu i dalje trebaju zasebne poruke, pa smo tekući razgovor morali predstaviti u obliku koji mogu razumjeti.

Kada pošaljemo delegirani zadatak, optimiziramo vrijeme potrebno da granični model proizvede nešto korisno za razgovor. Glasovni model može nakratko održavati razgovor dok granični model rezonuje ili koristi alate, ali ne može prikriti proizvoljno spor odgovor. Zato smo cijelu petlju delegiranja — usmjeravanje, obradu upita, inferenciju i pozive alata — uključili u vremenski okvir za odziv.

Prva optimizacija jeste pripremiti granični model i sve potrebne alate prije nego što se zatraži delegiranje. Kada glasovna sesija počne, aplikacijski server stvara inferencijsku sesiju za granični model i unaprijed je popunjava početnim kontekstom razgovora, čime osigurava da je upit potpuno obrađen prije prvog delegiranog zahtjeva.

Tu inferencijsku sesiju zatim držimo dostupnom tokom cijelog glasovnog razgovora i za uzastopne zahtjeve koristimo stabilnu vezanost za sesiju. U kombinaciji s predmemoriranjem upita, ove tehnike smanjuju kašnjenje, dok oporavak od kvara radnog procesa ostaje jednostavan.

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

Iako glasovni model obrađuje neprekidne tokove govora, mnogi okolni sistemi i dalje rade sa smjenama korisnika i asistenta, uključujući razgovorno sučelje usluge ChatGPT te dijelove naše analitičke i sigurnosne infrastrukture. Zato aplikacijski server razdvaja preklapajući, ponekad nejasan razgovor na zasebne poruke.

Dok zvuk pristiže, server koristi djelimične transkripte i vremenske signale da utvrdi ko govori i sastavi red poruka. Najnovija poruka ostaje privremena; njen tekst, vrijeme i pripisivanje govorniku mogu se mijenjati kako pristiže još govora. Kada govornik dovoljno dugo zadrži riječ da pripisivanje postane pouzdano, server zaključuje odgovarajuću poruku.

Preklapanje govornika dodatno otežava postupak. Kratka potvrda asistenta dok korisnik govori, npr. „mhm“ ili „u redu“, ne mora nužno postati zasebna poruka. Međutim, sadržajno ubacivanje asistenta često treba biti zasebna poruka. Slično tome, dajemo prednost smislenoj cjelini prikazanih odgovora asistenta čak i kada korisnik progovori usred odgovora.

Svaka politika segmentacije pravi kompromis između svježine i pouzdanosti. Prerano zaključivanje stvara rascjepkanu historiju i nestabilan redoslijed; predugo čekanje odgađa transkripte i funkcije koje od njih zavise. Sistem zato održava dva povezana prikaza razgovora: pretpostavljeni prikaz trenutnog stanja i mjerodavan zapis izgovorenog. Prikaz razgovora u aplikacijskom sučelju može obrađivati ažuriranja, pa koristi pretpostavljeni prikaz. Međutim, bilježenje u analitički sistem zahtijeva konačan transkript.

Tako ostatak usluge ChatGPT dobija stabilan prikaz razgovora, bez nametanja smjena govornika glasovnoj putanji uživo.

Brz odziv počinje čim korisnik pritisne dugme. Uz GPT‑Live sistem mora uspostaviti medijsku putanju i početi slati zvuk kroz model prije nego što razgovor može započeti. Zbog toga je svaki dio pokretanja na kritičnoj putanji.

Kao što je već navedeno, WebRTC pruža snažan temelj za rad u stvarnom vremenu, ali pokretanje standardne WebRTC sesije zahtijeva iznenađujuće mnogo protokolskih usklađivanja i mrežnih povratnih putovanja. WebRTC je nastao prije nego što je smanjenje povratnih putovanja postalo prioritet koji je oblikovao kasnije protokole poput QUIC-a. Zbog toga njegovi osnovni protokoli ponekad ponavljaju isti posao kada se koriste zajedno. Naprimjer, svaki protokol imao je vlastiti mehanizam zaštite od DoS napada, čak i kada nije bio potreban u kontekstu cijelog WebRTC sistema.

Analizirali smo sistem i razvili WebRTC Abridged Roundtrip Protocol (WARP⁠(otvara se u novom prozoru)), koji pokretanje medija i podataka skraćuje sa šest mrežnih povratnih putovanja na samo jedno. WARP to postiže skupom unazad kompatibilnih poboljšanja protokola: prenošenjem DTLS usklađivanja preko ICE-a (SPED⁠(otvara se u novom prozoru)), korištenjem bržeg DTLS 1.3⁠(otvara se u novom prozoru) usklađivanja, prethodnim dogovaranjem SCTP usklađivanja (SNAP⁠(otvara se u novom prozoru)) i prethodnim dogovaranjem podatkovnih kanala umjesto korištenja protokola DCEP⁠(otvara se u novom prozoru).

WARP smo osmislili kao skup otvorenih specifikacija, sarađujući s članovima WebRTC zajednice kako bi širi ekosistem mogao imati koristi od ovog rada. Prijedloge razvijamo kroz radnu grupu TSVWG organizacije IETF, a podrška za WARP već je dodana u libwebrtc i Pion, dok je rad na drugim WebRTC implementacijama u toku.

Nakon optimizacije medijskog usklađivanja izdvojilo se još jedno kašnjenje: razmjena signalizacije kojom se dijele SDP parametri prije nego što WebRTC može uspostaviti vezu. Kako bismo tu razmjenu uklonili s kritične putanje, razvili smo ono što nazivamo Instant Connect. On unaprijed dogovara te parametre bez rezerviranja serverskog kapaciteta i bez izmjena postojećih WebRTC implementacija.

Instant Connect radi paralelno sa standardnim tokom signalizacije. Ako su unaprijed dogovoreni parametri važeći, server može uspostaviti sesiju čim stigne prvi medijski paket. Ako su zastarjeli ili nevažeći, tok signalizacije već je u toku, 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 medijskog toka uživo. Budući da je SDP razmjena uklonjena s kritične putanje, a WARP sažima usklađivanje prijenosa, klijent sada može pokrenuti sesiju jednim UDP paketom. Server može odmah odgovoriti, pa ostatak sistema može početi raditi ono što je korisniku zaista važno: slušati i odgovarati.

Sistem može na papiru izgledati brz, a ipak zastajati pri stvarnom glasovnom saobraćaju. Prije nego što smo omogućili GPT‑Liveu da razgovara s korisnicima, proveli smo nečujni test koji je mali, postepeno rastući udio produkcijskih sesija usluge ChatGPT Voice usmjeravao i na postojeći napredni glasovni način rada i na naš novi sistem. Napredni glasovni način rada nastavio je uobičajeno služiti korisnicima, dok je paralelna putanja izvodila inferenciju samo za čitanje. Tako smo sistem izložili stvarnim klijentima, mrežama, trajanjima sesija i geografskoj raspodjeli, a da nismo promijenili ono što su korisnici čuli.

Jedna od prvih lekcija bila je da se kapacitet ne može svesti na protok GPU-a. Glasovne sesije ostaju otvorene i neprekidno šalju okvire, pa se rukovatelji tokovima na CPU strani, redovi čekanja i mrežne putanje moraju skalirati zajedno s inferencijom. Pod stvarnim opterećenjem jedna pomoćna komponenta dosegla je zasićenje ranije nego što su predviđale naše procjene iz testa opterećenja, pa su se zahtjevi za inferenciju gomilali, a kašnjenje dodatno raslo. Pitanje kapaciteta promijenili smo iz „Koliko zahtjeva GPU može obraditi?“ u „Koliko istovremenih sesija sistem može održavati, a da svaki okvir obradi na vrijeme?“

Test je pokazao i da geografija mora biti među najvažnijim faktorima. Usmjeravanje sesije prema udaljenom kapacitetu može povećati kašnjenje u više tačaka tokom pokretanja i prijenosa. Uvođenje modela počeli smo provjeravati zajedno s regionalnim kapacitetom i konfiguracijom usmjeravanja saobraćaja, a zatim smo kašnjenje raščlanili prema geografskom porijeklu. Približavanje inferencije korisnicima pomoglo je, ali je potvrdilo i širu pouku: odziv cijelog sistema zavisi od svake usluge na putanji, a ne samo od servera modela.

Drugi kvarovi pojavljivali su se tek tokom realističnih životnih ciklusa sesija. Dugotrajne sesije otkrile su pritisak na memoriju i trajnu pohranu. Ponovna povezivanja testirala su kompakciju i obnavljanje stanja. Uobičajeni prekidi veze klijenta otkrili su utrke u usklađivanju gašenja. Ti problemi rijetko su se pojavljivali u kratkim testovima opterećenja jer su zavisili od vremena, nagomilanog stanja i ponašanja preko granica usluga.

Na kraju, produkcijsko testiranje primoralo nas je da poboljšamo praćenje sistema 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 mehanizme i razlike u konfiguraciji testiranih i uvedenih sistema. Zato smo dodali detaljniju telemetriju, provjeru prema pouzdanim konfiguracijama, postepeno povećavanje opterećenja te mogućnost brzog izdvajanja ili isključivanja pojedinačnih putanja. Nečujni test postao je rana proba pokretanja: njime nismo provjeravali samo koliko saobraćaja sistem može prihvatiti nego i koliko brzo možemo otkriti i ograničiti kvar te se oporaviti od njega.

Dovođenje GPT‑Livea na nivo usluge ChatGPT zahtijevalo je potpuno nov sistem izgrađen oko jednog temeljnog načela: glas mora teći. Inferencija putem prijenosa kontinuirano opskrbljuje dvosmjerni model zvukom. Namjenska medijska putanja osigurava pouzdanu isporuku okvira. Asinhrono delegiranje omogućava da se dublje razmišljanje odvija paralelno. Optimizirani prijenos održava brz odziv sve do korisnika.

Arhitektura GPT‑Livea već prerasta u širu platformu za interakciju u stvarnom vremenu. Pokreće ChatGPT Voice dok se on širi s razgovora na koordinaciju agenata, a bit će i temelj predstojećeg GPT‑Live API-ja. S vremenom će omogućiti da glasovna iskustva obuhvate više uređaja, 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⁠.