Engenharia de Inferência
Use esta skill para transformar os requisitos de qualidade, latência, confiabilidade e custo de um produto de IA em um sistema de inferência medido. É uma síntese operacional independente, informada pelo livro Inference Engineering de Philip Kiely (Baseten Books, 2026), e não é afiliada ou endossada pelo autor ou editora. Recursos de fornecedores, lançamentos de modelos, disponibilidade de hardware e comportamento de software mudam rapidamente; verifique os detalhes atuais com a documentação oficial antes de tomar decisões de implementação.
Comece com a carga de trabalho
Antes de escolher um mecanismo ou otimização, estabeleça:
- Contrato do produto: qualidade de saída exigida, modalidades, tamanhos de contexto/entrada, formato da resposta, necessidades de streaming e comportamento em caso de falha.
- Forma do tráfego: taxa de requisições, concorrência, intermitência, padrão de chegada, distribuições de comprimento de entrada/saída e frequência de prefixo cacheável.
- Objetivos de serviço: latência ponta a ponta P50/P95/P99, tempo até o primeiro token (TTFT), latência entre tokens (ITL), taxa de transferência, disponibilidade e metas de recuperação.
- Restrições: orçamento, regiões, residência de dados, privacidade, licença, acesso a hardware e capacidade operacional.
- Linha de base: avaliação de qualidade representativa mais desempenho e custo ponta a ponta sob carga realista.
Não otimize uma métrica proxy isoladamente. Defina a unidade de trabalho e inclua o tempo de cliente, fila, rede, pré-processamento, modelo e pós-processamento quando aplicável. Para fluxos agentivos, meça toda a tarefa, incluindo chamadas de ferramentas e novas tentativas.
Fluxo de trabalho operacional
- Caracterize a carga de trabalho. Separe o tráfego online interativo do trabalho offline/em lote; identifique caminhos sensíveis à latência e orientados a taxa de transferência. Registre as distribuições reais de entrada/saída e concorrência.
- Escolha modelos candidatos. Selecione uma lista restrita com base em qualidade específica da tarefa, modalidade, contexto, restrições de serviço, licença e adequação operacional. Use benchmarks públicos apenas para restringir candidatos; avalie em dados de produto representativos e casos de falha.
- Defina orçamentos. Traduza objetivos ponta a ponta em orçamentos para fila, rede, pré-processamento, prefill, decodificação e pós-processamento. Inclua margem para picos e condições degradadas.
- Ajuste o modelo ao hardware. Estime memória de pesos, sobrecarga de runtime/ativação, demanda de cache KV e margem utilizável. Verifique largura de banda de memória medida, computação, interconexão e topologia; uma especificação nominal de acelerador não é um benchmark de carga de trabalho.
- Estabeleça uma linha de base reproduzível. Fixe revisão do modelo, mecanismo/versão, hardware, precisão, configuração, mix de prompts, limites de saída e formato de carga. Aqueça, execute amostras suficientes e reporte percentis e taxa de transferência ao mesmo tempo.
- Localize o gargalo. Use medições ponta a ponta primeiro, depois perfil de sistema e kernel. Diferencie fila, prefill, decodificação, capacidade/largura de banda de memória, computação, comunicação e sobrecarga do host.
- Altere uma variável por vez. Aplique a otimização menos complexa que aborde o gargalo medido. Verifique novamente qualidade, latência de cauda, taxa de transferência, memória e custo juntos.
- Valide o comportamento em produção. Teste sobrecarga, cold starts, eventos de escala, falhas, deploys, cancelamento, streaming e recuperação. Instrumente as mesmas métricas usadas nos objetivos de serviço.
Métricas e diagnóstico
- TTFT: tempo desde um evento de início claramente definido (por exemplo, envio do cliente ou aceitação do servidor) até o primeiro token gerado. Mantenha esse limite consistente ao comparar execuções; é sensível a fila, comprimento do prompt, prefill e efeitos de inicialização.
- ITL: tempo entre tokens gerados; reflete a capacidade de resposta da decodificação. Reporte distribuições por requisição, não apenas a taxa agregada de tokens.
- Latência ponta a ponta: tempo de conclusão observado pelo cliente; inclua trabalho de rede e aplicação.
- Taxa de transferência: requisições ou tokens concluídos por unidade de tempo em uma carga de trabalho e envelope de latência/qualidade declarados. Especifique se tokens/seg é por usuário ou sistema.
- Percentis: reporte P50 mais objetivos de cauda, como P95/P99; médias podem ocultar requisições lentas.
- Goodput: trabalho concluído enquanto atende aos objetivos relevantes de latência e qualidade. Use isso para comparar configurações que trocam velocidade por qualidade ou comportamento de cauda.
Interprete sintomas como hipóteses, depois verifique com traces/perfis:
| Sintoma | Áreas prováveis para medir |
|---|---|
| TTFT alto, ITL normal | Espera na fila, prompts longos, computação de prefill, cold start, pré-processamento |
| TTFT normal, ITL ruim | Largura de banda de decodificação, contenção de lote, pressão de cache KV, eficiência de kernel |
| Ambos pioram com o aumento da concorrência | Fila, capacidade de memória, política de lote, controle de admissão, saturação |
| Utilização da GPU baixa, latência alta | CPU/tokenização, transferência de dados, sincronização, rede, escalonamento |
| Taxa de transferência sobe, mas latência de cauda viola SLO | Política de batching/concorrência, limites de fila, isolamento de carga de trabalho |
Estas são pistas de diagnóstico, não conclusões. Confirme o gargalo ativo antes de alterar a configuração.
Decisões de modelo e hardware
- Prefira o modelo menor/menos custoso que passe na avaliação de qualidade do produto com margem aceitável. Considere prompting, recuperação, fine-tuning ou destilação apenas quando a avaliação identificar uma lacuna específica e o custo do ciclo de vida for justificado.
- Separe implantações online e offline quando seus objetivos de latência, batching ou disponibilidade entrarem em conflito e o tráfego medido justificar a sobrecarga operacional.
- Ajuste o modelo e o estado de runtime na memória do acelerador com margem explícita para cache KV, ativações, fragmentação e concorrência. Apenas o ajuste de peso é insuficiente.
- Para LLMs autorregressivos, prefill e decodificação estressam o hardware de forma diferente: prefill é geralmente pesado em computação; decodificação frequentemente se torna limitada por largura de banda de memória. Meça ambos para a sequência real e o mix de batching.
- Escolhas de multi-GPU trocam memória/latência/taxa de transferência por comunicação e complexidade. Paralelismo tensorial pode reduzir a latência por requisição para um modelo dividido; paralelismo de especialistas pode servir especialistas esparsos em escala. Valide custos de interconexão e sincronização. Execução multi-nó requer medição de comunicação especialmente cuidadosa.
- Para cargas de trabalho de imagem, vídeo, áudio, embedding e visão-linguagem, use pipelines e métricas específicos da modalidade. Inclua custos de pré-processamento, chunking, codificador/decodificador e pós-processamento; não aplique métricas de token de LLM cegamente.
- Verifique as licenças do modelo e do conjunto de dados e os requisitos relevantes de segurança, privacidade e regulamentação antes da implantação.
Para o raciocínio por trás dessas escolhas, use fundamentos de modelo e hardware. Para compatibilidade de framework, formato e mecanismo de serviço, use seleção de pilha de software. Essas referências fornecem métodos de decisão, não classificações atemporais: verifique o suporte para o modelo exato, acelerador, versão de runtime e conjunto de recursos.
Playbooks de otimização
Aplique somente após estabelecer uma linha de base e identificar um gargalo compatível:
Batching e escalonamento
Batching pode melhorar a utilização do acelerador e amortizar sobrecarga, enquanto aumenta a fila e a latência por requisição. Ajuste concorrência, limites de lote, janelas de espera e controle de admissão com base em chegadas realistas. Proteja o tráfego interativo do trabalho em lote quando seus objetivos colidirem.
Quantização
Trate a quantização como um espectro de qualidade/desempenho, não uma configuração binária. Escolha quais componentes e precisão alterar com base em memória medida, largura de banda, computação e restrições de qualidade. Avalie a qualidade da tarefa representativa, casos extremos e conjuntos de regressão após cada alteração; observe separadamente os efeitos em pesos, ativações, atenção e cache KV onde o mecanismo permitir. Reverta se o piso de qualidade do produto ou a meta de confiabilidade forem perdidos.
Decodificação especulativa
Use um mecanismo de rascunho/proposta apenas quando seu custo de proposta e comportamento de aceitação produzirem um ganho líquido para a carga de trabalho alvo. Meça taxa de aceitação, sobrecarga de memória, impacto no tamanho do lote, ITL por usuário, taxa de transferência agregada e custo. O benefício pode diminuir ou reverter em alta concorrência ou com aceitação fraca.
Cache KV e de prefixo
Reutilize estado em cache quando os prefixos se repetirem e os requisitos de correção/isolamento permitirem. Meça taxa de acerto, trabalho de prefill economizado, custo de armazenamento/memória, comportamento de despejo e localidade de roteamento. Defina chaves de cache e limites de locatário/segurança para que uma requisição não possa reutilizar o contexto privado de outro locatário. Contextos longos e alta concorrência aumentam a pressão de KV; considere custos de posicionamento e transferência.
Paralelismo e desagregação
Introduza paralelismo quando as medições de ajuste de modelo, latência ou taxa de transferência justificarem a sobrecarga de comunicação. Desagregue prefill e decodificação apenas quando a carga de trabalho for grande e estável o suficiente para se beneficiar da alocação independente de recursos e o sistema puder gerenciar a transferência/roteamento de KV. Inclua largura de banda de rede, latência de transferência, modos de falha e complexidade operacional na comparação.
Otimização de kernel e runtime
Profile antes de escrever ou selecionar kernels especializados. A fusão de kernel pode reduzir tráfego de memória e sobrecarga de lançamento, mas a compatibilidade e o comportamento numérico são importantes. Compare candidatos de framework/runtime/mecanismo usando a mesma revisão de modelo, hardware, mix de prompts, comprimentos de saída, carga e verificações de qualidade.
Para comparações detalhadas de métodos de quantização, famílias de decodificação especulativa, posicionamento de cache, serviço de contexto longo e execução distribuída, leia o playbook de otimização.
Benchmarking e perfilamento
- Use traces de produção ou uma carga de trabalho segura para privacidade que preserve os tamanhos das requisições, padrões de chegada e características de cache. Testes sintéticos são úteis para experimentos controlados, mas declare seus limites.
- Registre o comportamento a frio e a quente separadamente. Inclua aquecimento, duração/número de amostras adequados, execuções repetidas, variância e versões de hardware/software.
- Varie a carga para encontrar tanto a saturação quanto o goodput máximo sob SLOs. Evite comparar uma execução com carga leve com uma sobrecarregada.
- Altere um fator por vez para atribuição; após o ajuste, execute um teste ponta a ponta combinado, pois as otimizações podem interagir.
- Emparelhe benchmarks de sistema com avaliação de qualidade da tarefa. Melhorias de desempenho que degradam as saídas além do limite do produto não são vitórias.
- Benchmarks mostram o que está lento; perfilamento ajuda a explicar por quê. Use o profiler menos intrusivo que possa isolar o gargalo ativo e valide a correção proposta com um novo benchmark.
Prontidão para produção
- Capacidade e escalonamento automático: escale com base em indicadores principais (profundidade da fila, utilização, pressão de memória/KV, taxa de chegada) além do trabalho concluído. Considere o tempo de provisionamento e carregamento do modelo; mantenha capacidade suficiente ou degrade-se graciosamente quando cold starts violarem os objetivos.
- Fila e sobrecarga: limite filas e tamanhos de requisições, defina timeouts/cancelamento, use controle de admissão e defina respostas explícitas para sobrecarga. Filas ilimitadas convertem saturação em falha de latência de cauda.
- Confiabilidade: teste health checks, novas tentativas com limites, idempotência quando necessário, perda de instância, falha de região/provedor, rollout, rollback e exaustão de capacidade. Novas tentativas podem amplificar a sobrecarga.
- Implantação: fixe artefatos de modelo e dependências, valide inicialização/prontidão, faça canary de alterações, compare métricas de qualidade e serviço, e mantenha um caminho de rollback testado. Evite expor segredos em imagens, logs ou artefatos de benchmark.
- Observabilidade: correlacione traces de requisição com versões de modelo, mecanismo, hardware e configuração. Acompanhe TTFT, ITL, percentis ponta a ponta, tempo de fila, taxa de transferência/goodput, erros, taxa de acerto de cache, utilização, memória, cold starts e custo.
- Custo: compare o custo por requisição bem-sucedida ou saída útil na qualidade e SLO exigidos, incluindo capacidade ociosa, replicação, rede, armazenamento e sobrecarga de engenharia/operações. Escalar para zero pode reduzir gastos ociosos, mas adiciona latência de cold start.
- Segurança e conformidade: controle o acesso ao modelo e aos dados, isole locatários, proteja prompts e saídas em logs, defina retenção, valide dependências e artefatos, e atenda aos requisitos aplicáveis de residência de dados e regulamentação.
Para reprodutibilidade de contêineres, capacidade e roteamento, operações multi-região, protocolos de cliente e práticas de rollout, leia operações de produção. Para medição por modalidade, leia considerações de inferência específicas por modalidade.
Roteamento de referência
| Tarefa | Leia |
|---|---|
| Construir um cartão de carga de trabalho, estabelecer uma linha de base ou localizar um gargalo | Este arquivo, depois playbook de otimização |
| Entender execução de modelo, ajuste de acelerador ou tradeoffs de hardware | Fundamentos de modelo e hardware |
| Selecionar um framework, formato de modelo, caminho de kernel ou mecanismo de serviço | Seleção de pilha de software |
| Ajustar quantização, especulação, caches, paralelismo ou desagregação | Playbook de otimização |
| Servir cargas de trabalho de visão, embeddings, áudio, imagem ou vídeo | Considerações específicas por modalidade |
| Planejar escalonamento automático, implantação, confiabilidade, comportamento de API/cliente e custo | Operações de produção |
Formato de resposta para tarefas de inferência
Ao aconselhar ou implementar, forneça:
- Suposições de carga de trabalho e medições ausentes.
- O objetivo e as métricas de linha de base.
- A hipótese principal de gargalo e como prová-la.
- Um plano de experimentos classificado com tradeoffs esperados.
- Critérios de aceitação de qualidade, latência de cauda, confiabilidade, segurança e custo.
- Fatos atuais de fornecedor/modelo/runtime com links para fontes oficiais quando afetarem a recomendação.