80-90% do custo de IA vai para inference, segundo dados da indústria. E a maioria dos times está pagando 50-90% a mais do que precisaria, segundo benchmarks de FinOps. Não por falta de ferramentas, por falta de ordem. Existem cinco alavancas mensuráveis para cortar esse desperdício. A ordem em que você as aplica importa mais do que qualquer uma individualmente. Este é o guia que usamos na Tech86.
Alavanca 1: Prompt/KV Caching, até 90% de redução, zero risco
Toda requisição de LLM carrega um bloco repetido: system prompt, instruções de tool calling, contexto de RAG, few-shot examples. Esses tokens são processados do zero a cada chamada. Prompt caching elimina essa redundância.
Os números são inequívocos. No Anthropic Sonnet 4.6, leituras de cache custam US$ 0,30/MTok contra US$ 3,00/MTok sem cache. 90% de redução. O ponto de equilíbrio para cache de 1 hora: menos de 3 reuses/hora. A maioria dos workloads excede trivialmente esse limiar, um chatbot corporativo com system prompt de 2K tokens e contexto RAG de 5K tokens reprocessa 7K tokens idênticos a cada interação.
Esforço: baixo. É uma flag na API call ou configuração de endpoint. Zero impacto em qualidade, o output é idêntico ao sem cache. É o primeiro mover por razão óbvia: elimina custo sem tocar na arquitetura.
Alavanca 2: Semantic Caching, 61-69% menos chamadas à API
Prompt caching resolve exact match. Semantic caching resolve equivalência semântica. "Qual o preço do plano Pro" e "Quanto custa o plano Pro" geram chamadas distintas na API, mas pedem a mesma resposta. O semantic cache entende isso.
Pesquisa confirma: 61-69% de redução em chamadas à API, segundo estudos de caso, com 97%+ de acurácia preservada. O mecanismo é um embedding pipeline que converte cada query em vetor, compara com cache existente por similaridade coseno, e retorna a resposta cacheada quando o score ultrapassa o threshold.
O esforço é médio porque requer infraestrutura: embedding model, vector store, pipeline de ingestão e, principalmente, threshold tuning. O threshold define o trade-off entre economia e acurácia. Muito agressivo retorna respostas erradas. Muito conservador não cacheia o suficiente. Cada domínio precisa de calibração própria.
Alavanca 3: Async Batching, 50% de desconto garantido
Nem toda chamada de LLM precisa de resposta em tempo real. Classificação de tickets, enriquecimento de dados, geração de embeddings, análise de sentimento em batch, esses workloads toleram latência de horas. A OpenAI Batch API oferece 50% de desconto com janela de 24 horas. Não é promessa, é preço publicado.
A implementação é mínima: empacote as requisições em JSONL, submeta via API, receba resultados em até 24h. Para workloads que já rodam em pipelines assíncronos, a migração é trivial. A economia é incondicional, não depende de volume, nem de distribuição de prompts, nem de benchmark.
Esforço: baixo. Zero impacto em qualidade, o modelo é o mesmo, o output é o mesmo, só muda o timing. A única restrição é que não serve para nada interativo. Se o usuário está esperando uma resposta, não é batch.
Alavanca 4: Model Routing/Cascade, 30%+ de economia + 5%+ de acurácia
Um único modelo para tudo é desperdício. Queries simples, "qual o horário de funcionamento", "resuma este texto", "extraia entidades", não precisam de um modelo de ponta. Model routing direciona cada query para o modelo mais adequado baseado na complexidade.
Routers inteligentes preveem o melhor modelo por query. Dados de vendor: 30%+ de economia de custo e 5%+ de ganho de acurácia sobre modelo único. O ganho de acurácia contra-intuitivo vem do fato de que modelos pequenos frequentemente superam modelos grandes em tasks simples, menos alucinação, menos reasoning desnecessário, respostas mais diretas.
O esforço é médio porque requer benchmark contra sua distribuição real de prompts. Não basta confiar em benchmarks públicos, você precisa rodar seu tráfego real contra múltiplos modelos, medir custo e qualidade por faixa de complexidade, e calibrar o router. Sem esse benchmark, o routing é achismo.
Alavanca 5: Quantização FP8, praticamente sem perda, apenas hospedagem local
FP8 é o ponto seguro da quantização. Estudo com 500 mil+ avaliações na família Llama-3.1: zero degradação de acurácia. INT8 adiciona 1-3% de perda. INT4 é variável e depende do modelo e da task. FP8 reduz consumo de memory e aumenta throughput, é performance gratuita em hardware que suporta.
Mas esta alavanca só existe para inferência hospedada localmente. Para APIs gerenciadas (OpenAI, Anthropic, Google), você não controla a quantização. O provider decide. Se sua inferência roda em GPUs próprias ou on-prem, FP8 é o primeiro passo de otimização de hardware. Se roda em API, pule esta alavanca.
Esforço: alto. Requer infraestrutura de serving (vLLM, TensorRT-LLM), validação de compatibilidade de hardware, e testes de regressão. O ROI aparece em scale, para poucas GPUs, o esforço de implementação pode não compensar.
A métrica que alinha engenharia com resultados
Custo por token é métrica de entrada. Custo por resultado bem-sucedido é a métrica que alinha engenharia com resultados. Otimizar custo por token à custa de taxas de retry, taxas de alucinação ou taxas de conclusão de tarefas corta a fatura de tokens enquanto aumenta o custo real por resultado.
Um modelo que custa 50% menos por token mas gera 3x mais retries não está mais barato, está mais caro por resultado útil. Um cache agressivo que retorna respostas erradas em 10% dos casos não está economizando, está transferindo custo da API para o suporte. Track ambos: custo por token e custo por resultado bem-sucedido. A diferença entre os dois é o seu desperdício real.
A ordem não é estilística
Começar pela alavanca 3 significa otimizar um modelo cujo custo você não consegue quantificar, porque não aplicou cache nos prompts repetidos. Começando pela alavanca 5 significa quantizar antes de eliminar chamadas desnecessárias. É como trocar o motor do carro antes de fechar o janela: o esforço é real, a economia é marginal.
O caminho: cache primeiro (risco zero, economia máxima) → batch (50% guaranteed) → route (benchmark) → quantize (apenas hospedagem local). Cada alavanca reduz o volume que a próxima precisa processar. Caching reduz tokens. Batch reduz custo dos que sobram. Routing direciona o que restou para o modelo certo. Quantização otimiza o que efetivamente roda em hardware próprio.
Na Tech86, desenhamos arquiteturas de inference com FinOps integrado, da escolha do modelo ao pipeline de caching e routing. Se sua fatura de IA escala mais rápido que seu revenue, essas alavancas existiam desde o dia 1. Bastava aplicá-las na ordem certa.