Optimisation de la latence des agents vocaux : guide étape par étape

La réactivité d’un agent vocal dépend du délai total entre la fin de parole de l’utilisateur et le début de la réponse de l’agent. Ce délai est rarement causé par un seul composant lent. Il s’accumule sur plusieurs étapes indépendantes, chacune ajoutant quelques dizaines ou centaines de millisecondes. Le réduire exige de savoir combien de temps prend chaque étape.

Optimiser la latence d’un agent vocal consiste à identifier où ce temps se cache et à le récupérer étape par étape.

Cet article complète la présentation conceptuelle de la latence. Là où cette page explique ce qu’est la latence, celle-ci aborde l’architecture et la mesure. Vous disposerez ainsi d’un budget de latence à mesurer et d’actions concrètes à mettre en œuvre.

En résumé

• Le délai jusqu’au premier audio représente l’ensemble du pipeline, et non le temps d’inférence d’un seul modèle.
• Le délai jusqu’au premier token du LLM et la détection de fin de parole constituent les deux principaux postes.
• Faire se chevaucher les étapes, plutôt que de les exécuter en série, permet de récupérer l’essentiel du budget.
• Le streaming, le choix du codec et le réglage de la mémoire tampon du lecteur permettent chacun de gagner des millisecondes mesurables.
• Mesurez les résultats par région sur votre propre déploiement, en indiquant les valeurs P50 et P95.

Définir le budget de latence d’un agent vocal

Un budget de latence est un objectif global de délai jusqu’au premier audio, réparti entre les étapes du pipeline. Chaque étape reçoit une marge, et leur somme doit rester sous votre objectif. Le définir est la première étape, mais c’est aussi là que le travail sur la latence échoue le plus souvent, car les ingénieurs peuvent confondre deux chiffres similaires qui n’ont pourtant pas la même signification.

Le premier est la latence d’inférence du modèle, c’est-à-dire le temps qu’un modèle consacre à générer une sortie. Pour nos modèles Flash, elle est d’environ 75 ms pour des entrées courtes typiques, hors surcoûts réseau et applicatifs. Il s’agit d’un chiffre interne, utile pour comparer les modèles entre eux. Ce n’est pas le chiffre que perçoit votre utilisateur.

Du point de vue de l’utilisateur, vous vous concentrerez sur le délai jusqu’au premier audio (TTFA) : le temps écoulé entre le moment où l’utilisateur cesse de parler et celui où il entend le premier échantillon de la réponse de l’agent. Le TTFA est toujours supérieur à la latence d’inférence de n’importe quel modèle pris isolément, car il additionne l’ensemble du pipeline.

Un agent vocal en cascade est une chaîne de cinq étapes :

• capture (micro) -> STT -> LLM -> TTS -> lecture

L’audio est capturé par le microphone, transcrit en texte, envoyé à un modèle de langage, puis le texte du modèle est synthétisé en parole, mise en mémoire tampon et lue. Chaque étape ajoute de la latence et, pour plusieurs d’entre elles, le principal coût n’est pas celui auquel vous vous attendez.

Voici un exemple détaillé pour un agent en anglais, avec des serveurs raisonnablement proches de l’utilisateur. Ces chiffres sont des fourchettes indicatives, pas des garanties.

En général, les deux principaux postes de latence sont le délai jusqu’au premier token du LLM et le délai de détection de fin de parole au début de la chaîne. 

Le tableau permet de visualiser utilement le pipeline, mais il donne l’impression que les étapes s’exécutent strictement en série, ce qui n’est pas le cas. Plusieurs des optimisations les plus importantes de la latence des agents vocaux viennent de leur chevauchement, qui permet de récupérer l’essentiel du budget ci-dessous.

Speech to Text : optimisation de la latence de transcription et de détection de fin de parole

La transcription est la deuxième étape du pipeline. Son véritable coût ne vient pas de la transcription elle-même, mais de la décision que l’utilisateur a cessé de parler. Cette section couvre ces deux aspects afin de vous aider à optimiser la latence de votre agent vocal.

La transcription intervient avant l’arrivée au LLM. Scribe v2 Realtime (scribe_v2_realtime) renvoie des transcriptions partielles en environ 150 ms et diffuse l’audio par segments. La transcription est ainsi constituée pendant que l’utilisateur parle encore. Il prend en charge le PCM de 8 kHz à 48 kHz ainsi que l’encodage mu-law, un point important pour la section sur les codecs ci-dessous. Les résultats partiels à 150 ms sont peu coûteux.

Le coût de latence le plus élevé est la détection de fin de parole : le moment où votre système décide que l’utilisateur a réellement terminé son tour de parole.

Détection d’activité vocale (VAD) segmente la parole en fonction des silences, et c’est là que le temps s’accumule. Si vous attendez, par exemple, 700 ms de silence avant de déclarer le tour terminé, vous ajoutez 700 ms à chaque tour, en plus de la transcription elle-même. Ce délai est invisible dans un benchmark de précision de transcription, mais très perceptible dans une conversation réelle. C’est souvent la plus grande source de latence contrôlable de tout le pipeline et, précisément parce qu’elle est contrôlable, c’est un bon point de départ.

La détection de fin de parole implique un compromis entre réactivité et interruption. Un seuil de silence court permet à l’agent de répondre vite, mais risque de couper l’utilisateur au milieu de sa phrase lors d’une pause naturelle. Un seuil long est sûr, mais peu réactif. En pratique, les trois modifications qui optimisent la latence du Speech to Text sont :

1. Ajustez finement le seuil de silence : réduisez le seuil de silence à la plus petite valeur qui ne tronque pas les pauses naturelles de vos utilisateurs, puis mesurez le taux d’interruption en production au lieu de l’estimer.
2. Intégrez un événement de contrôle physique : utilisez une validation manuelle lorsque votre application sait que le tour est terminé grâce à un autre signal, comme le relâchement d’un bouton push-to-talk ou un événement d’interface, plutôt que d’attendre le minuteur VAD.
3. Faites chevaucher les processus du LLM : envoyez tôt les résultats partiels aux étapes suivantes. Transmettez les résultats partiels stables au LLM et corrigez-les si la transcription finale diffère. Cette forme d’exécution spéculative masque le délai de détection de fin de parole derrière le traitement du prompt par le LLM.

Pour en savoir plus, Scribe v2 Realtime est décrit plus en détail sur la page des fonctionnalités Speech to Text et la page produit Realtime Speech to Text.

La contribution du LLM à la latence

Le modèle de langage est généralement le principal contributeur individuel au TTFA. C’est donc aussi là que le chevauchement est le plus rentable pour optimiser la latence d’un agent vocal. L’idée clé est que l’agent n’a pas besoin de disposer de la réponse entière avant de commencer à parler.

Le modèle qui récupère le plus de budget de latence consiste à diffuser les tokens du LLM et à les transmettre au TTS au fil de leur arrivée, découpés aux limites des phrases ou propositions. Il s’agit de mettre les tokens en mémoire tampon jusqu’à une limite de phrase, puis de synthétiser cette phrase pendant que la suivante est encore en cours de génération :

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

Pour les conversations longues, privilégiez le WebSocket TTS afin qu’une connexion ouverte puisse recevoir du texte progressivement sans payer à nouveau l’établissement de connexion à chaque phrase. Seul le temps pendant lequel le modèle génère activement de l’audio compte dans votre limite de requêtes simultanées. Un WebSocket ouvert mais inactif est donc presque gratuit.

Text to Speech : streaming et choix de la voix

Text to Speech est l’étape où vous pouvez maîtriser la latence avec le plus de précision. Elle comporte deux leviers principaux : la façon dont vous diffusez l’audio et la voix choisie.

Flash v2.5 (eleven_flash_v2_5) est le modèle à utiliser dans un agent. Il offre environ 75 ms d’inférence pour des entrées courtes, prend en charge 32 langues et accepte jusqu’à 40 000 caractères par requête.

Le chiffre de 75 ms concerne uniquement l’inférence. La ligne TTFA du TTS dans le budget ci-dessus est plus élevée, car elle ajoute l’aller-retour réseau et la planification côté serveur à l’inférence.

Le principal levier est ici le streaming. Si vous demandez l’audio complet et attendez sa réception, l’utilisateur attend que l’intégralité du clip soit synthétisée avant d’entendre quoi que ce soit. Avec le streaming, il entend le premier segment dès qu’il est généré, tandis que le reste arrive pendant qu’il écoute déjà. Le streaming n’accélère pas le modèle : il commence simplement à transmettre la sortie à l’utilisateur pendant que la génération se poursuit.

Le guide pratique du streaming couvre le streaming HTTP, tandis que le guide WebSocket en temps réel couvre la voie WebSocket à privilégier lorsque vous transmettez des tokens depuis un LLM.

Initialisez le client une fois et réutilisez-le pour chaque appel ci-dessous :

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

Configurez ensuite un flux et transmettez-le au fur et à mesure de son arrivée :

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

L’autre levier est le choix de la voix, qui a lui aussi un coût en latence. Les voix par défaut, les voix synthétiques et les clonages de voix instantanés (IVC) synthétisent plus vite que les clonages de voix professionnels (PVC), car les PVC impliquent une complexité de modèle supplémentaire qui ajoute un surcoût à chaque génération. Pour un agent soumis à des exigences strictes de latence, l’association de Flash avec un IVC ou une voix par défaut est l’option la plus rapide.

Choix de la taille des segments de streaming

Avec les tokens qui entrent dans le TTS et l’audio qui revient, la décision suivante concerne la taille des segments et la quantité d’audio que le lecteur met en mémoire tampon avant de démarrer.

Les segments plus petits atteignent le lecteur plus tôt, réduisant la latence jusqu’au premier octet, au prix d’un plus grand nombre de messages et d’un léger surcoût par segment. Les segments plus grands sont plus efficaces à transporter, mais font attendre l’utilisateur plus longtemps avant le premier. Pour les agents interactifs, privilégiez les petits segments au début de l’énoncé, car c’est le premier que l’utilisateur attend. Les segments suivants arrivent alors que l’audio est déjà en cours de lecture, et leur taille compte moins.

Le lecteur représente une part importante de la latence restante. La plupart des lecteurs audio ne commencent pas la lecture dès le premier octet. Ils mettent une petite quantité d’audio en mémoire tampon pour éviter les saccades si le flux ralentit brièvement. Une mémoire tampon par défaut de 500 ms est courante et s’ajoute directement à la latence perçue. La réduire augmente légèrement le risque de saccades, mais diminue le TTFA. La bonne valeur dépend de la gigue réseau entre votre serveur et le client :

• Sur une connexion stable, avec une lecture côté serveur ou un client colocalisé, une mémoire tampon de 50 à 150 ms est généralement sûre et réduit sensiblement le TTFA.
• Sur une connexion mobile instable ou interrégionale, une mémoire tampon plus importante évite des coupures audibles, plus gênantes que la latence qu’elles coûtent.

La configuration exacte dépend de votre cas d’usage actif et de vos priorités.

Choix des codecs

La destination de l’audio doit dicter le codec demandé. Nous renvoyons notamment les formats mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 et ulaw_8000. Utiliser le format natif du transport élimine une étape de transcodage et contribue à optimiser la latence des agents vocaux.

Pour la téléphonie, notamment Twilio et les fournisseurs similaires, utilisez ulaw_8000. Le réseau téléphonique utilise du mu-law 8 kHz de bout en bout. Le demander directement évite donc une étape de transcodage dans votre pipeline et correspond à ce qu’attend l’opérateur. Synthétiser un audio de meilleure fidélité que le réseau téléphonique sous-échantillonnera immédiatement n’apporte aucun avantage : vous ajouteriez seulement de la latence sans rien perdre d’audible.

Pour WebRTC et la lecture dans le navigateur, utilisez le PCM (pcm_24000 ou pcm_16000) ou un format MP3. Le PCM n’est pas compressé : aucune étape de décodage n’est donc requise côté client, ce qui supprime une légère latence par segment et est pratique si vous alimentez directement un pipeline Web Audio. Le MP3 est plus compact en transit, ce qui aide sur les connexions limitées, au prix d’un léger décodage côté client.

Géographie et distances réseau

Toutes les optimisations ci-dessus supposent que les octets ont peu de distance à parcourir. La géographie fixe le plancher de votre budget de latence. Il vaut donc la peine de l’examiner avant d’ajuster quoi que ce soit d’autre.

Nous traitons les requêtes depuis des clusters en Amérique du Nord, en Europe et en Asie du Sud-Est, et routons automatiquement chaque requête vers le cluster le plus proche. L’aller-retour réseau sur Internet est généralement de 20 à 200 ms selon la proximité géographique, et il est impossible de le réduire sans modifier l’emplacement de votre infrastructure.

Un agent qui semble instantané à San Francisco, à quelques sauts d’un cluster nord-américain, peut sembler lent à un utilisateur d’Asie du Sud dont le trafic traverse un océan deux fois à chaque tour.

La solution consiste à colocaliser vos serveurs d’application avec vos utilisateurs, et pas seulement avec nous. Si vos utilisateurs sont en Europe, exécutez le backend de votre agent en Europe afin de raccourcir le trajet entre l’utilisateur et votre serveur. Notre routage gère ensuite le trajet entre votre serveur et le modèle depuis un cluster proche.

Mesurer vous-même la latence d’un agent vocal

Les chiffres du tableau de budget de latence ci-dessus sont des fourchettes indicatives pour vous aider à planifier. Les chiffres sur lesquels vous déployez doivent provenir d’un script comme celui-ci, exécuté sur votre propre déploiement.

L’instrumentation ci-dessous mesure le TTFA de l’étape TTS de façon isolée, soit le délai entre la requête et le premier segment audio, sur de nombreux essais, puis indique les percentiles. Exécutez-la depuis la même région que vos serveurs, et non depuis votre machine de développement. Elle suppose que le client elevenlabs présenté précédemment est utilisé :

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

Quelques points à retenir :

• Indiquez les valeurs P50 et P95 : privilégiez-les à la moyenne. La moyenne masque la traîne, alors que c’est elle qui donne l’impression qu’un agent n’est pas fiable. P95 correspond à l’expérience d’un tour sur vingt. 
• Expérimentation par zone géographique : exécutez le même script depuis chaque région que vous servez et conservez les résultats séparément.
• Espacez les requêtes pour plus de précision : espacez vos requêtes, comme avec le setTimeout ci-dessus. Si vous les lancez toutes en même temps, vous mesurez votre propre file d’attente plutôt que le service. Lorsque la limite de requêtes simultanées est dépassée, les requêtes sont mises en file d’attente par priorité, ce qui ajoute généralement environ 50 ms. Au-delà de la capacité, vous recevez une réponse HTTP 429.
• Mesurez toute la chaîne de latence : étendez le même modèle de chronométrage aux autres étapes. Encadrez votre finalisation STT, le premier token de votre LLM et le démarrage de votre lecteur avec les mêmes appels à performance.now(). Vous pourrez ainsi renseigner le tableau de budget complet avec vos propres chiffres et déterminer l’étape à traiter en premier.

En suivant ces conseils, vous pourrez mesurer vous-même la latence de votre agent vocal. Vous disposerez alors d’un ordre de priorités clair pour agir en premier.

Qu’est-ce qui réduit le plus la latence d’un agent vocal ?

Pour des actions rapides sur lesquelles vous concentrer, voici les changements les plus efficaces.

Voici, approximativement par ordre d’impact, les méthodes qui permettent de réduire la latence des agents :

• Commencez le traitement du LLM à partir de résultats partiels STT stables pour masquer le délai de détection de fin de parole.
• Diffusez les tokens du LLM vers le TTS aux limites des phrases afin que la synthèse de la première phrase chevauche la génération de la deuxième.
• Diffusez l’audio TTS vers le lecteur et réduisez sa mémoire tampon à la plus petite valeur que votre gigue réseau tolère.
• Utilisez Flash avec une voix par défaut ou un IVC pour un TTS à faible latence, et adaptez le codec au transport : ulaw_8000 pour la téléphonie, PCM ou MP3 pour le navigateur ou WebRTC.
• Colocalisez vos serveurs avec vos utilisateurs et mesurez les résultats par région, car les trajets réseau sont réels et inégaux.

Pour des techniques plus spécifiques et approfondies, consultez le guide pratique destiné aux développeurs sur l’optimisation de la latence. Pour un point de départ complet et exécutable, le guide de démarrage rapide de l’API et le guide pratique du streaming proposent des exemples complets. 

Vous souhaitez accéder plus rapidement à des cascades d’agents optimisées ? ElevenAgents met en œuvre ce pipeline avec des optimisations de chevauchement déjà en place.

Créez des agents vocaux à faible latence avec ElevenAgents

L’optimisation de la latence d’un agent vocal exige de mesurer chaque étape, puis de les faire se chevaucher afin que les plus lentes s’exécutent en arrière-plan d’un travail déjà en cours. Vous pouvez construire et régler cette cascade manuellement au fil de plusieurs itérations, en appliquant les modèles ci-dessus, ou partir d’un pipeline qui inclut déjà des optimisations de latence.

ElevenAgents met en œuvre toute cette cascade, du STT en streaming au transfert token par token vers le LLM, puis au TTS Flash, avec des techniques de chevauchement déjà intégrées. Plutôt que de partir de zéro, vous réglerez les seuils selon les performances qui comptent le plus pour vous.

Utilisez ElevenAgents pour créer un agent dès aujourd’hui ou Réserver une démo pour en savoir plus.

FAQ sur l’optimisation de la latence des agents vocaux