Modèles

Modèles phares

Text to Speech

Speech to Text

Agents vocaux

Musique

Présentation des modèles

L’API ElevenLabs propose une gamme de modèles audio optimisés pour différents cas d’usage, 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 est particulièrement adapté aux scénarios suivants :

• Voix off de personnages : idéal pour les jeux et l’animation grâce à sa gamme d’émotions.
• 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 aux interprétations émotionnelles complexes.
• Projets multilingues : préserve une qualité vocale homogène 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, notamment :

L’afrikaans (af), l’arabe (ar), l’arménien (hy), l’assamais (as), l’asturien (ast), l’azerbaïdjanais (az), le biélorusse (be), le bengali (bn), le bosnien (bs), le bulgare (bg), le birman (my), le cantonais (yue), le catalan (ca), le cebuano (ceb), le croate (hr), le tchèque (cs), le danois (da), le néerlandais (nl), l’anglais (en), l’estonien (et), le filipino (fil), le finnois (fi), le français (fr), le galicien (gl), le géorgien (ka), l’allemand (de), le grec (el), le gujarati (gu), le haoussa (ha), l’hébreu (he), le hindi (hi), le hongrois (hu), l’islandais (is), l’indonésien (id), l’irlandais (ga), l’italien (it), le japonais (ja), le javanais (jv), le kannada (kn), le kazakh (kk), le coréen (ko), le kirghize (ky), le letton (lv), le lingala (ln), le lituanien (lt), le luxembourgeois (lb), le macédonien (mk), le malais (ms), le malayalam (ml), le maltais (mt), le chinois mandarin (zh), le māori (mi), le marathi (mr), le mongol (mn), le népalais (ne), le norvégien (no), l’occitan (oc), l’odia (or), le pachto (ps), le persan (fa), le polonais (pl), le portugais (pt), le pendjabi (pa), le roumain (ro), le russe (ru), le serbe (sr), le sindhi (sd), le slovaque (sk), le slovène (sl), le somali (so), l’espagnol (es), le swahili (sw), le suédois (sv), le tadjik (tg), le tamoul (ta), le télougou (te), le thaï (th), le turc (tr), l’ukrainien (uk), l’ourdou (ur), l’ouzbek (uz), le vietnamien (vi), le gallois (cy) et le yoruba (yo).

Eleven v4 Turbo

Eleven v4 Turbo est notre modèle de pointe pour la synthèse vocale en temps réel. Il offre un audio de haute qualité, 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 est particulièrement adapté aux scénarios suivants :

• Agents d’assistance : 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 mettant en scène 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, notamment :

L’afrikaans (af), l’arabe (ar), l’arménien (hy), l’assamais (as), l’asturien (ast), l’azerbaïdjanais (az), le biélorusse (be), le bengali (bn), le bosnien (bs), le bulgare (bg), le birman (my), le cantonais (yue), le catalan (ca), le cebuano (ceb), le croate (hr), le tchèque (cs), le danois (da), le néerlandais (nl), l’anglais (en), l’estonien (et), le filipino (fil), le finnois (fi), le français (fr), le galicien (gl), le géorgien (ka), l’allemand (de), le grec (el), le gujarati (gu), le haoussa (ha), l’hébreu (he), le hindi (hi), le hongrois (hu), l’islandais (is), l’indonésien (id), l’irlandais (ga), l’italien (it), le japonais (ja), le javanais (jv), le kannada (kn), le kazakh (kk), le coréen (ko), le kirghize (ky), le letton (lv), le lingala (ln), le lituanien (lt), le luxembourgeois (lb), le macédonien (mk), le malais (ms), le malayalam (ml), le maltais (mt), le chinois mandarin (zh), le māori (mi), le marathi (mr), le mongol (mn), le népalais (ne), le norvégien (no), l’occitan (oc), l’odia (or), le pachto (ps), le persan (fa), le polonais (pl), le portugais (pt), le pendjabi (pa), le roumain (ro), le russe (ru), le serbe (sr), le sindhi (sd), le slovaque (sk), le slovène (sl), le somali (so), l’espagnol (es), le swahili (sw), le suédois (sv), le tadjik (tg), le tamoul (ta), le télougou (te), le thaï (th), le turc (tr), l’ukrainien (uk), l’ourdou (ur), l’ouzbek (uz), le vietnamien (vi), le gallois (cy) et le yoruba (yo).

Eleven v3

Eleven v3 est notre modèle de synthèse vocale de génération précédente. Il produit une parole 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 parole naturelle et réaliste, avec une grande palette émotionnelle et une compréhension du contexte dans plusieurs langues.

Retrouvez de plus amples informations sur l’API Text to Dialogue ici.

Langues prises en charge

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

L’afrikaans (af), l’arabe (ar), l’arménien (hy), l’assamais (as), l’asturien (ast), l’azerbaïdjanais (az), le biélorusse (be), le bengali (bn), le bosnien (bs), le bulgare (bg), le birman (my), le cantonais (yue), le catalan (ca), le cebuano (ceb), le chichewa (ny), le croate (hr), le tchèque (cs), le danois (da), le néerlandais (nl), l’anglais (en), l’estonien (et), le filipino (fil), le finnois (fi), le français (fr), le galicien (gl), le géorgien (ka), l’allemand (de), le grec (el), le gujarati (gu), le haoussa (ha), l’hébreu (he), le hindi (hi), le hongrois (hu), l’islandais (is), l’indonésien (id), l’irlandais (ga), l’italien (it), le japonais (ja), le javanais (jv), le kannada (kn), le kazakh (kk), le kirghize (ky), le coréen (ko), le letton (lv), le lingala (ln), le lituanien (lt), le luxembourgeois (lb), le macédonien (mk), le malais (ms), le malayalam (ml), le maltais (mt), le chinois mandarin (zh), le māori (mi), le marathi (mr), le mongol (mn), le népalais (ne), le norvégien (no), l’occitan (oc), l’odia (or), le pachto (ps), le persan (fa), le polonais (pl), le portugais (pt), le pendjabi (pa), le roumain (ro), le russe (ru), le serbe (sr), le sindhi (sd), le slovaque (sk), le slovène (sl), le somali (so), l’espagnol (es), le swahili (sw), le suédois (sv), le tadjik (tg), le tamoul (ta), le télougou (te), le thaï (th), le turc (tr), l’ukrainien (uk), l’ourdou (ur), l’ouzbek (uz), le vietnamien (vi), le gallois (cy) et le yoruba (yo).

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 parole 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.

Retrouvez de plus amples informations sur le WebSocket Text to Dialogue ici.

Langues prises en charge

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

L’afrikaans (af), l’arabe (ar), l’arménien (hy), l’assamais (as), l’asturien (ast), l’azerbaïdjanais (az), le biélorusse (be), le bengali (bn), le bosnien (bs), le bulgare (bg), le birman (my), le cantonais (yue), le catalan (ca), le cebuano (ceb), le chichewa (ny), le croate (hr), le tchèque (cs), le danois (da), le néerlandais (nl), l’anglais (en), l’estonien (et), le filipino (fil), le finnois (fi), le français (fr), le galicien (gl), le géorgien (ka), l’allemand (de), le grec (el), le gujarati (gu), le haoussa (ha), l’hébreu (he), le hindi (hi), le hongrois (hu), l’islandais (is), l’indonésien (id), l’irlandais (ga), l’italien (it), le japonais (ja), le javanais (jv), le kannada (kn), le kazakh (kk), le kirghize (ky), le coréen (ko), le letton (lv), le lingala (ln), le lituanien (lt), le luxembourgeois (lb), le macédonien (mk), le malais (ms), le malayalam (ml), le maltais (mt), le chinois mandarin (zh), le māori (mi), le marathi (mr), le mongol (mn), le népalais (ne), le norvégien (no), l’occitan (oc), l’odia (or), le pachto (ps), le persan (fa), le polonais (pl), le portugais (pt), le pendjabi (pa), le roumain (ro), le russe (ru), le serbe (sr), le sindhi (sd), le slovaque (sk), le slovène (sl), le somali (so), l’espagnol (es), le swahili (sw), le suédois (sv), le tadjik (tg), le tamoul (ta), le télougou (te), le thaï (th), le turc (tr), l’ukrainien (uk), l’ourdou (ur), l’ouzbek (uz), le vietnamien (vi), le gallois (cy) et le yoruba (yo).

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 grande palette émotionnelle et une compréhension du contexte dans plusieurs langues.

Le modèle offre une qualité vocale et une personnalité homogènes 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é et riche en nuances émotionnelles :

• Voix off de personnages : idéal pour les jeux et l’animation grâce à sa gamme d’émotions.
• Contenu professionnel : adapté aux vidéos d’entreprise et aux supports d’e-learning.
• Projets multilingues : préserve une qualité vocale homogène 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 offre une parole de haute qualité avec une latence ultra-faible (environ 75 ms†) dans 32 langues.

Le modèle équilibre 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 homogènes d’une langue à l’autre.

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

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

Avec son prix réduit pour les générations via API et sa latence de 75 ms, Flash v2.5 est une option économique pour toutes les personnes 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’usage, 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 comme 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 : 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 audios comprenant plusieurs locuteurs
• Balisage audio dynamique pour un contexte enrichi
• Prise en charge de plus de 90 langues
• Détection d’entités
• Guidage par termes clés
• Édition de transcription

Retrouvez de plus amples informations 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’usage 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 reconnaissance 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 morceaux tout en recevant des 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 selon la détection des silences
• Contrôle de validation manuel : contrôlez précisément le moment où finaliser les segments de transcription
• Détection d’entités
• Édition de transcription

Retrouvez de plus amples informations sur Scribe v2 Realtime ici.

Scribe v2 Medical

Scribe v2 Medical est un modèle de reconnaissance vocale par lots spécialisé dans les audios médicaux et cliniques. 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 sur 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 où les termes médicaux apparaissent au cours de la conversation
• Dictée : séquences denses de médicaments, de dosages et d’observations
• Appels de prise en charge et de coordination : patients décrivant leurs propres pathologies, souvent par téléphone
• Processus de conformité : associez-le à la détection d’entités pour les catégories d’informations de santé protégées

Fonctionnalités clés :

• Même format de requête que Scribe v2 (keyterms, entity_detection, no_verbatim, diarisation, horodatages)
• Reconnaissance améliorée des noms de médicaments ainsi que des termes anatomiques et pathologiques
• Aucune régression sur la parole courante par rapport à Scribe v2
• Prise en charge de plus de 90 langues
• Diarisation des locuteurs pour les audios comprenant plusieurs locuteurs
• Balisage audio dynamique
• Détection d’entités, y compris des catégories d’informations de santé protégées

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

Scribe v2 Medical est éligible à la conformité HIPAA. Des accords d’associé commercial sont 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.

Retrouvez de plus amples informations sur Speech to Text ici.

Eleven Realtime

Eleven Realtime est une nouvelle catégorie de modèles Speech to Speech conçus pour créer des agents vocaux naturels. Chaque modèle Realtime est un agent vocal complet : reconnaissance vocale, détection d’activité vocale et gestion des tours de parole, LLM et synthèse vocale, sélectionnés et réglés par ElevenLabs pour fonctionner ensemble au sein d’un même système. Sélectionnez un modèle Realtime et obtenez un agent performant à partir d’un seul choix, sans composants à configurer.

Deux modèles Realtime sont disponibles.

Eleven Realtime v1 Mini est optimisé pour des conversations rapides et naturelles, et convient particulièrement aux scénarios suivants :

• Assistants IA : dialogue rapide et expressif, où la conversation constitue le produit.
• Tuteurs pédagogiques : échanges naturels qui suivent le rythme de l’apprenant.
• Personnages interactifs : personnages expressifs pour les jeux et le divertissement.

Eleven Realtime v1 Max est optimisé pour les tâches complexes, et convient particulièrement aux scénarios suivants :

• Assistance client : résolution de demandes qui nécessitent de suivre un processus et de rechercher des informations.
• Qualification de prospects : conversations structurées qui recueillent des informations et déterminent les prochaines étapes.
• Processus en plusieurs étapes : tâches qui appellent des outils afin de rechercher des informations ou d’effectuer des actions.

Fonctionnalités clés :

• Reconnaissance vocale, gestion des tours de parole, modèle de langage et voix réunis en un seul choix de modèle
• Gestion naturelle des tours de parole et des interruptions
• Appel d’outils
• Voix personnalisables depuis la Voice Library d’ElevenLabs
• Prise en charge de plus de 90 langues
• Passage de v1 Mini à v1 Max par une sélection de modèle, sans modifier l’intégration

Eleven Realtime est disponible dans ElevenAgents, où vous sélectionnez un modèle Realtime dans la liste déroulante des modèles, ainsi que via l’API Realtime, conçue pour être compatible avec l’API Realtime d’OpenAI sur WebSocket. Si vous utilisez déjà l’API Realtime d’OpenAI, consultez le guide de migration.

Langues prises en charge

Les modèles Realtime prennent en charge plus de 90 langues. Consultez la liste des langues d’Eleven v4.

Retrouvez de plus amples informations sur Eleven Realtime 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’invites en langage naturel.

Ce modèle est excellent pour les scénarios suivants :

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

Fonctionnalités clés :

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

Retrouvez de plus amples informations 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 bénéficie 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 aux côtés des requêtes moins prioritaires. 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 différentes 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 manière dont les requêtes sont regroupées.

Exemple 1 : requêtes espacées Si vous aviez 180 requêtes par minute, prenant chacune 1 seconde pour 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 également de 3, car 3 requêtes seraient toujours 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 pour s’exécuter, mais toutes envoyées en même temps, le nombre maximal de requêtes simultanées serait de 180 et la moyenne serait de 9 (les 3 premières secondes de la minute compteraient 180 requêtes simultanées, les 57 dernières secondes 0 requête).

Notre système étant axé sur les requêtes simultanées, le nombre de requêtes par minute importe moins que la durée de chacune d’elles et le rythme auquel 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. Ainsi, 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 les limites de vos sessions de dialogue sont dimensionnées pour s’adapter à cette nouvelle méthode de gestion des requêtes simultanées. Consultez les requêtes simultanées 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’usage.

En règle générale, une limite de 5 requêtes simultanées peut généralement 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 schéma 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 de modèle peuvent tout de même aboutir, mais plus lentement, dans la limite des capacités disponibles et sans garantie.

Requêtes simultanées 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, comme le WebSocket Text to Dialogue, sont comptabilisés sous forme de sessions de dialogue. Une connexion ouverte occupe 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, de sorte que votre utilisation ne fluctue pas selon l’activité de génération. Une session étant occupée pendant toute la durée de la connexion, et non uniquement pendant la génération de l’audio, les limites de vos sessions de dialogue sont dimensionnées pour s’adapter à cette nouvelle méthode de gestion 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 Développeurs en bas de la barre latérale du Dashboard, sélectionnez l’onglet Analytiques, puis consultez la métrique Requêtes simultanées dans la vue Utilisation. Les sessions de dialogue sont signalées dans leur propre série, Sessions Websocket TTD, distincte de vos autres requêtes simultanées.

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

Les tests à grande échelle peuvent vous aider à identifier les problèmes de mise à l’échelle côté client et à vérifier que les limites de requêtes simultanées sont correctement définies pour votre cas d’usage.

Nous vous recommandons vivement de tester les flux de travail de bout en bout en vous rapprochant autant 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 de simples requêtes
• Simuler le comportement habituel des utilisateurs, comme l’attente de la fin de la lecture audio, de la prise de parole de l’utilisateur ou de la transcription avant d’effectuer des requêtes
• Augmenter lentement le nombre d’utilisateurs sur plusieurs minutes
• Introduire un caractère aléatoire dans le moment des requêtes et leur taille
• Capturer les métriques de latence et les éventuels 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 suivent généralement un cycle répété 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 pour l’utilisateur. Chaque utilisateur doit donc suivre le modèle consistant à effectuer toutes les 20 secondes un appel WebSocket à l’API Text to Speech pour 150 caractères de texte, en introduisant une légère part d’aléatoire dans le délai d’attente et le nombre de caractères demandés. Le test consisterait à lancer un utilisateur par seconde jusqu’à en avoir 100, puis à effectuer le test pendant 10 minutes au total afin d’évaluer 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