Hoe we in zes maanden een realtimesysteem voor responsieve spraak-AI bouwden

Voor spraak-AI is weten wanneer je moet spreken moeilijker dan het klinkt. Mensen geven elkaar moeiteloos binnen een fractie van een seconde het woord, maar eerdere spraak-AI-systemen konden dat ritme niet bijhouden. Hun beurtgebaseerde architectuur vertrouwde op kleine modellen die beurtendetectors werden genoemd. Die hadden een ondankbare taak: te vroeg beslissen en de gebruiker wordt onderbroken; te laat beslissen en het antwoord voelt traag. Pas nadat de detector een beslissing had genomen, kon de veel grotere LLM aan de slag.

GPT‑Live⁠, ons spraaksysteem van de derde generatie, haalt de beurtendetector uit het audiopad. Het spraakmodel werkt full-duplex, wat betekent dat het tegelijkertijd kan luisteren en spreken. Daardoor is geen afzonderlijke detector meer nodig en voelt het gesprek directer en natuurlijker aan. Wanneer diepgaandere redenering of toolgebruik nodig is, kan GPT‑Live ook onze grensverleggende modellen raadplegen, zoals GPT‑5.5, zonder de gespreksstroom te onderbreken. Samen geven deze mogelijkheden GPT‑Live een ongekende combinatie van responsiviteit en intelligentie in gesprekken.

Om deze ervaring op grote schaal te bieden, was een nieuwe systeemarchitectuur nodig die voor lage latentie is geoptimaliseerd. Anders dan bij gebruikelijke inferentie op basis van verzoeken en antwoorden, streamt ons systeem binnenkomende audio naar het spraakmodel en gesproken uitvoer terug naar de gebruiker, terwijl delegatie via een afzonderlijk asynchroon pad verloopt. De afgelopen zes maanden hebben we modelinferentie, contextbeheer en mediatransport herzien om spraak van begin tot eind soepel te laten doorstromen.

De architectuur zorgt ook voor een duidelijke scheiding tussen het centrale spraakpad en de applicatielogica. Daardoor kan het applicatiegedrag eenvoudig worden aangepast zonder de responsiviteit te beïnvloeden. Deze basis ondersteunt steeds meer mogelijkheden in ChatGPT Voice, waaronder de onlangs gelanceerde functie om je computer te bedienen en je agents te coördineren in de ChatGPT‑desktopapp.

In dit artikel leggen we uit waarom eerdere beurtgebaseerde systemen niet aan onze behoeften voldeden en hoe we het nieuwe systeem op elke laag responsief hebben gemaakt. We bespreken statusbehoudende inferentie, dynamisch contextbeheer, asynchrone delegatie en optimalisatie op protocolniveau. Samen laten die GPT‑Live echt live aanvoelen.

Eerdere spraakarchitecturen namen het beurtgebaseerde karakter van tekst-LLM's over, maar vertegenwoordigden elke beurt als een afzonderlijk audioblok in plaats van tekst. In cascadesystemen werden spraak-naar-tekst, de LLM en tekst-naar-spraak achter elkaar uitgevoerd. Deze opeenvolging zorgde voor extra latentie en negeerde signalen zoals toon en spreektempo.

Modellen voor spraak naar spraak verbeterden deze aanpak door audio rechtstreeks te verwerken. Door het model te trainen om spraak rechtstreeks te begrijpen en te genereren, kon het details behouden die bij transcriptie verloren gaan en sneller reageren. Het systeem bleef echter afhankelijk van de beurtendetector om te bepalen wanneer de inferentie kon beginnen. Het model nam een groter deel van de interactie voor zijn rekening, maar die interactie bleef beurtgebaseerd.

GPT‑Live geeft het spraakmodel de regie over het gesprek: audio stroomt het model in en uit, terwijl diepgaandere redenering en toolgebruik asynchroon plaatsvinden. De voornaamste taak van het systeem is een ononderbroken medialus in stand houden. Ander werk, zoals het aanroepen van grensverleggende modellen en het permanent opslaan van het gesprek, vindt buiten het livepad plaats.

Het is niet altijd eenvoudig om deze medialus ononderbroken te laten werken. Elke vertraging in transport, verwerking of inferentie kan leiden tot een hoorbare pauze of vervorming. Een eerder beurtgebaseerd systeem kon enige variatie verdragen in het moment waarop een audioblok binnenkwam. Een live mediasysteem moet elk audioframe echter op tijd leveren.

Eerder werk aan ChatGPT Voice en de Realtime API bood ons een belangrijke basis. We hadden onze spraakinfrastructuur al opnieuw opgebouwd⁠ om audio en video rechtstreeks onze systemen in en uit te streamen, met een lagere en voorspelbaardere latentie. GPT‑Live voerde dit ontwerp verder door en streamt media helemaal tot aan het model via een nieuw statusbehoudend inferentiesysteem voor continue gesprekken.

Streaminginferentie was echter maar een deel van de oplossing. Om dit in productie goed te laten werken, moesten we ook betrouwbare audiolevering van de client naar de inferentiestack waarborgen en de uitdagingen van statusbehoud aanpakken.

Al vroeg besloten we de mediastroom nadrukkelijk te scheiden van applicatie- en bedrijfslogica. Audio gaat via een speciaal snel pad tussen de client en het spraakmodel. Delegatie, toolgebruik en ander applicatiewerk vinden plaats achter een asynchrone RPC-grens. Een trage toolaanroep of backendservice kan het eigen resultaat vertragen, maar de mediastroom niet blokkeren.

Deze scheiding biedt het systeem ook een duidelijke grens voor aanpassingen. Applicaties kunnen hun tools, beleid en backendgedrag wijzigen zonder gevolgen voor de mediafrontend die de audio laat doorstromen. Het livepad blijft klein, voorspelbaar en gericht op het werk dat in realtime moet gebeuren.

We schreven de mediafrontend en inferentielogica in Go en vervingen daarmee een eerdere Python-implementatie met asyncio. Dit maakte de levering van frames aanzienlijk vloeiender: de p95 van het nieuwe systeem kwam overeen met de p50 van het vorige systeem.

WebRTC vormt de transportbasis. Het is ontworpen voor media met lage latentie en blijft werken bij pakketverlies, klokafwijkingen en wijzigingen in clientverbindingen. Als pakketten te laat aankomen, kan WebRTC de audio subtiel uitrekken om onderbrekingen te voorkomen en het afspelen daarna kort versnellen om de realtime weergave weer in te halen.

Door buffering en blokkades in het hele systeem te beperken, kunnen we de reactietijd van minder dan een seconde bieden die mensen van een gesprek verwachten.

Statusbehoudende inferentie brengt eigen operationele afwegingen met zich mee. Een spraaksessie kan lang actief blijven, maar de context groeit voortdurend en modelinstanties worden op basis van de vraag opgestart en afgesloten.

Om dit aan te pakken, bouwden we een naadloos overdrachtsmechanisme tussen modelinstanties. Wanneer een overgang nodig is, kunnen we naast de bestaande modelinstantie een vervangende instantie opwarmen, deze vooraf vullen met de actuele sessiecontext, op beide parallel inferentie uitvoeren en overschakelen zodra de nieuwe instantie volledig gereed is.

Hetzelfde basismechanisme ondersteunt ook dynamische compaction. Naarmate een gesprek voortduurt, kan de opgebouwde context uiteindelijk de contextlimiet van het model overschrijden. Compaction kan de context verkleinen zodat deze binnen de limiet past, maar dat kost tijd. Omdat daardoor eerdere context verandert, wordt ook de key-value-cache (KV-cache) van het model ongeldig. Deze bewaart aandachtssleutels en -waarden van eerder verwerkte tokens. Voor het opnieuw opbouwen van die status is een nieuwe prefill nodig, wat extra vertraging veroorzaakt.

In plaats daarvan behandelen we compaction als een andere beheerde overgang. Terwijl de oorspronkelijke modelinstantie blijft praten, voert het systeem compaction uit op de context en bereidt het met de nieuwe context een vervangende modelinstantie voor. Zodra die instantie gereed is, kunnen we overschakelen zonder de media te onderbreken. Hierdoor kan het systeem langdurige gesprekken ondersteunen en waar nodig compaction uitvoeren.

Het zware werk blijft buiten het livepad, zodat het gesprek zelfs tijdens een overdracht geen moment hapert.

Doordat GPT‑Live bestaande grensverleggende modellen kan aanroepen, beschikt het over veel mogelijkheden en worden "praten" en diepgaander "denken" effectief van elkaar losgekoppeld. Om deze architectuur met twee modellen als één systeem te laten aanvoelen, moesten we echter twee samenhangende technische problemen oplossen.

Ten eerste moeten resultaten snel genoeg terugkomen om nuttig te zijn in het lopende gesprek. Daarom moesten we de latentie in het hele delegatiepad beperken, van routering en promptverwerking tot inferentie en toolaanroepen. Tegelijkertijd hebben andere systemen in het product nog steeds afzonderlijke berichten nodig. Daarom moesten we het lopende gesprek weergeven in een vorm die zij begrijpen.

Wanneer een delegatie wordt verzonden, optimaliseren we de tijd totdat het grensverleggende model iets oplevert dat nuttig is voor het gesprek. Het spraakmodel kan het gesprek kort gaande houden terwijl een grensverleggend model redeneert of tools gebruikt, maar kan een willekeurig trage respons niet verhullen. Daarom rekenden we de volledige delegatielus — routering, promptverwerking, inferentie en toolaanroepen — mee in het budget voor responsiviteit.

De eerste optimalisatie is het grensverleggende model en alle benodigde tools gereedmaken voordat om delegatie wordt gevraagd. Wanneer een spraaksessie begint, maakt de applicatieserver een inferentiesessie voor het grensverleggende model en vult deze vooraf met de eerste gesprekscontext. Zo is de prompt volledig verwerkt vóór het eerste gedelegeerde verzoek.

Vervolgens houden we die inferentiesessie gedurende het spraakgesprek beschikbaar en gebruiken we stabiele sessieaffiniteit voor opeenvolgende verzoeken. Samen met promptcaching verbeteren deze technieken de latentie, terwijl een storing van een worker eenvoudig te herstellen blijft.

Ook de redeneerinspanning, uitvoerlimieten, toolschema's en heen-en-weerverkeer tussen model en tool bepalen wanneer het gesprek een nuttig resultaat ontvangt. We hebben deze instellingen aangepast voor snellere reacties. Door het benodigde werk in het delegatiepad te beperken, kon het spraakmodel resultaten van onze grensverleggende modellen snel verwerken.

Hoewel het spraakmodel continue spraakstromen verwerkt, werken veel omliggende systemen nog steeds met beurten van gebruiker en assistent. Dat geldt onder meer voor de gespreksinterface van ChatGPT en delen van onze infrastructuur voor analyse en veiligheid. De applicatieserver ontrafelt het overlappende en soms dubbelzinnige gesprek daarom tot afzonderlijke berichten.

Terwijl audio binnenkomt, gebruikt de server gedeeltelijke transcripties en timingsignalen om te bepalen wie aan het woord is en een berichtenwachtrij op te bouwen. Het nieuwste bericht blijft voorlopig; de tekst, timing en toewijzing aan een spreker kunnen allemaal veranderen wanneer meer spraak binnenkomt. Zodra een spreker lang genoeg aan het woord is om de toewijzing betrouwbaar te maken, legt de server het bijbehorende bericht definitief vast.

Overlappende sprekers maken dit ingewikkelder. Een korte bevestiging van de assistent terwijl de gebruiker praat, zoals "mm hmm" of "okay", hoeft niet per se een afzonderlijk bericht te worden. Een inhoudelijke tussenkomst van de assistent moet dat vaak wel. Ook geven we prioriteit aan samenhang in de weergegeven antwoorden van de assistent, zelfs wanneer de gebruiker tussendoor praat.

Elk segmentatiebeleid maakt een afweging tussen actualiteit en zekerheid. Te vroeg vastleggen leidt tot een versnipperde geschiedenis en instabiele volgorde; te lang wachten vertraagt transcripties en de functies die ervan afhankelijk zijn. Het systeem houdt daarom twee samenhangende weergaven van het gesprek bij: een voorlopige weergave van de actuele status en een definitief verslag van wat er is gezegd. De gespreksweergave in de applicatie-interface kan updates verwerken en gebruikt daarom de voorlopige weergave. Voor registratie in de analysepijplijn is echter een definitieve transcriptie nodig.

Zo krijgt de rest van ChatGPT een stabiele weergave van het gesprek, zonder beurtwisseling aan het live spraakpad op te leggen.

Responsiviteit begint zodra de gebruiker op de knop klikt. Bij GPT‑Live moet het systeem het mediapad tot stand brengen en audio door het model voeren voordat het gesprek kan beginnen. Daardoor ligt elk onderdeel van de opstartvolgorde op het kritieke pad.

Zoals hierboven vermeld, biedt WebRTC een sterke realtime basis. Voor het starten van een standaard WebRTC-sessie zijn echter verrassend veel protocolhandshakes en heen-en-weerrondes over het netwerk nodig. WebRTC stamt van vóór de aandacht voor het beperken van heen-en-weerrondes die latere protocollen zoals QUIC vormgaf. Daardoor herhalen de onderliggende protocollen soms werk wanneer ze samen worden gebruikt. Zo bevatte elk protocol een eigen anti-DoS-mechanisme, zelfs wanneer dat binnen de volledige WebRTC-stack niet nodig was.

We analyseerden de stack en ontwikkelden het WebRTC Abridged Roundtrip Protocol (WARP⁠(opent in een nieuw venster)), dat het opstarten van media en gegevens terugbrengt van zes heen-en-weerrondes over het netwerk naar slechts één. WARP bereikt dit met een reeks achterwaarts compatibele protocolverbeteringen: de DTLS-handshake meesturen via ICE (SPED⁠(opent in een nieuw venster)), de snellere DTLS 1.3⁠(opent in een nieuw venster)-handshake gebruiken, de SCTP-handshake vooraf afstemmen (SNAP⁠(opent in een nieuw venster)) en gegevenskanalen vooraf afstemmen in plaats van DCEP⁠(opent in een nieuw venster) te gebruiken.

Samen met partners uit de WebRTC-community ontwierpen we WARP als een reeks open specificaties, zodat het bredere ecosysteem van dit werk kan profiteren. We brengen de voorstellen verder binnen de TSVWG-werkgroep van de IETF. Ondersteuning voor WARP is al toegevoegd aan zowel libwebrtc als Pion, en er wordt aan andere WebRTC-implementaties gewerkt.

Na optimalisatie van de mediahandshake bleef één vertraging opvallen: de signaleringsuitwisseling waarmee SDP-parameters worden gedeeld voordat WebRTC verbinding kan maken. Om die uitwisseling uit het kritieke pad te halen, ontwikkelden we wat we Instant Connect noemen. Daarmee worden deze parameters vooraf afgestemd, zonder servercapaciteit te reserveren en zonder bestaande WebRTC-implementaties te wijzigen.

Instant Connect wordt naast de standaard signaleringsstroom uitgevoerd. Als de vooraf afgestemde parameters geldig zijn, kan de server de sessie tot stand brengen zodra het eerste mediapakket binnenkomt. Als ze verouderd of ongeldig zijn, is de signaleringsstroom al onderweg. De client kan dan zonder extra latentie terugvallen op de standaardmethode.

Samen verkorten Instant Connect en WARP de tijd tussen de intentie van de gebruiker en een live mediastroom aanzienlijk. Nu de SDP-uitwisseling buiten het kritieke pad valt en WARP de transporthandshake samenvoegt, kan de client een sessie starten met één UDP-pakket. De server kan direct reageren, zodat de rest van het systeem kan beginnen met wat voor de gebruiker echt telt: luisteren en antwoorden.

Een systeem kan op papier snel lijken, maar bij echt spraakverkeer toch vastlopen. Voordat we GPT‑Live met gebruikers lieten praten, voerden we een stille test uit. Daarbij leidden we een klein, geleidelijk toenemend deel van de productiesessies van ChatGPT Voice naar zowel de bestaande geavanceerde spraakmodus als ons nieuwe systeem. De geavanceerde spraakmodus bleef gebruikers zoals gewoonlijk bedienen, terwijl het schaduwpad inferentie uitvoerde in de modus Alleen-lezen. Zo werd het systeem blootgesteld aan echte clients, netwerken, sessieduren en geografische spreiding, zonder dat gebruikers iets anders hoorden.

Een van de eerste lessen was dat capaciteit niet kon worden teruggebracht tot GPU-doorvoer. Spraaksessies blijven open en verzenden continu frames. Daarom moeten streamhandlers, wachtrijen en netwerkpaden aan de CPU-zijde net zo goed kunnen opschalen als de inferentie. Onder echte belasting bereikte een ondersteunend onderdeel eerder zijn limiet dan onze belastingstests voorspelden. Daardoor stapelden inferentieverzoeken zich op en liep de latentie steeds verder op. We veranderden de capaciteitsvraag van "Hoeveel verzoeken kan een GPU verwerken?" in "Hoeveel gelijktijdige sessies kan het systeem aan terwijl elk frame op tijd blijft?"

De test maakte ook duidelijk dat geografie een cruciale factor was. Een sessie naar capaciteit op grote afstand routeren kan tijdens het opstarten en streamen op meerdere punten vertraging veroorzaken. We gingen modeluitrol valideren in combinatie met regionale capaciteit en configuraties voor verkeerssturing, en splitsten de latentie vervolgens uit naar geografische herkomst. Inferentie dichter bij gebruikers uitvoeren hielp, maar onderstreepte ook de bredere les: de responsiviteit van begin tot eind hangt af van elke service in het pad, niet alleen van de modelserver.

Andere fouten traden alleen op tijdens realistische sessielevenscycli. Langdurige sessies legden de druk op geheugen en permanente opslag bloot. Bij opnieuw verbinden werden compaction en statusherstel op de proef gesteld. Normale verbroken clientverbindingen brachten racecondities in de afsluitende handshake aan het licht. Deze problemen deden zich zelden voor in korte belastingstests, omdat ze afhankelijk waren van tijd, opgebouwde status en gedrag over servicegrenzen heen.

Tot slot dwongen productietests ons de observeerbaarheid en uitrolcontroles te verbeteren. We ontdekten meetwaarden waarin verschillende oorzaken van latentie op één hoop werden gegooid, dashboards waarvan de totalen afzonderlijke ongezonde engines verborgen en configuratieverschillen tussen geteste en uitgerolde systemen. Daarom voegden we gedetailleerdere telemetrie, validatie aan de hand van bewezen configuraties en gefaseerde opschaling toe, plus de mogelijkheid om afzonderlijke paden snel te isoleren of uit te schakelen. De stille test werd een vroege generale repetitie voor de lancering: niet alleen om te bepalen hoeveel verkeer het systeem aankon, maar ook hoe snel we storingen konden detecteren, indammen en herstellen.

Om GPT‑Live op de schaal van ChatGPT te laten werken, was een volledig nieuw systeem nodig dat rond één fundamenteel principe was gebouwd: de spraak moet blijven stromen. Streaminginferentie voorziet het full-duplexmodel voortdurend van audio. Een speciaal mediapad zorgt voor betrouwbare levering van frames. Dankzij asynchrone delegatie kan diepgaander denkwerk parallel plaatsvinden. Geoptimaliseerd transport houdt de ervaring responsief, tot aan de gebruiker.

De architectuur achter GPT‑Live groeit nu al uit tot een breder platform voor realtime interactie. De architectuur ondersteunt ChatGPT Voice bij de uitbreiding van gesprekken naar agentische coördinatie en zal de basis vormen voor de komende GPT‑Live-API. Na verloop van tijd kunnen spraakervaringen hiermee meer apparaten, apps en modaliteiten omvatten, zonder de directheid te verliezen waardoor een spraakgesprek echt live aanvoelt.

Wil je dit soort technische problemen oplossen? Kom dan bij ons werken⁠.