Otimização de tokens LLM estilo Headroom: reduzir custo de contexto sem quebrar respostas

Resposta rápida

A otimização de custo em LLMs deve começar pela qualidade do contexto, não por compressão cega. Um otimizador estilo Headroom fica entre a aplicação e o modelo, remove contexto de baixo valor, comprime saída ruidosa de ferramentas, reutiliza partes estáveis do prompt e roteia tarefas simples para modelos mais baratos quando a qualidade permite.

O objetivo não é "usar menos tokens a qualquer custo". O objetivo é:

Manter a qualidade da resposta estável.
Preservar instruções críticas de segurança.
Reduzir contexto repetido, irrelevante ou gerado por máquina.
Medir economias e regressões com o mesmo conjunto de testes.
Fazer rollout gradual com observabilidade e rollback.

Se seus prompts incluem logs longos, payloads JSON, resultados de busca, chunks RAG ou histórico repetido, vale testar otimização de contexto.

De onde vem o desperdício de tokens

A maioria das requisições LLM caras não é cara por causa de uma frase do usuário. Elas ficam caras porque a aplicação anexa contexto demais.

Fonte de desperdício	Exemplo	Melhor abordagem
Texto de sistema repetido	Mesmo bloco de política em todo turno	Cachear ou encurtar instruções estáveis
Saída ruidosa de ferramentas	Logs, stack traces, HTML, dumps JSON completos	Extrair campos relevantes antes de enviar
Chunks RAG grandes demais	20 passagens quando 4 bastam	Rerank e corte agressivo
Histórico longo	Todas as mensagens desde a primeira sessão	Resumir ou criar janela por recência e relevância
Roteamento errado de modelo	Classificação simples enviada a modelo grande	Rotear tarefas simples para modelos menores
Retentativas sem limite	Calls falhos reenviam contexto completo	Orçamentos de retry e estado intermediário cacheado

Uma arquitetura de otimização mais segura

Use camadas. Não aplique todas as otimizações de uma vez.

User request
  -> input normalization
  -> context selection
  -> tool/RAG output cleanup
  -> prompt assembly
  -> cache lookup
  -> model routing
  -> model call
  -> quality and cost logging

Cada camada deve ser mensurável e poder ser desativada independentemente.

Camada 1: seleção de contexto

Seleção de contexto decide o que o modelo realmente precisa.

Bons candidatos para remover:

Instruções duplicadas.
Turnos antigos que não são mais relevantes.
Documentos recuperados com baixa similaridade ou baixo rerank.
Campos de saída de ferramentas que a tarefa não usa.
Stack frames ou linhas de log repetidas.

Não remova:

Instruções de segurança e permissão.
Restrições do usuário.
Contratos de API.
Regras de negócio.
Proveniência de dados necessária para citações ou auditoria.

Regra de exemplo:

type ContextBlock = {
  id: string;
  source: "system" | "user" | "tool" | "rag" | "memory";
  text: string;
  score?: number;
  required?: boolean;
};

function selectContext(blocks: ContextBlock[], maxBlocks = 8) {
  const required = blocks.filter((block) => block.required);
  const optional = blocks
    .filter((block) => !block.required)
    .sort((a, b) => (b.score ?? 0) - (a.score ?? 0))
    .slice(0, maxBlocks);

  return [...required, ...optional];
}

Camada 2: compressão de saída de ferramentas

Saída de ferramentas costuma ser a maior fonte de tokens evitáveis. Logs, JSON, HTML, linhas de banco e saída CLI devem virar resumos específicos da tarefa antes de chegar ao modelo.

Saída de ferramenta	Envie isto em vez disso
Stack trace completo repetido 200 vezes	Erro único, frames principais, primeira/última ocorrência
500 linhas de banco	Agregados, anomalias, linhas de exemplo
HTML bruto	Texto extraído, links, headings, metadados
Resposta JSON completa	Campos necessários para a tarefa atual
Logs de testes	Testes falhos, assertions, blocos de erro relevantes

Exemplo:

function summarizeTestOutput(output: string) {
  const failed = output
    .split("\n")
    .filter((line) => /FAIL|Error:|AssertionError/.test(line));

  return failed.slice(0, 80).join("\n");
}

Isso é mais seguro que compressão genérica porque preserva evidências relevantes.

Camada 3: prompt caching

Muitos prompts contêm partes estáveis: instruções de sistema, regras de produto, schemas, guias de estilo e descrições de ferramentas. Mantenha blocos estáveis separados do contexto dinâmico para que caching funcione.

Montagem recomendada:

Stable:
  - system policy
  - output schema
  - product rules
  - tool descriptions

Dynamic:
  - current user request
  - selected history
  - selected retrieved passages
  - current tool output

Mesmo sem prompt caching do provedor, caching no nível da aplicação pode evitar recalcular retrieval, reranking e summarization caros.

Camada 4: model routing

Model routing pode reduzir custos quando tarefas têm níveis claros de complexidade.

Tipo de request	Rota típica
Classificação, extração, reescrita simples	Modelo pequeno/rápido
Resposta com retrieval e contexto curto	Modelo intermediário
Raciocínio complexo, coding, revisão legal	Modelo mais forte
Ação crítica de segurança ou dinheiro	Modelo mais forte mais revisão humana

O roteamento deve ser baseado em qualidade medida, não em intuição. Mantenha fallback: se o modelo barato estiver incerto ou falhar validação, tente novamente com um modelo mais forte.

function chooseModel(task: { type: string; risk: "low" | "medium" | "high"; tokens: number }) {
  if (task.risk === "high") return "strong-model";
  if (task.type === "classification" && task.tokens < 2000) return "small-model";
  if (task.tokens > 24000) return "long-context-model";
  return "balanced-model";
}

Meça qualidade antes de economia

Economia de tokens só é útil se a qualidade da saída continuar aceitável.

Acompanhe pelo menos:

Métrica	Por que importa
Input tokens	Direcionador direto de custo
Output tokens	Direcionador direto de custo
Task success rate	Principal sinal de qualidade
Human correction rate	Revela perdas sutis de qualidade
Validation failures	Captura regressões de schema e fatos
Escalation rate	Mostra se o roteamento está agressivo demais
Latency	Compressão pode adicionar overhead
Cost per successful task	Melhor que custo bruto por request

Faça A/B test com tráfego real ou casos históricos. Compare saídas otimizadas e baseline antes de habilitar rollout amplo.

Plano de rollout

Registrar uso de tokens por rota, ferramenta e feature.
Escolher um workflow de alto volume e baixo risco de negócio.
Adicionar apenas seleção de contexto.
Adicionar limpeza de saída de ferramentas.
Adicionar caching para componentes estáveis do prompt.
Adicionar model routing só depois que existir validação.
Fazer rollout por porcentagem.
Manter kill switch por feature.

Não comece por tarefas de alto risco como reembolsos, exclusão de conta, aconselhamento médico, revisão legal ou automação de segurança.

Armadilhas comuns

Comprimir o requisito real do usuário

A instrução mais recente do usuário quase sempre deve permanecer intacta. Comprima primeiro contextos antigos.

Resumir regras de segurança

Regras de segurança e permissão devem ser copiadas exatamente ou referenciadas por um bloco de política estável. Não deixe um summarizer enfraquecê-las.

Otimizar apenas custo médio

Uma tarefa importante que falha pode apagar economias de muitas requisições baratas. Acompanhe custo por tarefa bem-sucedida e custo de correção humana.

Rotear só pelo tamanho do prompt

Prompts curtos podem ser difíceis, e prompts longos podem ser simples. Use tipo de tarefa, risco, confiança de validação e desempenho histórico.

Esquecer auditabilidade

Se o contexto otimizado muda a resposta, você precisa saber o que foi removido, resumido, cacheado ou roteado de outro jeito.

FAQ

Otimização de tokens pode reduzir custo em 50% ou mais?

Às vezes, especialmente quando prompts contêm logs repetidos, grandes payloads JSON ou contexto recuperado em excesso. Mas a economia varia por workload. Meça sua própria baseline.

Compressão de contexto é segura?

Pode ser segura quando instruções obrigatórias são protegidas, saídas são validadas e rollout é gradual. Compressão cega é arriscada.

Devo usar um modelo menor para tudo?

Não. Modelos menores são úteis para tarefas simples, mas raciocínio complexo, decisões de alto risco e pedidos ambíguos precisam de modelos mais fortes ou revisão humana.

O que otimizar primeiro?

Comece por saída de ferramentas e contexto RAG. Eles geralmente contêm mais desperdício que a mensagem do usuário.

Resumo

Otimização de tokens estilo Headroom é melhor entendida como engenharia de contexto: selecionar melhor contexto, limpar saída ruidosa de ferramentas, cachear blocos estáveis do prompt, rotear por risco da tarefa e medir qualidade antes de celebrar economia. Feita com cuidado, pode reduzir custo e latência de LLM. Feita às cegas, pode remover exatamente a informação de que o modelo precisa.