L'architettura WebRTC di OpenAI alimenta l'AI vocale a bassa latenza su larga scala

L'architettura WebRTC di OpenAI alimenta l'AI vocale a bassa latenza su larga scala

Affinché l'AI vocale sia naturale, la conversazione deve svolgersi alla velocità del parlato. Pause imbarazzanti o risposte ritardate rompono l'illusione di intelligenza. Sulla scala impressionante di OpenAI—con oltre 900 milioni di utenti attivi settimanali di ChatGPT e 2 miliardi di dollari di fatturato mensile—fornire questa esperienza è una sfida infrastrutturale monumentale. Un nuovo approfondimento tecnico rivela come l'azienda abbia ricostruito il suo stack di media in tempo reale per supportare l'AI vocale a bassa latenza a livello globale.

Il problema principale era triplice: raggiungere una copertura globale, una configurazione di connessione veloce e tempi di andata e ritorno stabili e bassi per i media. Il team, guidato dai membri del personale tecnico Yi Zhang e William McDonald, ha identificato che il modello di distribuzione WebRTC convenzionale era in conflitto con l'infrastruttura cloud-native moderna. La soluzione è stata un'architettura divisa innovativa soprannominata "relay + transceiver", descritta in dettaglio in un post del blog di ingegneria del maggio 2026.

La sfida: WebRTC incontra Kubernetes

OpenAI si affida allo standard aperto WebRTC per i suoi prodotti AI in tempo reale, tra cui ChatGPT Voice e la Realtime API. WebRTC gestisce i compiti complessi di stabilire la connettività, la crittografia e la negoziazione del codec, fornendo un'esperienza client uniforme su browser e piattaforme mobili.

Tuttavia, il ridimensionamento di WebRTC su Kubernetes ha presentato vincoli severi. Il modello tradizionale richiede una porta UDP pubblica per sessione attiva. Ai livelli di concorrenza di OpenAI, ciò significava gestire decine di migliaia di porte—un incubo per il bilanciamento del carico che ha ampliato la superficie di attacco e rotto il modello di scalabilità elastica di Kubernetes.

Inoltre, le sessioni WebRTC sono state mantenute. I protocolli Interactive Connectivity Establishment (ICE) e Datagram Transport Layer Security (DTLS) richiedono che la proprietà della sessione rimanga stabile. Se un pod Kubernetes che gestisce una sessione viene rischedulato, il flusso multimediale si interrompe. "La terminazione dei media su una porta per sessione non si adatta bene all'infrastruttura di OpenAI", hanno notato gli ingegneri.

Scelta architetturale: Transceiver rispetto a SFU

OpenAI ha valutato due architetture multimediali primarie. Un'unità di inoltro selettivo (SFU) agisce come un server multimediale che instrada i flussi tra più partecipanti, compreso l'AI come peer. Questo è comune per le chiamate multiparte. Tuttavia, il carico di lavoro di OpenAI è prevalentemente uno-a-uno: un singolo utente che conversa con un singolo modello AI.

Hanno scelto un modello transceiver. Un servizio edge WebRTC termina la connessione client, gestendo tutta la logica di protocollo con stato (ICE, DTLS, crittografia SRTP), e converte i media in protocolli interni più semplici per i servizi di backend di inferenza. Ciò mantiene lo stato complesso di WebRTC isolato al bordo, consentendo ai servizi AI di scalare senza diventare essi stessi peer WebRTC.

L'innovazione principale: Relay + Transceiver

La svolta è stata la separazione dell'instradamento dei pacchetti dalla terminazione del protocollo. La nuova architettura introduce un relay senza stato e un transceiver con stato.

• Il Relay: Un livello di inoltro UDP leggero con un footprint IP:porta pubblico piccolo e fisso. Analizza solo i metadati del pacchetto sufficienti (specificamente il frammento del nome utente ICE, o ufrag) per instradare i pacchetti al transceiver corretto, senza decrittografare i media o gestire lo stato della sessione.
• Il Transceiver: L'endpoint WebRTC con stato che possiede il ciclo di vita completo della sessione. Si trova dietro il relay e comunica con i servizi AI di backend.

Questo design risolve il problema di Kubernetes. Il relay espone solo una manciata di porte pubbliche, semplificando il bilanciamento del carico e la sicurezza. Il transceiver può ora essere eseguito su Kubernetes, scalando in modo elastico, perché il relay assicura che i suoi pacchetti lo trovino sempre, anche se il suo indirizzo IP del pod cambia. Una cache Redis contiene la mappatura client-transceiver per un rapido recupero.

Scala globale e ottimizzazioni delle prestazioni

OpenAI ha distribuito questo come un livello di Global Relay—punti di ingresso geograficamente distribuiti che accorciano il primo hop di rete per gli utenti in tutto il mondo. La geo-steering di Cloudflare indirizza le richieste di segnalazione al cluster transceiver più vicino, che poi istruisce il client a connettersi all'indirizzo Global Relay più vicino.

L'implementazione del relay, scritta in Go, è ottimizzata per l'efficienza. Utilizza `SO_REUSEPORT` di Linux per consentire a più lavoratori di condividere una porta UDP, `runtime.LockOSThread` per fissare le goroutine ai core CPU per una migliore località della cache, e buffer pre-allocati per minimizzare l'overhead della raccolta dei rifiuti. "Non abbiamo avuto bisogno di alcun framework di bypass del kernel", ha concluso il team, trovando il design più semplice nello spazio utente sufficiente per il loro traffico.

Contesto di mercato e pressione competitiva

Questo investimento infrastrutturale arriva in un momento critico per OpenAI. Nonostante un recente round di finanziamento da 122 miliardi di dollari e una valutazione di 852 miliardi di dollari, l'azienda si trova ad affrontare una concorrenza intensa. Un articolo di TIME dell'aprile 2026 nota che rivali come Anthropic e Google stanno "premendo forte". La divisione AI di Google, DeepMind, ha spinto Gemini ai primi posti nelle classifiche delle capacità, contribuendo a far superare ad Alphabet i 400 miliardi di dollari di fatturato annuo.

Un rapporto di Gizmodo suggerisce che il successo di Google sta direttamente incidendo su OpenAI, con la crescita di ChatGPT che rallenta e i chip TPU di Google che guadagnano popolarità come alternativa a NVIDIA. Il CFO di OpenAI, Sarah Friar, era apparentemente preoccupata per la copertura dei costi di calcolo a causa di obiettivi di ricavo mancati, in parte attribuiti ai guadagni di quota di mercato di Gemini.

Internamente, OpenAI sta affilando la sua attenzione. L'azienda ha recentemente chiuso la sua app di generazione video Sora e ha messo in pausa i piani per una modalità erotica, reindirizzando gli sforzi verso "prodotti con un ritorno commerciale più chiaro, specialmente coding, strumenti di lavoro e servizi aziendali", secondo TIME. Il CEO della distribuzione AGI, Fidji Simo, ha detto ai dipendenti: "Non possiamo perdere questo momento perché siamo distratti da missioni secondarie".

Perché questo salto tecnico è importante

L'architettura relay+transceiver è più di un'ottimizzazione infrastrutturale; è un abilitatore strategico. L'interazione vocale a bassa latenza e naturale è un fattore chiave di differenziazione per i prodotti AI consumer e aziendali. Risolvendo il problema di WebRTC su larga scala, OpenAI assicura che il suo ChatGPT Voice di punta e la sua Realtime API per gli sviluppatori rimangano competitivi sull'esperienza utente.

Questo lavoro esemplifica anche una tendenza più ampia nell'infrastruttura AI: il passaggio da stack specializzati monolitici a design cloud-native decomposti. Come notato in un pezzo sponsorizzato di TechCrunch su Tether AI, l'ecosistema è saturo di LLM in competizione per risorse GPU centralizzate. L'architettura di OpenAI dimostra come costruire strati in tempo reale efficienti e scalabili su quel calcolo.

Le principali lezioni apprese dal team di ingegneria—preservare la semantica del protocollo client, centralizzare lo stato difficile, instradare sui dati di protocollo esistenti e evitare l'ottimizzazione prematura—forniscono un modello per altre aziende che costruiscono applicazioni in tempo reale su larga scala. Nella corsa al dominio dell'AI, dove l'esperienza utente può essere il fattore decisivo, tale lavoro infrastrutturale fondamentale può rivelarsi tanto prezioso quanto i modelli stessi.