Latence des API text-to-speech en 2026 : délai jusqu'au premier audio, mesures indépendantes

Deux benchmarks menés indépendamment de Speechify ont mesuré le délai jusqu’au premier audio du modèle SpeechifyAI Simba 3.2 en septembre 2026. Coval a relevé une médiane de 106 ms sur les 24 heures précédant le 24 septembre 2026. Voice Arena a mesuré 123 ms sur son classement US English le même jour, soit le meilleur score parmi les 14 modèles testés. Cet article explique ce que signifient ces chiffres, pourquoi c’est le délai jusqu’au premier audio qu’il faut comparer, et comment le mesurer dans votre code.

Les chiffres

Les deux mesures indépendantes sont supérieures à la nôtre, car elles incluent le réseau entre leurs serveurs et le nôtre, ainsi que tout silence au début de l’audio. Chacune reflète le résultat du benchmark à cette date. Les classements évoluent, consultez-les pour obtenir la dernière valeur.

Classement US English de Voice Arena, 24 sept. 2026

Source : Voice Arena, consulté le 24 sept. 2026. Le classement a chronométré 14 modèles ; voici les six plus rapides.

Pourquoi comparer le délai jusqu’au premier audio

Quand un agent vocal répond ou qu’une appli lit un texte à voix haute, l’utilisateur attend entre l’envoi du texte et le moment où il entend un son. Cet intervalle, c’est le délai jusqu’au premier audio.

• Le temps jusqu’au premier octet peut paraître meilleur que ce que l’auditeur perçoit.
• Un flux peut commencer par du silence, et l’auditeur n’entend rien avant le premier échantillon audible. Le délai jusqu’au premier audio en tient compte.
• Le temps total de génération correspond à l’attente jusqu’au dernier octet.
• C’est important quand on enregistre un fichier, mais moins quand on écoute pendant le streaming.
• La marge est très réduite en conversation.
• En général, on répond en quelques centaines de millisecondes. Un agent vocal doit intégrer reconnaissance vocale, LLM et synthèse avant de parler ; chaque ms gagnée ou perdue compte sur le budget total.

Comment Simba 3.2 est devenu plus rapide sans réduire la taille du modèle

Dans les données de Coval, la médiane quotidienne de Simba 3.2 est passée de 379 ms (13 sept. 2026) à 116 ms (18 sept. 2026), soit environ 70 % de moins en cinq jours.

Le modèle n’a pas changé : mêmes poids, sans distillation, quantification ni déclinaison "turbo" allégée. Le gain vient de l’optimisation de la chaîne de service autour du modèle :

• Nouvelle version du service sur une autre classe de GPU, avec un travail bas niveau dans la pile d’inférence pour sortir l’audio plus vite.
• Les contrôles d’abonnement, d’accès et de limites sont lus depuis un cache plutôt que via des requêtes en direct avant le premier octet.
• La passerelle API fonctionne dans la même région que les GPU, avec des connexions maintenues ouvertes d’une requête à l’autre.
• Environ 100 ms de silence initial ont été supprimés. La mesure Coval du silence de début pour Simba 3.2 est passée de 102 ms (14 sept.) à 13 ms.

La qualité reste au rendez-vous. Sur le leaderboard text-to-speech Artificial Analysis, Simba 3.2 affichait un Elo de 1 237 (±14) au 23 sept. 2026, dans le top 5 sur 92 voix de fournisseurs, et tous les modèles mieux classés coûtent plus cher.

Comment obtenir la latence minimale dans votre application

1. Utilisez le streaming.
2. Appelez
3. POST /v1/audio/stream
4. pour tout audio généré à la volée.
5. POST /v1/audio/speech
6. ne répond qu’une fois le clip entièrement généré.
7. Demandez Simba 3.2.
8. Définissez
9. model
10. sur
11. simba-3.2
12. pour l’anglais. Si
13. model
14. est omis, l’API utilise
15. simba-3.0
16. .
17. Réutilisez la même connexion.
18. Créez un seul client HTTP, ouvrez la connexion dès le lancement et conservez-la pour chaque requête ; ainsi, aucune ne subit le coût de la résolution DNS ni des handshakes TCP/TLS.
19. Envoyez chaque phrase dès qu’elle est prête.
20. Si un modèle de langage est en amont, transmettez chaque phrase complète dès qu’elle est disponible et lisez les flux dans l’ordre.
21. Choisissez le format adapté à votre lecteur.
22. Le
23. audio/pcm
24. à 24 kHz ne nécessite aucun encodage. Préférez le MP3 ou Ogg Opus si la bande passante est prioritaire.
25. Exécutez au plus près de l’API.
26. L’API est hébergée en US East ; un serveur proche de cette zone réduit le temps réseau.

Vous développez avec LiveKit Agents ? Ce guide montre comment créer un agent vocal avec le plugin Speechify, qui streame chaque phrase dès que le modèle de langage la génère. Chaque étape, code compris, est détaillée dans la documentation sur la latence.

Mesurez-le par vous-même

Chronométrez la réception du premier bloc d’une réponse en streaming depuis votre code. Pour obtenir une valeur représentative :

• Ignorez les une ou deux premières requêtes ; elles incluent l’ouverture de la connexion.
• Faites varier le texte à chaque requête, comme en trafic réel.
• Envoyez les requêtes en série, pas en parallèle.
• Faites au moins 20 requêtes et reportez la médiane (p50) et la p90, pas seulement la meilleure valeur ou la moyenne.
• Mesurez avec du PCM. En Ogg, les premiers octets sont des en-têtes et non de l’audio.

Chaque réponse en streaming inclut un en-tête Server-Timing dont la valeur ttfb représente notre part du délai ; le reste vient du réseau et de votre propre stack. La documentation sur la latence propose des scripts Python et TypeScript pour cela.

Foire aux questions

Essayez Simba 3.2 sur SpeechifyAI : créez une clé API gratuite et comparez vos temps aux chiffres ci-dessus.