Com vam crear en sis mesos un sistema en temps real per a una IA de veu àgil

En la IA de veu, saber quan cal parlar és més difícil del que sembla. Les persones es passen el torn de paraula sense esforç en una fracció de segon, però els sistemes anteriors d'IA de veu no podien seguir aquest ritme. La seva arquitectura basada en torns depenia de petits models anomenats detectors de torn, que tenien una tasca poc envejable: si s'avançaven, interrompien l'usuari; si trigaven massa, la resposta semblava lenta. L'LLM, molt més gran, només podia començar a treballar després que el detector prengués la decisió.

GPT‑Live⁠, el nostre sistema de veu de tercera generació, elimina el detector de torn de la ruta d'àudio. El seu model de veu és bidireccional, és a dir, pot escoltar i parlar alhora. Això elimina la necessitat d'un detector independent i fa que la conversa sembli més immediata i natural. Quan cal un raonament més profund o utilitzar eines, GPT‑Live també pot consultar els nostres models d'avantguarda, com GPT‑5.5, sense interrompre el flux de la conversa. En conjunt, aquestes capacitats ofereixen a GPT‑Live una combinació sense precedents de capacitat de resposta conversacional i intel·ligència.

Oferir aquesta experiència a gran escala exigia una nova arquitectura de sistema optimitzada per a una latència baixa. A diferència de la inferència típica de sol·licitud i resposta, el nostre sistema transmet l'àudio entrant al model de veu i la parla sortint a l'usuari, mentre gestiona la delegació per una ruta asíncrona independent. Durant els últims sis mesos, hem redissenyat la inferència del model, la gestió del context i el transport multimèdia per mantenir un flux de parla fluid d'extrem a extrem.

L'arquitectura també crea un límit clar entre la ruta de veu principal i la lògica de l'aplicació. Això facilita personalitzar el comportament de l'aplicació sense afectar-ne la capacitat de resposta. Aquesta base impulsa un ventall creixent de funcions de ChatGPT Voice, com la nova capacitat de controlar l'ordinador i coordinar els agents a l'aplicació d'escriptori de ChatGPT.

En aquest article explicarem per què els sistemes anteriors basats en torns no satisfeien les nostres necessitats i com vam dissenyar el sistema nou perquè oferís capacitat de resposta en totes les capes. Parlarem d'inferència amb estat, gestió dinàmica del context, delegació asíncrona i optimització a escala de protocol, que treballen conjuntament perquè GPT‑Live sembli realment en directe.

Les arquitectures de veu anteriors van heretar la naturalesa basada en torns dels LLM de text, però cada torn es representava com un bloc d'àudio diferenciat en lloc de text. En els sistemes en cascada, la conversió de veu a text, l'LLM i la conversió de text a veu s'executaven l'una rere l'altra. Aquesta seqüenciació afegia latència i ignorava indicis com el to i el ritme.

Els models de veu a veu van millorar aquest enfocament processant l'àudio directament. Entrenar el model perquè entengués i generés parla de manera nativa li permetia conservar detalls perduts en la transcripció i respondre més ràpidament. Però el sistema encara depenia del detector de torn per decidir quan podia començar la inferència. El model gestionava una part més gran de la interacció, però aquesta continuava basada en torns.

GPT‑Live posa el model de veu al control de la conversa: l'àudio entra i surt del model, mentre que el raonament més profund i l'ús d'eines es duen a terme de manera asíncrona. La tasca principal del sistema és mantenir un bucle multimèdia ininterromput. Altres tasques, com invocar models d'avantguarda i conservar la conversa, es duen a terme fora de la ruta en directe.

Mantenir aquest bucle multimèdia sense interrupcions no sempre és fàcil. Qualsevol retard en el transport, el processament o la inferència es pot convertir en una pausa o un artefacte audible. Un sistema anterior basat en torns podia tolerar certa variació en el moment en què arribava un bloc d'àudio. En canvi, un sistema multimèdia en directe ha de lliurar cada trama d'àudio a temps.

La feina anterior a ChatGPT Voice i la Realtime API ens va proporcionar una base important. Ja havíem reconstruït la nostra infraestructura de veu⁠ per transmetre àudio i vídeo directament cap als nostres sistemes i des d'aquests amb una latència més baixa i previsible. GPT‑Live va portar aquest disseny més enllà, en transmetre els continguts multimèdia fins al model mitjançant un nou sistema d'inferència amb estat creat per a la conversa contínua.

Tanmateix, la inferència en flux només era una part de la solució. Perquè funcionés bé en producció, també havíem de garantir un lliurament fiable de l'àudio des del client fins a la pila d'inferència i afrontar els reptes de mantenir l'estat.

Una de les primeres decisions va ser separar expressament el flux multimèdia de la lògica de l'aplicació i del negoci. L'àudio circula entre el client i el model de veu per una ruta ràpida dedicada. La delegació, l'ús d'eines i les altres tasques de l'aplicació es duen a terme rere un límit RPC asíncron. Una crida lenta a una eina o un servei de backend pot retardar el seu propi resultat, però no pot aturar el flux multimèdia.

Aquesta separació també ofereix al sistema un límit clar per a la personalització. Les aplicacions poden canviar les eines, les polítiques i el comportament del backend sense afectar el frontend multimèdia encarregat de mantenir l'àudio en moviment. La ruta en directe es manté petita, previsible i centrada en la feina que s'ha de fer en temps real.

Vam escriure el frontend multimèdia i la lògica d'inferència en Go, en substitució d'una implementació anterior de Python amb asyncio. Això va millorar molt la fluïdesa del lliurament de trames: el p95 del sistema nou igualava el p50 de l'anterior.

WebRTC proporciona la base del transport. Està dissenyat per a continguts multimèdia de baixa latència i pot continuar funcionant malgrat la pèrdua de paquets, la deriva del rellotge i els canvis en la connexió del client. Si els paquets arriben tard, WebRTC pot allargar subtilment l'àudio per evitar buits i, després, accelerar breument la reproducció per tornar a sincronitzar-se amb el temps real.

En minimitzar la memòria intermèdia i els bloquejos arreu del sistema, podem oferir la resposta en menys d'un segon que les persones esperen d'una conversa.

La inferència amb estat té les seves pròpies contrapartides operatives. Una sessió de veu pot mantenir-se activa durant molt de temps, però el context creix contínuament i les instàncies del model s'inicien i s'aturen segons la demanda.

Per abordar aquestes qüestions, vam crear un mecanisme de traspàs fluid entre instàncies del model. Quan cal fer una transició, podem preparar una instància del model substituta en paral·lel amb l'existent, precarregar-la amb el context actual de la sessió, executar la inferència en totes dues alhora i canviar a la nova quan estigui completament a punt.

El mateix mecanisme bàsic també permet la condensació dinàmica de context. A mesura que avança una conversa, el context acumulat pot acabar superant el límit de context del model. La condensació de context en pot reduir la mida perquè s'ajusti al límit, però l'operació requereix temps. A més, com que modifica el context anterior, també invalida la memòria cau de claus i valors (KV) del model, que emmagatzema les claus i els valors d'atenció dels tokens processats prèviament. Reconstruir aquest estat exigeix una nova precàrrega, cosa que introdueix més retard.

En comptes d'això, tractem la condensació de context com una altra transició gestionada. Mentre la instància original del model continua conversant, el sistema condensa el context i prepara una instància substituta amb el context nou. Quan aquesta instància està a punt, podem fer el canvi sense interrompre els continguts multimèdia. Això permet que el sistema admeti trucades llargues i condensi el context sempre que calgui.

La feina més pesada queda fora de la ruta en directe, de manera que la conversa no perd el ritme ni tan sols durant un traspàs.

La capacitat de GPT‑Live d'invocar models d'avantguarda existents li dona molta potència i, a la pràctica, desvincula el fet de "parlar" del de "pensar" més profundament. Però fer que aquesta arquitectura de dos models semblés un únic sistema va exigir resoldre dos problemes d'enginyeria relacionats.

En primer lloc, els resultats han de tornar prou de pressa per ser útils en l'intercanvi en curs, així que havíem de minimitzar la latència de tota la ruta de delegació, des de l'encaminament i el processament de la indicació fins a la inferència i les crides a eines. Alhora, altres sistemes del producte encara necessiten missatges diferenciats, així que havíem de representar la conversa en curs d'una manera que poguessin entendre.

Quan s'envia una delegació, optimitzem el temps fins que el model d'avantguarda produeix alguna cosa útil per a la conversa. El model de veu pot mantenir breument l'intercanvi mentre un model d'avantguarda raona o utilitza eines, però no pot ocultar una resposta arbitràriament lenta. Per tant, vam considerar tot el bucle de delegació —encaminament, processament de la indicació, inferència i crides a eines— part del pressupost de capacitat de resposta.

La primera optimització consisteix a preparar el model d'avantguarda i les eines que necessiti abans que se sol·liciti la delegació. Quan comença una sessió de veu, el servidor d'aplicacions crea una sessió d'inferència per al model d'avantguarda i la precarrega amb el context inicial de la conversa, per garantir que la indicació s'hagi processat completament abans de la primera sol·licitud delegada.

Després mantenim disponible aquesta sessió d'inferència durant tota la conversa de veu i fem servir una afinitat de sessió estable per a les sol·licituds successives. Juntament amb la memòria cau d'indicacions, aquestes tècniques milloren la latència i permeten recuperar-se fàcilment si falla un procés de treball.

L'esforç de raonament, els límits de sortida, els esquemes de les eines i els trajectes d'anada i tornada entre el model i les eines també afecten el moment en què la conversa rep un resultat útil, i vam ajustar aquests factors per obtenir respostes més ràpides. En minimitzar la feina necessària a la ruta de delegació, vam permetre que el model de veu incorporés ràpidament els resultats dels nostres models d'avantguarda.

Tot i que el model de veu treballa amb fluxos continus de parla, molts dels sistemes que l'envolten encara funcionen amb torns de l'usuari i de l'assistent, com ara la interfície de conversa de ChatGPT i parts de la nostra infraestructura d'analítica i seguretat. Per això, el servidor d'aplicacions descompon la conversa superposada i de vegades ambigua en missatges diferenciats.

A mesura que arriba l'àudio, el servidor utilitza transcripcions parcials i senyals temporals per inferir qui té el torn de paraula i crear una cua de missatges. El missatge més recent continua sent provisional: el text, els temps i l'assignació del parlant poden canviar a mesura que arriba més parla. Quan un parlant ha mantingut el torn prou temps perquè l'atribució sigui fiable, el servidor dona per definitiu el missatge corresponent.

La superposició de parlants ho fa més complicat. Una breu mostra d'assentiment de l'assistent mentre parla l'usuari (p. ex., "ahà" o "entesos") no s'ha de convertir necessàriament en un missatge independent. En canvi, sovint sí que ho ha de fer una intervenció substancial de l'assistent. De la mateixa manera, prioritzem la coherència de les respostes de l'assistent que es mostren, fins i tot quan l'usuari parla entremig.

Tota política de segmentació contraposa la immediatesa a la certesa. Confirmar massa aviat genera un historial fragmentat i una ordenació inestable; esperar massa retarda les transcripcions i les funcions que en depenen. Per tant, el sistema manté dues visions relacionades de la conversa: una visió especulativa de l'estat actual i un registre autoritatiu del que s'ha dit. La vista de conversa de la interfície de l'aplicació admet actualitzacions, de manera que utilitza la visió especulativa. Però el registre al canal de processament analític requereix una transcripció definitiva.

Això proporciona a la resta del ChatGPT una visió estable de l'intercanvi sense imposar torns a la ruta de veu en directe.

La capacitat de resposta comença tan bon punt l'usuari fa clic al botó. Amb GPT‑Live, el sistema ha d'establir la ruta multimèdia i començar a enviar àudio al model abans no pugui començar la conversa. Això situa cada part de la seqüència d'inici a la ruta crítica.

Com hem assenyalat abans, WebRTC proporciona una base sòlida per al temps real, però iniciar una sessió WebRTC estàndard exigeix una quantitat sorprenent de protocols d'enllaç i trajectes d'anada i tornada per la xarxa. WebRTC és anterior a l'èmfasi en la reducció dels trajectes d'anada i tornada que va donar forma a protocols posteriors com QUIC. Per això, els protocols subjacents de vegades repeteixen feina quan s'utilitzen conjuntament. Per exemple, cada protocol incloïa el seu propi mecanisme contra atacs DoS, fins i tot quan no calia en el context de la pila WebRTC completa.

Vam analitzar la pila i desenvolupar el WebRTC Abridged Roundtrip Protocol (WARP⁠(s'obre en una finestra nova)), que redueix l'inici dels continguts multimèdia i de les dades de sis trajectes d'anada i tornada per la xarxa a només un. WARP ho aconsegueix amb un conjunt de millores de protocol compatibles amb versions anteriors: incorpora el protocol d'enllaç DTLS sobre ICE (SPED⁠(s'obre en una finestra nova)), utilitza el protocol d'enllaç més ràpid DTLS 1.3⁠(s'obre en una finestra nova), prenegocia el protocol d'enllaç SCTP (SNAP⁠(s'obre en una finestra nova)) i prenegocia els canals de dades en lloc d'utilitzar DCEP⁠(s'obre en una finestra nova).

Vam dissenyar WARP com un conjunt d'especificacions obertes, en col·laboració amb membres de la comunitat WebRTC, perquè tot l'ecosistema es pugui beneficiar d'aquesta feina. Estem fent avançar les propostes mitjançant el grup de treball TSVWG de l'IETF, i tant libwebrtc com Pion ja admeten WARP, mentre continuen els esforços en altres implementacions de WebRTC.

Després d'optimitzar el protocol d'enllaç multimèdia, quedava un retard destacat: l'intercanvi de senyalització utilitzat per compartir els paràmetres SDP abans que WebRTC es pugui connectar. Per treure aquest intercanvi de la ruta crítica, vam desenvolupar el que anomenem Instant Connect. Negocia aquests paràmetres amb antelació, sense reservar capacitat del servidor ni modificar les implementacions existents de WebRTC.

Instant Connect s'executa en paral·lel amb el flux de senyalització estàndard. Si els paràmetres prenegociats són vàlids, el servidor pot materialitzar la sessió quan arriba el primer paquet multimèdia. Si estan obsolets o no són vàlids, el flux de senyalització ja està en marxa, de manera que el client pot recórrer a l'alternativa sense afegir latència.

Junts, Instant Connect i WARP redueixen dràsticament el temps entre la intenció de l'usuari i l'inici del flux multimèdia en directe. Amb l'intercanvi SDP fora de la ruta crítica i WARP condensant el protocol d'enllaç de transport, ara el client pot iniciar una sessió amb un únic paquet UDP. El servidor pot respondre immediatament i permetre que la resta del sistema comenci a fer la feina que realment importa a l'usuari: escoltar i respondre.

Un sistema pot semblar ràpid sobre el paper i, tot i així, bloquejar-se amb trànsit de veu real. Abans de permetre que GPT‑Live parlés amb els usuaris, vam fer una prova silenciosa que dirigia una proporció petita i creixent de les sessions de veu de ChatGPT en producció tant a l'experiència existent del mode de veu avançat com al sistema nou. El mode de veu avançat va continuar atenent els usuaris com sempre, mentre que la ruta paral·lela executava la inferència en mode de només lectura. Això va exposar el sistema a clients, xarxes, durades de sessió i distribucions geogràfiques reals sense canviar el que sentien els usuaris.

Una de les primeres lliçons va ser que la capacitat no es podia reduir al rendiment de les GPU. Les sessions de veu es mantenen obertes i envien trames contínuament, de manera que els gestors de fluxos de la CPU, les cues i les rutes de xarxa han d'escalar al mateix ritme que la inferència. Amb càrrega real, un component auxiliar es va saturar abans del que preveien les proves de càrrega, cosa que va fer acumular les sol·licituds d'inferència i va agreujar la latència. Vam reformular la pregunta sobre la capacitat, de "Quantes sol·licituds pot gestionar una GPU?" a "Quantes sessions simultànies pot mantenir el sistema sense endarrerir cap trama?"

La prova també va convertir la geografia en una qüestió primordial. Dirigir una sessió a una capacitat distant pot afegir retards en diversos punts de l'inici i la transmissió. Vam començar a validar els desplegaments de models juntament amb la capacitat regional i la configuració de l'encaminament del trànsit, i després a desglossar la latència per ubicació d'origen. Apropar la inferència als usuaris hi va ajudar, però també va reforçar una idea més general: la capacitat de resposta d'extrem a extrem depèn de tots els serveis de la ruta, no només del servidor del model.

Altres errors només apareixien en cicles de vida de sessió realistes. Les sessions llargues van posar de manifest la pressió sobre la memòria i la persistència. Les reconnexions van posar a prova la condensació de context i la restauració de l'estat. Les desconnexions normals dels clients van revelar condicions de cursa en el protocol de tancament. Aquests problemes gairebé no apareixien en proves de càrrega breus perquè depenien del temps, de l'estat acumulat i del comportament entre els límits dels serveis.

Finalment, les proves en producció ens van obligar a millorar l'observabilitat i els controls de desplegament. Vam trobar mètriques que barrejaven diferents fonts de latència, taulers amb agregats que ocultaven motors individuals amb problemes i divergències de configuració entre els sistemes provats i els desplegats. Com a resposta, vam afegir telemetria més granular, validació amb configuracions de bon funcionament conegut, increments graduals i la possibilitat d'aïllar o desactivar ràpidament rutes individuals. La prova silenciosa es va convertir en un assaig inicial del llançament, no només per saber quant de trànsit podia acceptar el sistema, sinó també amb quina rapidesa podíem detectar, contenir i resoldre els errors.

Portar GPT‑Live a l'escala del ChatGPT exigia un sistema completament nou, creat al voltant d'un principi fonamental: la veu ha de fluir. La inferència en flux alimenta contínuament el model bidireccional amb àudio. Una ruta dedicada als continguts multimèdia garanteix el lliurament fiable de les trames. La delegació asíncrona permet executar en paral·lel un raonament més profund. Un transport optimitzat manté la capacitat de resposta de l'experiència fins a l'usuari.

L'arquitectura de GPT‑Live ja s'està convertint en una plataforma més àmplia per a la interacció en temps real. Impulsa ChatGPT Voice a mesura que evoluciona de la conversa a la coordinació basada en agents, i serà la base de la futura API de GPT‑Live. Amb el temps, permetrà estendre les experiències de veu a més dispositius, aplicacions i modalitats sense perdre la immediatesa que fa que una conversa de veu sembli en directe.

Si aquests són els problemes d'enginyeria que vols resoldre, vine a treballar amb nosaltres⁠.