Slik bygde vi et sanntidssystem for responsiv tale-AI på seks måneder

For tale-AI er det vanskeligere enn man skulle tro å vite når man skal snakke. Mennesker veksler uanstrengt på å snakke i løpet av brøkdelen av et sekund, men tidligere tale-AI-systemer klarte ikke å holde tritt med denne rytmen. Den turbaserte arkitekturen deres var avhengig av små modeller kalt tursensorer, som hadde en utakknemlig oppgave: Gjetter de for tidlig, blir brukeren avbrutt. Gjetter de for sent, føles svaret tregt. Først etter at sensoren hadde tatt avgjørelsen, kunne den langt større LLM-en begynne å arbeide.

GPT‑Live⁠, tredjegenerasjonssystemet vårt for tale, fjerner tursensoren fra lydbanen. Talemodellen bruker full dupleks, noe som betyr at den kan lytte og snakke samtidig. Dermed trengs ingen separat sensor, og samtalen føles mer umiddelbar og naturlig. Når det kreves grundigere resonnering eller verktøybruk, kan GPT‑Live også rådføre seg med de banebrytende modellene våre, som GPT‑5.5, uten å avbryte samtaleflyten. Til sammen gir disse egenskapene GPT‑Live en enestående kombinasjon av responsiv samtale og intelligens.

Å levere denne opplevelsen i stor skala krevde en ny systemarkitektur optimalisert for lav forsinkelse. I motsetning til vanlig forespørsel–svar-inferens strømmer systemet innkommende lyd inn i talemodellen og tale tilbake til brukeren, mens delegering håndteres i en separat asynkron bane. I løpet av de siste seks månedene har vi omarbeidet modellinferens, konteksthåndtering og medietransport for å holde taleflyten jevn fra ende til ende.

Arkitekturen skaper også et tydelig skille mellom den sentrale talebanen og applikasjonslogikken. Det gjør det enkelt å tilpasse applikasjonens atferd uten å påvirke responstiden. Dette fundamentet driver et voksende utvalg funksjoner i ChatGPT Voice, blant annet den nylig lanserte muligheten til å styre datamaskinen og koordinere agentene dine i ChatGPT‑skrivebordsappen.

I dette innlegget forklarer vi hvorfor tidligere turbaserte systemer ikke oppfylte behovene våre, og hvordan vi utviklet det nye systemet for responsivitet i alle lag. Vi tar for oss tilstandsbevarende inferens, dynamisk konteksthåndtering, asynkron delegering og optimalisering på protokollnivå – alt i samspill for å få GPT‑Live til å føles virkelig direkte.

Tidligere talearkitekturer arvet den turbaserte strukturen fra tekstbaserte LLM-er, men hver tur ble representert som en avgrenset lydblokk i stedet for tekst. I kaskadesystemer kjørte tale-til-tekst, LLM-en og tekst-til-tale etter hverandre. Denne sekvensen ga økt forsinkelse og overså signaler som tonefall og taletempo.

Tale-til-tale-modeller forbedret denne tilnærmingen ved å behandle lyd direkte. Ved å trene modellen til å forstå og generere tale direkte kunne den bevare detaljer som går tapt ved transkripsjon, og svare raskere. Systemet var likevel fortsatt avhengig av tursensoren for å avgjøre når inferensen kunne begynne. Modellen håndterte mer av samhandlingen, men denne var fortsatt turbasert.

GPT‑Live lar talemodellen styre samtalen: Lyd strømmer inn og ut av modellen, mens grundigere resonnering og verktøybruk skjer asynkront. Systemets hovedoppgave er å opprettholde en uavbrutt mediesløyfe. Annet arbeid, som å bruke banebrytende modeller og lagre samtalen, skjer utenfor sanntidsbanen.

Det er ikke alltid enkelt å holde denne mediesløyfen i gang uten avbrudd. Enhver forsinkelse i transport, behandling eller inferens kan bli til en hørbar pause eller lydfeil. Et tidligere turbasert system kunne tåle noe variasjon i når en lydblokk ankom. Et system for direktestrømmet medieinnhold må derimot levere hver lydramme til rett tid.

Tidligere arbeid med ChatGPT Voice og Realtime API ga oss et viktig fundament. Vi hadde allerede bygget om taleinfrastrukturen vår⁠ slik at lyd og video kunne strømmes direkte inn og ut av systemene våre med lavere og mer forutsigbar forsinkelse. GPT‑Live videreutviklet denne løsningen ved å strømme medier helt frem til modellen gjennom et nytt tilstandsbevarende inferenssystem bygget for kontinuerlige samtaler.

Strømmet inferens var imidlertid bare en del av løsningen. For å få dette til å fungere godt i produksjon måtte vi også sikre pålitelig levering av lyd fra klienten til inferensstakken og håndtere utfordringene ved å bevare tilstand.

En tidlig beslutning var å skille medieflyten tydelig fra applikasjons- og forretningslogikken. Lyden går mellom klienten og talemodellen via en egen hurtigbane. Delegering, verktøybruk og annet applikasjonsarbeid skjer bak et asynkront RPC-grensesnitt. Et tregt verktøykall eller en treg backendtjeneste kan forsinke sitt eget resultat, men kan ikke stanse medieflyten.

Dette skillet gir også systemet en tydelig grense for tilpasning. Applikasjoner kan endre verktøy, retningslinjer og backendatferd uten å påvirke mediegrensesnittet som holder lyden i bevegelse. Sanntidsbanen forblir liten, forutsigbar og konsentrert om arbeidet som må skje i sanntid.

Vi skrev mediegrensesnittet og inferenslogikken i Go og erstattet en tidligere Python-implementering basert på asyncio. Dette ga vesentlig jevnere rammelevering, og p95 i det nye systemet tilsvarte p50 i det forrige.

WebRTC utgjør transportfundamentet. Det er utviklet for medier med lav forsinkelse og kan fortsette å fungere ved pakketap, klokkeavvik og endringer i klienttilkoblingen. Hvis pakker kommer for sent, kan WebRTC strekke lyden umerkelig for å unngå opphold og deretter øke avspillingshastigheten kortvarig for å komme à jour med sanntiden.

Ved å minimere bufring og blokkering i hele systemet kan vi oppnå responstiden på under ett sekund som mennesker forventer i en samtale.

Tilstandsbevarende inferens har sine egne driftsmessige avveininger. En taleøkt kan være aktiv lenge, men konteksten vokser kontinuerlig, og modellinstanser startes og stoppes etter behov.

For å håndtere dette bygget vi en sømløs mekanisme for overlevering mellom modellinstanser. Når en overgang er nødvendig, kan vi varme opp en ny modellinstans parallelt med den eksisterende, forhåndsfylle den med øktens gjeldende kontekst, kjøre inferens mot begge samtidig og bytte når den nye instansen er helt klar.

Den samme grunnleggende mekanismen støtter også dynamisk kontekstkomprimering. Etter hvert som en samtale fortsetter, kan den akkumulerte konteksten til slutt overskride modellens kontekstgrense. Komprimering kan redusere konteksten slik at den holder seg innenfor grensen, men operasjonen tar tid. Fordi den endrer tidligere kontekst, ugyldiggjør den også modellens nøkkel-verdi-hurtigbuffer (KV), som lagrer oppmerksomhetsnøkler og -verdier fra tidligere behandlede tokener. Å bygge opp denne tilstanden på nytt krever en ny forhåndsfylling, noe som gir ytterligere forsinkelse.

I stedet behandler vi komprimering som en ny kontrollert overgang. Mens den opprinnelige modellinstansen fortsetter samtalen, komprimerer systemet konteksten og klargjør en ny modellinstans med den nye konteksten. Når denne instansen er klar, kan vi bytte uten avbrudd i medieflyten. Dermed kan systemet støtte langvarige samtaler og komprimere ved behov.

Det tunge arbeidet holdes utenfor sanntidsbanen, slik at samtalen flyter uavbrutt selv under en overlevering.

GPT‑Lives evne til å bruke eksisterende banebrytende modeller gir systemet stor kraft og skiller i praksis «samtalen» fra den grundigere «tenkningen». Men for at denne tomodellarkitekturen skulle oppleves som ett system, måtte vi løse to beslektede tekniske problemer.

For det første må resultatene komme raskt nok til å være nyttige i den pågående samtalen. Derfor måtte vi minimere forsinkelsen i hele delegeringsbanen, fra ruting og behandling av prompten til inferens og verktøykall. Samtidig trenger andre systemer i produktet fortsatt avgrensede meldinger, så vi måtte representere den pågående samtalen i en form de kunne forstå.

Når en delegering sendes, optimaliserer vi tiden frem til den banebrytende modellen produserer noe nyttig for samtalen. Talemodellen kan holde samtalen i gang en kort stund mens en banebrytende modell resonnerer eller bruker verktøy, men den kan ikke skjule en vilkårlig treg respons. Derfor regnet vi hele delegeringssløyfen – ruting, behandling av prompten, inferens og verktøykall – inn i tidsbudsjettet for respons.

Den første optimaliseringen er å klargjøre den banebrytende modellen og eventuelle verktøy den trenger, før delegeringen etterspørres. Når en taleøkt starter, oppretter applikasjonsserveren en inferensøkt for den banebrytende modellen og forhåndsfyller den med den innledende samtalekonteksten. Dermed er prompten ferdigbehandlet før den første delegerte forespørselen.

Deretter holder vi inferensøkten tilgjengelig gjennom hele talesamtalen og bruker stabil økttilknytning for påfølgende forespørsler. Sammen med hurtigbufring av prompter reduserer disse teknikkene forsinkelsen, samtidig som det er enkelt å gjenopprette etter feil i en arbeidsnode.

Resonneringsinnsats, resultatgrenser, verktøyskjemaer og turer mellom modell og verktøy påvirker også når samtalen får et nyttig resultat. Vi justerte derfor disse faktorene for å oppnå raskere svar. Ved å minimere arbeidet i delegeringsbanen gjorde vi det mulig for talemodellen å ta i bruk resultater fra de banebrytende modellene våre raskt.

Selv om talemodellen arbeider med kontinuerlige talestrømmer, bruker mange av systemene rundt den fortsatt turer mellom bruker og assistent. Det gjelder blant annet samtalegrensesnittet i ChatGPT og deler av infrastrukturen vår for analyse og sikkerhet. Applikasjonsserveren skiller derfor den overlappende og tidvis tvetydige samtalen i avgrensede meldinger.

Etter hvert som lyden kommer inn, bruker serveren delvise transkripsjoner og tidssignaler til å utlede hvem som har ordet, og bygger opp en meldingskø. Den nyeste meldingen forblir foreløpig. Teksten, tidsangivelsen og talertilordningen kan endres etter hvert som mer tale kommer inn. Når en taler har hatt ordet lenge nok til at tilordningen er pålitelig, ferdigstiller serveren den tilhørende meldingen.

Overlappende tale gjør dette mer komplisert. En kort bekreftelse fra assistenten mens brukeren snakker, for eksempel «mhm» eller «greit», bør ikke nødvendigvis bli en egen melding. Et innholdsrikt innspill fra assistenten bør derimot ofte bli det. På samme måte prioriterer vi sammenheng i assistentsvarene som vises, selv når brukeren snakker midt i dem.

Alle segmenteringsregler innebærer en avveining mellom aktualitet og sikkerhet. Hvis meldinger fastsettes for tidlig, blir historikken oppstykket og rekkefølgen ustabil. Venter man for lenge, forsinkes transkripsjonene og funksjonene som avhenger av dem. Systemet opprettholder derfor to beslektede visninger av samtalen: en foreløpig visning av gjeldende tilstand og en autoritativ oversikt over det som ble sagt. Samtalevisningen i applikasjonsgrensesnittet kan håndtere oppdateringer og bruker derfor den foreløpige visningen. Logging til analyseprosessen krever derimot en endelig transkripsjon.

Dette gir resten av ChatGPT en stabil visning av samtalen uten å påtvinge sanntidsbanen for tale en turbasert struktur.

Responsiviteten begynner idet brukeren klikker på knappen. Med GPT‑Live må systemet opprette mediebanen og begynne å sende lyd gjennom modellen før samtalen kan starte. Dermed havner alle deler av oppstartssekvensen på den kritiske banen.

Som nevnt ovenfor gir WebRTC et solid sanntidsfundament, men å starte en standard WebRTC-økt krever overraskende mange protokollhåndtrykk og nettverksrundturer. WebRTC ble utviklet før fokuset på å minimere rundturer, som senere formet protokoller som QUIC. Derfor gjentar de underliggende protokollene noen ganger arbeid når de brukes sammen. Hver protokoll hadde for eksempel sin egen mekanisme mot tjenestenektangrep, selv når den ikke var nødvendig i sammenheng med hele WebRTC-stakken.

Vi analyserte stakken og utviklet WebRTC Abridged Roundtrip Protocol (WARP⁠(åpnes i et nytt vindu)), som reduserer oppstarten av medier og data fra seks nettverksrundturer til bare én. WARP oppnår dette med flere bakoverkompatible protokollforbedringer: DTLS-håndtrykket sendes sammen med ICE (SPED⁠(åpnes i et nytt vindu)), det raskere DTLS 1.3⁠(åpnes i et nytt vindu)-håndtrykket brukes, SCTP-håndtrykket forhåndsforhandles (SNAP⁠(åpnes i et nytt vindu)), og datakanaler forhåndsforhandles i stedet for å bruke DCEP⁠(åpnes i et nytt vindu).

Vi utformet WARP som et sett med åpne spesifikasjoner i samarbeid med bidragsytere fra WebRTC-miljøet, slik at hele økosystemet kan dra nytte av arbeidet. Vi viderefører forslagene gjennom IETFs TSVWG-arbeidsgruppe. Støtte for WARP er allerede lagt til i både libwebrtc og Pion, og arbeid pågår i andre WebRTC-implementeringer.

Etter at vi hadde optimalisert mediehåndtrykket, sto én gjenværende forsinkelse tydelig frem: signaleringsutvekslingen som brukes til å dele SDP-parametere før WebRTC kan koble til. For å fjerne denne utvekslingen fra den kritiske banen utviklet vi det vi kaller Instant Connect. Løsningen forhandler disse parameterne på forhånd uten å reservere serverkapasitet og uten endringer i eksisterende WebRTC-implementeringer.

Instant Connect kjører parallelt med standardflyten for signalering. Hvis de forhåndsforhandlede parameterne er gyldige, kan serveren opprette økten når den første mediepakken ankommer. Hvis de er utdaterte eller ugyldige, er signaleringsflyten allerede i gang, slik at klienten kan falle tilbake uten ekstra forsinkelse.

Sammen reduserer Instant Connect og WARP tiden fra brukerens initiativ til direkte medieflyt dramatisk. Når SDP-utvekslingen er fjernet fra den kritiske banen og WARP har samlet transporthåndtrykket, kan klienten starte en økt med én enkelt UDP-pakke. Serveren kan svare umiddelbart, slik at resten av systemet kan begynne med det brukeren faktisk er opptatt av: å lytte og svare.

Et system kan se raskt ut på papiret, men likevel stoppe opp under reell taletrafikk. Før vi lot GPT‑Live snakke med brukere, gjennomførte vi en stille test der en liten, gradvis økende andel av ChatGPT Voice-øktene i produksjon ble rutet til både den eksisterende opplevelsen med avansert talemodus og det nye systemet vårt. Avansert talemodus betjente fortsatt brukerne som vanlig, mens skyggeløsningen kjørte inferens i skrivebeskyttet modus. Dermed ble systemet utsatt for reelle klienter, nettverk, øktlengder og geografisk fordeling uten at det endret hva brukerne hørte.

Noe av det første vi lærte, var at kapasitet ikke kunne reduseres til GPU-gjennomstrømming. Taleøkter forblir åpne og sender kontinuerlig rammer, så strømbehandlere på CPU-siden, køer og nettverksbaner må skaleres i takt med inferensen. Under reell belastning nådde en støttekomponent kapasitetsgrensen tidligere enn belastningstestene våre tilsa. Dermed hopet inferensforespørslene seg opp, og forsinkelsen økte ytterligere. Vi endret kapasitetsspørsmålet fra «Hvor mange forespørsler kan en GPU håndtere?» til «Hvor mange samtidige økter kan systemet opprettholde og samtidig behandle hver ramme til rett tid?»

Testen gjorde også geografi til et sentralt hensyn. Ruting av en økt til fjern kapasitet kan gi forsinkelser på flere punkter under oppstart og strømming. Vi begynte å validere modellutrullinger sammen med regional kapasitet og konfigurasjonen for trafikkstyring, og deretter analysere forsinkelsen etter geografisk opprinnelse. Det hjalp å flytte inferensen nærmere brukerne, men understreket også en bredere lærdom: Responstiden fra ende til ende avhenger av alle tjenestene i kjeden, ikke bare modellserveren.

Andre feil viste seg bare gjennom realistiske øktforløp. Langvarige økter avdekket press på minne og vedvarende lagring. Gjentilkoblinger satte komprimering og gjenoppretting av tilstand på prøve. Vanlige klientfrakoblinger avdekket kappløpstilstander i nedstengingsprosedyren. Disse problemene viste seg sjelden i korte belastningstester fordi de var avhengige av tid, akkumulert tilstand og atferd på tvers av tjenestegrenser.

Til slutt tvang produksjonstestingen oss til å forbedre observerbarheten og kontrollene for utrulling. Vi fant måledata som blandet sammen ulike forsinkelseskilder, instrumentpaneler der aggregerte data skjulte enkelte motorer med problemer, og konfigurasjonsavvik mellom testede og utrullede systemer. Som svar innførte vi mer detaljert telemetri, validering mot konfigurasjoner vi visste fungerte, trinnvis oppskalering og muligheten til raskt å isolere eller deaktivere enkeltbaner. Den stille testen ble en tidlig generalprøve på lanseringen – ikke bare på hvor mye trafikk systemet kunne håndtere, men også på hvor raskt vi kunne oppdage, begrense og komme oss etter feil.

Å bringe GPT‑Live opp på ChatGPT‑skala krevde et helt nytt system bygget rundt ett grunnleggende prinsipp: Talen må flyte. Strømmet inferens forsyner full dupleks-modellen kontinuerlig med lyd. En dedikert mediebane sikrer pålitelig levering av rammer. Asynkron delegering gjør at grundigere tenkning kan foregå parallelt. Optimalisert transport holder opplevelsen responsiv helt frem til brukeren.

Arkitekturen bak GPT‑Live er allerede i ferd med å bli en bredere plattform for samhandling i sanntid. Den driver ChatGPT Voice etter hvert som tjenesten utvides fra samtaler til agentbasert koordinering, og vil danne grunnlaget for det kommende GPT‑Live-API-et. Over tid vil den gjøre det mulig å tilby taleopplevelser på flere enheter, i flere apper og på tvers av flere modaliteter uten å ofre umiddelbarheten som får talesamtaler til å føles direkte.

Hvis dette er typen tekniske problemer du ønsker å løse, kan du jobbe sammen med oss⁠.