Qual é a ordem certa para otimizar os custos dos LLMs?

Ative primeiro o cache de prompts, reduza o prompt de sistema, elimine definições de ferramentas desnecessárias, encaminhe os pedidos por tarefa e processe em lote o tráfego fora de produção. Considere o fine-tuning apenas no fim.

Porque é que o fine-tuning costuma ser um mau primeiro passo?

Um relato de produção de setembro de 2026 descreve manutenção pesada e qualidade em queda ao ajustar um modelo para trabalho repetitivo. A poupança esperada abrangia 15 % do volume e 2 % da despesa.

Quanto pode poupar o cache de prompts?

No Opus 5.5, um milhão de tokens lidos do cache custa 0,20 $ contra 4,00 $ de entrada nova: 95 % de desconto nesses tokens. Com um prefixo repetido, a redução total estimada no exemplo pode chegar a 40–70 %.

Devo remover definições de ferramentas pouco usadas?

Sim, se as ferramentas forem dispensáveis. Cada definição ocupa contexto em todos os pedidos, mesmo sem utilização. A sua remoção evita enviar tokens desnecessários.

Ordem das otimizações de custos de LLMs

Atualizado September 27, 2026 · publicado originalmente September 27, 2026

Em setembro de 2026, uma discussão no r/LLMDevs perguntou como as equipas controlam de facto os custos dos LLMs em produção e o que fariam se o tempo de engenharia não fosse um limite. A resposta mais votada trouxe uma lição importante: a ordem das medidas conta muito mais do que se admite. A equipa começou por usar cache de prompts e reduzir bastante os prompts de sistema. A tentativa de ajustar um modelo pequeno para tarefas repetitivas correu mal: a manutenção tornou-se pesada e a qualidade continuou a degradar-se.

A ordem que funciona

Ativar o cache de prompts. É uma das horas de engenharia com maior retorno. No Opus 5.5, um milhão de tokens lidos do cache custa 0,20 $ contra 4,00 $ por um milhão de tokens de entrada novos: um desconto de 95 % nessa rubrica. Se o prompt de sistema, as definições das ferramentas ou o contexto recuperado se repetem, comece aqui.
Reduzir o prompt de sistema. A mesma resposta destacou esta medida. Instruções extensas são cobradas em todas as chamadas. É sobretudo um trabalho de escrita clara, não de engenharia.
Remover ferramentas não utilizadas. Cada definição segue no contexto de todos os pedidos, mesmo quando a ferramenta não é chamada. É o mesmo custo adicional das definições de ferramentas MCP. Retirar uma ferramenta pode exigir apenas uma linha de configuração e produzir uma poupança contínua.
Encaminhar conforme a tarefa. Só nesta fase é que o roteamento entre modelos compensa plenamente. Um sistema de roteamento criado depois do cache já parte de custos mais baixos antes de trocar um único modelo.
Processar em lote ou adiar. Uma API de lotes oferece um desconto direto para tarefas que dispensam uma resposta imediata ao utilizador. Sempre que adequado, o tráfego fora de produção deve usar lotes desde o início.
Deixar o fine-tuning para o fim, se for preciso. É uma medida a que muitas equipas recorrem primeiro e que falhou neste caso. A manutenção e a perda de qualidade criam um custo operacional permanente por uma poupança que o cache e o roteamento poderão já ter proporcionado.

Porque é que a ordem faz diferença

Cada passo altera a quantidade de tokens e o custo sobre os quais o passo seguinte atua. Reduzir o prompt de sistema antes do roteamento permite que um modelo mais barato trate mais pedidos com a mesma lógica. Ativar o cache antes de ajustar um modelo limita a justificação do investimento no ajuste aos pedidos que falham o cache. Pela ordem errada, paga-se duas vezes: por um ajuste que uma revisão do prompt teria evitado, ou por um sistema de roteamento que envia 60 mil tokens de instruções para um modelo económico incapaz de os tratar bem.

O erro recorrente

Na discussão, o problema foi ajustar um modelo pequeno para trabalho repetitivo. A poupança pretendida era plausível, mas cada alteração nesse trabalho exigia novo treino. À medida que o modelo de base era atualizado, a qualidade da versão ajustada ficava para trás. O esforço de operação tornou-a difícil de manter. Esse trabalho representaria talvez 15 % do volume e 2 % da despesa: uma poupança pequena com um custo recorrente elevado.

Experimentar a sequência num pedido

Escolha um pedido representativo, aplique cada passo pela ordem indicada e registe os tokens faturados e o custo:

Passo	O que muda	Redução típica indicada
Ativar o cache	O prefixo repetido passa a ser lido do cache	40–70 %
Reduzir o prompt de sistema	Menos tokens sem cache por chamada	10–25 %
Remover ferramentas não utilizadas	Bloco de ferramentas menor	5–15 %
Roteamento	Modelo mais barato para a maioria dos pedidos	30–60 %
Lotes fora de produção	Tarifa com desconto	25–50 % desse tráfego

Os efeitos acumulam-se. Neste exemplo, o mesmo pedido pode ficar 80–90 % mais barato. Começar pelo fine-tuning pode, pelo contrário, deixar a equipa com um modelo ajustado para 15 % do volume e uma regra de roteamento que nunca se paga. Os valores associados ao cache e ao roteamento referem-se à poupança de custos; o roteamento por si só não diminui o número de tokens.

Conclusão

O cache, a redução dos prompts e a remoção de ferramentas não utilizadas são medidas baratas, relativamente pouco arriscadas e cumulativas. Seguem-se o roteamento e o processamento em lote. O fine-tuning fica para o fim, caso ainda seja necessário. O desafio está na sequência.