Performance, simultanéité et dimensionnement de l’IA vocale

Périmètre. Un résultat de capacité ne vaut que pour la charge, le modèle, la voix, le matériel, le logiciel et la configuration de service testés. Ce guide fournit une méthode pour produire un résultat, pas un nombre universel d’appels par GPU.

À retenir

• Mesurez le délai entre la fin du tour de parole et le premier audio lisible pour rendre compte de l’expérience utilisateur, et conservez les horodatages par composant pour le diagnostic.
• Pilotez les tests avec des arrivées, un comportement de session, des textes et des durées audio calqués sur la production. Une boucle à simultanéité fixe ne remplace pas un modèle d’arrivées.
• Définissez la capacité utilisable comme la charge testée la plus élevée qui respecte encore tous les objectifs de latence, d’échec, de file d’attente et de rétablissement.
• Traitez le p99, le facteur temps réel et l’utilisation GPU comme des preuves assorties d’un périmètre explicite, non comme des affirmations de capacité autonomes.
• Chiffrez la capacité utilisable testée, travail échoué et annulé compris, plutôt que de diviser le coût par un débit maximal théorique.

Dernière mise à jour : août 2026. Aucun résultat de capacité matérielle ou de latence de KugelAudio n’est revendiqué ici.

Quelle latence l’utilisateur d’une IA vocale perçoit-il réellement ?

L’utilisateur perçoit l’intervalle entre la fin de son tour de parole et le début d’une lecture utile. Selon l’application, cela englobe la détection de fin de tour, la transcription, la logique applicative, la sortie du modèle de langage, la normalisation du texte, la synthèse vocale, le transfert réseau, le décodage et un tampon de lecture. Le seul temps d’inférence du modèle ne décrit pas cette expérience.

Instrumentez une trace avec des horodatages monotones à ces frontières :

user turn end
-> transcript ready
-> first stable text sent to TTS
-> TTS request admitted
-> synthesis starts
-> first audio byte received
-> enough valid audio is decoded and buffered
-> playback starts
-> synthesis completes or is cancelled

Nommez la métrique d’après ses bornes. Par exemple, le délai avant le premier audio de synthèse (TTFA) peut courir de l’admission de la requête au premier fragment audio, tandis que le premier audio lisible côté utilisateur court de la fin du tour au début de la lecture. Le premier octet réseau peut être un en-tête ou une trame partielle : ce n’est donc pas automatiquement de l’audio lisible. Consignez avec le résultat la région cliente, la réutilisation des connexions, le codec, la fréquence d’échantillonnage et la règle de tampon de lecture.

Le guide de diffusion en continu et de découpage de KugelAudio documente l’influence du découpage côté serveur et du vidage côté client sur le TTFA. Il ne dispense pas de mesurer l’ensemble du chemin applicatif.

Utilité principale : exécutez ces tests comme des scénarios nommés. Fondre démarrages à froid, rafales et trafic stable dans un même agrégat masque la cause d’un percentile lent.

Comment un test de capacité doit-il modéliser la charge de production ?

Partez d’un manifeste de charge versionné, pas d’un simple nombre de requêtes. Incluez :

• le taux d’arrivée des sessions et la distribution des rafales ;
• les appels en cours, les tours par session et le temps de réflexion entre les tours ;
• la répartition des longueurs de texte, des langues, des voix et des normalisations ;
• la durée, le format et la fréquence d’échantillonnage de l’audio généré ;
• le comportement de découpage et de vidage en diffusion continue ;
• la réutilisation des connexions, les reconnexions, les délais limites et les reprises ;
• les interruptions, le moment des annulations et les sessions abandonnées ;
• le trafic voisin ou par lots qui partage les mêmes dépendances.

Utilisez des distributions de production anonymisées lorsque c’est possible. Sinon, publiez le corpus de textes ou le générateur déterministe, la graine aléatoire et les paramètres de distribution. Calculez l’empreinte du corpus et notez la révision du générateur de charge, afin qu’une exécution ultérieure reprenne exactement le même travail.

Choisissez délibérément le modèle du générateur de charge. Un générateur en boucle fermée attend une réponse avant d’émettre la requête suivante : quand le service ralentit, il envoie moins de travail et peut masquer la saturation. Il reste utile lorsqu’une simultanéité active fixe constitue elle-même la condition de production. Un générateur en boucle ouverte planifie les arrivées indépendamment de la fin des réponses. Les recommandations de test de charge de Google Cloud expliquent cette distinction. Pour un produit d’appel, modélisez les débuts de session comme des arrivées et préservez le rythme des tours à l’intérieur d’une session. Rapportez à la fois le travail planifié et le travail réellement émis, car un générateur de charge saturé invalide l’exécution.

Menez séparément les expériences à froid et à chaud. Définissez précisément l’état à froid, par exemple une nouvelle réplique dont le modèle n’est pas chargé, et consignez chaque phase de démarrage. Pour une exécution à chaud, terminez le préchauffage déclaré, puis ne commencez la mesure qu’une fois que le débit, la file d’attente et les signaux de ressources satisfont une règle de stabilité définie à l’avance. Ne mélangez pas la première requête à un percentile mesuré à chaud et ne l’écartez pas sans publier le résultat à froid.

Comment s’articulent simultanéité, loi de Little et facteur temps réel ?

« Appels simultanés » peut désigner des sockets ouverts, des sessions actives, des tours en file d’attente ou des flux en train de générer de l’audio. Publiez chacun séparément. Le travail actif consomme des ressources d’inférence, le travail en file ajoute de l’attente et occupe des ressources de service, et les appelants inactifs comptent encore pour les connexions et la mémoire.

Pour un système stable, la loi de Little relie des moyennes de long terme :

L = lambda * W

L       average work in the measured system
lambda  effective throughput per second
W       average time each item spends in that system, in seconds

Utilisez-la comme contrôle de cohérence et comme première estimation de charge. Elle ne prédit ni la latence de queue de distribution, ni le débit maximal, ni la marge nécessaire. Définissez la même frontière pour ses trois termes, comptez le travail achevé plutôt que d’utiliser en silence le travail offert, et n’appliquez pas cette relation de régime permanent à une fenêtre où la file continue de croître.

Le facteur temps réel (RTF) répond à une autre question :

RTF  = synthesis elapsed time / generated audio duration
RTFx = generated audio duration / synthesis elapsed time = 1 / RTF

Un RTF plus bas signifie plus rapide ; un RTFx plus élevé signifie plus rapide. La documentation de performance TTS de NVIDIA utilise le RTFx et publie ses entrées de test, son nombre de flux parallèles et d’itérations. Précisez la convention et la frontière temporelle retenues. Un RTF calculé sur le seul calcul exclut le temps de file et de réseau ; un RTF de bout en bout ne les exclut pas. Ni l’un ni l’autre ne rend compte du premier audio lisible : publiez le TTFA et les écarts entre fragments séparément. Un RTF inférieur à un sur un flux unique ne prouve pas non plus qu’un service interactif peut accepter un travail parallèle illimité.

Quelle quantité de données étaye un percentile de latence ?

Publiez le nombre d’observations, la durée du test, le nombre de répétitions, la méthode de calcul des quantiles et les bornes d’histogramme à côté de chaque percentile. Avec seulement 100 observations réussies, le p99 est déterminé par environ une observation de queue, selon l’estimateur retenu. C’est la description d’un petit échantillon, pas un engagement stable. Google Cloud avertit également, dans ses recommandations sur les métriques de latence, qu’un p99 calculé sur un faible volume peut n’être que la requête la plus lente.

Il n’existe pas de nombre d’échantillons universellement pertinent. Définissez d’abord l’incertitude acceptable, puis choisissez la durée et le nombre de répétitions indépendantes en fonction de la variabilité du trafic. Si l’exécution ne permet pas d’estimer la queue de distribution, publiez un percentile plus bas ou la proportion de requêtes respectant un seuil de latence déclaré. Définissez explicitement la population du percentile. Comptez les expirations, les rejets et les annulations comme des issues à part entière et incluez-les au dénominateur de tout taux de réussite calculé sur l’ensemble des tentatives.

Conservez les événements bruts lorsque c’est praticable et gardez des histogrammes fusionnables pour l’exploitation. Le modèle de données des métriques d’OpenTelemetry décrit l’agrégation des histogrammes. Placez les bornes de compartiments autour des seuils de décision de l’application. Ne faites pas la moyenne de percentiles précalculés par instance ; Prometheus explique pourquoi c’est invalide dans ses recommandations sur les histogrammes.

Comment un service vocal doit-il se comporter en saturation ?

La saturation doit être bornée et visible. Fixez les limites d’admission à partir du délai d’interaction et de la capacité de service mesurée. Lorsqu’un travail ne peut pas commencer à temps, rejetez-le ou réorientez-le explicitement au lieu d’accepter une file non bornée. Un pic bref ne doit pas se transformer en plusieurs minutes de parole obsolète ni consommer de la mémoire jusqu’à la panne du service.

Testez le cycle complet :

1. établir une référence stable à un débit offert connu ;
2. appliquer une rafale versionnée ou retirer une réplique ;
3. observer les admissions, les rejets, l’âge de la file, la latence et le travail actif ;
4. annuler certains flux et vérifier que leur calcul s’arrête ;
5. supprimer la panne ou la rafale ;
6. vérifier que la file se vide et que tous les signaux reviennent dans la plage de référence ;
7. contrôler que les flux acceptés n’ont pas été mélangés, dupliqués ni tronqués.

Ne relancez une tentative que si le délai restant pour l’utilisateur la rend utile. Bornez le nombre de tentatives et appliquez un délai croissant avec gigue ; des reprises synchronisées peuvent devenir une nouvelle charge. Les recommandations de Google sur les défaillances en cascade relient tests de capacité réalistes, files courtes, rejet précoce et maîtrise des reprises. Le repli peut être un message préapprouvé, un service provisionné séparément ou un transfert vers un humain, mais il doit être éprouvé sous charge.

Comment tester la mise à l’échelle automatique et la télémétrie GPU ?

La mise à l’échelle automatique ne démarre qu’une fois la demande déjà modifiée. Mesurez le délai complet de montée en charge : collecte des métriques, décision, ordonnancement, disponibilité de l’image, chargement du modèle, contrôles de santé et préchauffage. Le contrôle d’admission et la capacité réservée doivent protéger les requêtes pendant ce délai. Testez aussi la réduction d’échelle, le drainage des connexions, les mises à jour progressives et les oscillations, pas seulement la montée en charge.

Kubernetes documente les métriques personnalisées et externes ainsi que le comportement de stabilisation dans son guide de mise à l’échelle horizontale des pods. Une cible générique de CPU n’est pas automatiquement adaptée à une synthèse vocale sur GPU. L’âge de la file, le travail actif admis et un signal de saturation peuvent réagir plus directement, mais n’utilisez que des métriques rapides, bornées et validées par rapport à la latence perçue.

L’utilisation GPU, la mémoire, la température, la consommation électrique et les compteurs d’erreurs matérielles expliquent pourquoi un résultat a changé ; ils ne définissent pas la capacité utilisable. Corrélez-les à l’attente en file, au temps de synthèse, au premier audio lisible, à la complétion et aux échecs. La documentation du Data Center GPU Manager de NVIDIA décrit les fonctions de santé et de télémétrie disponibles. Notez le nom de la métrique, l’intervalle d’échantillonnage, le matériel et la version de l’exportateur plutôt que de présenter un graphique isolé de « pourcentage GPU ».

Comment traduire les résultats en répliques et en coûts ?

Pour chaque modèle et chaque mélange de charge, augmentez la charge offerte par paliers et répétez les exécutions proches de la limite. La capacité utilisable par réplique correspond au débit testé le plus élevé pour lequel tous les critères déclarés de latence, d’échec, de stabilité de file et de rétablissement sont respectés. Validez ensuite plusieurs répliques : le routage, l’affinité de connexion, la normalisation partagée, le stockage et les dépendances du plan de contrôle peuvent empêcher une mise à l’échelle linéaire.

Une première estimation de dimensionnement est :

replicas = ceiling(forecast peak offered rate / validated per-replica rate)

Ce n’est pas le nombre final de répliques à déployer. Ajoutez de la capacité pour le scénario de panne retenu, la maintenance, l’erreur de prévision et le délai de démarrage, puis réexécutez les tests sur cette topologie. La marge relève d’une décision métier et de fiabilité, pas d’un pourcentage universel. Google SRE recommande la prévision de la demande et des tests de charge réguliers pour relier les ressources brutes à la capacité de service dans ses recommandations de dimensionnement.

Ne comparez l’économie qu’à objectifs respectés identiques :

cost per delivered audio hour =
  total deployment cost during the window / successful playable audio hours

cost per 1,000 completed interactions =
  total deployment cost during the window / completed interactions * 1,000

Incluez le calcul, les répliques inactives, l’orchestration, les licences et les coûts réseau imputables. Le travail échoué, rejeté et annulé reste au numérateur, afin que le gaspillage ne soit pas masqué. Publiez le taux d’utilisation et la date des tarifs. Un résultat de saturation moins cher qui manque l’objectif de latence ne constitue pas un système utilisable moins cher.

Que doit contenir un rapport de capacité reproductible ?

Un rapport doit fournir le manifeste de charge et l’empreinte du corpus ; la révision et la topologie du générateur de charge ; les régions client et serveur ; la source d’horloge ; les versions de modèle, de voix, de normalisation et de service ; le matériel, le pilote et le mode d’alimentation ; la configuration des répliques, du traitement par lots et des files ; les fenêtres de préchauffage et de mesure ; les distributions de latence brutes ou fusionnables ; le travail offert, admis, rejeté et achevé ; la durée de l’audio produit ; chaque classe d’échec et d’annulation ; les traces de ressources ; ainsi que la chronologie de saturation et de rétablissement.

Terminez par des décisions, pas par des adjectifs : la charge validée, le critère non respecté, le nombre de répliques retenu, la réserve de panne, les bornes de mise à l’échelle automatique et le déclencheur d’une nouvelle campagne. Les recommandations SRE de Google sur les objectifs de niveau de service constituent un cadre utile pour dériver ces critères des attentes des utilisateurs.

Pour un KugelAudio opéré par le client, le guide de déploiement auto-hébergé documente la livraison sur Kubernetes au moyen d’un chart Helm. Il ne publie pas de garantie reliant le matériel à un nombre d’appels simultanés. Dimensionnez le modèle, le matériel et la charge retenus avec la méthode ci-dessus.

Quelles sont les limites de ce guide ?

Cet article n’évalue les performances d’aucun GPU, modèle, voix ou déploiement nommé. Il ne prescrit pas non plus de cible de latence conversationnelle, de taille de file ou de marge de sécurité. Ces décisions dépendent du flux d’appel, des attentes des utilisateurs, de la variation du trafic, de la politique de gestion des pannes et des preuves produites par le système réel.

FAQ

Le délai avant le premier octet équivaut-il au délai avant le premier audio lisible ?

Non. Le premier octet peut être un en-tête ou une trame partielle. Le premier audio lisible est le moment où le client dispose d’un audio décodé valide et d’un tampon suffisant pour démarrer la lecture selon la politique de lecteur déclarée.

Pourquoi la latence moyenne est-elle insuffisante ?

Une moyenne masque la distribution et ne dit rien des échecs. Publiez le nombre d’observations, les percentiles retenus, le taux de respect du seuil, les erreurs, les expirations, les rejets et les annulations sur la même fenêtre de mesure.

Combien d’appels un GPU peut-il traiter ?

Seul un banc d’essai correspondant peut y répondre. Le modèle, le matériel, la version du service, la longueur des textes et la durée de l’audio, le comportement en diffusion continue, le mélange de charge et l’objectif de latence modifient tous la simultanéité utilisable.

Un RTF inférieur à un suffit-il pour un agent vocal en temps réel ?

Non. Il montre que l’intervalle de synthèse mesuré était plus court que la durée de l’audio généré. Il n’établit ni le premier audio lisible, ni le délai en file, ni la latence de queue, ni le comportement à l’annulation, ni la capacité multiflux.

L’utilisation GPU doit-elle déclencher la mise à l’échelle automatique ?

Uniquement si les tests montrent qu’elle anticipe assez tôt la pression subie par les utilisateurs. Comparez-la à l’âge de la file, à la génération active, au taux d’admission, à la latence perçue et au temps réellement nécessaire pour qu’une nouvelle réplique soit prête.

Que doit-il se passer lorsque la capacité est épuisée ?

Cessez d’admettre le travail qui ne peut pas respecter son délai, émettez une issue de saturation explicite et déclenchez le repli éprouvé. Ne dissimulez pas la demande excédentaire dans une file non bornée ou une boucle de reprise immédiate.

À quelle fréquence faut-il répéter les tests de capacité ?

Répétez-les après tout changement significatif de modèle, d’environnement d’exécution, de pilote, de matériel, de normalisation, de routage, de politique de mise à l’échelle automatique ou de charge. Réexécutez-les également avant de prendre ou de renouveler un engagement de capacité en production.