OpenAI Décrit l'Architecture WebRTC pour la Voix AI à Basse Latence à Échelle Mondiale

InfoQ Homepage Actualités OpenAI Décrit l'Architecture WebRTC pour la Voix AI à Basse Latence à Échelle Mondiale Architecture & Design Portable by Design: Modèles de Mobilité et de Recuperation de Données pour les Systèmes Multi-Nuage (Webinar 21 mai) OpenAI Décrit l'Architecture WebRTC pour la Voix AI à Basse Latence à Échelle Mondiale 20 mai 2026 2 min read par Eran Stiller Écris pour InfoQ Nourris ta curiosité. Aide 550k+ développeurs seniors chaque mois à rester à la pointe. Établis un contact Écoutez cet article - 0:00 Audio prêt à jouer Ton navigateur ne prend pas en charge l'élément audio. 0:00 0:00 Normal 1.25x 1.5x J'aime Liste de lecture OpenAI a récemment décrit comment elle a adapté WebRTC pour la voix AI à basse latence à échelle mondiale . La nouvelle architecture a remplacé un modèle de terminaison de médias conventionnel par un design de relay-transceiver plus adapté à Kubernetes et aux équilibreurs de charge en nuage. Elle garde WebRTC état de session dans une couche de transceiver dédiée, tandis que les relais légers sont utilisés pour réduire l'exposition publique UDP et garder la route des médias près des utilisateurs. Dans l'article, Yi Zhang et William McDonald, membres du personnel technique d'OpenAI, expliquent que la portée mondiale, la configuration rapide des connexions et les temps de round-trip stables des médias étaient les principales contraintes derrière le changement. L'équipe a évalué plusieurs approches pour exposer les sessions de médias, chacune avec des avantages opérationnels différents. La première approche était l'exposition directe par session UDP, qui conserve le modèle WebRTC conventionnel. Cependant, cela déplace la complexité opérationnelle dans le niveau d'infrastructure, en particulier dans les environnements Kubernetes, où les grandes plages de ports publics sont difficiles à gérer de manière sécurisée. L'allocation de ports uniques par serveur simplifie certaines décisions de routing, mais laisse aux opérateurs le problème de la planification des ports, de l'utilisation inégale et des modèles de lancement plus fragiles. Option 1: L'approche SFU inclut l'IA comme participant WebRTC ( source ) Relay -style relais étaient également une option plausible, mais ils introduisent un intermédiaire plus lourd dans le chemin des médias et résolvent un problème plus large que ce dont OpenAI avait besoin pour les sessions 1:1 modèle-to-user dominantes. OpenAI a choisi d'opérer les responsabilités entre deux couches. Un relais léger accepte les paquets en arrivée et les envoie, tandis qu'un transceiver séparé possède toute la machine WebRTC étatique, y compris la négociation ICE, les poignées de main DTLS, la cryptage SRTP et le cycle de vie de la session. Option 2: L'approche tranceiver interrompt WebRTC au bord et convertit en un protocole de backend ( source ) Cette séparation signifie que le relais peut rester simple, rapide et en grande partie sans état, tandis que le transceiver est le seul composant qui doit comprendre le protocole complet. Cela garde la complexité concentrée dans un seul endroit plutôt que de la dupliquer dans les services backend ou de la déplacer dans le comportement du client. "Le meilleur endroit pour ajouter de la complexité est dans une couche de routing fine, pas dans chaque service backend et pas dans le comportement du client personnalisé," affirment les auteurs. Relay statelessly envoie des paquets au transceiver ( source ) WebRTC est une option courante pour les charges de travail AI en temps réel. En plus de la livraison de médias à basse latence, il fournit également la traversée NAT, le transport chiffré, la négociation de codes, la bufferisation de jitter et les fonctionnalités audio telles que l'annulation de l'écho sur les navigateurs et les plates-formes mobiles. STUN fait partie de cette base, en aidant les points de terminaison à découvrir comment ils apparaissent sur le réseau et en soutenant ICE pendant les vérifications de connectivité. Beaucoup d'équipes se basent sur les unités de forwarding sélectif, ou SFUs, car elles centralisent la route des médias et la politique pour les systèmes multi-participants. Cependant, les tâches d'OpenAI sont principalement des sessions 1:1 entre un utilisateur et un modèle, ce qui fait que un design transceiver est un meilleur ajustement que de traiter le modèle comme un autre participant dans une architecture de conférence. L'article ajoute des détails d'infrastructure au push de voix en temps réel d'OpenAI, déjà disponible dans des produits tels que ChatGPT-Voice et l'API Realtime . Pour les architectes qui construisent des systèmes de médias interactifs, le modèle le plus intéressant est la décomposition elle-même : conserver le comportement du protocole dans la couche de routing