Capítulo 16 — Estratégias de Corte de Custo em Produção

Publicado em: 2026-05-08 Última atualização em: 2026-07-07 Versão: 1
Capítulo 16 — Estratégias de Corte de Custo em Produção

Capítulo 16 — Estratégias de Corte de Custo em Produção

Último post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O catálogo de movimentos ortogonais que se compõem em um terço ou metade da fatura do mês passado.


Por que este capítulo existe

Os dois capítulos anteriores contaram para o time onde o dinheiro vai e deram uma estrutura para decidir de que lado da linha API-versus-dedicado sentar. Este capítulo é o catálogo dos movimentos que o time pode fazer uma vez tomadas essas decisões. Os movimentos são em grande parte independentes de postura — economizam dinheiro em uma API, economizam em hardware dedicado, economizam em um arranjo híbrido — e se compõem. Times que os adotam em sequência costumam descobrir, seis meses dentro de um esforço focado de custo, que sua fatura de inferência é um terço a metade do que era. Nenhum dos movimentos é exótico; todos exigem engenharia deliberada; o custo de construí-los é pequeno em relação ao que economizam.

Em uma linha: Roteamento, compactação, batch, cache, auditoria de prompt, teto de output — quatro a seis movimentos independentes que se multiplicam em uma redução de 80 por cento sem mudar o que o usuário vê.

16.1 O roteamento inteligente de modelos é a maior alavanca isolada

Tráfego de produção não é uniformemente difícil. Metade ou mais das requisições é simples o suficiente para um modelo de tier econômico uma ordem de magnitude mais barato que o de fronteira; uma fração menor genuinamente precisa da fronteira. O time que rotea tudo para o topo paga em excesso pelas simples de 10 a 20×. A arquitetura certa é um roteador que classifica cada requisição e despacha para o tier mais barato capaz de lidar com ela. O gradiente de custo no momento em que este texto foi escrito é de cerca de 30:1 no input e 20:1 no output entre fronteira (US$ 15 a 30 por milhão de output) e econômico (US$ 0,10 a 1 por milhão). As opções de roteador vão de uma heurística sobre o formato da requisição (comprimento, formato, marcadores de tool use) a um classificador pequeno de tier econômico que emite um rótulo de tier, até um roteador aprendido treinado sobre dados históricos de qual modelo de fato funcionou. Restrições de projeto: barato e rápido (abaixo de 100 ms, décimo de centavo), observável (toda decisão logada com features e desfecho), seguro por padrão (na dúvida, sobe de tier — o custo de rotear para cima é um dólar a mais, o custo de rotear para baixo é uma regressão visível de qualidade).

16.2 Compactação, batch APIs e cache semântico cada um resgata uma fatia grande

A compactação de contexto ataca o crescimento quadrático de input que o Capítulo 14 nomeou. A forma mais simples é uma janela deslizante: manter os últimos K turnos na íntegra, substituir tudo o que veio antes por um resumo feito pelo tier econômico; a chamada de resumo custa uma fração de centavo e encolhe o input em cada turno subsequente de milhares de tokens de histórico literal para centenas de tokens de resumo. Um compactador mais sofisticado preserva certos tipos na íntegra (código, saídas de ferramentas, dados fornecidos pelo usuário) e resume o resto. As batch APIs assíncronas pela metade do preço absorvem qualquer workload sem orçamento síncrono de latência — sumarização noturna, reclassificação, pré-geração para um A/B test, atualização de embeddings — a categoria é maior do que os times reconhecem inicialmente, e a engenharia para mover uma workload para batch é trivial. O cache semântico responde antes de chamar o modelo: gera-se o embedding de cada requisição, procura-se em um índice vetorial de pares requisição-resposta anteriores, devolve-se a resposta em cache se a similaridade cruzar um limiar. Dois usuários perguntando "qual é a política de devolução" e "como faço para devolver um item" batem na mesma entrada. Em tráfego com formato de FAQ, taxas de hit de cache de 30 a 50 por cento são rotineiras, e o token mais barato é aquele que nunca é gerado.

16.3 Os movimentos se compõem multiplicativamente, não aditivamente

Tome um agente cuja fatura chegou a US$ 4.000 por mês a 1.000 queries por dia. Rotear: 60 por cento econômico, 30 por cento intermediário, 10 por cento fronteira → o custo misto cai para 28 por cento da tarifa de fronteira, a fatura cai para US$ 1.100. Compactar: o inchaço de input é cortado pela metade, a fatura cai para US$ 770. Mover 20 por cento para batch: US$ 720. Cache semântico com 25 por cento de hit: US$ 540. De US$ 4.000 para US$ 540 — uma redução de 86 por cento — sem mudança visível para o usuário. Dois outros movimentos se pagam mesmo sem seção própria. Uma auditoria de prompt — ler todo prompt com olhos frescos, apagar qualquer coisa que não justifique seus tokens — costuma encontrar 10 a 20 por cento de gasto a cortar sem mudança de comportamento. Um teto explícito de max_tokens impede que uma resposta se estenda até 2.000 tokens quando a aplicação só precisava de 300 — quase 7× de pagamento excedente naquela requisição. O modelo mental é o do Livro IV: toda requisição tem um custo unitário, e o trabalho de engenharia é rotear cada requisição pelas camadas baratas primeiro e só alcançar a camada cara quando necessário.

Vale a pena guardar: Custo é uma métrica de engenharia. Os times que cortaram suas faturas em uma ordem de magnitude levaram custo a sério do mesmo jeito que levaram latência a sério — decompuseram, instrumentaram, construíram as camadas de roteamento, cache e compactação, e mediram. Os outros esperaram o financeiro notar.

O que o Capítulo 16 encerra

O volume abriu com o gargalo autorregressivo — o fato irredutível de que geração de LLM é sequencial e que o hardware que é tão bom em aritmética paralela passa a maior parte do tempo esperando por memória. Todo capítulo depois disso foi uma resposta a esse fato central em um nível diferente da pilha. Os capítulos de hardware construíram o substrato físico. Os capítulos de modelo encolheram o modelo. Os capítulos de sistemas extraíram o máximo de trabalho útil de cada ciclo de clock. Os capítulos de engine e orquestração colocaram tudo em produção. Os capítulos de economia descreveram como o time que roda o sistema paga por ele. Cada camada é uma resposta à anterior, e a disciplina de rodar LLMs em escala é a integração de todas elas pelas mesmas pessoas — ou, no mínimo, por pessoas que consigam conversar entre si no mesmo vocabulário.


Fim do passeio. Este é o último capítulo do Volume VI. O próximo volume da série — LLM Primer VII — Segurança de IA — estende a disciplina de engenharia de produção deste volume para modelagem de ameaças, guardrails, sandboxing de código gerado por modelo, mitigação de prompt injection, filtragem de output e a regulação que agora molda como tudo o que este volume descreveu deve ser implantado. A infraestrutura construída ao longo deste volume — a frota de inferência, a camada de roteamento, os sandboxes, os ambientes de execução de agente — é exatamente a infraestrutura sobre a qual as preocupações de segurança do Volume VII se desenrolam. Escala e segurança são dois lados do mesmo problema: uma é a engenharia do crescimento, a outra é a engenharia da resiliência aos ataques que o crescimento convida.

Quer o panorama completo? O capítulo do livro inclui as classes executáveis ModelRouter, ConversationCompactor, BatchJobBuilder e SemanticCache; o traço completo do exemplo trabalhado que compõe a queda de US$ 4.000 para US$ 540; o checklist de auditoria de prompt; e a reflexão de encerramento sobre a trajetória do custo de inferência que este artigo só pode resumir. Veja o LLM Primer VI na Amazon →

SHO
SHO
CTO e Fundador da RECEIPTROLLER. Focado em dados, movido pela inovação, sempre curioso.