Cum am creat în șase luni un sistem în timp real pentru AI vocală cu răspuns rapid

Pentru AI vocală, a ști când să vorbească este mai dificil decât pare. Vorbitorii umani își transferă cu ușurință rândul într-o fracțiune de secundă, însă sistemele vocale cu AI anterioare nu puteau ține pasul cu acest ritm. Arhitectura lor bazată pe schimburi de replici se baza pe modele mici, numite detectoare de tură, care aveau o sarcină ingrată: dacă decideau prea devreme, întrerupeau utilizatorul; dacă decideau prea târziu, răspunsul părea lent. LLM-ul mult mai mare putea începe să lucreze abia după ce detectorul lua o decizie.

GPT‑Live⁠, sistemul nostru vocal de a treia generație, elimină detectorul de tură din ruta audio. Modelul său vocal este full-duplex, ceea ce înseamnă că poate asculta și vorbi simultan. Astfel, nu mai este necesar un detector separat, iar conversația pare mai promptă și mai naturală. Când sunt necesare un raţionament mai aprofundat sau utilizarea instrumentelor, GPT‑Live poate consulta și modelele noastre de vârf, precum GPT‑5.5, fără a întrerupe cursul conversației. Împreună, aceste capacități îi oferă GPT‑Live o combinație fără precedent de promptitudine conversațională și inteligență.

Furnizarea acestei experiențe la scară largă a necesitat o nouă arhitectură de sistem, optimizată pentru latență redusă. Spre deosebire de inferența obișnuită de tip solicitare-răspuns, sistemul nostru transmite în flux sunetul primit către modelul vocal și vorbirea generată înapoi către utilizator, gestionând delegarea pe o rută asincronă separată. În ultimele șase luni, am reproiectat inferența modelului, gestionarea contextului și transportul media pentru a menține vorbirea fluidă de la un capăt la altul.

Arhitectura creează și o delimitare clară între ruta vocală principală și logica aplicației. Astfel, comportamentul aplicației poate fi personalizat cu ușurință, fără a afecta timpul de răspuns. Această bază susține o gamă tot mai largă de capacități în ChatGPT Voice, inclusiv funcția lansată recent pentru controlarea computerului și coordonarea agenților în aplicația ChatGPT pentru desktop.

În acest articol vom explica de ce sistemele anterioare bazate pe schimburi de replici nu ne puteau satisface cerințele și cum am proiectat noul sistem pentru răspuns rapid la fiecare nivel. Vom aborda inferența cu stare, gestionarea dinamică a contextului, delegarea asincronă și optimizarea la nivel de protocol, toate colaborând pentru ca GPT‑Live să pară cu adevărat live.

Arhitecturile vocale anterioare au preluat structura pe replici a LLM-urilor pentru text, însă fiecare replică era reprezentată de un bloc audio distinct, nu de text. În sistemele în cascadă, conversia vorbirii în text, LLM-ul și conversia textului în vorbire rulau succesiv. Această succesiune creștea latența și ignora indicii precum tonul și ritmul.

Modelele de conversie directă a vorbirii în vorbire au îmbunătățit această abordare prin procesarea directă a sunetului. Antrenarea modelului pentru a înțelege și genera în mod nativ vorbirea i-a permis să păstreze detaliile pierdute prin transcriere și să răspundă mai rapid. Sistemul depindea însă în continuare de detectorul de tură pentru a decide când putea începe inferența. Modelul gestiona o parte mai mare a interacțiunii, dar aceasta rămânea bazată pe schimburi de replici.

GPT‑Live pune modelul vocal în controlul conversației: sunetul intră și iese din model, în timp ce raţionamentul aprofundat și utilizarea instrumentelor au loc asincron. Principala sarcină a sistemului este să mențină o buclă media neîntreruptă. Alte operațiuni, precum apelarea modelelor de vârf și păstrarea conversației, au loc în afara rutei live.

Menținerea neîntreruptă a acestei bucle media nu este întotdeauna simplă. Orice întârziere de transport, procesare sau inferență se poate transforma într-o pauză ori o distorsiune perceptibilă. Un sistem anterior bazat pe schimburi de replici putea tolera unele variații ale momentului în care sosea un bloc audio. Un sistem media live trebuie însă să livreze fiecare cadru audio la timp.

Lucrările anterioare la ChatGPT Voice și Realtime API ne-au oferit o bază importantă. Deja ne reconstruiserăm infrastructura vocală⁠ pentru a reda în flux conținut audio și video direct către și dinspre sistemele noastre, cu o latență mai mică și mai previzibilă. GPT‑Live a dus acest design mai departe, redând conținutul media în flux până la model, printr-un nou sistem de inferență cu stare, construit pentru conversații continue.

Inferența în flux era însă doar o parte a soluției. Pentru a funcționa bine în producție, trebuia să asigurăm și livrarea fiabilă a sunetului de la client la stiva de inferență și să gestionăm provocările asociate stării persistente.

Una dintre primele decizii a fost să separăm în mod explicit fluxul media de logica aplicației și de cea operațională. Sunetul circulă între client și modelul vocal pe o rută rapidă dedicată. Delegarea, utilizarea instrumentelor și celelalte operațiuni ale aplicației au loc dincolo de o interfață RPC asincronă. Un apel lent către un instrument sau un serviciu backend își poate întârzia propriul rezultat, dar nu poate bloca fluxul media.

Această separare oferă sistemului și o delimitare clară pentru personalizare. Aplicațiile își pot modifica instrumentele, politicile și comportamentul sistemelor backend fără a afecta componenta media frontend, responsabilă de menținerea fluxului audio. Calea de procesare live rămâne restrânsă, previzibilă și concentrată asupra activităților care trebuie realizate în timp real.

Am scris componenta media frontend și logica de inferență în Go, înlocuind implementarea anterioară în Python, bazată pe asyncio. Acest lucru a îmbunătățit semnificativ fluiditatea livrării cadrelor, valoarea p95 a noului sistem fiind egală cu valoarea p50 a sistemului anterior.

WebRTC asigură baza pentru transport. Este conceput pentru conținut media cu latență redusă și poate continua să funcționeze în pofida pierderii pachetelor, a abaterilor de ceas și a schimbărilor conexiunii clientului. Dacă pachetele sosesc târziu, WebRTC poate prelungi subtil sunetul pentru a preveni întreruperile, apoi poate accelera scurt redarea pentru a reveni la timpul real.

Reducând la minimum stocarea în memoria tampon și blocajele din întregul sistem, putem obține timpul de răspuns sub o secundă pe care oamenii îl așteaptă de la o conversație.

Inferența cu stare presupune propriile compromisuri operaționale. O sesiune vocală poate rămâne activă mult timp, însă contextul ei crește continuu, iar instanțele modelului pornesc și se opresc în funcție de cerere.

Pentru a rezolva aceste probleme, am creat un mecanism de transfer fără întreruperi între instanțele modelului. Când este necesară o tranziție, putem pregăti o instanță înlocuitoare a modelului în paralel cu cea existentă, o putem preîncărca cu contextul curent al sesiunii, putem rula inferența pe ambele în paralel și putem comuta când noua instanță este complet pregătită.

Același mecanism de bază permite și compactarea dinamică a contextului. Pe măsură ce conversația continuă, contextul acumulat poate depăși în cele din urmă limita de context a modelului. Compactarea poate reduce dimensiunea contextului pentru a se încadra în limită, dar operațiunea necesită timp. Iar pentru că modifică istoricul contextului, invalidează și memoria cache cheie-valoare (KV) a modelului, care stochează cheile și valorile de atenție ale tokenurilor procesate anterior. Reconstruirea acestei stări necesită o nouă preîncărcare, ceea ce introduce o întârziere suplimentară.

În schimb, tratăm compactarea ca pe o altă tranziție gestionată. În timp ce instanța inițială a modelului continuă conversația, sistemul compactează contextul și pregătește o instanță înlocuitoare cu noul context. După ce instanța este pregătită, putem comuta fără nicio întrerupere a fluxului media. Astfel, sistemul poate susține apeluri de lungă durată, compactând contextul ori de câte ori este necesar.

Operațiunile complexe rămân în afara rutei live, astfel încât conversația continuă fără ezitare chiar și în timpul transferului.

Capacitatea GPT‑Live de a apela modele de vârf existente îi conferă multă putere, separând efectiv „vorbirea” de „gândirea” aprofundată. Dar pentru ca această arhitectură cu două modele să pară un singur sistem, a trebuit să rezolvăm două probleme inginerești conexe.

În primul rând, rezultatele trebuie să revină suficient de repede pentru a fi utile în dialogul aflat în desfășurare, așa că a trebuit să reducem latența pe întreaga rută de delegare: de la dirijare și procesarea promptului până la inferență și apelarea instrumentelor. În același timp, alte sisteme din produs au încă nevoie de mesaje distincte, așa că a trebuit să reprezentăm conversația în desfășurare într-o formă pe care să o poată înțelege.

Când este trimisă o delegare, optimizăm timpul necesar modelului de vârf pentru a produce ceva util conversației. Modelul vocal poate menține dialogul pentru scurt timp cât un model de vârf raționează sau folosește instrumente, dar nu poate masca un răspuns oricât de lent. Prin urmare, am inclus întreaga buclă de delegare — dirijarea, procesarea promptului, inferența și apelarea instrumentelor — în bugetul de timp pentru răspuns.

Prima optimizare constă în configurarea modelului de vârf și a instrumentelor necesare înainte ca delegarea să fie solicitată. La începerea unei sesiuni vocale, serverul aplicației creează o sesiune de inferență pentru modelul de vârf și o preîncarcă cu contextul inițial al conversației, asigurând procesarea completă a promptului înaintea primei cereri delegate.

Apoi păstrăm sesiunea de inferență disponibilă pe durata conversației vocale și folosim o afinitate stabilă a sesiunii pentru solicitările succesive. Împreună cu stocarea în cache a promptului, aceste tehnici îmbunătățesc latența și permit totodată recuperarea ușoară după defectarea unui proces de lucru.

Efortul de raţionament, limitele de ieșire, schemele instrumentelor și schimburile repetate dintre model și instrumente influențează și ele momentul în care conversația primește un rezultat util, așa că am ajustat acești parametri pentru răspunsuri mai rapide. Reducând la minimum operațiunile necesare pe ruta delegării, am permis modelului vocal să încorporeze rapid rezultatele modelelor noastre de vârf.

Deși modelul vocal operează cu fluxuri continue de vorbire, multe dintre sistemele din jurul său funcționează încă pe baza replicilor utilizatorului și asistentului, inclusiv interfața de conversație ChatGPT și componente ale infrastructurii noastre de analiză și siguranță. Prin urmare, serverul aplicației descompune conversația suprapusă și uneori ambiguă în mesaje distincte.

Pe măsură ce sosește sunetul, serverul folosește transcrieri parțiale și semnale temporale pentru a deduce cine vorbește și pentru a construi o coadă de mesaje. Cel mai nou mesaj rămâne provizoriu; textul, momentul și atribuirea vorbitorului se pot schimba pe măsură ce sosește mai mult conținut vocal. După ce un vorbitor și-a păstrat suficient timp rândul pentru ca atribuirea să fie fiabilă, serverul finalizează mesajul corespunzător.

Suprapunerea vorbitorilor complică situația. O confirmare scurtă din partea asistentului în timp ce utilizatorul vorbește (de exemplu, „mm hmm” sau „okay”) nu trebuie neapărat să devină un mesaj separat. O intervenție substanțială a asistentului ar trebui însă adesea să devină un mesaj separat. În mod similar, acordăm prioritate coerenței răspunsurilor afișate ale asistentului, chiar și atunci când utilizatorul vorbește între timp.

Orice politică de segmentare presupune un compromis între actualitate și certitudine. Finalizarea prea devreme produce un istoric fragmentat și o ordine instabilă; așteptarea prea îndelungată întârzie transcrierile și funcțiile care depind de ele. Prin urmare, sistemul menține două perspective conexe asupra conversației: o perspectivă speculativă asupra stării curente și o evidență definitivă a celor spuse. Vizualizarea conversației din interfața aplicației poate gestiona actualizări, așa că folosește perspectiva speculativă. Înregistrarea în sistemul de analiză necesită însă o transcriere finală.

Astfel, restul sistemului ChatGPT primește o perspectivă stabilă asupra dialogului, fără a impune schimburi stricte de replici pe ruta vocală live.

Viteza de răspuns contează din clipa în care utilizatorul apasă butonul. Cu GPT‑Live, sistemul trebuie să stabilească ruta media și să înceapă alimentarea modelului cu sunet înainte ca discuția să poată începe. Astfel, fiecare etapă a secvenței de pornire ajunge pe ruta critică.

După cum am menționat, WebRTC oferă o bază solidă pentru comunicarea în timp real, însă pornirea unei sesiuni WebRTC standard necesită un număr surprinzător de negocieri de protocol și schimburi dus-întors prin rețea. WebRTC precedă preocuparea pentru reducerea schimburilor dus-întors care a influențat protocoalele ulterioare, precum QUIC. Prin urmare, protocoalele sale de bază repetă uneori aceleași operațiuni atunci când sunt folosite împreună. De exemplu, fiecare protocol includea propriul mecanism anti-DoS, chiar și atunci când nu era necesar în contextul întregii stive WebRTC.

Am analizat stiva și am dezvoltat WebRTC Abridged Roundtrip Protocol (WARP⁠(se deschide într-o fereastră nouă)), care reduce pornirea fluxurilor media și de date de la șase schimburi dus-întors prin rețea la unul singur. WARP realizează acest lucru printr-un set de îmbunătățiri de protocol compatibile cu versiunile anterioare: includerea negocierii DTLS în ICE (SPED⁠(se deschide într-o fereastră nouă)), folosirea negocierii mai rapide DTLS 1.3⁠(se deschide într-o fereastră nouă), prenegocierea SCTP (SNAP⁠(se deschide într-o fereastră nouă)) și prenegocierea canalelor de date în locul utilizării DCEP⁠(se deschide într-o fereastră nouă).

Am conceput WARP ca pe un set de specificații deschise, colaborând cu membri ai comunității WebRTC, astfel încât întregul ecosistem să beneficieze de această activitate. Promovăm propunerile prin grupul de lucru TSVWG al IETF, iar compatibilitatea WARP a fost deja adăugată în libwebrtc și Pion, în timp ce se lucrează și la alte implementări WebRTC.

După optimizarea negocierii media, mai rămânea o întârziere evidentă: schimbul de semnalizare folosit pentru transmiterea parametrilor SDP înainte ca WebRTC să se poată conecta. Pentru a elimina acest schimb de pe ruta critică, am dezvoltat ceea ce numim Instant Connect. Acesta negociază parametrii în avans, fără a rezerva capacitate pe server și fără a modifica implementările WebRTC existente.

Instant Connect rulează în paralel cu fluxul standard de semnalizare. Dacă parametrii prenegociați sunt valizi, serverul poate crea efectiv sesiunea la sosirea primului pachet media. Dacă parametrii sunt expirați sau nevalizi, fluxul de semnalizare este deja în desfășurare, astfel încât clientul poate reveni la acesta fără latență suplimentară.

Împreună, Instant Connect și WARP reduc considerabil timpul dintre intenția utilizatorului și pornirea fluxului media live. Prin scoaterea schimbului SDP de pe ruta critică și comprimarea negocierii transportului cu WARP, clientul poate porni acum o sesiune cu un singur pachet UDP. Serverul poate răspunde imediat, permițând restului sistemului să înceapă operațiunile care contează cu adevărat pentru utilizator: ascultarea și răspunsul.

Un sistem poate părea rapid pe hârtie, dar se poate bloca în condiții reale de trafic vocal. Înainte ca GPT‑Live să discute cu utilizatorii, am efectuat un test silențios care direcționa o proporție mică și treptat crescătoare a sesiunilor ChatGPT Voice din producție atât către experiența existentă a modului vocal avansat, cât și către noul nostru sistem. Modul vocal avansat a continuat să deservească utilizatorii ca de obicei, în timp ce ruta din umbră efectua inferențe în regim doar în citire. Astfel, sistemul a fost expus unor clienți, rețele, durate ale sesiunilor și distribuții geografice reale, fără a schimba ceea ce auzeau utilizatorii.

Una dintre primele lecții a fost că o capacitate nu putea fi redusă la randamentul GPU-ului. Sesiunile vocale rămân deschise și trimit cadre continuu, așadar gestionarii fluxurilor de pe CPU, cozile și rutele de rețea trebuie să se scaleze odată cu inferența. Sub o sarcină reală, o componentă auxiliară a ajuns la saturație mai devreme decât indicau estimările testelor noastre de încărcare, ceea ce a dus la acumularea solicitărilor de inferență și la agravarea latenței. Am reformulat întrebarea privind capacitatea, de la „Câte solicitări poate gestiona un GPU?” la „Câte sesiuni simultane poate susține sistemul, păstrând fiecare cadru în grafic?”

Testul a arătat și că distribuția geografică este un aspect esențial. Direcționarea unei sesiuni către resurse aflate la distanță poate adăuga întârzieri în mai multe puncte, atât la pornire, cât și în timpul redării în flux. Am început să validăm lansările modelelor împreună cu capacitatea regională și configurația de dirijare a traficului, apoi să defalcăm latența în funcție de regiunea sursă. Apropierea inferenței de utilizatori a ajutat, dar a confirmat și lecția mai amplă: viteza de răspuns de la un capăt la altul depinde de fiecare serviciu de pe traseu, nu doar de serverul modelului.

Alte erori au apărut numai pe parcursul unor cicluri de viață realiste ale sesiunilor. Sesiunile de lungă durată au evidențiat presiuni asupra memoriei și persistenței. Reconectările au pus la încercare compactarea și restabilirea stării. Deconectările obișnuite ale clienților au scos la iveală condiții de concurență în negocierea închiderii. Aceste probleme apăreau rar în testele scurte de încărcare, deoarece depindeau de timp, de starea acumulată și de comportamentul dincolo de limitele serviciilor.

În cele din urmă, testarea în producție ne-a obligat să îmbunătățim observabilitatea și mecanismele de control al lansării. Am găsit metrici care combinau surse diferite de latență, panouri de control ale căror valori agregate ascundeau motoare individuale cu probleme și diferențe de configurație între sistemele testate și cele implementate. Ca răspuns, am adăugat telemetrie mai granulară, validare în raport cu configurații despre care știam că funcționează, creșteri etapizate și posibilitatea de a izola sau dezactiva rapid rute individuale. Testul silențios a devenit o repetiție timpurie pentru lansare, nu doar pentru volumul de trafic pe care îl putea accepta sistemul, ci și pentru rapiditatea cu care puteam detecta, limita și remedia o defecțiune.

Aducerea GPT‑Live la scara ChatGPT a necesitat un sistem complet nou, construit în jurul unui principiu fundamental: vocea trebuie să curgă neîntrerupt. Inferența în flux alimentează continuu modelul full-duplex cu sunet. O rută media dedicată asigură livrarea fiabilă a cadrelor. Delegarea asincronă permite proceselor de gândire aprofundată să ruleze în paralel. Transportul optimizat menține răspunsul rapid al experienței până la utilizator.

Arhitectura din spatele GPT‑Live devine deja o platformă mai amplă pentru interacțiuni în timp real. Aceasta susține ChatGPT Voice pe măsură ce evoluează de la conversație la coordonarea agenților și va sta la baza viitorului API GPT‑Live. În timp, va permite extinderea experiențelor vocale pe mai multe dispozitive, aplicații și modalități, fără a sacrifica naturalețea imediată care face conversația vocală să pară live.

Dacă acestea sunt genul de probleme inginerești pe care vrei să le rezolvi, vino să lucrezi cu noi⁠.