OpenAI Outlines l'Architettura WebRTC per la Voce AI a Bassa Latenza a Scala

InfoQ Homepage News OpenAI Outlines l'Architettura WebRTC per la Voce AI a Bassa Latenza a Scala Architecture & Design Portable by Design: Data Mobility & Recovery Patterns per Sistemi Multi-Cloud (Webinar 21 maggio) OpenAI Outlines l'Architettura WebRTC per la Voce AI a Bassa Latenza a Scala 20 maggio 2026 2 min read by Eran Stiller Write for InfoQ Feed your curiosity. Help 550k+ global senior developers each month stay ahead. Get in touch Listen to this article - 0:00 Audio ready to play Your browser does not support the audio element. 0:00 0:00 Normal 1.25x 1.5x Like Reading list OpenAI ha recentemente descritto come ha adattato WebRTC per la voce AI a bassa latenza a scala globale . La nuova architettura ha sostituito un modello di terminazione dei media convenzionale con un design di relay-transceiver più adatto a Kubernetes e load balancers cloud. Mantiene lo stato delle sessioni WebRTC in un layer di transceiver dedicato mentre utilizza relais leggeri per ridurre l'esposizione pubblica UDP e mantenere la routing dei media vicino agli utenti. Nell'articolo, Yi Zhang e William McDonald, membri del personale tecnico di OpenAI, spiegano che la portata globale, la configurazione veloce delle connessioni e i tempi di round-trip dei media stabili erano le principali restrizioni dietro il cambiamento. L'equipe ha valutato diverse alternative per esporre le sessioni dei media, ognuna con differenti trade-off operativi. La prima alternativa era l'esposizione diretta per-sessione UDP, che preserva il modello WebRTC convenzionale. Tuttavia, ciò sposta la complessità operativa nel layer di infrastruttura, specialmente in ambienti Kubernetes, dove grandi intervalli di porte pubbliche sono difficili da gestire in modo sicuro. L'assegnazione di porte uniche per server semplifica alcune decisioni di routing, ma lascia ancora agli operatori il problema della pianificazione delle porte, dell'utilizzo disuguale e dei modelli di rilascio più fragili. Opzione 1: L'approccio SFU include l'AI come partecipante WebRTC ( source ) Relay -style relais erano anche un'opzione plausibile, ma introducono un intermediario più pesante nel percorso dei media e risolvono un problema più ampio di quanto OpenAI non ne avesse bisogno per le sessioni 1:1 model-to-user predominanti. OpenAI ha invece scelto di suddividere le responsabilità tra due layer. Un relais leggero accetta i pacchetti in arrivo e li invia, mentre un transceiver separato possiede tutta la macchina WebRTC statale, compresa la negoziazione ICE, i handshakes DTLS, la crittografia SRTP e il ciclo di vita della sessione. Opzione 2: L'approccio tranceiver interrompe WebRTC all'edge e converte in un protocollo backend ( source ) Questa separazione significa che il relais può rimanere semplice, veloce e in gran parte senza stato, mentre il transceiver è l'unico componente che deve comprendere il protocollo completo. Ciò mantiene la complessità concentrata in un solo posto anziché duplicarla in servizi backend o spostarla nel comportamento del client. "Il posto migliore per aggiungere complessità è in un layer di routing sottile, non in ogni servizio backend e non nel comportamento del client personalizzato," gli autori affermano. Relay statelessly invia pacchetti al transceiver ( source ) WebRTC è una scelta comune per carichi di lavoro AI in tempo reale. Oltre alla consegna dei media a bassa latenza, fornisce anche la traversata NAT, il trasporto crittografato, la negoziazione del codice, la bufferizzazione del jitter e le funzionalità audio come l'annullamento dell'eco su browser e piattaforme mobili. STUN è parte di quella fondazione, aiutando gli endpoint a scoprire come appaiono sulla rete e supportando ICE durante le verifiche di connettività. Molti team si affidano a unità di forwarding selettivo, o SFUs, perché centralizzano la routing dei media e la politica per i sistemi multi-partecipanti. Tuttavia, i carichi di lavoro di OpenAI sono principalmente sessioni 1:1 tra un utente e un modello, rendendo un design transceiver un migliore adattamento che trattare il modello come un altro partecipante in un'architettura di conferenza. L'articolo aggiunge dettagli di infrastruttura al push di voce in tempo reale di OpenAI, già disponibile in prodotti come ChatGPT voice e l'API Realtime . Per gli architetti che costruiscono sistemi di media interattivi, il pattern più interessante è la decomposizione stessa: preservare il comportamento del protocollo al livello di routing