Comment nous avons créé en six mois un système d’IA vocale réactif en temps réel

Pour l’IA vocale, savoir quand parler est plus difficile qu’il n’y paraît. Les humains se passent naturellement la parole en une fraction de seconde, mais les anciens systèmes d’IA vocale ne pouvaient pas suivre ce rythme. Leur architecture au tour par tour reposait sur de minuscules modèles appelés détecteurs de tour, qui devaient accomplir une tâche ingrate : deviner trop tôt coupait la parole à l’utilisateur; deviner trop tard donnait l’impression d’une réponse lente. Ce n’est qu’après la décision du détecteur que le LLM, beaucoup plus grand, pouvait se mettre au travail.

GPT‑Live⁠, notre système vocal de troisième génération, retire le détecteur de tour du chemin audio. Son modèle vocal est duplex intégral, ce qui signifie qu’il peut écouter et parler simultanément. Cela élimine la nécessité d’un détecteur distinct et rend la conversation plus immédiate et naturelle. Lorsqu’un raisonnement approfondi ou l’utilisation d’outils est nécessaire, GPT‑Live peut aussi consulter nos modèles de pointe, comme GPT‑5.5, sans interrompre la conversation. Ensemble, ces capacités confèrent à GPT‑Live une combinaison inédite de réactivité conversationnelle et d’intelligence.

Offrir cette expérience à grande échelle a exigé une nouvelle architecture système optimisée pour une faible latence. Contrairement à l’inférence classique de type demande-réponse, notre système diffuse l’audio entrant vers le modèle vocal et la parole sortante vers l’utilisateur, tout en gérant la délégation sur un chemin asynchrone distinct. Au cours des six derniers mois, nous avons remanié l’inférence du modèle, la gestion du contexte et le transport multimédia afin que la parole circule avec fluidité de bout en bout.

L’architecture crée aussi une frontière nette entre le chemin vocal principal et la logique applicative. Il est ainsi facile de personnaliser le comportement de l’application sans nuire à la réactivité. Cette base propulse un éventail croissant de capacités dans ChatGPT Voix, dont la nouvelle possibilité de contrôler votre ordinateur et de coordonner vos agents dans l’application de bureau ChatGPT.

Dans cet article, nous expliquerons pourquoi les anciens systèmes au tour par tour ne répondaient pas à nos besoins et comment nous avons conçu le nouveau système pour assurer sa réactivité à chaque couche. Nous aborderons l’inférence avec état, la gestion dynamique du contexte, la délégation asynchrone et l’optimisation au niveau des protocoles, qui se combinent pour rendre GPT‑Live véritablement vivant.

Les anciennes architectures vocales avaient hérité du fonctionnement au tour par tour des LLM textuels, mais chaque tour était représenté par un bloc audio distinct plutôt que par du texte. Dans les systèmes en cascade, la reconnaissance vocale, le LLM et la synthèse vocale s’exécutaient successivement. Cet enchaînement augmentait la latence et ignorait des indices comme le ton et le rythme.

Les modèles parole à parole ont amélioré cette approche en traitant directement l’audio. Entraîner le modèle à comprendre et à générer nativement la parole lui a permis de préserver des détails perdus lors de la transcription et de répondre plus rapidement. Le système dépendait toutefois encore du détecteur de tour pour décider quand l’inférence pouvait commencer. Le modèle gérait une plus grande part de l’interaction, mais celle-ci demeurait au tour par tour.

GPT‑Live confie au modèle vocal le contrôle de la conversation : l’audio entre dans le modèle et en sort, tandis que le raisonnement approfondi et l’utilisation d’outils se font de façon asynchrone. La tâche principale du système consiste à maintenir une boucle multimédia ininterrompue. Les autres tâches, comme l’appel aux modèles de pointe et la conservation de la conversation, s’effectuent hors du chemin en direct.

Il n’est pas toujours facile de maintenir cette boucle multimédia sans interruption. Tout délai de transport, de traitement ou d’inférence peut devenir une pause ou un artefact audible. Un ancien système au tour par tour pouvait tolérer une certaine variation du moment d’arrivée d’un bloc audio. Cependant, un système multimédia en direct doit livrer chaque trame audio à temps.

Nos travaux antérieurs sur ChatGPT Voix et la Realtime API nous ont fourni une base importante. Nous avions déjà reconstruit notre infrastructure vocale⁠ afin de diffuser directement l’audio et la vidéo vers et depuis nos systèmes, avec une latence plus faible et prévisible. GPT‑Live a poussé cette conception plus loin en diffusant le contenu multimédia jusqu’au modèle grâce à un nouveau système d’inférence avec état conçu pour la conversation continue.

L’inférence en continu n’était toutefois qu’une partie de la solution. Pour assurer son bon fonctionnement en production, nous devions aussi garantir la livraison fiable de l’audio du client à la pile d’inférence et relever les défis liés à la gestion de l’état.

Nous avons rapidement décidé de séparer précisément le flux multimédia de la logique applicative et commerciale. L’audio circule entre le client et le modèle vocal sur un chemin rapide dédié. La délégation, l’utilisation d’outils et les autres tâches applicatives se déroulent derrière une frontière RPC asynchrone. Un appel d’outil ou un service dorsal lent peut retarder son propre résultat, mais ne peut pas interrompre le flux multimédia.

Cette séparation offre aussi au système une frontière nette pour la personnalisation. Les applications peuvent modifier leurs outils, leurs politiques et le comportement dorsal sans toucher au frontal multimédia chargé de maintenir la circulation de l’audio. Le chemin en direct reste petit, prévisible et axé sur le travail qui doit se faire en temps réel.

Nous avons écrit le frontal multimédia et la logique d’inférence en Go, remplaçant une ancienne mise en œuvre Python fondée sur asyncio. Cela a nettement amélioré la fluidité de la livraison des trames, le p95 du nouveau système égalant le p50 de l’ancien.

WebRTC fournit la base du transport. Il est conçu pour les contenus multimédias à faible latence et peut continuer de fonctionner malgré la perte de paquets, la dérive d’horloge et les changements de connexion du client. Si des paquets arrivent en retard, WebRTC peut subtilement étirer l’audio pour éviter les interruptions, puis accélérer brièvement la lecture afin de revenir au temps réel.

En réduisant au minimum la mise en mémoire tampon et les blocages dans tout le système, nous pouvons offrir la réactivité inférieure à une seconde que les humains attendent d’une conversation.

L’inférence avec état comporte ses propres compromis opérationnels. Une session vocale peut rester active longtemps, mais son contexte croît continuellement et les instances de modèle démarrent et s’arrêtent selon la demande.

Pour répondre à ces enjeux, nous avons créé un mécanisme de transfert transparent entre les instances de modèle. Lorsqu’une transition est nécessaire, nous pouvons préparer une instance de modèle de remplacement en parallèle de l’instance existante, la préremplir avec le contexte actuel de la session, exécuter l’inférence sur les deux en parallèle et basculer lorsque la nouvelle instance est entièrement prête.

Le même mécanisme de base prend aussi en charge le compactage dynamique du contexte. À mesure qu’une conversation se poursuit, son contexte accumulé peut finir par dépasser la limite contextuelle du modèle. Le compactage peut réduire la taille du contexte pour respecter la limite, mais l’opération prend du temps. Comme il modifie le contexte antérieur, il invalide aussi le cache clé-valeur (KV) du modèle, qui stocke les clés et les valeurs d’attention des jetons déjà traités. La reconstruction de cet état exige un nouveau préremplissage, ce qui ajoute un délai.

Nous traitons plutôt le compactage comme une autre transition gérée. Pendant que l’instance de modèle initiale poursuit la conversation, le système compacte le contexte et prépare une instance de remplacement avec le nouveau contexte. Une fois cette instance prête, nous pouvons basculer sans interrompre le contenu multimédia. Le système peut ainsi prendre en charge les longs appels et effectuer un compactage au besoin.

Le gros du travail reste hors du chemin en direct; même pendant un transfert, la conversation se poursuit donc sans perdre le rythme.

La capacité de GPT‑Live à faire appel aux modèles de pointe existants lui confère une grande puissance, en dissociant efficacement la « parole » de la « réflexion » approfondie. Mais pour que cette architecture à deux modèles semble former un seul système, il a fallu résoudre deux problèmes d’ingénierie connexes.

Premièrement, les résultats doivent revenir assez vite pour être utiles à l’échange en cours. Nous avons donc dû réduire la latence de tout le chemin de délégation, de l’acheminement et du traitement de l’invite jusqu’à l’inférence et aux appels d’outils. Parallèlement, d’autres systèmes du produit ont encore besoin de messages distincts; nous devions donc représenter la conversation en cours sous une forme qu’ils pouvaient comprendre.

Lorsqu’une délégation est envoyée, nous optimisons le temps nécessaire pour que le modèle de pointe produise un élément utile à la conversation. Le modèle vocal peut brièvement maintenir l’échange pendant qu’un modèle de pointe raisonne ou utilise des outils, mais il ne peut pas masquer une réponse excessivement lente. Nous avons donc intégré toute la boucle de délégation — acheminement, traitement de l’invite, inférence et appels d’outils — au budget de réactivité.

La première optimisation consiste à configurer le modèle de pointe et tous les outils nécessaires avant la demande de délégation. Au démarrage d’une session vocale, le serveur d’applications crée une session d’inférence pour le modèle de pointe et la préremplit avec le contexte initial de la conversation, afin que l’invite soit entièrement traitée avant la première demande déléguée.

Nous gardons ensuite cette session d’inférence disponible pendant toute la conversation vocale et utilisons une affinité de session stable pour les demandes successives. Avec la mise en cache de l’invite, ces techniques réduisent la latence tout en permettant de récupérer facilement d’une défaillance de processus de travail.

L’effort de raisonnement, les limites de sortie, les schémas d’outils et les allers-retours entre modèle et outils influent aussi sur le moment où la conversation reçoit un résultat utile; nous avons ajusté ces leviers pour accélérer les réponses. En réduisant au minimum le travail nécessaire sur le chemin de délégation, nous avons permis au modèle vocal d’intégrer rapidement les résultats de nos modèles de pointe.

Même si le modèle vocal traite des flux continus de parole, bon nombre des systèmes qui l’entourent fonctionnent encore selon les tours de l’utilisateur et de l’assistant, notamment l’interface de conversation de ChatGPT et certaines parties de notre infrastructure d’analyse et de sécurité. Le serveur d’applications démêle donc la conversation superposée et parfois ambiguë en messages distincts.

À mesure que l’audio arrive, le serveur utilise des transcriptions partielles et des signaux temporels pour déterminer qui a la parole et créer une file de messages. Le message le plus récent demeure provisoire; son texte, son minutage et l’identité de la personne qui parle peuvent tous changer à mesure que la parole arrive. Lorsqu’une personne a gardé la parole assez longtemps pour que l’attribution soit fiable, le serveur finalise le message correspondant.

Le chevauchement des voix complique les choses. Une brève marque d’écoute de l’assistant pendant que l’utilisateur parle (p. ex. « hum-hum » ou « d’accord ») ne devrait pas nécessairement devenir un message distinct. Cependant, une intervention substantielle de l’assistant devrait souvent le devenir. De même, nous privilégions la cohérence des réponses affichées de l’assistant, même lorsque l’utilisateur intervient au milieu.

Toute politique de segmentation établit un compromis entre fraîcheur et certitude. Une validation trop hâtive produit un historique fragmenté et un ordre instable; une attente excessive retarde les transcriptions et les fonctionnalités qui en dépendent. Le système conserve donc deux vues connexes de la conversation : une vue spéculative de l’état actuel et un registre faisant autorité de ce qui a été dit. La vue de conversation dans l’interface de l’application peut gérer les mises à jour; elle utilise donc la vue spéculative. Toutefois, la journalisation dans le pipeline d’analyse exige une transcription définitive.

Le reste de ChatGPT obtient ainsi une vue stable de l’échange sans imposer de tours de parole au chemin vocal en direct.

La réactivité commence dès que l’utilisateur clique sur le bouton. Avec GPT‑Live, le système doit établir le chemin multimédia et commencer à transmettre l’audio au modèle avant le début de la conversation. Chaque partie de la séquence de démarrage se trouve donc sur le chemin critique.

Comme indiqué plus haut, WebRTC offre une solide base en temps réel, mais le démarrage d’une session WebRTC standard exige un nombre étonnant de protocoles de connexion et d’allers-retours réseau. WebRTC précède l’accent mis sur la réduction des allers-retours qui a façonné des protocoles ultérieurs comme QUIC. Par conséquent, ses protocoles sous-jacents répètent parfois du travail lorsqu’ils sont utilisés ensemble. Par exemple, chaque protocole comprenait son propre mécanisme anti-DoS, même lorsqu’il n’était pas nécessaire dans le contexte de la pile WebRTC complète.

Nous avons analysé la pile et développé le WebRTC Abridged Roundtrip Protocol (WARP⁠(s'ouvre dans une nouvelle fenêtre)), qui fait passer le démarrage des contenus multimédias et des données de six allers-retours réseau à un seul. WARP y parvient grâce à un ensemble d’améliorations de protocole rétrocompatibles : intégrer le protocole de connexion DTLS à ICE (SPED⁠(s'ouvre dans une nouvelle fenêtre)), utiliser le protocole de connexion DTLS 1.3⁠(s'ouvre dans une nouvelle fenêtre) plus rapide, prénégocier le protocole de connexion SCTP (SNAP⁠(s'ouvre dans une nouvelle fenêtre)) et prénégocier les canaux de données plutôt que d’utiliser DCEP⁠(s'ouvre dans une nouvelle fenêtre).

Nous avons conçu WARP comme un ensemble de spécifications ouvertes, en collaboration avec des membres de la communauté WebRTC, afin que l’ensemble de l’écosystème profite de ces travaux. Nous faisons progresser les propositions au sein du groupe de travail TSVWG de l’IETF, et la prise en charge de WARP a déjà été ajoutée à libwebrtc et à Pion, tandis que des travaux sont en cours dans d’autres mises en œuvre WebRTC.

Après l’optimisation du protocole de connexion multimédia, un dernier délai ressortait : l’échange de signalisation utilisé pour transmettre les paramètres SDP avant que WebRTC puisse se connecter. Pour retirer cet échange du chemin critique, nous avons développé ce que nous appelons Instant Connect. Il négocie ces paramètres à l’avance, sans réserver de capacité serveur ni modifier les mises en œuvre WebRTC existantes.

Instant Connect fonctionne parallèlement au flux de signalisation standard. Si les paramètres prénégociés sont valides, le serveur peut matérialiser la session à l’arrivée du premier paquet multimédia. S’ils sont périmés ou invalides, le flux de signalisation est déjà en cours; le client peut donc revenir à celui-ci sans latence supplémentaire.

Ensemble, Instant Connect et WARP réduisent considérablement le délai entre l’intention de l’utilisateur et le flux multimédia en direct. Comme l’échange SDP est retiré du chemin critique et que WARP condense le protocole de connexion du transport, le client peut maintenant démarrer une session avec un seul paquet UDP. Le serveur peut répondre immédiatement, permettant au reste du système d’entreprendre ce qui compte vraiment pour l’utilisateur : écouter et répondre.

Un système peut sembler rapide sur papier, mais ralentir avec un trafic vocal réel. Avant de laisser GPT‑Live converser avec les utilisateurs, nous avons effectué un test silencieux qui acheminait une part faible et croissante des sessions ChatGPT Voix en production vers l’expérience existante du mode vocal avancé et notre nouveau système. Le mode vocal avancé continuait de servir les utilisateurs comme d’habitude, tandis que le chemin fantôme exécutait l’inférence en lecture seule. Le système a ainsi été exposé à de vrais clients, réseaux, durées de session et répartitions géographiques sans modifier ce que les utilisateurs entendaient.

L’une des premières leçons a été que la capacité ne pouvait pas se résumer au débit des GPU. Les sessions vocales restent ouvertes et envoient continuellement des trames; les gestionnaires de flux côté processeur, les files d’attente et les chemins réseau doivent donc évoluer au même rythme que l’inférence. Sous une charge réelle, un composant auxiliaire a saturé plus tôt que ne le prévoyaient nos estimations de test de charge, entraînant une accumulation des demandes d’inférence et une hausse cumulative de la latence. Nous avons remplacé la question de capacité « Combien de demandes un GPU peut-il traiter? » par « Combien de sessions simultanées le système peut-il prendre en charge tout en livrant chaque trame à temps? »

Le test a aussi fait de la géographie une préoccupation prioritaire. Acheminer une session vers une capacité éloignée peut ajouter des délais à plusieurs étapes du démarrage et de la diffusion en continu. Nous avons commencé à valider les déploiements de modèles avec la capacité régionale et la configuration de l’orientation du trafic, puis à ventiler la latence selon la provenance géographique. Rapprocher l’inférence des utilisateurs a aidé, mais a aussi renforcé une leçon plus générale : la réactivité de bout en bout dépend de chaque service du parcours, et pas seulement du serveur de modèles.

D’autres défaillances ne sont apparues qu’au fil de cycles de vie de session réalistes. Les longues sessions ont révélé des contraintes de mémoire et de persistance. Les reconnexions ont mis à l’épreuve le compactage et la restauration de l’état. Les déconnexions ordinaires des clients ont révélé des conditions de concurrence dans le protocole d’arrêt. Ces problèmes apparaissaient rarement lors de courts tests de charge, car ils dépendaient du temps, de l’état accumulé et du comportement au-delà des limites des services.

Enfin, les tests en production nous ont obligés à améliorer l’observabilité et les contrôles de déploiement. Nous avons trouvé des mesures qui confondaient différentes sources de latence, des tableaux de bord dont les agrégats masquaient des moteurs individuels défaillants et des écarts de configuration entre les systèmes testés et déployés. Nous avons donc ajouté une télémétrie plus détaillée, une validation par rapport à des configurations éprouvées, des montées en charge graduelles et la capacité d’isoler ou de désactiver rapidement des chemins individuels. Le test silencieux est devenu une répétition avant le lancement, non seulement pour déterminer le trafic que le système pouvait accepter, mais aussi la vitesse à laquelle nous pouvions détecter et contenir une défaillance, puis nous en remettre.

Faire passer GPT‑Live à l’échelle de ChatGPT a exigé un tout nouveau système fondé sur un principe essentiel : la voix doit circuler. L’inférence en continu alimente le modèle duplex intégral en audio. Un chemin multimédia dédié assure une livraison fiable des trames. La délégation asynchrone permet une réflexion plus poussée en parallèle. Un transport optimisé maintient la réactivité de l’expérience jusqu’à l’utilisateur.

L’architecture derrière GPT‑Live devient déjà une plateforme plus vaste d’interaction en temps réel. Elle propulse ChatGPT Voix dans son évolution de la conversation vers la coordination agentique et servira de base à la future API GPT‑Live. À terme, elle permettra aux expériences vocales de couvrir plus d’appareils, d’applications et de modalités sans sacrifier l’immédiateté qui donne vie à la conversation vocale.

Si vous souhaitez résoudre ce genre de problèmes d’ingénierie, venez travailler avec nous⁠.