Jak dobrać autoskalowanie TTS w SageMaker z pomiarów

Progi autoskalowania endpointu TTS warto wyprowadzić z pomiarów jego współbieżności i czasu skalowania, a nie przenosić z innego modelu. AWS pokazuje tę metodę na przykładzie Kokoro-82M działającego w ml.g5.xlarge na Amazon SageMaker AI: przy wybranym celu p95 TTFAB równym 3000 ms granicą Q_max było 50 równoczesnych żądań na instancję.

Co trzeba przygotować

Przykład AWS dotyczy własnego kontenera z modelem Kokoro-82M na endpoincie czasu rzeczywistego. Q_max oznacza najwyższą współbieżność na jednej instancji, przy której 95. percentyl czasu do pierwszego bajtu dźwięku, czyli p95 TTFAB, pozostaje w wybranym celu poziomu usług (SLO). Drugim pomiarem jest T_total, czyli czas od zażądania dodatkowej pojemności do przywrócenia obsługi ruchu.

Do wdrożenia AWS wymienia uprawnienia do tworzenia zasobów IAM, S3, ECR i SageMaker, AWS CDK v2 zainicjalizowany na docelowym koncie i w regionie, Python 3.11 lub nowszy, uv, Docker oraz wolny limit co najmniej jednej instancji ml.g5.xlarge ponad bazową pulę. Trzy stosy CDK uruchamia się w kolejności: SpeechFoundationStack tworzy role i zasobnik S3 na wagi modelu, SpeechModelCacheStack kopiuje wagi, a SpeechEndpointStack buduje kontener i tworzy endpoint.

Repozytorium AWS Samples określa rozwiązanie jako proof-of-value, a nie gotową implementację produkcyjną. Przypina torch==2.6.0, wersję objętą ostrzeżeniem PYSEC-2026-2286 dotyczącym błędu pamięci w mechanizmie weights_only podczas wczytywania złośliwie przygotowanego checkpointu. Repozytorium wskazuje torch 2.10.0 jako wersję z poprawką. Opisuje też przypięcie rewizji Kokoro-82M do konkretnego SHA z Hugging Face jako ograniczenie drogi ataku; to wyjaśnienie repozytorium, nie niezależny audyt bezpieczeństwa.

Pięć kroków pomiaru i konfiguracji

1. Sprawdź rozbieżności poleceniem drift

Najpierw porównaj stan wdrożonych celów skalowania, polityk i alarmów z konfiguracją:

uv run tts-bench drift

To polecenie tylko odczytuje stan. Zatrzymany lub anulowany pomiar qmax albo ttotal może pozostawić skalowanie zamrożone na jednej instancji. Jeśli kontrola wykryje taki stan, AWS podaje polecenie przywracające politykę:

uv run tts-bench thaw --endpoint speech-kokoro-82m

Przed dalszymi pomiarami ponownie sprawdź stan endpointu.

2. Zmierz Q_max na jednej instancji

Testuj stałe poziomy współbieżności, zwiększając je po kolejnych szczeblach, aż p95 TTFAB przekroczy SLO. AWS używa zamkniętej pętli obciążenia, która utrzymuje zadaną liczbę równoczesnych żądań.

Najpierw można oszacować harmonogram bez wywołań AWS, a następnie uruchomić właściwy pomiar:

uv run tts-bench qmax --model kokoro-82m --dry-run
uv run tts-bench qmax --model kokoro-82m

AWS szacuje, że właściwy pomiar trwa około 36 minut. Podczas niego autoskalowanie jest zamrożone, a pojemność ograniczona do jednej instancji; narzędzie przywraca ją po zakończeniu. W przykładzie AWS wybrał SLO 3000 ms dla p95 TTFAB. Wyniki dla Kokoro-82M na ml.g5.xlarge były następujące:

W tym teście Q_max wyniosło 50: przy 50 żądaniach p95 pozostawał poniżej celu, a przy 60 go przekraczał. Są to wyniki podane przez AWS dla tej konfiguracji, a nie uniwersalny limit SageMaker.

3. Zmierz T_total po uzyskaniu wyniku qmax

Wymuś skalowanie i zmierz czas do powrotu obsługi ruchu. Polecenie ttotal wymaga artefaktu z pomiaru qmax:

uv run tts-bench ttotal --model kokoro-82m --qmax <qmax-artifact>

AWS szacuje, że ten pomiar może potrwać do 28 minut. W opisanym przykładzie wymuszone skalowanie zajęło według AWS 260,2 sekundy. Do planowania dodano 60 sekund ograniczonego, lecz niezmierzonego opóźnienia wykrycia polityki, co dało T_total równy 320,2 sekundy.

Osiem opublikowanych czasów etapów wynosi: 30,0, 180,8, 3,7, 0,0, 6,5, 1,0, 20,7 i 47,4 sekundy. Ich suma to 290,1 sekundy, czyli o 29,9 sekundy więcej niż podany pomiar 260,2 sekundy. Tych etapów nie da się więc przedstawić jako uzgodnionego rozbicia tego wyniku.

4. Wylicz progi poleceniem plan

Przekaż oba artefakty pomiarowe oraz wartości potrzebne do oszacowania puli instancji:

uv run tts-bench plan --qmax <qmax-artifact> --ttotal <ttotal-artifact> --peak-rps 5000

W przykładzie AWS przyjął szczyt 5000 żądań na sekundę i dolny poziom 10. Te założenia służą do wyznaczenia liczby instancji. Progi skalowania wynikają z Q_max=50 oraz wybranego przez operatora współczynnika nagłego wzrostu ruchu 1,25×. Dla h = 1,25 − 1 = 0,25 obliczenia są następujące:

• próg skalowania w górę: (1 − h) × 50 = 37,5 żądania;
• próg skalowania w dół: (1 − 2h) × 50 = 25 żądań.

W przykładowej konfiguracji AWS ustawił minimum jednej i maksimum dziewięciu instancji ml.g5.xlarge, 30-sekundowy cooldown skalowania w górę, 960-sekundowy cooldown skalowania w dół oraz limit kolejki 50. Są to ustawienia tego przykładu, nie domyślne wartości SageMaker. Samo plan nie zmienia zasobów AWS.

Próg skalowania w dół wymaga osobnej uwagi: według analizy AWS zmniejszenie puli z dwóch instancji do jednej może obciążyć pozostałą instancję do poziomu Q_max i ponownie uruchomić presję na skalowanie w górę. Minimalna pula trzech instancji eliminuje tę konkretną niestabilność w opisanym wyliczeniu, ale utrzymuje więcej pojemności przy mniejszym ruchu.

Limit kolejki działa niezależnie od autoskalowania. Kontener odrzuca żądanie po przekroczeniu skonfigurowanej głębokości kolejki, zwracając HTTP 503 queue_saturated; nie dodaje w ten sposób instancji.

5. Porównaj wdrożenie z planem poleceniem validate

Na końcu sprawdź, czy aktywna polityka odpowiada wyliczonym wartościom:

uv run tts-bench validate --model kokoro-82m --plan <plan-artifact>

validate porównuje wdrożony próg skalowania w górę, próg skalowania w dół i oba cooldowny z artefaktem plan. Wraz z drift jest poleceniem tylko do odczytu.

Usuwanie zasobów

Po zakończeniu pracy AWS podaje polecenie usuwające endpoint i powiązane zasoby autoskalowania oraz CloudWatch:

uv run speech-infra destroy kokoro-82m

Polecenie nie usuwa współdzielonego zasobnika S3 z wagami ani repozytorium ECR z obrazem kontenera. Jeśli nie są już potrzebne, trzeba usunąć je osobno.