Réduire la latence d'un assistant vocal IA : le guide 2026

Votre agent vocal répond en deux secondes et la conversation s'effondre. L'utilisateur attend, s'ennuie, se met à parler par-dessus l'assistant ou finit par taper. La recherche sur les tours de parole place le silence moyen entre humains autour de 200 ms, et tout écart au-delà de 500 ms se lit déjà comme peu naturel. Tout ce qui dépasse 1,5 s ressemble à un retard dont il faut s'excuser.

La bonne nouvelle : le budget d'un agent vocal bien réglé en 2026 passe confortablement sous la seconde de bout en bout, et chaque milliseconde au-dessus est corrigeable. La mauvaise : la plupart des pipelines vocaux auto-hébergés perdent entre 800 et 1500 ms en synthèse par lots, STT bloquant et une étape de ré-encodage dont personne ne parle.

Ce post parcourt où passent réellement les secondes, quelles optimisations font bouger l'aiguille et à quoi ressemble un stack sous 500 ms en 2026. Si vous montez l'agent vocal de zéro, commencez par le guide de configuration vocale et revenez ensuite pour la passe latence.

Où passent réellement les secondes

Un tour vocal enchaîne quatre étapes, chacune avec son propre budget. Ratez-en une et tout le tour glisse.

Étape	Cible bien réglée 2026	Résultat auto-hébergé courant
Détection d'activité vocale + capture	~50 ms	100-200 ms
STT (transcription)	100-200 ms streaming	500-1500 ms par lots
LLM temps jusqu'au premier token	150-400 ms	700-2000 ms
TTS premier chunk audio	40-150 ms streaming	500-1200 ms par lots
Transport (WebRTC / upload Telegram)	20-80 ms	200-600 ms

Les deux vrais sauts sont le streaming et le choix du fournisseur. Un pipeline qui termine le STT avant de démarrer le LLM, attend la réponse complète du LLM avant de démarrer le TTS et ré-encode l'audio avant l'upload atterrit facilement à 3-4 s par tour. Le même pipeline avec des bords en streaming entre étapes, un TTS à faible latence et le codec que le canal accepte déjà se rapproche de 500-800 ms.

Le streaming est le plus gros gain, de loin

La synthèse par lots est la raison la plus fréquente pour laquelle un agent vocal auto-hébergé donne l'impression d'être lent. Dans un pipeline par lots, le LLM termine toute sa réponse, remet le texte complet au TTS, attend le rendu audio et ne joue qu'ensuite. Si la réponse fait 30 tokens, l'utilisateur attend les 30 avant d'entendre une syllabe.

Le streaming inverse ça. Le LLM émet les tokens au fil de la génération, le TTS commence à synthétiser dès qu'il tient la première phrase et le premier chunk audio arrive dans le canal pendant que la queue de la réponse s'écrit encore. Les benchmarks indépendants de 2026 mesurent ce changement à 300-600 ms de latence perçue en moins, et jusqu'à 400-800 ms de moins sur la latence P95 par tour quand vous streamez aussi le STT vers le LLM.

Deux règles pratiques :

Streamer en entrée et en sortie du LLM. Ne bufferisez pas la transcription complète avant d'appeler le LLM, ni la réponse complète avant d'appeler le TTS. Tout SDK sérieux supporte le streaming de tokens.
Choisissez un TTS avec un premier chunk sous 150 ms. Le mode batch d'ElevenLabs Multilingual v2 a une voix superbe, mais un time-to-first-audio de 500-800 ms tue la conversation en temps réel.

Latence TTS par fournisseur, chiffres honnêtes

Les benchmarks fournisseurs mentent parce qu'ils comparent leur mode rapide au mode réaliste des autres. Coval, Gradium et Future AGI ont publié des chiffres indépendants en 2026, et le résumé utile est court :

Cartesia Sonic Turbo - environ 40 ms de time-to-first-audio, le TTS de production le plus rapide disponible. Cartesia Sonic-3 tourne autour de 90 ms avec une prosodie un peu plus riche.
ElevenLabs Flash v2.5 - autour de 75 ms sur la voie temps réel, avec la contrepartie d'une fidélité de clonage sous Multilingual v2 ou v3.
Deepgram Aura-2 - environ 313 ms P50 dans le benchmark Coval. Compétitif, pas au premier rang en latence pure.
OpenAI tts-1 - environ 200 ms de premier chunk, derrière les fournisseurs temps réel dédiés, mais correct si vous vivez déjà dans OpenAI.
Piper (auto-hébergé) - dominé par le CPU. Sur un petit VPS il perd souvent face aux fournisseurs hébergés temps réel, même sans saut réseau.

La latence brute n'est plus le différenciateur en haut du marché. Cartesia, ElevenLabs Flash, Rime et Deepgram publient tous sous 150 ms de premier chunk, donc l'axe utile est prosodie, clonage et coût. Pour une comparaison plus large du paysage TTS payant, lisez le guide des fournisseurs TTS.

Temps jusqu'au premier token du LLM

Le budget du LLM dans une boucle vocale temps réel est de 150-400 ms jusqu'au premier token. Trois techniques le font passer de "parfois ça tient" à "toujours ça tient" :

Prompt caching. Pour tout pipeline qui renvoie le même system prompt (presque tous), activer le prompt caching fait tomber le time-to-first-token de 200-400 ms sans autre changement qu'un flag.
Petits modèles rapides. GPT-4o-mini, Claude Haiku 4.5 et les modèles Llama hébergés chez Groq livrent régulièrement le premier token en 100-180 ms. Prenez le gros modèle quand ces 500 ms supplémentaires de raisonnement en valent le prix, pas par défaut.
Décodage spéculatif sur votre propre inférence. Si vous auto-hébergez le modèle, le décodage spéculatif peut réduire le TTFT de 30 à 50% à qualité de sortie égale. C'est plus de travail que changer de modèle, mais le plafond est plus haut.

Le piège du codec audio

Presque tous les posts sur la latence vocale ignorent l'étape de ré-encodage, ce qui explique pourquoi les bots Telegram auto-hébergés paraissent systématiquement plus lents que les chiffres ne le suggèrent. Telegram accepte nativement les notes vocales Opus. Si votre TTS renvoie du MP3 ou du WAV, quelque chose dans votre pipeline doit ré-encoder en Opus avant que l'upload passe. Cette seule étape coûte 200-500 ms sur un petit VPS, jetés à la poubelle.

La correction se fait côté fournisseur : demandez la sortie Opus directement au TTS. ElevenLabs le supporte, Cartesia aussi, la plupart des fournisseurs modernes également. Sur Whisper auto-hébergé, le même piège fonctionne à l'envers quand la note vocale entrante est Opus et que vous la décodez via une route de codec lente.

Si votre agent vocal perd carrément l'audio au lieu de simplement être lent, c'est un autre problème - la checklist de dépannage vocal couvre les modes de panne typiques.

Un stack sous 500 ms en 2026

Assemblé à partir des chiffres ci-dessus, la voie rapide ressemble à ça :

STT : Deepgram Nova-3 en streaming - 60-100 ms
LLM : GPT-4o-mini ou Claude Haiku 4.5 avec prompt caching - 100-180 ms premier token
TTS : Cartesia Sonic Turbo ou ElevenLabs Flash v2.5 en Opus natif - 40-80 ms premier chunk
Transport : WebRTC ou upload direct Telegram - 20-40 ms

Ajoutez 50 ms pour la VAD et la capture, gardez des bords en streaming entre toutes les étapes, et la latence perçue bout en bout tombe sous 400 ms. C'est dans la fenêtre naturelle des tours de parole humains.

Le stack que la plupart des gens font réellement tourner - Whisper hébergé en batch, GPT-4o, ElevenLabs Multilingual v2 en batch, ré-encodage Opus, upload - se retrouve plus près de 2,5-3 s. Deux des quatre étapes sont fausses et l'audio fait un aller-retour inutile.

Ce qu'un agent vocal géré vous enlève

Tout ce qui précède est réglable si vous aimez régler. C'est aussi la partie du stack vocal auto-hébergé qui bouge chaque trimestre à mesure que les fournisseurs sortent de nouveaux modèles. Si vous préférez ne pas courir après Cartesia Sonic 3 contre Sonic 4 dans un fichier de config, la recommandation honnête est un agent géré qui maintient le stack de latence à jour à votre place.

Hermify exécute un Hermes Agent géré sur Telegram avec STT en streaming, prompt caching activé par défaut, une chaîne TTS à faible latence et sortie Opus native déjà câblée. La latence perçue mesurée sur une note vocale Telegram est typiquement de 500 à 800 ms bout en bout. Vous connectez votre clé OpenRouter, choisissez une formule et commencez à parler, sans docker-compose, sans ffmpeg et sans déboguer de codecs.

Démarrez avec Hermify et mettez votre agent vocal en ligne en une minute environ.