Comment j’ai construit moi-même un agent vocal avec moins de 500 ms de latence

 (ntik.me)
12 points par GN⁺ 2026-03-03 | 1 commentaires | Partager sur WhatsApp
  • Présentation d’un cas de développement d’un agent vocal auto-hébergé ayant réduit la latence d’un système d’IA vocale à environ 400 ms
  • En connectant STT, LLM et TTS dans un pipeline temps réel, le système a atteint une vitesse de réponse deux fois plus rapide que des plateformes commerciales existantes comme Vapi
  • Deepgram Flux gère la détection de parole et la prise de tour, tandis que le modèle llama-3.3-70b de Groq réduit fortement le temps de génération du premier token
  • Grâce au déploiement géographique et à l’optimisation réseau, la latence a été réduite de plus de moitié lors d’un déploiement dans la région UE
  • Le cœur d’un agent vocal réside dans l’orchestration temps réel et la conception du pipeline ; une implémentation en interne permet d’identifier clairement les goulets d’étranglement de performance

Contexte de la création de l’agent vocal

  • Fort d’une expérience de prototypage d’agents vocaux pour un grand groupe de biens de consommation, l’auteur a tenté une implémentation maison afin de maîtriser directement la complexité des plateformes commerciales
  • Des plateformes comme ElevenLabs et Vapi sont pratiques, mais il est difficile d’en comprendre le fonctionnement interne et impossible de contrôler finement la latence
  • L’objectif était de reproduire soi-même le niveau de performance de Vapi, ce qui a été réalisé en une journée avec environ 100 dollars de crédits API

La complexité des agents vocaux

  • Contrairement à un chatbot textuel, la voix exige une gestion en temps réel de la prise de tour (turn-taking)
  • Dès que l’utilisateur commence à parler, le système doit interrompre immédiatement son énoncé, puis répondre rapidement dès qu’il s’arrête
  • Une simple détection vocale (VAD) ne suffit pas à déterminer précisément la fin d’un tour de parole, ce qui entraîne latence, chevauchement de parole et silences inutiles

Première implémentation : test basé sur la VAD

  • Réception d’un flux audio μ-law via un serveur FastAPI et un WebSocket Twilio
  • Utilisation de Silero VAD pour détecter la présence de voix, puis lecture d’un fichier WAV préenregistré à la fin de l’énoncé
  • Malgré sa simplicité, cette approche a permis de vérifier une réactivité immédiate et un flux conversationnel naturel
  • Cette étape a servi de référence pour mesurer la borne basse de la latence

Deuxième implémentation : Deepgram Flux et pipeline temps réel

  • Adoption de Deepgram Flux pour unifier transcription en streaming et détection des tours de parole
  • Lorsque Flux détecte la fin d’un énoncé, le traitement s’enchaîne comme suit
    • transmission de la transcription et de l’historique de conversation au LLM
    • streaming vers le TTS (WebSocket) dès la génération du premier token
    • envoi en temps réel de l’audio généré vers Twilio
  • Le maintien préalable de la connexion TTS active (warm pool) a permis d’économiser environ 300 ms de latence
  • Dès que l’utilisateur recommence à parler, LLM, TTS et transmission audio sont annulés immédiatement, ce qui permet une interruption naturelle

Mesure de la latence et déploiement régional

  • En exécution locale depuis la Turquie, la latence moyenne observée était de 1,6 à 1,7 seconde
  • Après déploiement dans la région UE de Railway et alignement de Twilio, Deepgram et ElevenLabs sur des régions UE
    • la moyenne est tombée à 690 ms (790 ms au total), soit environ 50 ms plus rapide que Vapi
  • Cette baisse de latence a nettement amélioré la réactivité conversationnelle et fluidifié l’interruption en cours de parole

Choix du modèle et amélioration des performances

  • Au départ, le système utilisait gpt-4o-mini, puis il est passé à llama-3.3-70b de Groq
  • Les tests ont montré que le temps jusqu’au premier token (TTFT) du modèle Groq était jusqu’à trois fois plus rapide que celui d’OpenAI
  • Une latence de bout en bout inférieure à 400 ms a été obtenue en moyenne, avec le premier audio reçu en moins de 500 ms
  • À ce niveau, on a la sensation que l’agent réagit plus vite qu’un humain

Principaux enseignements techniques

  • L’optimisation de la latence repose avant tout sur la maîtrise du chemin complet entre la fin de l’énoncé et la première sortie vocale
  • Comme le TTFT représente plus de la moitié de la latence totale, le choix d’un modèle à faible latence est crucial
  • Il faut mettre STT→LLM→TTS en pipeline streaming plutôt que les exécuter séquentiellement
  • En cas d’interruption, tous les composants doivent être annulés immédiatement pour conserver une conversation naturelle
  • La proximité géographique entre services a un impact décisif sur la latence

Comparaison avec les plateformes commerciales

  • Vapi et ElevenLabs restent utiles pour la plupart des équipes grâce à leurs fonctions annexes comme l’API, la stabilité et l’observabilité
  • Mais une implémentation maison permet de comprendre les véritables goulets d’étranglement et le sens des paramètres, tout en rendant possible une
    orchestration sur mesure adaptée à des besoins spécifiques
  • Un système vocal est au fond un problème d’orchestration et, avec une architecture claire, cela devient un défi d’ingénierie solvable

Code source

À lire aussi

1 commentaires

 
GN⁺ 2026-03-03
Avis Hacker News

  • Cet article est vraiment intéressant. L’équipe Amazon Alexa a étudié ce problème il y a longtemps et il existe même des brevets associés
    Dans une conversation, la latence moyenne entre humains est de 0 ms : autrement dit, la personne suivante commence déjà à parler avant que l’autre ait fini. C’est parce que le cerveau anticipe ce que dit l’interlocuteur tout en préparant la réponse en parallèle
    En revanche, les gens s’attendent à de la latence de la part d’un assistant vocal. Pour deux raisons : l’idée qu’un ordinateur doit « réfléchir », et la latence des appels sur téléphone mobile
    Presque aucune réponse d’Alexa n’est en dessous de 500 ms. Avant, on considérait simplement 300 ms de silence comme une « fin de tour », mais le véritable point clé, c’est la semantic end-of-turn
    Aujourd’hui, la puissance de calcul est suffisante, donc je me demande à quel point cela a progressé. Le traitement géographiquement proche (edge computing) a été un tournant majeur

    • La latence des appels mobiles est particulièrement stressante pour les personnes plus âgées. À l’époque des lignes fixes, il n’y avait pratiquement pas de délai, donc elles ressentent cette gêne sans forcément comprendre pourquoi
    • Je ne suis pas d’accord avec le point 2. La latence des assistants vocaux reste beaucoup trop élevée. On se retrouve encore à attendre en se demandant : « Est-ce que ça a marché ? » Je ne pense pas que la latence du téléphone mobile crée une attente similaire pour d’autres appareils
    • Considérer 300 ms de silence comme une fin de tour était vraiment pénible. Du coup, il fallait volontairement insérer des mots de remplissage (filler) comme « euh… », et j’ai fini par abandonner le chat vocal
    • Merci pour ce partage passionnant. Mais je me demande pourquoi Amazon/Google/Apple ont cessé d’innover sur les assistants vocaux ces dernières années. Avec leur base d’utilisateurs existante, ils auraient pourtant pu redéfinir le marché
    • On dirait qu’il est question d’une architecture où le LLM prend la suite de l’énoncé de l’utilisateur de manière prédictive. Si, une fois l’énoncé réellement terminé, la prédiction correspond, il devient possible de répondre immédiatement sans latence. On peut aussi imaginer une approche qui prédit plusieurs branches candidates en parallèle avant de les élaguer

  • Au fond, la voix est un problème de turn-taking. Il y a une amélioration simple que personne n’a vraiment exploitée : les mots de remplissage et la modulation du tempo
    Si le LLM détecte un bref silence, il pourrait insérer des fillers contextuels comme « euh » ou « oui, c’est ça » pendant que la vraie réponse est en cours de génération. Cela rendrait la conversation beaucoup plus naturelle

    • Entièrement d’accord. Un petit modèle à faible latence pourrait d’abord générer une réponse courte, et si le résultat TTS est mis en cache, la latence peut être réduite de manière drastique. Des phrases comme « Un instant, je réfléchis » pourraient partir en quelques millisecondes
    • Mais ce n’est peut-être pas une « amélioration simple ». Humaniser un système robotique est difficile, et le simple fait de modifier la structure des phrases peut au contraire le faire sonner encore plus mécanique. J’ai essayé moi-même et j’ai échoué
    • À ce sujet, le billet de blog de LiveKit « Prompting Voice Agents to Sound More Realistic » est intéressant
    • Si le système peut prédire la réponse avant même que l’utilisateur ait fini de parler, cela paraîtra bien plus naturel
    • Quand la détection de fin de tour se trompe, il serait aussi possible de raccorder naturellement avec un filler au niveau phonémique. À l’inverse, si la détection arrive trop tard, on pourrait préfixer le prompt avec une première syllabe déjà décidée pour lancer la réponse avec celle-ci

  • Excellent article. Le client OpenAI Responses a récemment adopté les WebSockets, ce qui a réduit la latence.
    Une autre méthode consiste à exécuter un LLM minuscule directement en local. J’ai construit un pipeline entièrement local via le projet ova, et j’ai obtenu un temps d’aller-retour inférieur à une seconde, même sans streaming

    • Très beau projet, je l’ai ajouté à mes favoris. J’aimerais bien échanger plus tard et partager des retours d’expérience

  • La structure du pipeline de streaming de l’article et l’analyse détaillée de la latence à chaque étape étaient très utiles. Le fait d’avoir implémenté soi-même la boucle de turn-taking est particulièrement marquant
    En revanche, la comparaison « deux fois plus rapide que Vapi » est un peu inexacte. Vapi effectue bien plus de travail : appels d’outils, webhooks, routage multi-tenant, etc.
    La vraie valeur de cet article réside dans la « compréhension acquise en construisant sa propre boucle d’orchestration ». S’il avait simplement été présenté comme « ce que j’ai appris en le faisant moi-même », cela aurait été parfait

  • Moi aussi, je construis un agent vocal en production avec la combinaison Twilio + Deepgram + ElevenLabs + API LLM
    Le point central n’était pas la précision du STT, mais l’UX du turn-taking. Le ressenti a complètement changé quand nous avons remplacé un seuil de silence fixe par une semantic end-of-turn
    La latence interrégionale compte aussi. En se connectant depuis l’Inde vers des serveurs américains, rien que le saut edge de Twilio ajoute déjà 150 à 250 ms. Le routage régional a permis d’améliorer cela
    La gestion du barge-in (interruption en cours de réponse) est également complexe. Il ne suffit pas d’interrompre le LLM et le TTS : il faut aussi annuler les workflows d’automatisation déjà déclenchés. Nous avons déjà eu un bug où une réservation se validait réellement si l’utilisateur interrompait pendant la confirmation

  • Soniox Real-time (prise en charge de 60 langues) gère l’endpoint detection au niveau du modèle. C’est bien plus précis qu’un VAD
    Voir la documentation technique, le benchmark de Daily, et la page de démonstration
    J’ai travaillé chez Soniox autrefois. C’était le premier service à implémenter la détection de fin en temps réel

    • D’après l’article d’origine, ils ont utilisé Deepgram Flux. Cela aussi prend en charge l’endpointing, et se situe à un niveau d’abstraction supérieur au VAD
    • J’utilise Soniox actuellement et je suis curieux de savoir comment c’était en interne. J’aimerais comprendre comment ils parviennent à offrir des performances SoTA à un prix inférieur à celui de leurs concurrents

  • Personnellement, je pense que l’architecture STT → LLM → TTS a des limites. L’avenir est aux modèles vocaux end-to-end
    J’avais bricolé une démo Chirpy il y a deux ans, mais pour atteindre un niveau réellement exploitable, il fallait un entraînement dédié. Impossible à porter comme simple side project

    • Dans cette optique, la recherche PersonaPlex de NVIDIA devrait t’intéresser : https://research.nvidia.com/labs/adlr/personaplex/
    • Je travaille presque exclusivement sur les agents vocaux depuis quelques années. Les modèles en cascade (cascading model) ne vont pas disparaître de sitôt.
      Les clients entreprises accordent beaucoup d’importance à l’auditabilité et à la fiabilité. Dans les secteurs réglementés comme la santé ou la finance, il faut pouvoir valider séparément les sorties du STT et du LLM
      À l’inverse, les modèles vocaux end-to-end sont plus adaptés à des usages narratifs comme les entretiens ou les enquêtes. En pratique, les clients veulent davantage une qualité d’ingénierie irréprochable que le tout dernier modèle à la mode
    • Au fond, le modèle devrait intégrer la capacité à prédire quand vient son tour. Le mode full-duplex de Moshi montre bien cette direction : https://arxiv.org/abs/2410.00037
    • L’avantage d’une architecture en cascade, c’est qu’on peut remplacer chaque modèle à chaque étape. Comme le rythme de progression du STT, du TTS et du LLM diffère, cela offre une grande flexibilité
    • Les tokenizers vocaux récents atteignent environ 12 Hz, soit bien plus de tokens qu’un LLM classique

  • Cette approche me rappelle les débuts du netcode des moteurs de jeu. La latence n’est pas un problème de modèle, mais un problème d’orchestration
    Le papier VR de Carmack en 2013 défendait déjà la même idée : il faut tracer l’ensemble du pipeline pour repérer les goulots d’étranglement à l’échelle de la milliseconde
    Latency Mitigation Strategies mérite le détour. L’exemple où l’on ouvre à l’avance un pool de WebSockets TTS pour économiser 300 ms illustre parfaitement cela

  • Je voudrais présenter l’application open source de reconnaissance vocale Handy. Elle fonctionne entièrement hors ligne et peut être étendue
    Je l’utilise tous les jours avec Claude, et cela marche bien mieux que la dictée par défaut de macOS

  • Bon article, mais expliquer la conversation uniquement par le turn-taking est trop simpliste
    Les vraies conversations incluent aussi des chevauchements de parole, signaux d’acquiescement, messages phatiques, voire des comportements coopératifs où l’on termine la phrase de l’autre
    Ces éléments sont mal représentés par un simple modèle de turn-taking, et le modèle doit être capable de les générer comme de les comprendre