Como Reduzir Custo de Inferência de LLMs em 5 Técnicas

A conta de inferência de um produto rodando em produção tem um comportamento previsível: ela dobra antes que alguém perceba que poderia ter sido cortada pela metade. Cinco técnicas de engenharia podem reduzir entre 30% e 70% do custo de inferência de LLMs sem trocar de modelo. Nenhuma delas exige reescrever a aplicação. A maioria dos times que operam LLMs em produção não aplica três dessas cinco. O que separa a conta que assusta da conta que cabe no orçamento é menos sobre tecnologia e mais sobre a ordem em que as técnicas entram em produção.

Pré-requisitos: o que você precisa antes de começar

O leitor vai precisar de três coisas antes do primeiro passo. A primeira é acesso às APIs dos modelos que a aplicação consome, ou a uma infraestrutura self-hosted com GPUs disponíveis. Sem visibilidade do tráfego real, qualquer otimização é aposta. A segunda é uma ferramenta de observabilidade que registre tokens de entrada e saída por request, latência e modelo acionado. Langfuse, OpenLIT e o dashboard de consumo do Nexforce Router cumprem essa função. A terceira é um baseline de custo medido em dólares e em reais. Empresas brasileiras pagam um multiplicador de até 55% sobre cada dólar de inferência por causa da cadeia de IRRF, CIDE, PIS, COFINS, ISS, IOF e spread cambial que incide sobre cada remessa internacional. Sem esse número em BRL, a economia real de cada técnica fica subestimada.

O Nexforce Router fatura em reais com nota fiscal e impostos inclusos, eliminando o multiplicador na origem e dando ao time um baseline único.

A conta em dólar é metade da história. O financeiro vê reais.

Passo 1: Diagnosticar para onde o dinheiro está indo

Antes de aplicar qualquer técnica, o time precisa saber qual fatia da conta de inferência vem de input tokens, qual vem de output tokens, e qual parcela dos requests é repetida ou quase repetida. A maioria das implementações descobre que entre 40% e 60% do volume de tokens de entrada é redundante: prompts longos com instruções de sistema idênticas, contexto de conversa reenviado a cada turno, documentos de RAG puxados inteiros quando o modelo precisava de dois parágrafos.

O diagnóstico responde três perguntas. Primeira: qual é a proporção de input tokens contra output tokens? Modelos cobram mais por output, então uma aplicação que gera respostas longas tem um perfil de custo diferente de uma que processa documentos extensos com saída curta. Segunda: qual é a taxa de repetição de requests? Quanto maior, mais o cache semântico entrega. Terceira: o modelo atual está superdimensionado para a complexidade real das tarefas? A resposta quase sempre é sim. Um modelo de frontier chamado para classificar intenção de usuário é um táxi executivo fazendo entrega de panfleto.

Ferramentas como Langfuse e OpenLIT fornecem esse recorte por request. O dashboard do Nexforce Router entrega a visão agregada por chave de API e por projeto, com o custo já convertido para BRL, o que elimina a etapa separada de converter fatura em dólar para a moeda que o financeiro reconhece. O Benchmark de LLMs para CFOs cobre o ângulo de avaliação financeira; aqui o foco é a instrumentação para engenharia.

Passo 2: Cache semântico: a economia que mora na repetição

Cache semântico é a técnica de maior retorno sobre esforço para a maioria das aplicações. Em vez de enviar um request ao modelo, o sistema verifica se uma resposta para um prompt semanticamente similar já existe em cache. Se existir e estiver dentro do threshold de similaridade, a resposta é servida sem custo de inferência.

A implementação mais comum usa Redis como armazenamento e um modelo de embeddings para gerar o vetor do prompt de entrada. O sistema consulta o Redis por similaridade de cosseno contra os prompts cacheados. Se a distância for inferior ao threshold (tipicamente entre 0.05 e 0.15, dependendo da aplicação), a resposta em cache é retornada. O Nexforce Router oferece cache de respostas e embeddings como funcionalidade nativa, sem exigir que o time monte a infraestrutura de Redis e o pipeline de embeddings.

A economia típica fica entre 30% e 70% dos calls, mas depende diretamente do perfil de tráfego. Aplicações com alto volume de requests similares (chatbots de suporte, assistentes de documentação, sistemas de classificação de tickets) são as que mais ganham. Aplicações com prompts altamente variáveis, como geração de código sob medida ou análise de dados não estruturados, têm hit rate baixo e o cache não se paga.

O trade-off principal está no risco de respostas stale. Respostas envelhecem rápido. Se o modelo subjacente foi atualizado ou se o contexto de negócio mudou, o cache serve uma resposta desatualizada. A mitigação é um TTL agressivo (entre 1 e 24 horas, definido por experimento) combinado com invalidação manual para domínios sensíveis.

Passo 3: Prompt compression: menos contexto, mesma resposta

Se o cache semântico ataca a repetição entre requests, o prompt compression ataca o volume dentro de cada request. A técnica reduz o número de tokens de entrada sem perder a informação que o modelo precisa para responder.

O alvo mais comum é o contexto injetado por sistemas de RAG. Um pipeline típico recupera cinco documentos do banco vetorial, concatena os textos completos, e envia tudo ao modelo. Desses cinco, dois são relevantes e três são ruído, mas o modelo pagou por todos. Ferramentas como LLMLingua e prompt pruning via modelos menores aplicam compressão seletiva: removem tokens de baixa perplexidade, cortam parágrafos com baixa similaridade à query, e preservam entidades nomeadas, números e termos técnicos.

A economia típica fica entre 50% e 70% de redução em tokens de entrada para pipelines de RAG. Em aplicações que não injetam contexto externo, como um assistente de código que recebe apenas o arquivo atual, a compressão tem pouco efeito e não justifica a latência adicional do compressor.

Compressão não é gratuita. Cada request passa por um modelo compressor antes de chegar ao LLM principal.

O trade-off está na fronteira entre compressão e perda de precisão. Para tarefas de raciocínio complexo, um corte agressivo de contexto pode remover a nuance que o modelo usaria para chegar à resposta correta. A recomendação é aplicar prompt compression primeiro em tarefas de extração e sumarização, onde a informação relevante é localizada, e testar com um conjunto de avaliação antes de ativar em tarefas analíticas.

Passo 4: Quantização e self-hosting: o caminho estrutural

Quantização é a técnica de maior economia absoluta, mas também a que exige mais infraestrutura. Ela reduz a precisão numérica dos pesos do modelo (de FP16 para INT8 ou INT4), diminuindo o uso de memória e acelerando a inferência. Para times que rodam modelos próprios em GPUs, a economia pode chegar a 80% em relação ao custo equivalente via API.

Ferramentas como vLLM com AWQ (Activation-aware Weight Quantization) entregam inferência em INT4 com perda de qualidade inferior a 1% em benchmarks padrão para a maioria dos modelos open-source. O Llama 3.1 70B quantizado para INT4 cabe em uma única GPU A100 e entrega throughput comparável ao dobro do modelo em FP16, pelo mesmo custo de hardware.

A decisão de self-hosting não é apenas técnica. Ela envolve adquirir ou alugar GPUs, manter a infraestrutura, e assumir a responsabilidade por uptime e latência. Para volumes baixos, abaixo de aproximadamente 50 milhões de tokens por mês, o custo de manter GPUs ociosas supera a economia de não pagar a API. Para volumes altos e previsíveis, acima de 200 milhões de tokens por mês, o self-hosting se paga em semanas.

O Nexforce Router serve como camada de roteamento sobre modelos self-hosted e modelos de API com a mesma chave: o time começa via API, migra gradualmente para self-hosting nos modelos de maior volume, e mantém a API como fallback. A troca é transparente para a aplicação.

Passo 5: Roteamento inteligente: o modelo certo para cada request

Roteamento inteligente é a técnica que opera na camada de decisão: a cada request, o sistema escolhe qual modelo atende aquela chamada com base em complexidade, latência requerida e custo. É a técnica que captura a economia que as outras quatro deixam passar, porque atua sobre requests que não são repetidos, não são comprimíveis e não justificam self-hosting.

É a mais subestimada das cinco.

A arquitetura típica classifica cada request por intenção e complexidade. Uma classificação de sentimento ou uma extração de entidade vai para um modelo leve e barato. Uma análise jurídica ou uma geração de relatório complexo vai para um modelo de frontier. O diferencial está na classificação: se o sistema envia 5% dos requests simples para o modelo caro, a economia cai de 60% para 45%.

A economia típica fica entre 40% e 60% da conta de inferência para aplicações com perfil de tráfego heterogêneo, que é a maioria das aplicações reais. Quando todo o tráfego é complexo, o roteamento não tem para onde desviar e a economia é zero. Quando é predominantemente simples, o ganho pode passar de 70%.

O Nexforce Router implementa roteamento inteligente como funcionalidade nativa: classificação de intenção, seleção de modelo por custo e performance, e failover automático entre provedores. O time define regras por chave de API. Por exemplo, requests de classificação vão para um modelo leve, requests de raciocínio vão para um modelo de frontier, e o orçamento é controlado por teto de gasto por chave. O post Model Router: o middleware que falta na sua stack de IA detalha a arquitetura; o AI Gateway Corporativo cobre a camada de segurança e governança.

Como saber se funcionou: verificação de impacto

O impacto de cada técnica é medido contra o baseline estabelecido no Passo 1. As métricas essenciais são quatro. Custo total por período, comparado ao baseline em dólares e em reais. Hit rate do cache semântico, expresso como percentual de requests servidos sem inferência. Distribuição de requests por tier de modelo, mostrando a migração do modelo caro para o barato ao longo do tempo. Redução de tokens de entrada após prompt compression, medida como delta percentual sobre o baseline.

Um time que aplica as cinco técnicas na ordem correta (diagnóstico, cache, compressão, roteamento, e self-hosting apenas se o volume justificar) tipicamente vê uma redução de 50% a 70% na conta total em 90 dias. O ganho não é linear: as primeiras duas técnicas entregam 60% da economia com 20% do esforço.

Tabela de decisão: qual técnica aplicar primeiro

A ordem de aplicação importa mais do que a escolha das técnicas. A tabela abaixo organiza as cinco técnicas por perfil de carga e economia estimada, para que o time decida por onde começar.

A recomendação para a maioria dos times: começar pelo diagnóstico, aplicar cache semântico e prompt compression em paralelo, ativar roteamento inteligente em seguida, e avaliar self-hosting apenas quando o volume mensal justificar o investimento em hardware. As três primeiras técnicas não exigem infraestrutura adicional e entregam a maior parte da economia.

Comece pelo que é grátis. Depois invista.

O que pode dar errado (e como corrigir)

Três modos de falha aparecem consistentemente quando times implementam essas técnicas pela primeira vez.

Primeiro: cache servindo respostas stale. O sintoma é o usuário recebendo uma resposta que cita uma versão antiga da API ou um preço que mudou na semana anterior. A correção é reduzir o TTL do cache e implementar invalidação baseada em evento: sempre que o domínio de conhecimento muda (uma nova versão de documentação, uma alteração de política de preço), o cache é limpo seletivamente por padrão de prompt.

O segundo é a compressão de prompt degradando a qualidade em tarefas de raciocínio. O sintoma é o modelo entregando respostas corretas mas incompletas, porque a nuance que conectava dois parágrafos foi removida pelo compressor. A correção é aplicar compressão apenas em tarefas de extração e sumarização, e usar um threshold de similaridade mais conservador no compressor (acima de 0.85) para tarefas analíticas.

O terceiro é o roteador enviando requests complexos para modelos simples. O sintoma é o modelo leve respondendo com alucinações ou recusas em tarefas que exigem raciocínio em múltiplas etapas. A correção é calibrar o classificador de intenção com um conjunto de exemplos representativos e implementar uma regra de escape: se o modelo leve retornar baixa confiança ou recusar a resposta, o request é reencaminhado ao modelo de frontier.

Perguntas Frequentes

Quanto tempo leva para implementar as cinco técnicas?

Entre duas e seis semanas, dependendo da maturidade da infraestrutura. Cache semântico e prompt compression podem estar em produção em dias. Roteamento inteligente leva de uma a duas semanas se a camada de gateway já existir. Self-hosting exige de quatro a oito semanas para provisionamento, configuração e migração gradual do tráfego.

Qual técnica entrega o maior retorno sobre esforço?

Cache semântico para aplicações com tráfego repetitivo. Roteamento inteligente para aplicações com tráfego heterogêneo. As duas combinadas cobrem a maioria dos perfis de carga e entregam entre 50% e 70% de economia com esforço moderado.

Preciso aplicar todas as cinco técnicas?

Não. A maioria dos times obtém de 50% a 70% da economia possível com as três primeiras: cache, compressão e roteamento. Quantização e self-hosting são para times com volume que justifique o investimento em hardware. Continuous batching é relevante apenas para modelos self-hosted.

Como o multiplicador tributário brasileiro afeta essas contas?

Cada dólar de custo de inferência pago via faturamento internacional carrega um multiplicador de até 55% em território brasileiro. A cadeia é composta de IRRF (15% a 25%), CIDE de 10% sobre SaaS como serviço técnico (classificação da SC Cosit 191/2017, confirmada pela 99/2018, com isenção do §1°-A do art. 2° da Lei 10.168/2000 restrita a licenças puras sem transferência de tecnologia), PIS de 1,65%, COFINS de 7,6%, ISS de 2% a 5% conforme o município, IOF de 3,5% e spread cambial de 5% a 10%. Uma economia de 50% em dólares via otimização de engenharia vira uma economia de 50% sobre uma base que já era 55% maior em reais. O Nexforce Router elimina o multiplicador na origem ao faturar em BRL com nota fiscal e impostos inclusos.

Qual é a primeira coisa que um time deve fazer amanhã?

Instrumentar a aplicação para saber exatamente quantos tokens estão sendo consumidos, por qual modelo, e qual a taxa de repetição de requests. Sem esse diagnóstico, qualquer técnica aplicada é otimização no escuro. O dashboard do Nexforce Router entrega essa visão em minutos, com o custo já expresso em reais.

O multiplicador que torna cada técnica mais valiosa

A Comparação de Custos de LLMs em 2026 mostrou o preço por token de cada modelo. Este artigo mostrou como reduzir o número de tokens que a aplicação consome. As duas coisas se multiplicam.

Para empresas operando no Brasil, existe um terceiro fator que nenhuma técnica de engenharia resolve sozinha: o multiplicador tributário sobre cada dólar gasto em inferência. IRRF, CIDE, PIS, COFINS, IOF e spread cambial empilham até 55% sobre o custo do token. Uma aplicação que gasta US$100 mil por mês em inferência desembolsa até R$155 mil equivalentes. Aplicar cache semântico, prompt compression e roteamento inteligente reduz o gasto em dólares. Faturar via Nexforce Router em BRL elimina o multiplicador na origem, porque a nota fiscal já inclui os impostos e o câmbio está resolvido, e a economia das cinco técnicas de engenharia passa a ser calculada sobre o custo real em reais, sem o spread que o time de engenharia nunca vê na fatura do provedor.

As cinco técnicas de engenharia são o como. O faturamento em moeda local é o por onde. Juntos, transformam uma conta que dobra silenciosamente em uma conta que cabe no orçamento, e que o financeiro consegue ler.

Referências e Leitura Complementar

• Comparação de Custos de LLMs em 2026: Roteamento Inteligente com Nexforce Router
• Benchmark de LLMs para CFOs: o que importa é o custo
• Model Router: o middleware que falta na sua stack de IA
• AI Gateway Corporativo: roteamento e segurança para LLMs
• Nexforce Router