Réduire la latence du premier jeton en voix IA de production

Le budget : 800 ms, c'est le chiffre, et chaque composant en a sa part.

Huit cents millisecondes, c'est le seuil au-delà duquel une pause dans une conversation téléphonique cesse de ressembler à du traitement et commence à ressembler à un appel échappé. La norme des opérateurs pour la tolérance d'attente sur le RTPC se situe entre 600 ms et 1 200 ms selon la source, mais en pratique, tout ce qui dépasse 800 ms commence à coûter des points de satisfaction (CSAT). C'est le chiffre pour lequel nous construisons.

Le budget n'est pas un composant unique. C'est une somme : transcription STT, acheminement d'intention, inférence du modèle et synthèse TTS. Chacun a sa part. Si une des parties déborde, le chiffre total dépasse le seuil. La discipline sur chaque composant est le seul moyen de respecter le total.

Reconnaissance vocale (STT) : l'étape avec le plus de variance et les leviers les moins évidents.

Le STT est l'étape où se dépense la plus grande part du budget de latence et où réside la plus grande variance. La transcription en continu (streaming) aide (on n'attend pas la fin de l'énoncé avant d'acheminer), mais le délai du premier jeton dépend encore de la taille du modèle, de la précision de la détection des points de terminaison et du chemin réseau vers le nœud d'inférence.

Ce qu'on a changé

• Passage à l'inférence locale au point de terminaison pour les charges de travail téléphoniques. En éliminant l'aller-retour vers une API hébergée, on a réduit notre latence STT médiane de 180 ms à 62 ms.
• Ajustement de l'agressivité du VAD pour les profils de bruit des centres de contact. Les réglages par défaut du VAD supposent une entrée micro propre. Les centres de contact ont des clics de clavier, des fuites de musique d'attente et du bruit de fond en aire ouverte. On a réentraîné le détecteur de point de terminaison sur 400 heures d'enregistrements réels des opérateurs.
• Diffusion parallèle vers le routeur (le classificateur d'intention reçoit les transcriptions partielles et commence à évaluer les intentions avant que l'énoncé ne soit terminé). Ça ne rapporte pas toujours, mais quand l'énoncé est une courte recherche (numéro de réclamation, numéro de police), ça économise de 60 à 80 ms.

La ligne la plus coûteuse du budget STT, c'est celle qu'on ne voit pas : l'aller-retour vers une API hébergée qu'on ne savait pas payer, parce que le fournisseur calcule la latence depuis son serveur, pas depuis votre RVI.Audit interne de latence · T1 2026

Acheminement d'intention : petit modèle, décision rapide, presque toujours juste.

Le travail du routeur est étroit : à partir d'une transcription partielle ou complète, décider à quel flux de travail transférer l'appel, en moins de 20 ms. On utilise pour ça un classificateur affiné d'environ 110 millions de paramètres, pas un modèle de pointe. Les modèles de pointe sont précis, mais ils prennent 300 à 500 ms à eux seuls, même en continu. Un modèle plus petit et spécialisé, précis à 98,4 % sur la distribution réelle de vos appels, l'emporte sur un modèle généraliste précis à 99,1 % dans tous les contextes.

Inférence du modèle : là où se dépense le budget économisé partout ailleurs.

L'étape du LLM est celle où on dépense le budget acheté en étant disciplinés dans les trois étapes précédentes. Après l'acheminement, le modèle a une tâche contrainte : générer une réponse dans le contexte de la conversation, appeler le système pertinent au besoin (recherche de réclamation, lecture d'horaire), et retourner un flux de jetons en réponse. On vise un premier jeton en moins de 280 ms au p50.

Deux décisions comptent le plus ici : la fenêtre de contexte transmise (plus petite, c'est plus rapide) et si les appels d'outils s'exécutent en parallèle. Si un flux de travail exige à la fois une recherche dans le CRM et une lecture dans le système de réclamations, des appels séquentiels feront exploser le budget. Chaque flux de travail qu'on met en production a une carte de concurrence qui précise quels appels d'outils peuvent se déclencher simultanément.

TTS : la dernière étape, et celle que les appelants remarquent le plus.

Le TTS est l'étape où le flux de jetons du modèle devient le signal audio que l'appelant entend. On diffuse le TTS en continu; le premier segment audio est envoyé à l'appelant dès qu'une première limite de phrase est disponible dans le flux de jetons. Cela signifie que l'appelant commence à entendre la réponse avant même que le modèle n'ait fini de générer la réponse complète.

La voix est une décision de produit. On teste de trois à cinq voix par déploiement, avec de vrais enregistrements d'appels et de vrais commentaires d'appelants. La variance de CSAT entre les voix sur un même flux de travail peut atteindre de 0,4 à 0,6 point. Ce n'est pas négligeable. Choisissez la voix comme vous choisiriez la musique d'attente : de façon délibérée, avec des données.

Les trois changements qui ont fait passer la latence de 1,1 s à 612 ms.

Après un trimestre de télémétrie en production, trois changements expliquent la majorité de l'amélioration. Ce ne sont pas les trois changements les plus intéressants techniquement. Ce sont les trois plus ennuyeux sur le plan opérationnel, ceux que personne ne fait parce qu'ils exigent de la discipline entre les équipes, pas un nouveau modèle.

• Inférence STT locale. Élimine l'aller-retour réseau. Réduction médiane de 118 ms.
• Appels d'outils en parallèle. Là où deux lectures système étaient séquentielles, on les a rendues concurrentes. Réduction médiane de 80 ms sur les flux de travail touchés par les deux.
• Discipline sur la fenêtre de contexte. On a audité chaque modèle de invite (prompt) et réduit la taille médiane du contexte de 38 %. Un contexte plus petit veut dire un premier jeton plus rapide. Réduction médiane de 60 ms.