OpenAI révolutionne l'IA vocale avec une latence ultra-faible

L'importance de la latence dans l'IA vocale

Pour que l'IA vocale soit perçue comme naturelle, elle doit fonctionner à la vitesse de la parole. Les utilisateurs remarquent immédiatement les pauses ou interruptions dues à la latence. Cela est particulièrement crucial pour le ChatGPT vocal d'OpenAI, ainsi que pour les développeurs utilisant l'API Realtime et les agents dans des flux de travail interactifs. OpenAI s'efforce de minimiser ces délais pour offrir une expérience utilisateur fluide.

Pour atteindre cet objectif, OpenAI a identifié trois exigences essentielles : une portée mondiale pour plus de 900 millions d'utilisateurs actifs hebdomadaires, une configuration de connexion rapide dès le début d'une session, et un temps de latence média aller-retour faible et stable. Ces exigences garantissent que les interactions vocales se déroulent sans heurts.

Réarchitecture de la pile WebRTC

OpenAI a récemment réarchitecturé sa pile WebRTC pour répondre aux contraintes de grande échelle. La terminaison média par port unique par session ne s'adapte pas bien à l'infrastructure d'OpenAI. De plus, les sessions ICE (Interactive Connectivity Establishment) et DTLS (Datagram Transport Layer Security) nécessitent une propriété stable, et le routage mondial doit maintenir une faible latence de premier saut.

WebRTC est une norme ouverte pour l'envoi d'audio, de vidéo et de données à faible latence. Bien qu'il soit souvent associé aux appels en pair-à-pair, il constitue également une base pratique pour les systèmes en temps réel client-serveur. WebRTC standardise les aspects complexes des médias interactifs, tels que l'établissement de connectivité ICE, le transport crypté DTLS et SRTP, la négociation de codecs, et le contrôle de qualité RTCP.

L'audio doit arriver sous forme de flux continu, ce qui permet à un agent vocal de commencer à transcrire, raisonner, appeler des outils ou générer de la parole pendant que l'utilisateur parle encore. Cette capacité est essentielle pour que le système paraisse conversationnel plutôt que de fonctionner comme un système push-to-talk.

Le rôle de Justin Uberti et Sean DuBois

L'écosystème WebRTC bénéficie de contributions significatives de personnalités comme Justin Uberti, l'un des architectes originaux de WebRTC, et Sean DuBois, créateur et mainteneur de Pion. Leur travail a permis à des équipes comme celle d'OpenAI de s'appuyer sur une infrastructure média éprouvée. Aujourd'hui, Justin et Sean sont collègues chez OpenAI, contribuant à rapprocher WebRTC et l'IA en temps réel.

Choisir une architecture média

Après avoir choisi WebRTC, OpenAI a dû décider où terminer la connexion et comment connecter ces sessions au backend d'inférence. La terminaison détermine la gestion de l'état de session, le transport média, le routage, la latence et l'isolation des pannes.

Un SFU (Selective Forwarding Unit) est souvent utilisé pour les produits multipartites, mais pour les sessions 1:1, OpenAI a opté pour un modèle de transceiver. Ce modèle permet de convertir les médias et événements en protocoles internes pour l'inférence des modèles, la transcription, et la génération de la parole.

Implémentation avec Pion

OpenAI a construit son service transceiver en Go, utilisant Pion pour gérer la signalisation et la terminaison média. Ce service alimente le ChatGPT vocal, l'API Realtime, et plusieurs projets de recherche. Le transceiver gère la négociation SDP, la sélection de codecs, les identifiants ICE, et la configuration de session.

Défis de déploiement avec Kubernetes

Le déploiement sur Kubernetes présente des défis, notamment l'épuisement des ports. Le modèle conventionnel de terminaison WebRTC par port unique par session nécessite de larges plages de ports UDP publics, difficiles à gérer et sécuriser.

OpenAI a séparé le routage des paquets de la terminaison des protocoles, utilisant une architecture de relais et transceiver. Cette approche permet de maintenir une petite surface UDP publique tout en routant chaque paquet vers le transceiver qui possède la session WebRTC correspondante.

Les protocoles ICE et DTLS sont des protocoles d'état, ce qui signifie que le processus qui a créé une session doit continuer à recevoir les paquets de cette session pour valider les vérifications de connectivité, compléter l'échange DTLS, déchiffrer le SRTP et traiter les changements ultérieurs de session tels que les redémarrages ICE.

Comparaison des architectures média WebRTC

OpenAI a évalué plusieurs architectures média WebRTC, y compris TURN (Traversal Using Relays around NAT) et IP:port unique par serveur. Chaque approche présente des avantages et des inconvénients en termes de gestion des ports, de sécurité, et d'adaptabilité à Kubernetes.

L'architecture de relais et transceiver d'OpenAI sépare le routage des paquets de la terminaison des protocoles. La signalisation atteint toujours le transceiver pour la configuration de session, tandis que les médias passent d'abord par le relais, une couche de retransmission UDP légère.

Épuisement des ports

Le premier problème était le modèle de port unique par session lui-même. À haute concurrence, cela signifie exposer et gérer de très grandes plages de ports UDP.

Les équilibreurs de charge cloud et les services Kubernetes ne sont pas conçus pour des dizaines de milliers de ports UDP publics par service. Chaque plage supplémentaire ajoute de la complexité opérationnelle dans la configuration de l'équilibreur de charge, la vérification de l'état, la politique de pare-feu et la sécurité des déploiements.

Les grandes plages de ports UDP sont difficiles à sécuriser car elles augmentent la surface d'attaque accessible et compliquent l'audit des politiques réseau.

Elles ne conviennent également pas à l'auto-scaling. Les pods sont constamment ajoutés, supprimés et reprogrammés dans Kubernetes. Exiger que chaque pod réserve et annonce une large plage de ports stables rend cette élasticité fragile.

Collage d'état

Les conceptions à port unique par serveur résolvent le problème du nombre de ports, mais elles introduisent un second problème : préserver la propriété de chaque session à travers une flotte. Les protocoles ICE et DTLS sont des protocoles d'état. Le processus qui a créé une session doit continuer à recevoir les paquets de cette session afin de valider les vérifications de connectivité, de compléter l'échange DTLS, de déchiffrer le SRTP et de traiter les changements ultérieurs de session tels que les redémarrages ICE. Si des paquets pour la même session arrivent sur un processus différent, la configuration peut échouer ou les médias peuvent être interrompus.

Cela nous a donné un objectif spécifique : exposer une petite surface UDP fixe au public tout en routant chaque paquet vers le transceiver qui possède la session WebRTC correspondante.

Comparaison des architectures média WebRTC

Nous avons évalué plusieurs manières d'y parvenir, y compris TURN (Traversal Using Relays around NAT), où un relais à la périphérie termine les allocations client et retransmet le trafic en leur nom.

• Approche : Avantages et inconvénients

  • IP:port unique par session (également connu sous le nom de UDP direct natif) :

    • Avantages : Chemin média direct client-serveur, pas de couche de retransmission dans le chemin de données.
    • Inconvénients : Nécessite un port UDP public par session, grandes plages de ports difficiles à exposer et sécuriser, mauvaise adaptation à Kubernetes et aux équilibreurs de charge cloud.

  • IP:port unique par serveur :

    • Avantages : Empreinte UDP publique beaucoup plus petite que l'exposition par session, un socket partagé par serveur peut démultiplexer plusieurs sessions.
    • Inconvénients : Fonctionne proprement sur un seul hôte, mais pas à travers une flotte équilibrée par charge.

  • Relais TURN (terminant le protocole) :

    • Avantages : Les clients n'ont besoin d'atteindre que l'adresse et le port du relais TURN, peut centraliser la politique à la périphérie.
    • Inconvénients : Les allocations TURN ajoutent des tours de configuration, déplacer ou récupérer des allocations entre serveurs TURN reste difficile.

  • Forwarder sans état + terminator avec état (relais OpenAI + transceiver) :

    • Avantages : Petite empreinte UDP publique, le transceiver possède toujours la session WebRTC complète.
    • Inconvénients : Ajoute un saut de retransmission avant que les médias n'atteignent le transceiver propriétaire, nécessite une coordination personnalisée entre le relais et le transceiver.

Vue d'ensemble de l'architecture : relais + transceiver

L'architecture que nous avons déployée sépare le routage des paquets de la terminaison des protocoles. La signalisation atteint toujours le transceiver pour la configuration de session, tandis que les médias entrent d'abord par le relais. Le relais est une couche de retransmission UDP légère avec une petite empreinte publique.