Como cortar o custo de tokens de LLM em produção sem perder qualidade

Toda automação de conteúdo que chama um modelo de linguagem tem o mesmo problema silencioso: a fatura cresce mais rápido que o tráfego. O motivo raramente é o volume de chamadas — é o desperdício por chamada. Contexto inflado, saídas longas demais, retries cegos e o hábito de mandar tudo para o modelo mais caro somam centavos que viram milhares de reais no fim do mês. Este guia mostra como reduzir o custo de tokens LLM em produção atacando a causa, não cortando funcionalidade.

Onde o dinheiro realmente vaza

Antes de otimizar, entenda a conta. Você paga por tokens de entrada (o prompt inteiro: instruções, contexto, histórico) e por tokens de saída (a resposta gerada). Saída costuma custar de 3 a 5 vezes mais que entrada. Os quatro vazamentos mais comuns:

• Contexto inflado: você anexa o artigo inteiro, o histórico todo e exemplos que o modelo não precisa ver de novo.
• Saída sem teto: sem max_tokens definido, o modelo escreve até onde quiser.
• Retry cego: uma falha 429 ou 503 dispara a mesma chamada cara três vezes.
• Modelo único: usar o modelo topo de linha para classificar um e-mail é como fretar um caminhão para entregar uma carta.

Meça antes de cortar

Você não pode otimizar o que não enxerga. O primeiro passo é registrar o consumo de tokens por feature, não só o total da conta. Quase toda API de LLM devolve um objeto usage com a contagem. Capture e persista isso a cada chamada:

<?php
// Registra o custo de cada chamada de IA por contexto de uso.
function wpraiz_log_token_usage(string $feature, array $usage): void {
    global $wpdb;
    $in  = (int) ($usage['prompt_tokens']     ?? $usage['input_tokens']  ?? 0);
    $out = (int) ($usage['completion_tokens'] ?? $usage['output_tokens'] ?? 0);

    // preço de exemplo por 1k tokens (ajuste ao seu provedor)
    $cost = ($in / 1000 * 0.00015) + ($out / 1000 * 0.0006);

    $wpdb->insert("{$wpdb->prefix}ai_usage", [
        'feature'      => $feature,
        'tokens_in'    => $in,
        'tokens_out'   => $out,
        'cost_usd'     => $cost,
        'created_at'   => current_time('mysql'),
    ]);
}

Com uma semana de dados você descobre que, quase sempre, 20% das features consomem 80% do orçamento. É ali que vale otimizar — o resto é ruído.

Técnica 1: enxugue o contexto

O ganho mais rápido é mandar menos entrada. Em vez de despejar o documento inteiro, envie só o trecho relevante. Para tarefas repetidas, mova instruções fixas para uma instrução de sistema enxuta e pare de repetir exemplos que o modelo já domina. Uma regra prática: se você não consegue justificar por que cada parágrafo do prompt está ali, ele provavelmente está custando à toa.

Cuidado com o histórico de conversa: ele cresce a cada turno. Em fluxos longos, resuma os turnos antigos em uma frase e mantenha apenas os últimos completos. Isso sozinho costuma cortar de 30% a 50% da entrada em assistentes de várias trocas.

Técnica 2: pague uma vez por respostas repetidas

Boa parte do tráfego de automação é redundante — variações da mesma pergunta gerando a mesma resposta. Um cache evita pagar de novo pelo que você já gerou. O cache exato (mesma string, mesma resposta) é trivial; o pulo do gato é o cache por significado, que reaproveita respostas de perguntas parecidas. Cobrimos a implementação completa em cache semântico para LLM, mas o princípio já entra aqui: antes de chamar o modelo, pergunte se você não tem isso guardado.

Técnica 3: use o modelo certo para cada tarefa

Nem toda chamada precisa do modelo mais caro. Classificação, extração de campos e respostas curtas rodam bem em modelos menores e baratos; só o raciocínio difícil justifica o topo de linha. Encaminhar cada requisição ao modelo adequado — o que chamamos de roteamento de modelos de IA — costuma derrubar 40% a 60% do custo sem que o usuário perceba diferença na ponta.

Técnica 4: limite a saída e trate falhas com cabeça

Defina sempre max_tokens com folga realista para a tarefa: se a resposta deve ter 3 frases, não autorize 2.000 tokens. E troque o retry cego por uma estratégia que respeite o cabeçalho Retry-After e use recuo exponencial — repetir uma chamada que falhou por excesso de uso só multiplica o gasto. O tratamento correto de erro 429 e limite de requisições é tema à parte, mas a regra de custo é simples: nunca repita às cegas.

Impacto típico de cada alavanca

Checklist de custo de tokens

• Registre usage por feature e revise semanalmente.
• Corte do prompt tudo que você não consegue justificar.
• Defina max_tokens em todas as chamadas.
• Cacheie antes de chamar; reaproveite por significado.
• Mande o modelo barato no fácil e o caro só no difícil.
• Troque retry cego por backoff que respeita Retry-After.

Nenhuma dessas alavancas exige reescrever seu produto. Elas exigem visibilidade — quando você enxerga o custo por feature, as decisões ficam óbvias e a fatura volta a acompanhar o valor que você entrega, não o desperdício.