Pour calibrer l’auto-scaling d’un endpoint TTS sur SageMaker, mesurez d’abord la concurrence maximale qu’une instance peut absorber, puis le temps nécessaire pour ajouter une instance. Dans son tutoriel publié le 22 octobre 2026, AWS applique cette méthode à Kokoro-82M sur une instance ml.g5.xlarge, avec un objectif de latence choisi de 3 000 ms au 95e percentile. AWS rapporte un plafond Q_max de 50 requêtes simultanées par instance : à 60, le délai jusqu’au premier octet audio dépasse l’objectif.

Les mesures qui déterminent les seuils

Q_max désigne la concurrence maximale par instance qui respecte l’objectif de niveau de service (SLO) choisi. Pour un service de synthèse vocale, AWS mesure le délai avant le premier octet audio, ou TTFAB, au 95e percentile (p95). Ce seuil dépend donc du modèle, de l’instance et du SLO retenu, pas d’une valeur universelle pour SageMaker.

La politique de l’exemple s’appuie sur ConcurrentRequestsPerModel, une métrique publiée par SageMaker. AWS la rapporte comme une statistique Maximum sur une fenêtre de 10 secondes. L’outil de test compare cette métrique à la concurrence mesurée côté client; le rapport entre les deux vaut 1,0 à chacun des paliers testés pour Kokoro-82M. Cette correspondance permet d’utiliser directement le seuil mesuré dans l’exemple.

Préparer l’endpoint et les outils

Il faut un compte AWS autorisé à créer des rôles IAM, des compartiments S3, des dépôts ECR et des ressources SageMaker. AWS demande aussi AWS CDK v2 installé et initialisé dans le compte et la région visés, Python 3.11 ou ultérieur, uv, Docker et une place disponible dans le quota ml.g5.xlarge pour le test de montée en capacité.

Le déploiement de l’exemple crée trois piles CDK dans cet ordre : SpeechFoundationStack prépare les rôles et le compartiment S3 des poids du modèle; SpeechModelCacheStack synchronise ces poids; SpeechEndpointStack construit le conteneur et crée l’endpoint. La commande de déploiement est uv run speech-infra deploy kokoro-82m. La pile de l’endpoint ne crée les ressources d’auto-scaling et d’observabilité que si l’auto-scaling est activé et qu’un plan mesuré réalisable existe.

AWS Samples présente le dépôt comme une démonstration de faisabilité, pas comme une implémentation prête pour la production. Le conteneur épingle torch==2.6.0, que le dépôt associe à l’avis PYSEC-2026-2286, une vulnérabilité de corruption mémoire dans le chargeur weights_only de PyTorch, déclenchable par un fichier de checkpoint malveillant. AWS Samples indique qu’un correctif est disponible dans torch 2.10.0, version que le dépôt n’avait pas adoptée. Le dépôt précise également que la révision du modèle Kokoro est épinglée à un commit Hugging Face précis et que l’exploitation nécessiterait, selon lui, la compromission de cette révision.

Exécuter les cinq étapes dans l’ordre

  1. Vérifiez l’état de l’endpoint avec drift. Lancez uv run tts-bench drift avant les mesures. Cette commande, en lecture seule, compare les ressources de mise à l’échelle déployées à la configuration attendue. Un résultat propre autorise la suite. Si un ancien test interrompu a laissé l’auto-scaling gelé, AWS indique d’exécuter uv run tts-bench thaw --endpoint speech-kokoro-82m avant de continuer.
  2. Mesurez Q_max avec qmax. Lancez d’abord uv run tts-bench qmax --model kokoro-82m --dry-run pour afficher le programme du test sans appel à AWS. Le test réel, uv run tts-bench qmax --model kokoro-82m, prend environ 36 minutes. Il maintient une concurrence fixe à chaque palier, puis l’augmente jusqu’à ce que le SLO soit dépassé. Pendant la mesure, l’auto-scaling est gelé et la capacité est fixée à une instance; le réglage est rétabli à la fin de la commande.AWS rapporte les résultats suivants pour Kokoro-82M sur ml.g5.xlarge, avec un SLO de 3 000 ms au p95 :Concurrence par instanceTTFAB au p95 (ms)SLO de 3 000 ms respecté ?165,4Oui5286,2Oui10568,5Oui201 129,3Oui301 689,8Oui402 245,0Oui502 805,7Oui, Q_max603 374,8NonLe palier à 50 respecte l’objectif et celui à 60 le dépasse : AWS retient donc Q_max=50 pour cet endpoint. La valeur ne se transpose pas automatiquement à un autre modèle ou à un autre type d’instance.
  3. Mesurez le temps de montée en capacité avec ttotal. Cette mesure force l’ajout d’une instance et calcule le temps écoulé jusqu’au retour d’un trafic sain. La commande ttotal doit recevoir l’artefact produit par qmax, car elle s’appuie sur ses paliers pour évaluer la reprise. AWS estime cette mesure à 28 minutes au maximum.AWS indique un total mesuré de 260,2 secondes, puis ajoute 60 secondes de délai de détection de la politique, borné mais non mesuré pendant cet essai, pour planifier sur 320,2 secondes. Les huit durées détaillées dans le tutoriel totalisent pourtant 290,1 secondes : 30,0 + 180,8 + 3,7 + 0,0 + 6,5 + 1,0 + 20,7 + 47,4. Cette somme dépasse de 29,9 secondes le total mesuré annoncé. Le récapitulatif d’AWS Samples donne une ventilation différente et un total arrondi d’environ 260 secondes, sans expliquer cet écart.
  4. Calculez les seuils avec plan. Cette commande, qui ne modifie pas l’endpoint, combine les artefacts qmax et ttotal avec les paramètres choisis par l’opérateur. Dans l’exemple, AWS utilise un SLO de 3 000 ms au p95, un ratio de pointe de 1,25 et des hypothèses de débit de 10 requêtes par seconde au creux et de 5 000 au pic. Le ratio de 1,25 correspond à une hausse de trafic de 25 % pendant un cycle de montée en capacité.Avec Q_max=50, AWS pose h=1,25−1=0,25. Le seuil de montée en capacité est (1−h)×Q_max, soit 37,5 requêtes simultanées. Le seuil de réduction de capacité est (1−2h)×Q_max, soit 25. Les deux artefacts doivent correspondre à la même configuration; ttotal et plan refusent par défaut les empreintes incompatibles.Paramètre de l’exempleValeurSeuil de montée en capacité37,5 requêtes simultanéesSeuil de réduction de capacité25 requêtes simultanéesNombre minimal et maximal d’instances1 et 9Délai de refroidissement après montée en capacité30 secondesDélai de refroidissement après réduction de capacité960 secondesProfondeur maximale de la file d’attente50 requêtesAWS explique que réduire une flotte de deux instances à une seule peut ramener l’instance restante à Q_max et provoquer une nouvelle montée en capacité. Dans son analyse, un minimum de trois instances évite ce cas précis, au prix du maintien d’une capacité plus importante lorsque le trafic est faible. Le conteneur applique séparément sa limite de file : au-delà de 50 requêtes, il refuse la demande avec la réponse HTTP 503 queue_saturated.
  5. Vérifiez la politique déployée avec validate. Cette commande compare la politique active à l’artefact plan, notamment les seuils et les délais de refroidissement. Un résultat sans écart confirme que les valeurs déployées correspondent au plan calculé.

Nettoyer les ressources après les essais

La commande uv run speech-infra destroy kokoro-82m retire le modèle, l’endpoint et les ressources d’auto-scaling et de CloudWatch qui lui sont attachées. Elle ne vide pas le compartiment S3 des poids ni ne supprime le dépôt ECR de l’image, car ces ressources peuvent être partagées entre plusieurs modèles; leur suppression, si elles ne sont plus utilisées, se fait séparément.