Como medir o autoescalonamento de TTS no SageMaker

Para dimensionar o autoescalonamento de um endpoint de texto para fala (TTS), meça primeiro quantas solicitações simultâneas cada instância atende dentro do seu objetivo de latência e quanto tempo o endpoint leva para ampliar a capacidade. No exemplo da AWS com Kokoro-82M e uma instância ml.g5.xlarge, o limite medido foi de 50 solicitações simultâneas por instância para um objetivo de 3.000 ms no percentil 95 do tempo até o primeiro byte de áudio (TTFAB). Esses números descrevem aquele teste, não um padrão para outros modelos ou endpoints.

Meça a concorrência que atende ao objetivo de latência

A métrica nativa ConcurrentRequestsPerModel acompanha as solicitações simultâneas por modelo. A AWS descreve seu valor como o máximo observado em uma janela de 10 segundos. No teste com Kokoro-82M, a AWS relata que a leitura do cliente de benchmark e a métrica do CloudWatch tiveram uma proporção de 1,0 em cada nível testado.

Q_max é a maior concorrência por instância que atende ao objetivo escolhido para o percentil 95 do TTFAB. Para o objetivo de 3.000 ms usado pela AWS, 50 solicitações ficaram abaixo do limite; 60 ultrapassaram esse valor.

A tabela resume os dois níveis que delimitam o Q_max informado pela AWS para Kokoro-82M em uma ml.g5.xlarge. O limite é útil para calcular uma política a partir da capacidade observada; a medição precisa ser refeita para as condições do endpoint que você pretende dimensionar.

Prepare as permissões, as ferramentas e o endpoint

O procedimento da AWS requer permissões para IAM, S3, ECR e SageMaker, AWS CDK v2 inicializado na conta e na região de destino, Python 3.11 ou posterior, uv, Docker e cota disponível para uma instância ml.g5.xlarge. A AWS estima cerca de 36 minutos para a medição qmax e até 28 minutos para ttotal.

A implantação usa três pilhas do AWS CDK em sequência: SpeechFoundationStack cria funções do IAM e um bucket S3 para os pesos do modelo; SpeechModelCacheStack sincroniza os pesos; e SpeechEndpointStack cria os recursos do endpoint. A pilha do endpoint só prepara recursos de escalabilidade automática e observabilidade quando essa opção está ativada e existe um plano viável derivado das medições.

O repositório AWS Samples descreve a implementação como uma prova de valor, não como pronta para produção. Ele informa que a dependência fixada torch==2.6.0 é afetada pelo alerta PYSEC-2026-2286, relacionado a corrupção de memória no unpickler weights_only diante de um checkpoint malicioso, e aponta torch 2.10.0 como versão corrigida. O repositório também diz que a revisão do modelo Kokoro está fixada a um commit específico do Hugging Face e que, segundo sua descrição, o caminho de ataque dependeria do comprometimento dessa revisão upstream.

Execute as cinco etapas na ordem certa

1. Compare a implantação com a configuração usando drift. Essa etapa, somente de leitura, verifica se os recursos de escalabilidade implantados correspondem à configuração esperada. Comece por ela antes de alterar o estado do endpoint.
2. Meça o limite de concorrência com qmax. A etapa mantém uma instância e testa níveis crescentes de concorrência em ciclo fechado para encontrar o Q_max que atende ao objetivo de latência. Ela afeta o estado ativo do endpoint.
3. Meça o tempo de ampliação com ttotal. Depois de obter o resultado de qmax, force uma ampliação e meça a recuperação da capacidade. Essa etapa também afeta o estado ativo e depende do artefato produzido por qmax.
4. Calcule a política com plan. Use os artefatos de qmax e ttotal para calcular os limites e demais parâmetros da política. Essa etapa é somente de leitura.
5. Confira a implantação com validate. Compare a política aplicada ao endpoint com o artefato gerado por plan. Essa etapa também é somente de leitura.

Se uma medição qmax ou ttotal for interrompida, a AWS alerta que a escalabilidade pode ficar congelada. O tutorial inclui uma verificação de desvio e o comando thaw para recuperar o estado antes de iniciar outra medição.

Calcule os limites a partir do resultado medido

No exemplo da AWS, a entrada escolhida para o planejamento foi uma proporção de surto de 1,25×, aplicada a Q_max=50. O cálculo resultou em um limite de 37,5 solicitações simultâneas para ampliar a capacidade e 25 para reduzi-la: (1 − 0,25) × 50 = 37,5 e (1 − 0,50) × 50 = 25.

A configuração ilustrativa usa uma ml.g5.xlarge, mínimo de uma instância, máximo de nove, intervalo de 30 segundos para ampliar a capacidade, intervalo de 960 segundos para reduzi-la e limite de fila de 50. São escolhas do exemplo da AWS, não valores padrão do SageMaker.

A AWS relata uma ampliação forçada de 260,2 segundos. Para o planejamento, acrescenta 60 segundos de atraso limitado na detecção da política, que não foram medidos nesse teste, chegando a 320,2 segundos. Esse total planejado, portanto, combina o tempo medido com a margem de detecção.

As oito durações de etapa publicadas pela AWS somam 290,1 segundos: 30,0 + 180,8 + 3,7 + 0,0 + 6,5 + 1,0 + 20,7 + 47,4. A soma fica 29,9 segundos acima dos 260,2 segundos informados como tempo medido. A documentação do exemplo da AWS Samples apresenta os tempos agrupados de outra forma, mas não explica essa diferença.

Evite reduzir capacidade até recriar a saturação

A análise da AWS alerta que reduzir uma frota de duas instâncias para uma pode deixar a instância restante novamente em Q_max e pressionar a política a ampliar a capacidade outra vez. No cálculo descrito, manter pelo menos três instâncias evita essa situação específica, mas conserva mais capacidade provisionada.

O controle de admissão do contêiner é separado do autoescalonamento: quando a fila ultrapassa o limite configurado, o exemplo retorna HTTP 503 com o código queue_saturated, em vez de aceitar mais solicitações. O contêiner também oferece transmissão da resposta e transmissão bidirecional por sessão.