Bepaal de drempels voor automatisch schalen van een TTS-endpoint met metingen van gelijktijdige aanvragen en opschaaltijd. AWS’ voorbeeld voor Kokoro-82M rapporteert een maximum van 50 gelijktijdige aanvragen per instantie bij een p95-doel voor de tijd tot de eerste audio-byte (TTFAB) van 3.000 ms. Die uitkomst hoort bij een ml.g5.xlarge en is geen standaardinstelling voor andere modellen of workloads.
Wat je nodig hebt
Voor het voorbeeld noemt AWS machtigingen voor IAM, S3, ECR en SageMaker, een opgestarte AWS CDK v2-omgeving in het doelaccount en de doelregio, Python 3.11 of hoger, uv, Docker en beschikbare quota voor een ml.g5.xlarge.
De implementatie gebruikt drie AWS CDK-stacks, in deze volgorde: SpeechFoundationStack maakt de rollen en een S3-bucket voor modelgewichten aan; SpeechModelCacheStack synchroniseert de modelgewichten; SpeechEndpointStack maakt het endpoint. Die laatste stack maakt resources voor autoscaling en observability alleen aan als autoscaling is ingeschakeld en er een haalbaar meetplan beschikbaar is.
AWS schat een live qmax-meting op ongeveer 36 minuten en ttotal op maximaal ongeveer 28 minuten. Beide opdrachten beïnvloeden de toestand van het live endpoint.
Meet de capaciteit met vijf stappen
Voer de stappen in deze volgorde uit. ttotal gebruikt de meting van qmax; plan gebruikt de resultaten van beide metingen.
- Voer
driftuit. Deze controle vergelijkt de ingestelde configuratie met de uitgerolde schaalresources en is alleen-lezen. Zo zie je of de omgeving overeenkomt met de configuratie. - Voer
qmaxuit. De meting houdt één instantie aan en test een oplopend aantal gelijktijdige aanvragen. AWS gebruikt de SageMaker-metricConcurrentRequestsPerModel, die als maximum over een venster van 10 seconden wordt gerapporteerd. In de geteste stappen was de verhouding tussen de gelijktijdigheid die de benchmarkclient mat en de waarde in CloudWatch 1,0. - Voer
ttotaluit. Deze stap forceert een schaalactie en meet de tijd tot de extra capaciteit beschikbaar is. De meting volgt opqmaxen beïnvloedt, net alsqmax, het live endpoint. - Voer
planuit. Deze alleen-lezen stap berekent schaalgrenzen aan de hand van de meetresultaten en de gekozen invoerwaarden. - Voer
validateuit. Deze alleen-lezen stap vergelijkt het uitgerolde schaalbeleid met het plan.
Als een meting wordt afgebroken of geannuleerd, kan autoscaling bevroren achterblijven. AWS beschrijft thaw als herstelstap voordat je verder meet.
Kies Q_max op basis van de TTFAB-doelstelling
Q_max is het hoogste aantal gelijktijdige aanvragen per instantie waarbij de gekozen p95-doelstelling voor de tijd tot de eerste audio-byte wordt gehaald. In AWS’ test met Kokoro-82M op ml.g5.xlarge was die doelstelling 3.000 ms. Bij 50 aanvragen mat AWS een p95-TTFAB van 2.805,7 ms; bij 60 was dat 3.374,8 ms. Daarom rapporteert AWS voor deze test een Q_max van 50.
| Gelijktijdige aanvragen per instantie | p95-TTFAB (ms) | Binnen de SLO van 3.000 ms? |
| 1 | 65,4 | Ja |
| 5 | 286,2 | Ja |
| 10 | 568,5 | Ja |
| 20 | 1.129,3 | Ja |
| 30 | 1.689,8 | Ja |
| 40 | 2.245,0 | Ja |
| 50 | 2.805,7 | Ja |
| 60 | 3.374,8 | Nee |
De tabel geeft de door AWS gerapporteerde metingen voor dit model, deze instantie en deze SLO. Voor een ander endpoint moet Q_max uit de eigen meting komen, niet uit deze voorbeeldwaarde.
Houd de gemeten opschaaltijd apart van de planningsmarge
AWS rapporteert voor een geforceerde schaalactie een gemeten totale tijd van 260,2 seconden. Voor de planning telt AWS daar 60 seconden begrensde, maar niet gemeten vertraging in de beleidsdetectie bij op: samen 320,2 seconden.
De acht gepubliceerde fasetijden zijn 30,0, 180,8, 3,7, 0,0, 6,5, 1,0, 20,7 en 47,4 seconden. Opgeteld is dat 290,1 seconden, oftewel 29,9 seconden meer dan de gerapporteerde meting van 260,2 seconden.
Leid schaalgrenzen af uit Q_max
AWS gebruikt in het voorbeeld Q_max=50 en een door de operator gekozen piekfactor van 1,25×. De berekende grens voor opschalen is 37,5 gelijktijdige aanvragen; de grens voor afschalen is 25:
- Opschalen:
(1 − 0,25) × 50 = 37,5 - Afschalen:
(1 − 0,50) × 50 = 25
De voorbeeldconfiguratie gebruikt ml.g5.xlarge, minimaal één en maximaal negen instanties, een cooldown van 30 seconden voor opschalen en 960 seconden voor afschalen. De wachtrijlimiet is 50. Dit zijn instellingen uit AWS’ voorbeeld, geen SageMaker-standaarden.
AWS waarschuwt dat afschalen van twee instanties naar één de resterende instantie weer op Q_max kan brengen. Een minimum van drie instanties voorkomt die specifieke situatie in de beschreven berekening, maar houdt meer capaciteit beschikbaar. De aparte toelatingscontrole in de container weigert aanvragen zodra de wachtrijlimiet wordt overschreden, met HTTP 503 en de melding queue_saturated; dat voegt geen capaciteit toe.
Houd rekening met de status van de voorbeeldcode
AWS Samples omschrijft de implementatie als een proof of value, niet als productierijp. De repository vermeldt dat de vastgepinde afhankelijkheid torch==2.6.0 onder advies PYSEC-2026-2286 valt en noemt torch 2.10.0 als versie met een oplossing. AWS Samples beschrijft het risico als geheugenbeschadiging in de weights_only-unpickler bij een kwaadaardig checkpoint. De repository vermeldt ook dat de gebruikte Kokoro-revisie aan een exacte Hugging Face-commit is vastgepind; volgens AWS Samples zou het beschreven aanvalspad compromittering van die vastgepinde upstream-revisie vereisen.
