Por que Auto-hospedar Modelos de Linguagem?
A ascensão de modelos de linguagem grande (LLMs) poderosos consumidos via chamadas de API simplificou bastante a integração de capacidades de inteligência artificial em aplicações. Porém, apesar dessa conveniência, muitas empresas optam por auto-hospedar seus próprios modelos, aceitando a complexidade de gerenciar infraestrutura, os custos de GPUs e o desafio de manter os modelos atualizados.
Essa decisão geralmente está baseada em dois fatores críticos que serviços de API não conseguem resolver completamente. Primeiro, a soberania de dados: garantir que informações sensíveis não saiam da infraestrutura, seja por requisitos regulatórios, preocupações competitivas ou obrigações contratuais. Segundo, a customização de modelos: capacidade de ajustar modelos com dados proprietários para terminologia específica do setor ou criar capacidades especializadas que APIs genéricas não oferecem.
A Solução: Gerenciamento Simplificado da Infraestrutura
A Amazon SageMaker AI aborda a complexidade de gerenciar a infraestrutura de auto-hospedagem abstraindo a carga operacional. Por meio de endpoints gerenciados, o SageMaker AI cuida do provisionamento, escalabilidade e monitoramento de recursos GPU, permitindo que os times se concentrem no desempenho do modelo em vez de questões de infraestrutura.
O sistema fornece containers otimizados para inferência com frameworks populares como o vLLM pré-configurados para máximo throughput e latência mínima. Por exemplo, a imagem do container Large Model Inference (LMI) v16 utiliza vLLM v0.10.2, que emprega o engine V1 e oferece suporte para novas arquiteturas de modelos e hardwares como a geração Blackwell/SM100. Essa abordagem gerenciada transforma o que normalmente exigiria expertise dedicada em operações de aprendizado de máquina em um processo de implantação que requer apenas algumas linhas de código.
O Desafio da Otimização
Apesar da praticidade dos containers gerenciados, alcançar desempenho ótimo ainda exige configuração cuidadosa. Parâmetros como grau de paralelismo de tensor, tamanho de lote, comprimento máximo de sequência e limites de concorrência impactam dramaticamente tanto latência quanto throughput. Encontrar o equilíbrio certo para sua carga de trabalho e restrições de custo é um processo iterativo que consome tempo.
É aqui que o BentoML LLM-Optimizer faz diferença. A ferramenta permite benchmarking sistemático entre diferentes configurações de parâmetros, substituindo testes manuais por busca automatizada. Você define restrições como alvos específicos de latência ou requisitos de throughput, facilitando a identificação de configurações que atendem seus objetivos de nível de serviço.
Conceitos Fundamentais de Desempenho em LLMs
Métricas-Chave de Desempenho
Throughput (requisições por segundo): Quantas requisições seu sistema completa por segundo. Maior throughput significa atender mais usuários simultaneamente.
Latência (segundos): Tempo total entre a chegada de uma requisição até o retorno da resposta completa. Menor latência significa experiência mais rápida para o usuário.
Intensidade Aritmética: Razão entre computação realizada e dados movimentados. Isso determina se sua carga está limitada por velocidade de transferência de dados (intensidade baixa) ou poder de processamento bruto da GPU (intensidade alta).
O Modelo Roofline
O modelo roofline visualiza desempenho plotando throughput contra intensidade aritmética. Para LLM, ele ajuda a identificar se você está limitado por largura de banda de memória (típico para tamanhos pequenos de lote) ou capacidade de computação bruta (típico para tamanhos grandes de lote).
O Dilema Throughput-Latência
Otimização de inferência de LLM segue um dilema fundamental: conforme você aumenta throughput, a latência sobe. Lotes maiores processam mais requisições juntas, aumentando throughput, mas também aumentam tempos de espera, elevando latência. Paralelismo de tensor distribui o modelo entre GPUs, afetando ambas as métricas diferentemente. O desafio está em equilibrar múltiplos parâmetros interdependentes:
- Grau de paralelismo de tensor (quantas GPUs usar)
- Tamanho de lote (máximo de tokens processados juntos)
- Limites de concorrência (máximo de requisições simultâneas)
- Alocação de cache KV (memória para estados de atenção)
Fluxo de Trabalho: Passo a Passo
1. Definir Restrições
O processo começa dentro do SageMaker AI Studio com um Jupyter Notebook definindo os objetivos de implantação. Você especifica restrições como latência alvo, throughput desejado e tokens de saída.
2. Executar Estimativas Teóricas e Benchmarks Empíricos
O LLM-Optimizer primeiro executa estimativa de desempenho GPU teórica para identificar configurações viáveis para o hardware selecionado. Em seguida, realiza testes de benchmark usando vLLM em múltiplas combinações de parâmetros, medindo empiricamente latência e throughput. Com base nesses dados, o otimizador determina automaticamente a configuração de serving mais eficiente que satisfaz suas restrições.
3. Gerar e Implantar Configuração Otimizada
Uma vez completo o benchmarking, o otimizador retorna arquivo JSON com valores de parâmetros ótimos. Esse JSON é passado da configuraçao de endpoint do SageMaker, que implanta o LLM usando um endpoint HTTP gerenciado com parâmetros de runtime otimizados.
Caso Prático: Modelo Qwen3-4B no SageMaker AI
Considere uma implantação do modelo Qwen-3-4B em instância ml.g6.12xlarge (4x NVIDIA L4 GPUs, 24GB VRAM cada) com restrições realistas:
- Alvo: 10 requisições por segundo (RPS)
- Comprimento de entrada: 1.024 tokens
- Comprimento de saída: 512 tokens
Executando a Estimativa Teórica
O primeiro passo é executar uma estimativa. O LLM-Optimizer analisa o modelo em 4x L4 e estima desempenho para os comprimentos de entrada e saída definidos. A análise roofline identifica gargalos da carga de trabalho.
Sob o capô, o LLM-Optimizer realiza análise roofline buscando arquitetura do modelo no Hugging Face, extraindo parâmetros como dimensões ocultas, número de camadas e cabeças de atenção. Calcula FLOPs teóricos necessários para fases de prefill (processamento de tokens de entrada) e decode (geração de saída). Compara intensidade aritmética contra características de hardware da GPU para determinar se prefill e decode estão limitados por memória ou computação.
Executando Benchmarks Empíricos
Com base nas saídas de estimativa, você executa benchmarks reais. O LLM-Optimizer testa diferentes combinações de paralelismo de tensor, tamanho de lote e concorrência, capturando métricas de baixo nível como time-to-first-token (TTFT), inter-token latency (ITL), latência end-to-end, tokens por segundo e utilização de GPU.
Os resultados mostram que paralelismo de tensor de 4 consistentemente supera configurações com menor paralelismo. A configuração ótima — tensor_parallel_size=4, max_num_batched_tokens=8192 e max_concurrency=128 — atinge 7,51 requisições/segundo, uma melhoria de 2,7x em relação ao baseline ingênuo com GPU única. Para workloads sensíveis a latência, a solução intermediária — tensor_parallel_size=4 com max_num_batched_tokens=4096 e concorrência moderada (32) — mantém latência p99 end-to-end abaixo de 24 segundos enquanto entrega 5,63 req/s, mais que o dobro do baseline.
Implantação no Amazon SageMaker AI
Com parâmetros ótimos identificados, o passo final é implantar em produção. O SageMaker AI fornece um ambiente ideal para essa transição, abstraindo complexidade de infraestrutura de hosting em GPU distribuído.
Os containers LMI da AWS são imagens Docker de alto desempenho especificamente projetadas para inferência de LLM. Integram nativamente com frameworks como vLLM e TensorRT, oferecendo suporte embutido para paralelismo de tensor multi-GPU, batching contínuo e geração de tokens com streaming.
Você passa as configurações determinadas diretamente ao container como variáveis de ambiente:
env = {
"HF_MODEL_ID": "Qwen/Qwen3-4B",
"OPTION_ASYNC_MODE": "true",
"OPTION_ROLLING_BATCH": "disable",
"OPTION_ENTRYPOINT": "djl_python.lmi_vllm.vllm_async_service",
"OPTION_MAX_ROLLING_BATCH_PREFILL_TOKENS": "8192",
"OPTION_TENSOR_PARALLEL_DEGREE": "4",
}Quando essas variáveis são aplicadas, o SageMaker as injeta na camada de configuração de runtime, inicializando o engine vLLM com os argumentos desejados. Durante inicialização, o container baixa pesos do modelo do Hugging Face, configura topologia de GPU para execução paralela de tensor e registra o modelo com o Runtime de Endpoint do SageMaker.
Impacto Real na Prática
A jornada de seleção de modelo para implantação em produção não precisa mais depender de tentativa e erro. Passar de uma configuração ingênua com GPU única para paralelismo de tensor 4 com tamanhos de lote otimizados pode exigir 2-4x menos GPUs enquanto entrega 2-3x menor latência. O que tradicionalmente levaria dias ou semanas de testes manuais toma poucas horas de benchmarking automatizado.
Sem otimização sistemática, times enfrentam jogo caro entre super-provisionar recursos GPU e arriscar degradação de experiência do usuário. Combinando busca automática de configuração com infraestrutura gerenciada, organizações tomam decisões baseadas em dados que impactam diretamente custos de nuvem e satisfação do usuário.
Conclusão
A combinação de benchmarking automatizado e implantação de modelos grandes gerenciada representa avanço significativo em tornar IA empresarial acessível e economicamente eficiente. Ao aproveitar otimização inteligente de configuração e hosting escalável e tolerante a falhas, times podem focar em construir experiências de IA diferenciadas em vez de gerenciar infraestrutura ou afinar stacks de inferência manualmente.
A melhor configuração de LLM não é apenas aquela que executa mais rápido — é aquela que atende objetivos específicos de latência, throughput e custo em produção. Com essas ferramentas, esse equilíbrio pode ser descoberto sistematicamente, reproduzido consistentemente e implantado com confiança.
Recursos Adicionais
Fonte
Optimizing LLM inference on Amazon SageMaker AI with BentoML’s LLM-Optimizer (https://aws.amazon.com/blogs/machine-learning/optimizing-llm-inference-on-amazon-sagemaker-ai-with-bentomls-llm-optimizer/)
Leave a Reply