Modèles

Modèles phares

Text to Speech

Speech to Text

Musique

Présentation des modèles

L’API ElevenLabs propose une gamme de modèles audio optimisés pour différents cas d’utilisation, niveaux de qualité et exigences de performances.

Modèles obsolètes

Eleven v4

Eleven v4 est notre modèle de synthèse vocale de pointe. Il offre notre meilleure qualité audio, une grande expressivité et un contrôle précis de l’interprétation des voix. Eleven v4 prend en charge le clonage de voix haute fidélité avec une préservation fiable du locuteur sur de longues générations de texte.

Ce modèle convient particulièrement aux scénarios suivants :

• Voix off de personnages : Idéal pour les jeux vidéo et l’animation grâce à sa palette émotionnelle.
• Dialogues émotionnels : Générez des dialogues naturels et réalistes, avec une grande palette émotionnelle et une compréhension du contexte.
• Production de livres audio : Parfait pour les narrations longues nécessitant une interprétation émotionnelle complexe.
• Projets multilingues : Maintient une qualité vocale constante lors des changements de langue.

Eleven v4 est disponible via l’API Text to Dialogue.

Langues prises en charge

La famille de modèles Eleven v4 prend en charge plus de 90 langues, dont :

Afrikaans (afr), amharique (amh), arabe (ara), arménien (hye), assamais (asm), asturien (ast), azéri (aze), biélorusse (bel), bengali (ben), bosnien (bos), bulgare (bul), birman (mya), cantonais (yue), catalan (cat), cebuano (ceb), croate (hrv), tchèque (ces), danois (dan), néerlandais (nld), anglais (eng), estonien (est), filipino (fil), finnois (fin), français (fra), peul/pulaar (ful), galicien (glg), géorgien (kat), allemand (deu), grec (ell), gujarati (guj), haoussa (hau), hébreu (heb), hindi (hin), hongrois (hun), islandais (isl), indonésien (ind), italien (ita), japonais (jpn), javanais (jav), kamba (kam), kannada (kan), kazakh (kaz), coréen (kor), kirghize (kir), lao (lao), letton (lav), lingala (lin), lituanien (lit), luganda (lug), luxembourgeois (ltz), macédonien (mkd), malais (msa), malayalam (mal), maltais (mlt), chinois mandarin (cmn), maori (mri), marathi (mar), mongol (mon), népalais (nep), norvégien bokmål (nob), occitan (oci), odia (ori), pachto (pus), persan (fas), polonais (pol), portugais du Brésil (por), pendjabi (pan), roumain (ron), russe (rus), serbe (srp), shona (sna), sindhi (snd), slovaque (slk), slovène (slv), somali (som), kurde sorani (ckb), espagnol d’Amérique latine (spa), swahili (swa), suédois (swe), tadjik (tgk), tamoul (tam), télougou (tel), thaï (tha), turc (tur), ukrainien (ukr), ourdou (urd), ouzbek (uzb), vietnamien (vie), gallois (cym), wolof (wol), zoulou (zul).

Eleven v4 Turbo

Eleven v4 Turbo est notre modèle de pointe pour la synthèse vocale en temps réel. Il offre une qualité audio élevée, une grande expressivité et un contrôle précis de l’interprétation des voix. Eleven v4 Turbo prend en charge le clonage de voix haute fidélité et fournit des résultats avec une latence d’inférence médiane d’environ 100 ms.

Ce modèle convient particulièrement aux scénarios suivants :

• Agents de support : Alimentez des agents vocaux qui résolvent les demandes des clients en temps réel.
• Assistants IA : Générez des dialogues naturels et réalistes, avec une grande palette émotionnelle et une compréhension du contexte.
• Personnages interactifs : Excellent pour les expériences audio avec des personnages expressifs.

Eleven v4 Turbo est disponible via le WebSocket Text to Dialogue.

Langues prises en charge

La famille de modèles Eleven v4 prend en charge plus de 90 langues, dont :

Afrikaans (afr), amharique (amh), arabe (ara), arménien (hye), assamais (asm), asturien (ast), azéri (aze), biélorusse (bel), bengali (ben), bosnien (bos), bulgare (bul), birman (mya), cantonais (yue), catalan (cat), cebuano (ceb), croate (hrv), tchèque (ces), danois (dan), néerlandais (nld), anglais (eng), estonien (est), filipino (fil), finnois (fin), français (fra), peul/pulaar (ful), galicien (glg), géorgien (kat), allemand (deu), grec (ell), gujarati (guj), haoussa (hau), hébreu (heb), hindi (hin), hongrois (hun), islandais (isl), indonésien (ind), italien (ita), japonais (jpn), javanais (jav), kamba (kam), kannada (kan), kazakh (kaz), coréen (kor), kirghize (kir), lao (lao), letton (lav), lingala (lin), lituanien (lit), luganda (lug), luxembourgeois (ltz), macédonien (mkd), malais (msa), malayalam (mal), maltais (mlt), chinois mandarin (cmn), maori (mri), marathi (mar), mongol (mon), népalais (nep), norvégien bokmål (nob), occitan (oci), odia (ori), pachto (pus), persan (fas), polonais (pol), portugais du Brésil (por), pendjabi (pan), roumain (ron), russe (rus), serbe (srp), shona (sna), sindhi (snd), slovaque (slk), slovène (slv), somali (som), kurde sorani (ckb), espagnol d’Amérique latine (spa), swahili (swa), suédois (swe), tadjik (tgk), tamoul (tam), télougou (tel), thaï (tha), turc (tur), ukrainien (ukr), ourdou (urd), ouzbek (uzb), vietnamien (vie), gallois (cym), wolof (wol), zoulou (zul).

Eleven v3

Eleven v3 est notre modèle de synthèse vocale de génération précédente. Il produit une voix naturelle et réaliste, avec une grande palette émotionnelle et une compréhension du contexte dans plusieurs langues.

Eleven v3 s’accompagne d’une nouvelle API Text to Dialogue, qui vous permet de générer des dialogues naturels et réalistes, avec une grande palette émotionnelle et une compréhension du contexte dans plusieurs langues. Vous pouvez également utiliser Eleven v3 avec l’API Text to Speech pour générer une voix naturelle et réaliste, avec une grande palette émotionnelle et une compréhension du contexte dans plusieurs langues.

En savoir plus sur l’API Text to Dialogue ici.

Langues prises en charge

Le modèle Eleven v3 prend en charge plus de 70 langues, dont :

Afrikaans (afr), arabe (ara), arménien (hye), assamais (asm), azéri (aze), biélorusse (bel), bengali (ben), bosnien (bos), bulgare (bul), catalan (cat), cebuano (ceb), chichewa (nya), croate (hrv), tchèque (ces), danois (dan), néerlandais (nld), anglais (eng), estonien (est), filipino (fil), finnois (fin), français (fra), galicien (glg), géorgien (kat), allemand (deu), grec (ell), gujarati (guj), haoussa (hau), hébreu (heb), hindi (hin), hongrois (hun), islandais (isl), indonésien (ind), irlandais (gle), italien (ita), japonais (jpn), javanais (jav), kannada (kan), kazakh (kaz), kirghize (kir), coréen (kor), letton (lav), lingala (lin), lituanien (lit), luxembourgeois (ltz), macédonien (mkd), malais (msa), malayalam (mal), chinois mandarin (cmn), marathi (mar), népalais (nep), norvégien (nor), pachto (pus), persan (fas), polonais (pol), portugais (por), pendjabi (pan), roumain (ron), russe (rus), serbe (srp), sindhi (snd), slovaque (slk), slovène (slv), somali (som), espagnol (spa), swahili (swa), suédois (swe), tamoul (tam), télougou (tel), thaï (tha), turc (tur), ukrainien (ukr), ourdou (urd), vietnamien (vie), gallois (cym).

Eleven v3 Conversational

Eleven v3 Conversational est notre modèle de génération précédente pour la synthèse vocale en temps réel. Il produit une voix naturelle et réaliste, avec une grande palette émotionnelle et une compréhension du contexte dans plusieurs langues.

Eleven v3 Conversational s’accompagne d’un nouveau WebSocket Text to Dialogue, qui vous permet de générer des dialogues naturels et réalistes, avec une grande palette émotionnelle et une compréhension du contexte dans plusieurs langues.

Eleven v3 Conversational s’accompagne d’un nouveau WebSocket Text to Dialogue, qui vous permet de générer des dialogues naturels et réalistes, avec une grande palette émotionnelle et une compréhension du contexte dans plusieurs langues.

En savoir plus sur le WebSocket Text to Dialogue ici.

Langues prises en charge

Le modèle Eleven v3 prend en charge plus de 70 langues, dont :

Afrikaans (afr), arabe (ara), arménien (hye), assamais (asm), azéri (aze), biélorusse (bel), bengali (ben), bosnien (bos), bulgare (bul), catalan (cat), cebuano (ceb), chichewa (nya), croate (hrv), tchèque (ces), danois (dan), néerlandais (nld), anglais (eng), estonien (est), filipino (fil), finnois (fin), français (fra), galicien (glg), géorgien (kat), allemand (deu), grec (ell), gujarati (guj), haoussa (hau), hébreu (heb), hindi (hin), hongrois (hun), islandais (isl), indonésien (ind), irlandais (gle), italien (ita), japonais (jpn), javanais (jav), kannada (kan), kazakh (kaz), kirghize (kir), coréen (kor), letton (lav), lingala (lin), lituanien (lit), luxembourgeois (ltz), macédonien (mkd), malais (msa), malayalam (mal), chinois mandarin (cmn), marathi (mar), népalais (nep), norvégien (nor), pachto (pus), persan (fas), polonais (pol), portugais (por), pendjabi (pan), roumain (ron), russe (rus), serbe (srp), sindhi (snd), slovaque (slk), slovène (slv), somali (som), espagnol (spa), swahili (swa), suédois (swe), tamoul (tam), télougou (tel), thaï (tha), turc (tur), ukrainien (ukr), ourdou (urd), vietnamien (vie), gallois (cym).

Multilingual v2

Eleven Multilingual v2 est un modèle de synthèse vocale de génération précédente, sensible aux émotions. Il produit une parole naturelle et réaliste, avec une large palette émotionnelle et une compréhension contextuelle dans plusieurs langues.

Le modèle offre une qualité vocale et une personnalité cohérentes dans toutes les langues prises en charge, tout en préservant les caractéristiques uniques et l’accent du locuteur.

Ce modèle excelle dans les scénarios nécessitant une parole de haute qualité avec des nuances émotionnelles :

• Voix off de personnages : idéal pour les jeux et l’animation grâce à sa palette émotionnelle.
• Contenu professionnel : particulièrement adapté aux vidéos d’entreprise et aux supports d’e-learning.
• Projets multilingues : préserve une qualité vocale cohérente lors des changements de langue.
• Qualité stable : produit un rendu audio homogène et de haute qualité.

Bien que sa latence et son coût par caractère soient plus élevés que ceux des modèles Flash, il offre une qualité supérieure pour les projets où une parole réaliste est essentielle.

Nos modèles multilingues v2 prennent en charge 29 langues :

Anglais (États-Unis, Royaume-Uni, Australie, Canada), japonais, chinois, allemand, hindi, français (France, Canada), coréen, portugais (Brésil, Portugal), italien, espagnol (Espagne, Mexique), indonésien, néerlandais, turc, filipino, polonais, suédois, bulgare, roumain, arabe (Arabie saoudite, Émirats arabes unis), tchèque, grec, finnois, croate, malais, slovaque, danois, tamoul, ukrainien et russe.

Flash v2.5

Eleven Flash v2.5 est notre modèle de synthèse vocale le plus rapide, conçu pour les applications en temps réel et Agents Platform. Il produit une parole de haute qualité avec une latence ultra-faible (~75 ms†) dans 32 langues.

Le modèle concilie vitesse et qualité, ce qui le rend idéal pour les applications interactives tout en préservant un rendu naturel et des caractéristiques vocales cohérentes d’une langue à l’autre.

Ce modèle est particulièrement adapté aux cas suivants :

• Agents Platform : parfait pour les agents vocaux et chatbots en temps réel.
• Applications interactives : idéal pour les jeux et applications nécessitant une réponse immédiate.
• Traitement à grande échelle : efficace pour la conversion groupée de texte en parole.

Avec son tarif plus bas pour les générations via API et sa latence de 75 ms, Flash v2.5 est l’option économique pour tous ceux qui ont besoin d’une synthèse vocale rapide et fiable dans plusieurs langues.

Flash v2.5 prend en charge 32 langues, toutes les langues des modèles v2 ainsi que :

Hongrois, norvégien et vietnamien

Points à prendre en compte

Guide de sélection des modèles

Pour savoir quel modèle répond le mieux à vos besoins et à votre cas d’utilisation, consultez le guide de sélection des modèles.

Limites de caractères

Le nombre maximal de caractères pris en charge dans une requête de synthèse vocale unique varie selon le modèle.

Scribe v2

Scribe v2 est notre modèle de reconnaissance vocale de pointe, conçu pour une transcription précise dans plus de 90 langues. Il fournit des horodatages précis au niveau du mot ainsi que des fonctionnalités avancées telles que la diarisation des locuteurs et le balisage audio dynamique.

Ce modèle excelle dans les scénarios nécessitant une conversion précise de la parole en texte :

• Services de transcription : parfait pour convertir du contenu audio et vidéo en texte
• Documentation de réunions : idéal pour capturer et documenter les conversations
• Analyse de contenu : particulièrement adapté au traitement et à l’analyse de contenu audio
• Reconnaissance multilingue : prend en charge une transcription précise dans plus de 90 langues

Fonctionnalités clés :

• Transcription précise avec horodatages au niveau du mot
• Diarisation des locuteurs pour les fichiers audio comportant plusieurs intervenants
• Balisage audio dynamique pour un contexte enrichi
• Prise en charge de plus de 90 langues
• Détection d’entités
• Indications par termes clés
• Édition de transcriptions

En savoir plus sur Scribe v2 ici.

Scribe v2 Realtime

Scribe v2 Realtime, notre modèle de reconnaissance vocale en direct le plus rapide et le plus précis, offre une précision de pointe dans plus de 90 langues avec une latence ultra-faible de 150 ms.

Ce modèle excelle dans les cas d’utilisation conversationnels :

• Transcription de réunions en direct : parfaite pour la transcription en temps réel
• Agents IA : idéal pour les conversations en direct
• Reconnaissance multilingue : prend en charge une transcription précise dans plus de 90 langues avec détection automatique de la langue

Fonctionnalités clés :

• Latence ultra-faible : obtenez des transcriptions partielles en environ 150 millisecondes
• Prise en charge du streaming : envoyez l’audio par segments tout en recevant les transcriptions en temps réel
• Plusieurs formats audio : prise en charge du PCM (de 8 kHz à 48 kHz) et de l’encodage μ-law
• Détection d’activité vocale (VAD) : segmentation automatique de la parole basée sur la détection des silences
• Contrôle manuel de la validation : contrôlez entièrement le moment où finaliser les segments de transcription
• Détection d’entités
• Édition de transcriptions

En savoir plus sur Scribe v2 Realtime ici.

Scribe v2 Medical

Scribe v2 Medical est un modèle de reconnaissance vocale par lots spécialisé dans l’audio médical et clinique. Il s’agit d’un Finetune de Scribe v2 qui améliore la reconnaissance des noms de médicaments, de l’anatomie, de la pathologie et de la dictée clinique, tout en conservant la précision de Scribe v2 pour la parole courante. Il utilise la même API Speech to Text que Scribe v2 et est facturé au même tarif. Transmettez scribe_v2_medical comme model_id.

Ce modèle est particulièrement adapté aux cas suivants :

• Documentation clinique : consultations ambiantes et notes dans lesquelles des termes médicaux apparaissent au cours de la conversation
• Dictée : séquences denses de médicaments, de dosages et de constatations
• Appels d’admission et de coordination : patients décrivant leur propre état, souvent par téléphone
• Flux de travail de conformité : associez-le à la détection d’entités pour les catégories de PHI

Fonctionnalités clés :

• Même format de requête que Scribe v2 (keyterms, entity_detection, no_verbatim, diarisation, horodatages)
• Meilleure reconnaissance des noms de médicaments, des termes d’anatomie et de pathologie
• Aucune régression sur la parole courante par rapport à Scribe v2
• Prise en charge de plus de 90 langues
• Diarisation des locuteurs pour les fichiers audio comportant plusieurs intervenants
• Balisage audio dynamique
• Détection d’entités, y compris les catégories de PHI

Scribe v2 Medical est un modèle par lots. Pour la transcription en direct, utilisez Scribe v2 Realtime.

Scribe v2 Medical est éligible à HIPAA, avec des accords de partenariat commercial disponibles pour les clients Enterprise, ainsi que le mode zéro rétention (ZRM). Lorsque le ZRM est activé, l’entrée audio et la sortie texte sont supprimées immédiatement après la fin de chaque requête. ElevenLabs ne conserve rien, et votre application reçoit la réponse complète de l’API et conserve les transcriptions sous vos propres contrôles.

En savoir plus sur Speech to Text ici.

Eleven Music

Eleven Music est notre modèle de génération musicale de qualité studio. Il vous permet de générer de la musique dans tous les styles à partir d’instructions en langage naturel.

Ce modèle excelle dans les scénarios suivants :

• Bandes originales de jeux : créez des bandes originales immersives pour les jeux
• Musiques de fond pour podcasts : enrichissez vos podcasts avec une musique professionnelle
• Marketing : ajoutez une musique de fond aux reels publicitaires

Fonctionnalités clés :

• Contrôle complet du genre, du style et de la structure
• Avec voix ou uniquement instrumental
• Multilingue, notamment en anglais, espagnol, allemand, japonais et bien plus encore
• Modifiez le son et les paroles de sections individuelles ou de l’ensemble du morceau

En savoir plus sur Eleven Music ici.

Requêtes simultanées et priorité

Votre forfait détermine le nombre de requêtes pouvant être traitées simultanément ainsi que le niveau de priorité de vos requêtes dans la file d’attente. Speech to Text dispose d’une limite de requêtes simultanées plus élevée. Une fois cette limite atteinte, les requêtes suivantes sont traitées dans une file d’attente avec des requêtes de priorité inférieure. En pratique, cela n’ajoute généralement qu’environ 50 ms de latence.

Les en-têtes de réponse incluent current-concurrent-requests et maximum-concurrent-requests, que vous pouvez utiliser pour suivre vos requêtes simultanées.

Requêtes API par minute et requêtes simultanées

Il est important de comprendre que les requêtes API par minute et les requêtes simultanées sont des métriques distinctes qui dépendent de vos habitudes d’utilisation.

Le nombre de requêtes API par minute peut différer du nombre de requêtes simultanées, car il dépend de la durée de chaque requête et de la façon dont les requêtes sont regroupées.

Exemple 1 : requêtes espacées Si vous aviez 180 requêtes par minute, chacune prenant 1 seconde à s’exécuter, et que vous les envoyiez à 0,33 seconde d’intervalle, le nombre maximal de requêtes simultanées serait de 3 et la moyenne serait de 3, car il y en aurait toujours 3 en cours.

Exemple 2 : requêtes regroupées En revanche, si vous aviez un autre mode d’utilisation, par exemple 180 requêtes par minute prenant chacune 3 secondes à s’exécuter mais toutes déclenchées en même temps, le nombre maximal de requêtes simultanées serait de 180 et la moyenne de 9 (les 3 premières secondes de la minute compteraient 180 requêtes simultanées, les 57 dernières secondes 0 requête).

Puisque notre système tient compte des requêtes simultanées, le nombre de requêtes par minute importe moins que la durée de chacune d’elles et le moment où elles sont envoyées.

La manière dont les requêtes sont effectuées auprès des endpoints a une incidence sur les limites de requêtes simultanées :

• Avec HTTP, chaque requête compte individuellement dans votre limite de requêtes simultanées.
• Avec le WebSocket Text to Speech, seul le temps pendant lequel notre modèle génère de l’audio compte dans votre limite de requêtes simultanées. Cela signifie que, la plupart du temps, un websocket ouvert ne compte pas du tout dans cette limite.
• Les WebSockets Text to Dialogue fonctionnent différemment : chaque connexion ouverte réserve une session de dialogue issue d’un pool distinct tant qu’elle reste ouverte, et l’audio généré via cette connexion ne compte pas dans votre limite standard de requêtes simultanées. Ce fonctionnement est plus simple à appréhender, car une connexion correspond à une session, et vos limites de sessions de dialogue sont dimensionnées pour s’adapter à cette nouvelle méthode de calcul des requêtes simultanées. Consultez les requêtes simultanées de Text to Dialogue.

Comprendre les limites de requêtes simultanées

La limite de requêtes simultanées associée à votre forfait ne doit pas être interprétée comme le nombre maximal de conversations, d’appels téléphoniques, de voix off de personnages, etc. pouvant être gérés simultanément. Le nombre réel dépend de plusieurs facteurs, notamment des voix IA utilisées et des caractéristiques du cas d’utilisation.

En règle générale, une limite de 5 requêtes simultanées peut prendre en charge jusqu’à environ 100 diffusions audio simultanées.

Cela s’explique par la vitesse de génération de l’audio par rapport au temps nécessaire au traitement de la requête TTS. Le diagramme ci-dessous montre comment 4 appels simultanés avec différents utilisateurs peuvent être pris en charge tout en n’atteignant que 2 requêtes simultanées.

Si vous dépassez à tout moment les limites de requêtes simultanées de votre forfait et que vous disposez du forfait Enterprise, les requêtes au modèle peuvent tout de même aboutir, mais plus lentement, selon les capacités disponibles et dans la mesure du possible.

Requêtes simultanées pour Text to Dialogue

Les requêtes Text to Dialogue sont comptabilisées de deux façons différentes selon la manière dont vous appelez l’API :

• Les endpoints HTTP (Créer un dialogue et Diffuser un dialogue) comptent dans la limite standard de requêtes simultanées de votre forfait pendant la génération de l’audio, comme toute autre requête Text to Speech.
• Les endpoints WebSocket, tels que le WebSocket Text to Dialogue, sont comptabilisés comme des sessions de dialogue. Une connexion ouverte conserve une session de dialogue tant qu’elle reste ouverte, que de l’audio soit généré ou non.

La comptabilisation par session simplifie la planification des capacités : une connexion correspond à une session, votre utilisation ne fluctue donc pas selon l’activité de génération. Comme une session est conservée pendant toute la durée de la connexion, plutôt que seulement pendant la génération audio, vos limites de sessions de dialogue sont dimensionnées pour s’adapter à cette nouvelle méthode de calcul des requêtes simultanées.

Si vous ouvrez une connexion alors que toutes les sessions de dialogue de votre Workspace sont utilisées, la nouvelle connexion est rejetée avec l’erreur too_many_concurrent_requests. Pour libérer des sessions, fermez les connexions dont vous n’avez plus besoin. Une connexion se ferme également automatiquement après 20 secondes d’inactivité, sauf si vous envoyez des messages keep_alive.

Pour suivre les sessions de dialogue, ouvrez Developers en bas de la barre latérale du Dashboard, sélectionnez l’onglet Analytics, puis consultez la métrique Concurrent requests dans la vue Usage. Les sessions de dialogue sont signalées dans leur propre série, TTD Websocket Sessions, distincte de vos autres requêtes simultanées.

Tester les limites de requêtes simultanées à grande échelle

Les tests à grande échelle peuvent être utiles pour identifier les problèmes de montée en charge côté client et vérifier que les limites de requêtes simultanées sont correctement définies pour votre cas d’utilisation.

Il est fortement recommandé de tester des workflows de bout en bout aussi proches que possible de l’utilisation réelle. La méthode recommandée consiste à simuler et à mesurer le nombre d’utilisateurs pouvant être pris en charge. Il est important de :

• Simuler des utilisateurs, et non des requêtes brutes
• Simuler le comportement habituel des utilisateurs, par exemple attendre la fin de la lecture audio, de la prise de parole ou de la transcription avant d’effectuer des requêtes
• Augmenter progressivement le nombre d’utilisateurs sur plusieurs minutes
• Introduire de l’aléa dans le calendrier des requêtes et dans la taille des requêtes
• Capturer les métriques de latence et les codes d’erreur renvoyés par l’API

Par exemple, pour tester un système d’agents conçu pour prendre en charge 100 conversations simultanées, vous créeriez jusqu’à 100 « utilisateurs » individuels simulant chacun une conversation. Les conversations se composent généralement d’un cycle répétitif d’environ 10 secondes de parole de l’utilisateur, suivies d’un appel à l’API TTS pour environ 150 caractères, puis d’environ 10 secondes de lecture audio à l’utilisateur. Chaque utilisateur doit donc suivre le modèle consistant à effectuer un appel API Text to Speech via websocket pour 150 caractères de texte toutes les 20 secondes, en introduisant un léger aléa dans la période d’attente et le nombre de caractères demandés. Le test consisterait à générer un utilisateur par seconde jusqu’à atteindre 100 utilisateurs, puis à effectuer le test pendant 10 minutes au total afin de vérifier la stabilité globale.

import json
import random
import time
import gevent
import locust
from locust import User, task, events, constant_throughput
import websocket
# Averages up to 10 seconds of audio when played, depends on the voice speed
DEFAULT_TEXT = (
    "Hello, this is a test message. I am testing if a long input will cause issues for the model "
    "like this sentence. "
)
TEXT_ARRAY = [
    "Hello.",
    "Hello, this is a test message.",
    DEFAULT_TEXT,
    DEFAULT_TEXT * 2,
    DEFAULT_TEXT * 3
]
# Custom command line arguments
@events.init_command_line_parser.add_listener
def on_parser_init(parser):
    parser.add_argument("--api-key", default="YOUR_API_KEY", help="API key for authentication")
    parser.add_argument("--encoding", default="mp3_22050_32", help="Encoding")
    parser.add_argument("--text", default=DEFAULT_TEXT, help="Text to use")
    parser.add_argument("--use-text-array", default="false", help="Text to use")
    parser.add_argument("--voice-id", default="aria", help="Text to use")
class WebSocketTTSUser(User):
    # Each user will send a request every 20 seconds, regardless of how long each request takes
    wait_time = constant_throughput(0.05)
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.api_key = self.environment.parsed_options.api_key
        self.voice_id = self.environment.parsed_options.voice_id
        self.text = self.environment.parsed_options.text
        self.encoding = self.environment.parsed_options.encoding
        self.use_text_array = self.environment.parsed_options.use_text_array
        if self.use_text_array:
            self.text = random.choice(TEXT_ARRAY)
        self.all_recieved = False
    @task
    def tts_task(self):
        # Do jitter waiting of up to 1 second
        # Users appear to be spawned every second so this ensures requests are not aligned
        gevent.sleep(random.random())
        max_wait_time = 10
        # Connection details
        uri = f"{self.environment.host}/v1/text-to-speech/{self.voice_id}/stream-input?auto_mode=true&output_format={self.encoding}"
        headers = {"xi-api-key": self.api_key}
        ws = None
        self.all_recieved = False
        try:
            init_msg = {"text": " "}
            # Use proper header format for websocket - this is case sensitive!
            ws = websocket.create_connection(uri, header=headers)
            ws.send(json.dumps(init_msg))
            # Start measuring after websocket initiated but before any messages are sent
            send_request_time = time.perf_counter()
            ws.send(json.dumps({"text": self.text}))
            # Send to flush and receive the audio
            ws.send(json.dumps({"text": ""}))
            def _receive():
                t_first_response = None
                audio_size = 0
                try:
                    while True:
                        # Wait up to 10 seconds for a response
                        ws.settimeout(max_wait_time)
                        response = ws.recv()
                        response_data = json.loads(response)
                        if "audio" in response_data and response_data["audio"]:
                            audio_size = audio_size + len(response_data["audio"])
                        if t_first_response is None:
                            t_first_response = time.perf_counter()
                            first_byte_ms = (
                                t_first_response - send_request_time
                            ) * 1000
                            if audio_size is None:
                                # The first response should always have audio
                                locust.events.request.fire(
                                    request_type="websocket",
                                    name="Bad Response (no audio)",
                                    response_time=first_byte_ms,
                                    response_length=audio_size,
                                    exception=Exception("Response has no audio"),
                                )
                                break
                        if "isFinal" in response_data and response_data["isFinal"]:
                            # Fire this event once finished streaming, but report the important TTFB metric
                            locust.events.request.fire(
                                request_type="websocket",
                                name="TTS Stream Success (First Byte)",
                                response_time=first_byte_ms,
                                response_length=audio_size,
                                exception=None,
                            )
                            break
                except websocket.WebSocketTimeoutException:
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Timeout",
                        response_time=max_wait_time * 1000,
                        response_length=audio_size,
                        exception=Exception("Timeout waiting for response"),
                    )
                except Exception as e:
                    # Typically JSON decode error if the server returns HTTP backoff error
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Failure",
                        response_time=0,
                        response_length=0,
                        exception=e,
                    )
                finally:
                    self.all_recieved = True
            gevent.spawn(_receive)
            # Sleep until recieved so new tasks aren't spawned
            while not self.all_recieved:
                gevent.sleep(1)
        except websocket.WebSocketTimeoutException:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Timeout",
                response_time=max_wait_time * 1000,
                response_length=0,
                exception=Exception("Timeout waiting for response"),
            )
        except Exception as e:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Failure",
                response_time=0,
                response_length=0,
                exception=e,
            )
        finally:
            # Try and close the websocket gracefully
            try:
                if ws:
                    ws.close()
            except Exception:
                pass