AWS SageMaker: TTS-Autoscaling aus Messwerten ableiten

Um das Auto Scaling eines Echtzeit-TTS-Endpunkts auf Amazon SageMaker AI sinnvoll einzustellen, messen Sie zuerst die tragbare Anfrage-Konkurrenz pro Instanz und die Zeit bis zur verfügbaren Zusatzkapazität. AWS berichtet diese Werte für Kokoro-82M auf ml.g5.xlarge bei einem selbst gewählten p95-Ziel von 3.000 ms. Sie sind ein Beispiel für dieses Modell und diese Konfiguration, keine SageMaker-Standardwerte.

Was Sie für den Messlauf benötigen

Sie brauchen ein AWS-Konto mit Berechtigungen für IAM-Rollen, S3-Buckets, ECR-Repositories und SageMaker-Ressourcen. Installieren und bootstrappen Sie AWS CDK v2 in Zielkonto und Zielregion. Außerdem nennt AWS Python 3.11 oder höher, uv, Docker und mindestens einen freien ml.g5.xlarge-Quota-Platz oberhalb des bereits genutzten Bestands als Voraussetzungen.

Das Beispiel legt die Umgebung in drei voneinander abhängigen CDK-Stacks an: SpeechFoundationStack richtet Rollen und einen S3-Bucket für Modellgewichte ein. SpeechModelCacheStack synchronisiert die Hugging-Face-Gewichte in diesen Bucket. SpeechEndpointStack baut das Container-Image, überträgt es zu ECR und erstellt SageMaker-Modell, Endpoint-Konfiguration und Endpoint. Der gemeinsame Einstieg lautet uv run speech-infra deploy kokoro-82m.

Der Endpoint-Stack erzeugt Auto-Scaling- und Observability-Ressourcen nur, wenn Auto Scaling aktiviert ist und ein durch Messungen gestützter, umsetzbarer Plan vorliegt. So kann eine bloß konfigurierte, aber nicht vermessene Skalierungspolitik diese Prüfung nicht passieren.

AWS beziffert den Live-Lauf für qmax auf ungefähr 36 Minuten und den Lauf für ttotal auf bis zu 28 Minuten. Beide beeinflussen den Zustand des laufenden Endpoints. drift, plan und validate sind dagegen Leseoperationen.

Fünf Schritte vom Zustandstest zur geprüften Policy

1. Mit drift den Ausgangszustand prüfen. Der Befehl vergleicht unter anderem bereitgestellte Skalierungsziele, Policies und Alarmzustände mit der Konfiguration. Ein sauberer Abgleich gibt den Messlauf frei. So verändert eine verwaiste Policy oder ein vorher abgebrochener Lauf nicht unbemerkt die Kapazität während der Messung.
2. Mit qmax die Concurrency-Grenze ermitteln. Concurrency bezeichnet hier die Zahl gleichzeitiger Anfragen, die auf einer Instanz warten oder ausgeführt werden. AWS verwendet eine geschlossene Lasttreppe: Der Test hält eine feste Zahl von Anfragen und erhöht sie stufenweise, bis das Latenzziel verfehlt wird. Dadurch kann eine langsamer werdende Instanz die Messung nicht dadurch beschönigen, dass ein Test mit festem Ankunftstakt selbst weniger Anfragen sendet. Für einen Probelauf ohne AWS-Aufrufe nennt AWS uv run tts-bench qmax --model kokoro-82m --dry-run; der Live-Lauf folgt mit uv run tts-bench qmax --model kokoro-82m. Währenddessen wird Auto Scaling eingefroren und die Kapazität auf eine Instanz gesetzt. AWS zufolge wird der vorherige Zustand beim regulären Ende wiederhergestellt.
3. Mit ttotal die Bereitstellung zusätzlicher Kapazität messen. T_total bezeichnet die Zeit vom Anfordern einer weiteren Instanz bis zu dem Punkt, an dem sie gesunden Traffic bedient. Der Lauf erzwingt eine Skalierung und umgeht dabei die Erkennung durch die aktive Policy. Er benötigt das Ergebnis des vorherigen qmax-Laufs; die Messungen müssen außerdem denselben Übertragungsweg verwenden. AWS berichtet für den Kokoro-Lauf 260,2 Sekunden gemessene Zeit. Die acht einzeln aufgeführten Phasen dauern 30,0, 180,8, 3,7, 0,0, 6,5, 1,0, 20,7 und 47,4 Sekunden. Zusammen ergeben sie 290,1 Sekunden, also 29,9 Sekunden mehr als der angegebene Messwert. Ein AWS-Samples-Beispiel fasst die Phasen anders zusammen und rundet die Messung auf etwa 260 Sekunden, löst die Abweichung aber nicht auf.
4. Mit plan aus Messwerten Schwellen berechnen. Der lesende Befehl verwendet die qmax- und ttotal-Ergebnisse sowie gewählte Planungswerte. Für den AWS-Beispiellauf sind das ein p95-Ziel von 3.000 ms und ein Surge-Faktor von 1,25. AWS addiert zu den gemessenen 260,2 Sekunden einen begrenzten, aber nicht gemessenen Puffer von 60 Sekunden für die Policy-Erkennung. Der Planungswert beträgt damit 320,2 Sekunden. Die Berechnung der Schwellen lautet C_scale_max = 0,75 × Q_max und C_scale_min = 0,50 × Q_max. Bei Q_max = 50 folgen daraus 37,5 gleichzeitige Anfragen zum Hochskalieren und 25 zum Herunterskalieren.
5. Mit validate die bereitgestellte Policy abgleichen. Der letzte Befehl vergleicht die tatsächlich eingerichteten Schwellen und Cooldowns mit dem Plan-Artefakt. Erst wenn beide übereinstimmen, entspricht die aktive Konfiguration den berechneten Einstellungen.

Die gemessene Q_max-Treppe des AWS-Beispiels

AWS definiert Q_max als die höchste Zahl gleichzeitiger Anfragen pro Instanz, bei der das gewählte p95-Ziel noch eingehalten wird. p95 bedeutet, dass 95 Prozent der gemessenen Antwortzeiten unter dem angegebenen Wert liegen. TTFAB ist die Zeit bis zum ersten Audiobyte; das SLO ist das festgelegte Service-Level-Ziel. Für Kokoro-82M auf ml.g5.xlarge lag dieses Ziel bei 3.000 ms.

Damit liegt Q_max in diesem Lauf bei 50: Bei 50 Anfragen bleibt p95-TTFAB mit 2.805,7 ms unter dem Ziel, bei 60 überschreitet sie es mit 3.374,8 ms. AWS meldet für denselben Lauf außerdem eine mittlere Antwortzeit ohne Warteschlange von 61,3 ms und einen p95-Wert von 66,1 ms.

Als Skalierungssignal verwendet das Beispiel ConcurrentRequestsPerModel, eine von SageMaker veröffentlichte Metrik, die als Maximum über ein Zehn-Sekunden-Fenster ausgewiesen wird. Der Benchmark vergleicht sie mit der vom Client gemessenen Concurrency. AWS berichtet für jede geprüfte Stufe ein Verhältnis von 1,0 zwischen beiden Werten. Dieses Verhältnis ist Teil des Kokoro-Beispiellaufs.

Schwellen, Cooldowns und Warteschlangen im Beispiel

Mit Q_max = 50 und dem gewählten Surge-Faktor von 1,25 setzt AWS den Schwellenwert zum Hochskalieren auf 37,5 und den zum Herunterskalieren auf 25 gleichzeitige Anfragen. Die Beispielkonfiguration verwendet außerdem ml.g5.xlarge, mindestens eine und höchstens neun Instanzen, einen Cooldown von 30 Sekunden fürs Hochskalieren und 960 Sekunden fürs Herunterskalieren sowie queue_max_depth=50. Die Flottengröße beruht auf den Annahmen von 10 Anfragen pro Sekunde im Tal und 5.000 pro Sekunde an der Spitze.

Die unterschiedliche Wartezeit berücksichtigt, dass eine entfernte Instanz bei erneut steigendem Bedarf nicht sofort ersetzt ist. AWS’ Analyse zeigt außerdem: Wird eine Flotte von zwei Instanzen auf eine verkleinert, kann die verbleibende Instanz wieder Q_max erreichen. Eine Mindestgröße von drei verhindert genau diesen beschriebenen Rückfall, hält aber mehr Kapazität bereit.

Die Warteschlangenbegrenzung ist eine separate Schutzmaßnahme und ersetzt Auto Scaling nicht. Im Beispiel weist das Container-Gate Anfragen oberhalb der Tiefe 50 mit HTTP 503 und queue_saturated zurück. So werden sie nicht unbegrenzt auf eine Instanz gelegt, deren gemessene Grenze bereits erreicht ist.

Unterbrechungen, Sicherheitsstand und Aufräumen

Ein abgebrochener qmax- oder ttotal-Lauf kann Auto Scaling eingefroren lassen. Meldet drift danach eine Abweichung, nennt AWS uv run tts-bench thaw --endpoint speech-kokoro-82m zur Wiederherstellung der Policy, bevor weitere Messungen beginnen.

AWS Samples bezeichnet das Repository als Proof of Value, nicht als produktionsreife Implementierung. Das Repository nennt die festgelegte Abhängigkeit torch==2.6.0 und den Hinweis PYSEC-2026-2286 zu einer Speicherbeschädigung im weights_only-Unpickler. Als Version mit Fehlerbehebung wird PyTorch 2.10.0 genannt; das Repository hat diese Version selbst nicht übernommen. Laut AWS Samples ist die Kokoro-Modellrevision auf einen konkreten Hugging-Face-Commit festgelegt. Das Repository beschreibt diese Bindung als Begrenzung des Angriffswegs: Dafür müsste die festgelegte Upstream-Revision kompromittiert sein. Wer ein anderes Modell oder Checkpoint einsetzt, ändert diese Voraussetzung.

Zum Entfernen der Beispielressourcen nennt AWS uv run speech-infra destroy kokoro-82m. Dieser Befehl löscht SageMaker-Modell, Endpoint-Konfiguration und Endpoint sowie angehängte Auto-Scaling- und CloudWatch-Ressourcen. Der S3-Bucket mit den Modellgewichten und das ECR-Repository mit dem Container-Image können von mehreren Modellen genutzt werden und bleiben bestehen; wenn sie nicht mehr gebraucht werden, müssen sie separat geleert beziehungsweise gelöscht werden.