Så byggde vi ett realtidssystem för responsiv röst-AI på sex månader

För röst-AI är det svårare än det låter att veta när man ska tala. Människor lämnar obehindrat över ordet till varandra på en bråkdel av en sekund, men tidigare röst-AI-system kunde inte följa den rytmen. Deras turbaserade arkitektur förlitade sig på små modeller som kallas turdetektorer och hade en otacksam uppgift: gissa för tidigt och användaren blir avbruten, gissa för sent och svaret känns trögt. Först när detektorn hade fattat sitt beslut kunde den betydligt större LLM:en börja arbeta.

GPT‑Live⁠, vårt tredje generationens röstsystem, tar bort turdetektorn från ljudvägen. Röstmodellen använder full duplex, vilket innebär att den kan lyssna och tala samtidigt. Därmed behövs ingen separat detektor och samtalet känns mer direkt och naturligt. När djupare resonemang eller verktygsanvändning behövs kan GPT‑Live också rådfråga våra banbrytande modeller, som GPT‑5.5, utan att avbryta samtalsflödet. Tillsammans ger dessa förmågor GPT‑Live en unik kombination av snabb respons och intelligens i samtal.

För att kunna erbjuda upplevelsen i stor skala krävdes en ny systemarkitektur optimerad för låg fördröjning. Till skillnad från vanlig inferens med begäran och svar strömmar vårt system inkommande ljud till röstmodellen och utgående tal tillbaka till användaren, medan delegering hanteras via en separat asynkron väg. Under de senaste sex månaderna har vi omarbetat modellinferens, kontexthantering och medieöverföring för att hålla talet flytande från början till slut.

Arkitekturen skapar också en tydlig gräns mellan det centrala röstflödet och applikationslogiken. Det gör det enkelt att anpassa applikationens beteende utan att påverka svarstiden. Den här grunden driver ett växande utbud av funktioner i ChatGPT Voice, däribland den nyligen lanserade möjligheten att styra datorn och samordna agenter i ChatGPT‑appen för datorer.

I det här inlägget förklarar vi varför tidigare turbaserade system inte uppfyllde våra behov och hur vi konstruerade det nya systemet för snabb respons i varje lager. Vi går igenom tillståndsbevarande inferens, dynamisk kontexthantering, asynkron delegering och optimering på protokollnivå – delar som tillsammans får GPT‑Live att kännas verkligt direktsänt.

Tidigare röstarkitekturer ärvde textbaserade LLM:ers turtagning, men varje tur representerades av ett separat ljudblock i stället för text. I kaskadsystem kördes tal-till-text, LLM:en och text-till-tal efter varandra. Denna sekvens ökade fördröjningen och bortsåg från signaler som tonfall och taltempo.

Modeller för tal till tal förbättrade metoden genom att bearbeta ljud direkt. Genom att träna modellen att direkt förstå och generera tal kunde den bevara detaljer som går förlorade vid transkription och svara snabbare. Systemet var dock fortfarande beroende av turdetektorn för att avgöra när inferensen kunde börja. Modellen hanterade mer av interaktionen, men den förblev turbaserad.

GPT‑Live låter röstmodellen styra samtalet: ljud strömmar in i och ut ur modellen, medan djupare resonemang och verktygsanvändning sker asynkront. Systemets främsta uppgift är att upprätthålla en obruten medieslinga. Annat arbete, som att anropa banbrytande modeller och lagra samtalet beständigt, sker utanför direktflödet.

Det är inte alltid enkelt att hålla den här medieslingan obruten. Varje fördröjning i överföring, bearbetning eller inferens kan höras som en paus eller störning. Ett tidigare turbaserat system kunde tolerera viss variation i när ett ljudblock anlände. Ett system för direktsända medier måste däremot leverera varje ljudbildruta i tid.

Tidigare arbete med ChatGPT Voice och Realtime API gav oss en viktig grund. Vi hade redan byggt om vår röstinfrastruktur⁠ för att strömma ljud och video direkt in i och ut ur våra system med lägre och mer förutsägbar fördröjning. GPT‑Live tog konstruktionen ett steg längre genom att strömma medier hela vägen till modellen via ett nytt tillståndsbevarande inferenssystem för kontinuerliga samtal.

Strömmande inferens var dock bara en del av lösningen. För att det skulle fungera bra i produktion behövde vi också säkerställa tillförlitlig ljudleverans från klienten till inferensstacken och hantera utmaningarna med tillstånd.

Ett tidigt beslut var att tydligt skilja medieflödet från applikations- och affärslogiken. Ljudet överförs mellan klienten och röstmodellen via en särskild snabb väg. Delegering, verktygsanvändning och annat applikationsarbete sker bakom en asynkron RPC-gräns. Ett långsamt verktygsanrop eller en långsam serverdelstjänst kan fördröja sitt eget resultat, men inte stoppa medieflödet.

Separationen ger också systemet en tydlig gräns för anpassning. Applikationer kan ändra sina verktyg, policyer och beteenden i serverdelen utan att påverka mediegränssnittet som håller ljudet i rörelse. Direktflödet förblir litet, förutsägbart och inriktat på det arbete som måste ske i realtid.

Vi skrev mediegränssnittet och inferenslogiken i Go och ersatte en tidigare Python-implementering med asyncio. Detta gav en betydligt jämnare leverans av bildrutor: det nya systemets p95 motsvarade det tidigare systemets p50.

WebRTC utgör grunden för överföringen. Det är utformat för medier med låg fördröjning och kan fortsätta fungera trots paketförluster, klockdrift och förändringar i klientanslutningen. Om paket anländer sent kan WebRTC försiktigt tänja ut ljudet för att undvika luckor och sedan kortvarigt öka uppspelningshastigheten för att hinna ikapp realtid.

Genom att minimera buffring och blockering i hela systemet kan vi ge den respons på under en sekund som människor förväntar sig av ett samtal.

Tillståndsbevarande inferens har sina egna driftsmässiga avvägningar. En röstsession kan vara aktiv länge, samtidigt som kontexten växer kontinuerligt och modellinstanser startas och stängs av efter behov.

För att hantera detta byggde vi en mekanism för sömlös överlämning mellan modellinstanser. När ett byte behövs kan vi värma upp en ersättande modellinstans parallellt med den befintliga, förinläsa den aktuella sessionskontexten, köra inferens mot båda samtidigt och växla över när den nya instansen är helt redo.

Samma grundläggande mekanism stöder även dynamisk kontextkomprimering. När ett samtal fortsätter kan den ackumulerade kontexten till slut överskrida modellens kontextgräns. Komprimering kan minska kontexten så att den ryms inom gränsen, men åtgärden tar tid. Eftersom den ändrar tidigare kontext ogiltigförklarar den också modellens nyckelvärdescache (KV-cache), som lagrar attention-nycklar och värden från tidigare bearbetade token. För att bygga upp tillståndet igen krävs en ny förinläsning, vilket medför ytterligare fördröjning.

I stället behandlar vi komprimering som ännu en hanterad övergång. Medan den ursprungliga modellinstansen fortsätter samtalet komprimerar systemet kontexten och förbereder en ersättande modellinstans med den nya kontexten. När instansen är redo kan vi växla över utan att medieflödet avbryts. Därmed kan systemet hantera långvariga samtal och komprimera vid behov.

Det tunga arbetet hålls borta från direktflödet, så samtalet tappar aldrig rytmen, inte ens under en överlämning.

GPT‑Lives förmåga att anropa befintliga banbrytande modeller ger systemet stor kraft genom att i praktiken frikoppla ”pratandet” från djupare ”tänkande”. För att få den här arkitekturen med två modeller att kännas som ett enda system behövde vi dock lösa två relaterade tekniska problem.

För det första måste resultaten återvända tillräckligt snabbt för att vara användbara i det pågående samtalet. Därför behövde vi minimera fördröjningen längs hela delegeringsvägen, från dirigering och promptbearbetning till inferens och verktygsanrop. Samtidigt behöver andra system i produkten fortfarande separata meddelanden, så vi behövde representera det pågående samtalet i en form som de kunde förstå.

När en delegering skickas optimerar vi tiden tills den banbrytande modellen producerar något användbart för samtalet. Röstmodellen kan kortvarigt hålla igång samtalet medan en banbrytande modell resonerar eller använder verktyg, men den kan inte dölja ett hur långsamt svar som helst. Därför räknade vi in hela delegeringsslingan – dirigering, promptbearbetning, inferens och verktygsanrop – i tidsbudgeten för respons.

Den första optimeringen är att förbereda den banbrytande modellen och alla verktyg den behöver innan delegeringen begärs. När en röstsession startar skapar applikationsservern en inferenssession för den banbrytande modellen och förinläser den inledande samtalskontexten. Därmed är prompten helt bearbetad före den första delegerade begäran.

Sedan håller vi inferenssessionen tillgänglig under hela röstsamtalet och använder stabil sessionstillhörighet för efterföljande begäranden. Tillsammans med promptcachelagring minskar dessa tekniker fördröjningen samtidigt som det är enkelt att återhämta sig från ett arbetsnodsfel.

Resonemangsnivå, utdatalimiter, verktygsscheman och turer mellan modell och verktyg påverkar också när samtalet får ett användbart resultat. Vi justerade därför dessa reglage för att få snabbare svar. Genom att minimera arbetet längs delegeringsvägen kunde röstmodellen snabbt införliva resultat från våra banbrytande modeller.

Även om röstmodellen arbetar med kontinuerliga talströmmar använder många omgivande system fortfarande användar- och assistentturer, däribland ChatGPT:s samtalsgränssnitt och delar av vår analys- och säkerhetsinfrastruktur. Applikationsservern delar därför upp det överlappande och ibland tvetydiga samtalet i separata meddelanden.

När ljudet anländer använder servern partiella transkriptioner och tidssignaler för att avgöra vem som har ordet och bygga upp en meddelandekö. Det senaste meddelandet förblir preliminärt. Texten, tidsangivelserna och talartilldelningen kan ändras när mer tal anländer. När en talare har haft ordet tillräckligt länge för att tilldelningen ska vara tillförlitlig slutför servern motsvarande meddelande.

Överlappande tal gör detta mer komplicerat. En kort bekräftelse från assistenten medan användaren talar, till exempel ”mm hmm” eller ”okay”, behöver inte bli ett eget meddelande. Ett innehållsrikt inpass från assistenten bör däremot ofta bli det. På samma sätt prioriterar vi sammanhanget i assistentens visade svar även när användaren börjar tala mitt i svaret.

Varje segmenteringspolicy innebär en avvägning mellan aktualitet och säkerhet. Att fastställa meddelanden för tidigt ger en fragmenterad historik och instabil ordning. Att vänta för länge fördröjer transkriptionerna och funktionerna som är beroende av dem. Systemet upprätthåller därför två relaterade vyer av samtalet: en preliminär vy av det aktuella tillståndet och ett slutgiltigt register över vad som sades. Samtalsvyn i applikationens gränssnitt kan hantera uppdateringar och använder därför den preliminära vyn. Loggning till analyspipelinen kräver däremot en slutgiltig transkription.

Det ger resten av ChatGPT en stabil bild av samtalet utan att tvinga in turtagning i det direktsända röstflödet.

Den snabba responsen börjar så snart användaren klickar på knappen. Med GPT‑Live måste systemet upprätta medievägen och börja mata ljud genom modellen innan samtalet kan börja. Därmed hamnar varje del av startsekvensen på den kritiska vägen.

Som nämnts ovan ger WebRTC en stabil grund för realtid, men att starta en vanlig WebRTC-session kräver förvånansvärt många protokollhandskakningar och nätverksturer. WebRTC tillkom före det fokus på att minimera nätverksturer som präglade senare protokoll som QUIC. Därför upprepar de underliggande protokollen ibland arbete när de används tillsammans. Varje protokoll innehöll till exempel en egen mekanism mot överbelastningsattacker, även när den inte behövdes i hela WebRTC-stackens sammanhang.

Vi analyserade stacken och utvecklade WebRTC Abridged Roundtrip Protocol (WARP⁠(öppnas i ett nytt fönster)), som minskar starten för medier och data från sex nätverksturer till bara en. WARP åstadkommer detta genom en uppsättning bakåtkompatibla protokollförbättringar: DTLS-handskakningen skickas tillsammans med ICE (SPED⁠(öppnas i ett nytt fönster)), den snabbare handskakningen DTLS 1.3⁠(öppnas i ett nytt fönster) används, SCTP-handskakningen förhandlas i förväg (SNAP⁠(öppnas i ett nytt fönster)) och datakanaler förhandlas i förväg i stället för att använda DCEP⁠(öppnas i ett nytt fönster).

Vi utformade WARP som en uppsättning öppna specifikationer tillsammans med samarbetspartner från WebRTC-communityn, så att hela ekosystemet kan dra nytta av arbetet. Vi driver förslagen vidare genom IETF:s arbetsgrupp TSVWG. Stöd för WARP har redan lagts till i både libwebrtc och Pion, och arbete pågår i andra WebRTC-implementeringar.

Efter att ha optimerat mediehandskakningen återstod en tydlig fördröjning: signaleringsutbytet som används för att dela SDP-parametrar innan WebRTC kan ansluta. För att ta bort det utbytet från den kritiska vägen utvecklade vi det vi kallar Instant Connect. Det förhandlar parametrarna i förväg utan att reservera serverkapacitet och utan att ändra befintliga WebRTC-implementeringar.

Instant Connect körs parallellt med det vanliga signaleringsflödet. Om de förhandlade parametrarna är giltiga kan servern skapa sessionen när det första mediepaketet anländer. Om de är inaktuella eller ogiltiga är signaleringsflödet redan igång, så klienten kan falla tillbaka utan ytterligare fördröjning.

Tillsammans minskar Instant Connect och WARP drastiskt tiden från användarens avsikt till ett aktivt medieflöde. När SDP-utbytet har flyttats bort från den kritiska vägen och WARP komprimerar transporthandskakningen kan klienten nu starta en session med ett enda UDP-paket. Servern kan svara omedelbart, så att resten av systemet kan börja göra det användaren faktiskt bryr sig om: lyssna och svara.

Ett system kan verka snabbt på papperet men ändå stanna upp under verklig rösttrafik. Innan GPT‑Live fick börja samtala med användare genomförde vi ett tyst test där en liten och gradvis ökande andel av produktionssessionerna i ChatGPT Voice dirigerades till både den befintliga upplevelsen Avancerat röstläge och vårt nya system. Avancerat röstläge fortsatte att betjäna användarna som vanligt, medan skuggflödet körde inferens i skrivskyddat läge. Detta exponerade systemet för verkliga klienter, nätverk, sessionslängder och geografisk fördelning utan att ändra vad användarna hörde.

En av de första lärdomarna var att kapacitet inte bara kunde mätas som GPU-kapacitet. Röstsessioner förblir öppna och skickar bildrutor kontinuerligt, så strömhanterare på CPU-sidan, köer och nätverksvägar måste skalas tillsammans med inferensen. Under verklig belastning nådde en stödkomponent sitt kapacitetstak tidigare än våra belastningstester förutsagt. Inferensbegäranden började då hopa sig och fördröjningen växte ytterligare. Vi ändrade kapacitetsfrågan från ”Hur många begäranden klarar en GPU?” till ”Hur många samtidiga sessioner kan systemet hantera och ändå leverera varje bildruta i tid?”

Testet visade också att geografin måste prioriteras från början. Att dirigera en session till avlägsen kapacitet kan orsaka fördröjningar på flera punkter under starten och strömningen. Vi började validera modellutrullningar tillsammans med regional kapacitet och konfigurationen för trafikstyrning och delade sedan upp fördröjningen efter källans geografi. Det hjälpte att flytta inferensen närmare användarna, men det bekräftade också en bredare lärdom: svarstiden från början till slut beror på alla tjänster längs vägen, inte bara modellservern.

Andra fel uppstod bara under realistiska sessionslivscykler. Långvariga sessioner blottlade belastning på minne och beständig lagring. Återanslutningar prövade komprimering och återställning av tillstånd. Vanliga klientfrånkopplingar avslöjade kapplöpningstillstånd i nedstängningshandskakningen. Dessa problem uppstod sällan i korta belastningstester eftersom de berodde på tid, ackumulerat tillstånd och beteenden över tjänstegränser.

Slutligen tvingade produktionstesterna oss att förbättra observerbarheten och kontrollerna för utrullning. Vi hittade mätvärden som blandade ihop olika fördröjningskällor, instrumentpaneler där aggregeringar dolde enskilda problematiska motorer och konfigurationsavvikelser mellan testade och driftsatta system. Därför lade vi till mer detaljerad telemetri, validering mot kända fungerande konfigurationer, stegvis upptrappning och möjligheten att snabbt isolera eller inaktivera enskilda flöden. Det tysta testet blev en tidig lanseringsövning – inte bara för hur mycket trafik systemet kunde ta emot, utan också för hur snabbt vi kunde upptäcka, begränsa och återhämta oss från fel.

Att skala upp GPT‑Live till ChatGPT‑nivå krävde ett helt nytt system byggt kring en grundläggande princip: rösten måste flöda. Strömmande inferens förser full duplex-modellen med ljud utan avbrott. En särskild medieväg säkerställer tillförlitlig leverans av bildrutor. Asynkron delegering låter djupare tänkande ske parallellt. Optimerad överföring ger snabb respons hela vägen till användaren.

Arkitekturen bakom GPT‑Live håller redan på att bli en bredare plattform för interaktion i realtid. Den driver ChatGPT Voice när tjänsten utvecklas från samtal till agentbaserad samordning och kommer att ligga till grund för det kommande GPT‑Live API:et. Med tiden kommer den att göra det möjligt för röstupplevelser att omfatta fler enheter, appar och modaliteter utan att förlora den omedelbarhet som får röstsamtal att kännas direktsända.

Om det här är den sorts tekniska problem du vill lösa, kom och jobba med oss⁠.