80-90% do custo de IA vai para inference. E a maioria dos times está pagando 50-90% a mais do que precisaria. 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 playbook que usamos na Tech86.
Lever 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, cache reads custam US$ 0,30/MTok contra US$ 3,00/MTok uncached. 90% de redução. O break-even 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 uncached. É o primeiro mover por razão óbvia: elimina custo sem tocar na arquitetura.
Lever 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 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 savings e acurácia. Muito agressivo retorna respostas erradas. Muito conservador não cacheia o suficiente. Cada domínio precisa de calibração própria.
Lever 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. O savings é 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.
Lever 4: Model Routing/Cascade — 30%+ savings + 5%+ accuracy
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 frontier model. 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 single-model. 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.
Lever 5: Quantização FP8 — effectively lossless, self-hosted only
FP8 é o ponto seguro da quantização. Estudo com 500.000+ evaluations 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 — é free performance em hardware que suporta.
Mas este lever só existe para self-hosted inference. Para managed APIs (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 este lever.
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 outcomes
Cost-per-token é input metric. Cost-per-successful-output é a métrica que alinha engenharia com outcomes. Otimizar cost-per-token à custa de retry rates, hallucination rates ou task completion rates corta a token bill 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: cost-per-token e cost-per-successful-output. A diferença entre os dois é o seu desperdício real.
A ordem não é estilística
Começar pelo lever 3 significa otimizar um modelo cujo custo você não consegue quantificar — porque não cachearou os prompts repetidos. Começar pelo lever 5 significa quantizar antes de eliminar chamadas desnecessárias. É como trocar o motor do carro antes de fechar o janela: o esforço é real, o savings é marginal.
O caminho: cache primeiro (zero risk, highest savings) → batch (50% guaranteed) → route (benchmark) → quantize (self-hosted only). 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 seu AI bill escala mais rápido que seu revenue, essas alavancas existiam desde o dia 1. Bastava aplicá-las na ordem certa.