Arrêtez de deviner les cibles d'auto scaling pour la synthèse vocale (TTS) sur Amazon SageMaker AI
Un pic de trafic frappe un point de terminaison de synthèse vocale (TTS) auto-hébergé, les requêtes s'accumulent et la latence dépasse l'objectif de niveau de service (SLO) au moment où le plus d'utilisateurs écoutent. La politique de mise à l'échelle automatique censée l'éviter reposait sur une valeur cible devinée. Trop prudente, elle laisse des instances GPU largement inactives, un coût qui s'accumule sur chaque facture sans déclencher d'alerte. Trop agressive, elle laisse chaque instance traiter plus de requêtes simultanées qu'elle ne peut en servir dans les délais promis, un risque invisible jusqu'au prochain pic. AWS propose d'y remédier en déployant Kokoro-82M, un modèle TTS de 82 millions de paramètres, dans un conteneur personnalisé sur un point de terminaison temps réel Amazon SageMaker AI, via des stacks AWS CDK. Deux mesures réalisées sur le point de terminaison en production remplacent l'intuition : Qmax, la concurrence maximale qu'une instance soutient sans enfreindre le SLO, et Ttotal, la durée complète d'une montée en charge. Le seuil de montée en charge, le seuil de réduction et les deux délais de refroidissement en découlent par simple calcul. Tous les chiffres proviennent d'un déploiement réel du dépôt aws-samples associé.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Cette approche compte parce que les indications publiques sur la mise à l'échelle de SageMaker visent surtout les appels synchrones courts ou le service de grands modèles de langage, où la métrique naturelle est le nombre de jetons générés par seconde. La synthèse vocale ne correspond à aucun de ces schémas : une requête garde une connexion ouverte plusieurs secondes, sans boucle de génération de jetons à instrumenter. Kokoro-82M, dérivé de StyleTTS2 avec un décodeur ISTFTNet, est non autoregressif et produit un énoncé complet en une seule passe alignée sur les durées. Ce qui détermine la surcharge d'une instance est donc simple : le nombre de requêtes en file d'attente et en cours d'exécution à l'instant présent. La politique déployée s'appuie sur ConcurrentRequestsPerModel, une métrique native publiée par SageMaker lui-même, ce qui écarte toute une classe de pannes où une métrique personnalisée semble correctement configurée alors que rien n'y est réellement publié. Pour les équipes qui exploitent des voix synthétiques sous contrainte de latence, cela permet de dimensionner la flotte selon des données plutôt que des estimations.
Cette métrique publie toutefois une statistique Maximum sur une fenêtre de 10 secondes, différente de la moyenne de requêtes en cours que mesure directement un client de test de charge. L'outillage mesure donc les deux grandeurs à chaque palier de l'échelle de concurrence, enregistre leur rapport et s'en sert pour convertir le seuil mesuré côté client en unités Amazon CloudWatch avant de l'écrire dans la configuration déployable. Pour Kokoro-82M, ce rapport s'est établi à exactement 1,0 à chaque palier, de sorte que les deux seuils coïncident. La solution fait traverser à une requête de synthèse quatre couches, du client jusqu'au modèle. Elle illustre un enjeu plus large pour l'inférence auto-hébergée : à mesure que les modèles spécialisés de petite taille se multiplient, les équipes doivent calibrer elles-mêmes l'élasticité de leurs services sur des mesures reproductibles plutôt que sur des valeurs par défaut conçues pour d'autres charges de travail.
Pas d'impact direct sur la France/UE