OpenAI explique comment elle a repensé WebRTC pour une IA vocale à faible latence

OpenAI a dévoilé les détails de la refonte de son infrastructure WebRTC pour les fonctions vocales de ChatGPT et la Realtime API. L'objectif était simple : empêcher que la conversation avec l'IA ne s'effondre à cause des latences réseau, même sous charge mondiale et avec des centaines de millions d'utilisateurs.

Pourquoi l'ancienne approche ne tenait plus

Pour une IA vocale, il ne suffit pas de reconnaître la parole et de générer rapidement une réponse. La conversation doit avancer au rythme de la parole humaine : sans pauses gênantes, sans interruptions coupées et sans une seconde d'attente avant que le modèle réagisse. OpenAI écrit qu'à son échelle, cela revient à trois exigences simultanées : une couverture mondiale pour plus de 900 millions d'utilisateurs actifs hebdomadaires, un établissement rapide de la connexion et un temps d'aller-retour audio faible et stable.

«

Une IA vocale ne paraît naturelle que lorsque la conversation avance à la vitesse de la parole. »

Le problème tenait au fait que l'approche WebRTC classique s'accorde mal avec l'infrastructure cloud d'OpenAI. Si chaque session exige son propre port UDP public, il faut, en cas de forte concurrence, ouvrir et protéger d'immenses plages de ports. C'est peu pratique pour Kubernetes, cela complique l'équilibrage de charge, fragilise l'autoscaling et élargit la surface d'attaque. De plus, les sessions ICE et DTLS restent stateful : les paquets doivent atterrir précisément sur le processus qui détient la connexion concernée.

Relay plus transceiver

Après avoir comparé plusieurs options, OpenAI a écarté le schéma où le modèle joue le rôle d'un participant WebRTC ordinaire via un SFU. Sa charge typique relève du un-à-un : un utilisateur parle à un modèle, ou un client échange avec un agent temps réel. L'entreprise a donc retenu le modèle transceiver : un service en périphérie termine la connexion WebRTC du client, puis traduit les flux média et les événements vers des protocoles internes pour l'inférence, la transcription, la synthèse vocale, l'appel d'outils et l'orchestration.

L'idée centrale de la nouvelle architecture est de séparer le routage des paquets de la terminaison du protocole. Le relay est devenu une couche UDP légère en entrée, avec une empreinte réseau publique réduite, tandis que le transceiver reste le composant stateful qui gère ICE, DTLS, les clés SRTP et tout le cycle de vie de la session. Le relay ne déchiffre pas les flux média, ne négocie pas les codecs et ne cherche pas à se faire passer pour un pair WebRTC. Il lit seulement un volume minimal de métadonnées dans le paquet et transmet le trafic là où vit la session voulue.

L'astuce la plus intéressante concerne le premier paquet. OpenAI utilise l'ICE username fragment, ou ufrag, et y intègre exactement l'information de routage dont le relay a besoin pour choisir le cluster et le transceiver précis. Pendant la signalisation, le client reçoit une VIP de relay partagée et un port UDP fixe, et le premier paquet STUN fournit au système assez de données pour envoyer immédiatement le flux sur le bon chemin, sans interroger un service de lookup externe. Une fois la route établie, la table de correspondance des adresses est aussi stockée dans Redis afin de récupérer rapidement après un redémarrage du relay.

Comment la latence a été réduite

Une fois la surface UDP publique ramenée à un petit nombre d'adresses et de ports stables, OpenAI a déployé le même schéma à l'échelle mondiale. C'est ainsi qu'est né Global Relay, un ensemble distribué de points d'entrée qui reçoivent les paquets plus près de l'utilisateur et les injectent dans le réseau d'OpenAI sans premier saut inutile par une région lointaine. Pour la signalisation, l'entreprise s'appuie sur le routage géographique et de proximité de Cloudflare : la requête HTTP/WebSocket initiale comme le premier contrôle ICE arrivent ainsi au cluster adapté le plus proche.

• Une couche UDP publique petite et fixe au lieu de milliers de ports ouverts
• Routage du premier paquet grâce à des données déjà intégrées à l'ICE ufrag
• Un socket UDP partagé côté transceiver au lieu d'un socket par session
• Un état en mémoire de courte durée plus un cache Redis pour restaurer rapidement la route
• `SO_REUSEPORT`, épinglage des threads sur des threads de l'OS et minimisation des allocations pour un débit élevé

OpenAI a écrit le relay en Go et en a volontairement restreint les responsabilités : il ne termine pas la session WebRTC, il se contente d'analyser rapidement les en-têtes nécessaires, de mettre à jour un état de flux minimal et de transmettre les paquets. L'entreprise souligne qu'elle n'a pas eu besoin de kernel bypass : une optimisation soignée autour de `SO_REUSEPORT`, du thread pinning et de la réduction des copies superflues a suffi pour écouler le trafic média temps réel mondial avec une couche de relay relativement réduite et sans renoncer au comportement standard de WebRTC côté clients.

Ce que cela signifie

Pour les utilisateurs, tout cela se résume à « le mode vocal est devenu plus réactif », mais pour le marché, l'essentiel est ailleurs : OpenAI a montré comment bâtir une IA vocale grand public sur du WebRTC standard, sans clients personnalisés et sans prolifération douloureuse de l'infrastructure réseau. C'est une bonne référence pour les développeurs d'assistants temps réel, d'agents vocaux et de produits où une demi-seconde de latence suffit à gâcher toute l'expérience utilisateur.