OpenAI a expliqué comment elle a repensé WebRTC pour une AI vocale à faible latence

OpenAI a révélé les détails de la façon dont elle a repensé son infrastructure WebRTC pour les fonctionnalités vocales de ChatGPT et l'API Realtime. L'objectif était simple : les conversations avec l'IA ne devaient pas s'interrompre en raison de la latence du réseau, même sous une charge mondiale avec des centaines de millions d'utilisateurs.

Pourquoi l'ancienne approche ne fonctionnait pas

Pour l'IA vocale, il ne suffit pas de simplement reconnaître la parole et de générer rapidement une réponse. La conversation doit s'écouler au rythme de la parole humaine : sans pauses maladroites, d'interruptions coupées et d'attentes de plusieurs secondes avant la réaction du modèle.

OpenAI écrit que, à son échelle, cela se réduit à trois exigences clés : une couverture mondiale pour plus de 900 millions d'utilisateurs actifs hebdomadaires, un établissement rapide de la connexion et une latence aller-retour faible et stable pour l'audio.

« L'IA vocale ne semble naturelle que lorsque la conversation se

déplace au rythme de la parole. »

Le problème était que l'approche WebRTC classique ne s'adaptait pas bien à l'infrastructure en nuage d'OpenAI. Si chaque session a besoin de son propre port UDP public, alors avec une haute concurrence, vous devez ouvrir et sécuriser d'énormes plages de ports. Cela est inconvenient pour Kubernetes, complique l'équilibrage de charge, rend la mise à l'échelle automatique plus fragile et augmente la surface d'attaque. Pendant ce temps, les sessions ICE et DTLS elles-mêmes restent avec état : les paquets doivent arriver exactement au processus qui possède la connexion particulière.

Relay plus transcepteur

Après avoir comparé plusieurs options, OpenAI a abandonné le schéma où le modèle agit comme un participant WebRTC régulier via un SFU. Pour sa charge de travail, les scénarios un-à-un sont typiques : un utilisateur parle à un modèle ou un client communique avec un agent en temps réel. Donc l'entreprise a choisi le modèle transcepteur : un service edge termine la connexion WebRTC du client, puis traduit les médias et les événements en protocoles internes pour l'inférence, la transcription, la synthèse vocale, l'appel d'outils et l'orchestration.

L'idée clé de la nouvelle architecture est de séparer l'acheminement des paquets de la terminaison du protocole. Relay est devenu une couche UDP légère à l'entrée avec une petite empreinte réseau publique, tandis que transcepteur est resté le composant avec état qui maintient ICE, DTLS, les clés SRTP et tout le cycle de vie de la session. Relay ne décrypte pas les médias, ne négocie pas les codecs et ne tente pas de prétendre être un pair WebRTC. Il lit simplement le minimum de métadonnées du paquet et envoie le trafic vers l'endroit où réside la session nécessaire.

L'astuce la plus intéressante implique le premier paquet. OpenAI utilise le fragment de nom d'utilisateur ICE, ou ufrag, et y intègre juste assez d'informations d'acheminement pour que relay sélectionne le cluster et le transcepteur spécifique. Pendant la signalisation, le client reçoit une IP de relay partagée et un port UDP fixe, et le premier paquet STUN fournit au système suffisamment de données pour envoyer le flux par le bon chemin immédiatement, sans un appel séparé à un service de recherche externe. Après l'établissement de la route, la cartographie des adresses est stockée supplémentairement dans Redis pour une récupération rapide après le redémarrage du relay.

Comment ils ont réduit la latence

Une fois que la surface UDP publique a été réduite à un petit nombre d'adresses et de ports stables, OpenAI a dimensionné ce même schéma mondialement. Ainsi 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 introduisent dans le réseau d'OpenAI sans un saut initial supplémentaire via une région éloignée. Pour la signalisation, l'entreprise utilise l'acheminement géographique et de proximité de Cloudflare, de sorte que la demande HTTP/WebSocket initiale et la première vérification ICE arrivent au cluster le plus proche approprié.

• Couche UDP publique petite et fixe au lieu de milliers de ports ouverts
• Acheminement du premier paquet via des données déjà intégrées dans l'ufrag ICE
• Socket UDP partagé côté transcepteur au lieu d'un socket par session
• État en mémoire de courte durée plus cache Redis pour récupération rapide de route
• `SO_REUSEPORT`, épinglage de thread aux threads du système d'exploitation et allocations minimisées pour un débit élevé

OpenAI a écrit son relay en Go et a délibérément le gardé étroit dans sa responsabilité : il n'interrompt pas la session WebRTC, mais ne fait que analyser rapidement les en-têtes nécessaires, met à jour l'état du thread minimum et envoie les paquets plus loin. L'entreprise souligne spécifiquement qu'elle n'avait pas besoin de contournement du kernel : une optimisation soignée au niveau de `SO_REUSEPORT`, l'épinglage de thread et la réduction des copies inutiles suffisaient pour gérer le trafic média en temps réel mondial avec une couche relay relativement petite et sans abandonner le comportement WebRTC standard sur les clients.

Ce que cela signifie

Pour les utilisateurs, tout cela ressemble à « le mode vocal est devenu plus réactif », mais pour le marché, quelque chose d'autre compte plus : OpenAI a démontré comment construire l'IA vocale à l'échelle de masse au-dessus de WebRTC standard sans clients personnalisés et sans l'expansion douloureuse de l'infrastructure réseau. C'est un bon point de référence pour les développeurs d'assistants en temps réel, d'agents vocaux et de produits où une latence d'une demi-seconde casse déjà toute l'expérience utilisateur.