Au-delà du trunk SIP : réduire la latence des agents vocaux à moins de 300 ms

Par l’équipe IdentityCall AI | Ingénierie | 8 min de lecture

Le nouveau standard de latence

En 2024, le « test de Turing » des agents vocaux n’est pas qu’une affaire d’intelligence : c’est une affaire de vitesse. Le standard précédent de 800 ms à 1 s de latence (typique des chaînes de LLM dans le cloud) n’est plus acceptable pour des interactions client à fort enjeu. Les utilisateurs perçoivent les délais >500 ms comme « robotiques » ou « défectueux », ce qui provoque des chevauchements de parole et de la frustration.

Le nouveau standard d’excellence est l’alternance de tours de parole en moins de 300 ms. Cet article explore les changements d’architecture nécessaires pour y parvenir.

Le goulot d’étranglement : les chaînes cloud traditionnelles

La pile d’IA vocale traditionnelle ressemble à ceci :

VAD (détection d’activité vocale) attend le silence (200-500 ms).
Téléversement de l’audio vers le cloud (100 ms).
ASR (transcription) traite l’énoncé complet (200-400 ms).
Inférence du LLM génère le flux de tokens (200-800 ms).
TTS (synthèse) génère l’audio à partir du texte (200-400 ms).
Téléchargement de l’audio et lecture (100 ms).

Latence totale : 1,5 s - 2,5 s. Voilà pourquoi votre bot vocal de première génération semblait lent.

La solution : architectures de streaming et edge

1. Exécution spéculative et ASR en streaming

N’attendez pas le silence. Les architectures modernes utilisent l’ASR en streaming, qui envoie des transcriptions partielles au LLM pendant que l’utilisateur parle encore.

Technique : le LLM commence à prédire la réponse à partir des 80 % premiers de la phrase.
Sécurité : une « porte d’engagement » garantit que le bot ne parle pas tant que l’intention n’est pas claire, mais les tokens sont pré-générés.

2. IA à l’edge et VAD local

Déplacer la détection d’activité vocale (VAD) vers l’edge (ou vers le nœud localisé du fournisseur de téléphonie) permet d’économiser un temps d’aller-retour critique.

Impact : réduit de 100-200 ms le jitter réseau.
Mise en œuvre : utiliser des modules VAD en WebAssembly (Wasm) qui s’exécutent directement dans le navigateur ou à l’edge de la téléphonie.

3. Optimisation du TTFT (temps jusqu’au premier token)

Pour le LLM lui-même, nous optimisons le temps jusqu’au premier token.

Quantification : utiliser des modèles quantifiés en 4 bits (par exemple, Llama-3-8B-Int4) augmente drastiquement la vitesse d’inférence avec une perte de précision négligeable pour les tâches conversationnelles.
Cache : la mise en cache sémantique stocke les réponses aux salutations courantes (« Bonjour », « Qui est à l’appareil ? ») pour les servir instantanément (0 ms d’inférence).

Diagramme d’architecture (Mermaid)

sequenceDiagram
    participant User
    participant Edge_VAD
    participant Cloud_LLM
    participant TTS_Engine
    
    User->>Edge_VAD: Speaks "I need to reset..."
    Edge_VAD->>Cloud_LLM: Stream: "I need to reset..."
    Cloud_LLM->>Cloud_LLM: Pre-fetch "Reset Password flow"
    User->>Edge_VAD: "...my password"
    Edge_VAD->>Cloud_LLM: Stream: "...my password" [EOS]
    Cloud_LLM->>TTS_Engine: Stream Tokens (Immediate)
    TTS_Engine->>User: Audio Stream (Sub-300ms)

Conclusion

Une latence inférieure à 300 ms transforme un « bot vocal » en un « agent vocal ». En abandonnant les cycles rigides de requête-réponse au profit d’architectures fluides de streaming, nous créons des expériences qui semblent remarquablement humaines.

Prêt à construire des agents plus rapides ? Explorez notre documentation de l’API pour les endpoints de streaming.