Engenharia de inferência: a nova fronteira para cortar custo de GPU e latência

Três anos atrás, "engenharia de inferência" mal existia como categoria. Hoje é uma das disciplinas mais críticas de IA em produção, e o episódio recente do Latent Space com Philip Kiely e Ali Taha (Baseten) é um bom mapa de por onde começar. A pergunta central, nas palavras de Kiely, muda o jogo: não é mais "como treinar", e sim "como transformar esses pesos num produto rápido, confiável e barato em escala".

Para quem constrói no Brasil, onde GPU é cara e escassa, isso importa direto no bolso. As otimizações discutidas no episódio ainda rendem ganhos de 20%, 100% e até 200% de throughput, e serving otimizado pode deixar um modelo até 10x mais rápido. Não é hype: são técnicas concretas.

O que acontece com um prompt de 200 mil tokens

Kiely descreve o caminho de uma request longa e a primeira pergunta é reveladora: "você já me mandou isso antes?". Se sim, entra o cache-aware routing, que roteia a requisição para uma réplica que já tenha parte do KV cache pronto, pulando o prefill de boa parte dos tokens. Num agente multi-turno ou numa sessão de coding, isso é regra, não exceção, e é onde mora boa parte da economia.

Quando não há cache, o request vai para um worker de prefill. Aqui aparece um padrão que virou tendência: prefill e decode desagregados. Um conjunto de GPUs processa a entrada e gera o KV cache e o primeiro token; outro conjunto, separado, roda o decode iterativo. São cargas de trabalho com perfis diferentes (prefill é compute-bound, decode é memory-bound), e separá-las permite otimizar cada etapa.

Speculative decoding, na prática

O speculative decoding é explicado por Taha de forma direta: acopla-se ao modelo grande um "parasita", um modelo rascunho pequeno que faz três forward passes rápidos e chuta os próximos tokens. O modelo grande então valida os três de uma vez, aceitando ou rejeitando. O detalhe que separa a teoria da prática é que o speculator é específico do tráfego: um draft treinado só em texto de coding tem alta taxa de aceitação em coding, mas trava se você pedir resumo dos livros do Harry Potter.

Isso conecta com uma decisão de arquitetura que todo time acaba enfrentando: API pública (pay-per-token) versus deployment dedicado (pay-per-hour). Taha é enfático: para quem empurra milhões de tokens por hora, alugar a caixa costuma sair muito mais barato do que pagar por token. Além do custo, o dedicado libera confiabilidade, speculators customizados para o seu tráfego, controle de batch size e escolha de precisão da quantização. A jornada típica, segundo Kiely, é começar na API pública para testar modelos abertos e migrar para o dedicado quando o caso de uso "gruda".

Tool calling e structured outputs

O episódio desmistifica tool calling: o LLM não executa nada, apenas sugere o que fazer. O problema real não é sandbox, é o modelo fechar o JSON errado e, por não ver o resultado da ferramenta, alucinar a resposta durante o decode. A solução do lado da inferência é antiga (a Baseten publicou há quase dois anos): usar uma máquina de estados para restringir a saída a um formato específico, o clássico problema de structured output, parente das gramáticas BNF. Isso não garante que o modelo chame a ferramenta certa, mas garante que a estrutura da saída esteja correta. E MCP, lembram os convidados, é só mais uma forma de tool, sem mágica extra.

Quantização que se cancela

O ponto mais contraintuitivo vem de um experimento com o GLM-5.2: quantizar mais camadas preservou a qualidade nos benchmarks e ainda aumentou o throughput em 20%. A explicação, detalhada num paper de Joshua Hill baseado em análise de Fourier, é que os erros introduzidos em camadas diferentes podem se cancelar: erro(camada A) + erro(camada B) < erro(camada A) sozinho. Vale o ceticismo de sempre: são resultados de fornecedor, medidos em benchmarks específicos. Antes de aplicar NVFP4 em produção, rode seus próprios evals, até porque, como Kiely lembra, uma quantização que não passa no seu benchmark é justamente uma das razões para ir de deployment dedicado.

O episódio vai muito além disso (Dynamo da NVIDIA, model parallelism, geração de vídeo, o gargalo quadrático da atenção), mas o recado para quem constrói é claro: inferência deixou de ser o passo final do treino e virou um problema de sistemas, com pesquisa e papéis próprios. Quem dominar essas alavancas extrai muito mais ROI do mesmo hardware.

Fonte: Latent Space