- 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
Aucun commentaire pour le moment.