AssemblyAI reduz 70% do custo de inferência de fala com GPU Spot na AWS

A AssemblyAI, fornecedora de API de transcrição de fala disponível no AWS Marketplace, publicou no AWS Machine Learning Blog o desenho de arquitetura que usa para rodar inferência de deep learning em GPU a um custo sustentável. O caso interessa direto a quem fecha a fatura de computação com aceleradores: GPU On-Demand é cara, e a empresa precisava de uma forma de usar Spot sem sacrificar o SLA de clientes em setores regulados.

Em números

• 70% de economia em compute de inferência rodando em Amazon EC2 Spot comparado a instâncias On-Demand
• 4x foi o crescimento ano a ano na demanda de compute da plataforma, mantido sustentável pela arquitetura baseada em Spot
• 2 minutos é o aviso de interrupção que a AWS dá antes de reclamar uma instância Spot
• ~2 minutos é o tempo que a AssemblyAI leva para subir uma AMI customizada já com artefatos de modelo e imagem de container prontos

O problema

Inferência de speech-to-text é pesada: cada arquivo de áudio passa por um pipeline de modelos de acoustic model, language model e pós-processamento, tudo rodando em GPU NVIDIA para atender latência. Em escala, isso significa milhares de instâncias GPU ligadas o tempo todo.

Rodar esse volume inteiro em On-Demand é proibitivo financeiramente. Spot resolve o preço, mas introduz um risco operacional: a AWS pode reclamar a instância de volta com apenas 2 minutos de aviso quando a capacidade for necessária em outro lugar. Para quem desenha SLA de produção, isso é o tipo de trade-off que normalmente afasta cargas críticas do Spot.

Havia ainda uma segunda restrição, de compliance: clientes em saúde, finanças e jurídico exigem que o áudio nunca saia de fronteiras geográficas específicas. Qualquer arquitetura de custo precisava respeitar residência de dados por região, não só economizar.

A arquitetura

O desenho publicado pela AWS mostra o fluxo de ponta a ponta dentro de uma VPC distribuída em múltiplas Availability Zones:

1. O job de transcrição chega e é colocado em uma fila Amazon SQS principal, desacoplando o pedido da execução.
2. Tarefas do Amazon ECS rodando sobre instâncias GPU (identificadas no diagrama como ECS Task GPU Spot 1 e GPU Spot 2) fazem polling na fila e puxam jobs pendentes.
3. Cada tarefa busca o arquivo de áudio em um bucket Amazon S3 e executa o pipeline de inferência completo naquela instância.
4. O resultado da transcrição é gravado em um results store, de onde a AssemblyAI entrega o output ao cliente final.
5. Quando uma instância Spot recebe o aviso de interrupção, o Amazon EventBridge dispara uma função AWS Lambda, o Spot Interruption Handler.
6. O handler devolve o job em andamento para a fila SQS principal, de onde outra tarefa ECS saudável, possivelmente em outro tipo de instância ou outra Availability Zone, assume o trabalho.
7. Jobs que esgotam as tentativas de retry são roteados para uma Dead Letter Queue separada, para investigação manual.
8. O Amazon CloudWatch monitora a saúde da frota e os eventos de interrupção Spot, dando observabilidade ao conjunto.

O ponto central do desenho é que nenhuma etapa depende de uma instância específica sobreviver até o fim: o job só é considerado perdido se sair da fila sem completar, e isso só acontece depois de esgotar retries.

Os serviços envolvidos

A arquitetura combina um número pequeno de serviços gerenciados, cada um resolvendo uma parte específica do problema:

As três famílias de GPU cobrem perfis de carga diferentes: g4dn com NVIDIA T4 é a base custo-efetiva para reconhecimento de fala padrão, g5 com NVIDIA A10G entrega mais throughput para arquiteturas de modelo mais exigentes, e g6 com NVIDIA L4 melhora o desempenho por dólar em modelos maiores, incluindo inferência baseada em LLM. Diversificar entre essas três famílias, e não só entre tamanhos dentro de uma única família, é o que dá acesso a pools de capacidade Spot independentes entre si.

A estratégia de alocação usada é a price-capacity-optimized: o EC2 escolhe os pools de capacidade Spot com maior disponibilidade e menor preço, reduzindo a chance de interrupção em vez de só perseguir o preço mais baixo. Um exemplo de capacity provider strategy que segue esse padrão, com um provider On-Demand como piso sempre ligado e um provider Spot absorvendo picos, ficaria assim num template de ECS:

{
 "capacityProviderStrategy": [
 { "capacityProvider": "OnDemandCP", "base": 10, "weight": 1 },
 { "capacityProvider": "SpotGpuCP", "base": 0, "weight": 4 }
 ]
}

Com base de 10 no provider On-Demand e weight 4 vezes maior no Spot, o cluster mantém um piso estável e deixa o Spot absorver a maior parte do crescimento de demanda, que é exatamente o papel que a AssemblyAI descreve para o On-Demand na arquitetura publicada.

Trade-offs

O pilar mais evidente aqui é confiabilidade. Rodar inferência crítica em Spot significa aceitar que a instância pode sumir a qualquer momento com 2 minutos de aviso; a arquitetura só funciona porque o job é idempotente e retomável por outra instância, não porque a interrupção deixou de acontecer. Quem desenha um pipeline parecido precisa garantir que cada unidade de trabalho seja curta e sem estado preso à máquina, porque é essa propriedade que transforma a reclamação de Spot em evento rotineiro em vez de incidente.

Há também um trade-off direto de otimização de custos contra excelência operacional. Manter um On-Demand sempre ligado como piso custa mais do que rodar tudo em Spot, mas garante latência previsível mesmo em um cenário de reclamação em massa de capacidade Spot. Zerar o piso On-Demand economizaria mais, mas empurraria todo o risco de disponibilidade para o momento exato em que a capacidade Spot ficar escassa, o pior momento possível para isso acontecer.

No pilar de eficiência de desempenho, a diversificação entre g4dn, g5 e g6 entrega outro ganho colateral: além de reduzir interrupção, ela permite rotear cargas mais pesadas de LLM para GPUs mais potentes sem reescrever a lógica de orquestração, porque o ECS capacity provider já abstrai essa escolha. A contrapartida é mais complexidade de teste: validar o mesmo pipeline de inferência em três gerações de GPU diferentes exige mais cobertura de QA do que travar em uma única família.

Custo estimado

A AWS não publicou valores de hora de instância nesse post, mas documenta de forma geral que o desconto de Spot em relação a On-Demand pode chegar a até 90% dependendo do tipo de instância e da região; a AssemblyAI reporta 70% de economia em compute de inferência especificamente, um número mais conservador, compatível com manter um piso On-Demand fixo e usar Spot só para o excedente.

O dado que mais interessa para quem acompanha a fatura, porém, não é o percentual isolado: é o fato de que a plataforma cresceu quase 4 vezes em demanda de compute ano a ano e a arquitetura Spot foi o que manteve a unidade econômica sustentável nesse crescimento. Em outras palavras, sem a diversificação de Spot, o mesmo crescimento de volume teria multiplicado a fatura de GPU quase proporcionalmente, porque o custo por hora de GPU não cai sozinho com escala.

Para quem fecha orçamento de ML em GPU, o ponto prático é separar duas linhas na análise de custo: o piso On-Demand (previsível, dimensionado pelo volume mínimo) e o excedente Spot (variável, dimensionado pela diversificação de instância disponível). Tratar as duas como uma fatura única dificulta enxergar onde a economia realmente acontece.

Como adaptar

A AWS recomenda esse padrão para qualquer equipe com workloads batch ou quase em tempo real que tenham a mesma característica: jobs curtos, retentáveis de forma independente, rodando em GPU. Antes de portar o desenho, valem algumas verificações:

• Confirmar que cada unidade de trabalho cabe dentro da janela de 2 minutos de aviso de interrupção, ou que é seguro interrompê-la e retomar do zero em outra instância.
• Mapear pelo menos duas ou três famílias de instância GPU compatíveis com o modelo (como g4dn, g5 e g6), em vez de depender de uma única família.
• Construir uma fila SQS com Dead Letter Queue separada, para não perder jobs que falham repetidamente por motivo diferente de interrupção Spot.
• Automatizar a reação ao Spot interruption notice via EventBridge e Lambda, em vez de depender de polling manual de status da instância.
• Pré-construir a AMI com artefatos de modelo e imagem de container, para reduzir o tempo de warm-up de uma instância de reposição, como a AssemblyAI faz ao preparar a imagem em cerca de 2 minutos.

Para quem opera em região com exigência de residência de dados, o detalhe relevante do caso é que a AssemblyAI não compartilha fila nem fleet entre regiões: cada Região, no caso US West (Oregon) e Europe (London), roda uma cópia independente da pilha inteira, com suas próprias filas SQS, clusters ECS e capacity providers. Isso evita que um job de um cliente europeu seja processado numa GPU Spot americana só porque havia capacidade sobrando lá, o que quebraria o requisito de compliance mesmo que resolvesse o problema de disponibilidade.

Fonte: AWS Machine Learning Blog