5.1 — Métricas de Custo Computacional e Economia de Contexto

Objetivo da Aula

Explicar o mecanismo da "inflação de tokens" e por que o custo de um sistema de IA cresce mais rápido do que o valor de negócio que ele entrega

Decompor o custo de uma chamada de LLM nos seus componentes reais: tokens de entrada, tokens de saída, overhead de sistema e reaproveitamento de cache

Calcular o custo efetivo de um fluxo de agente multi-turno, incluindo o efeito cumulativo do contexto reenviado a cada rodada

Definir métricas de economia de contexto que orientam decisões arquiteturais: custo por tarefa, custo marginal por turno, taxa de reaproveitamento

Identificar em quais pontos do harness o crescimento de contexto é estrutural — parte do desenho — e não um acidente de implementação

Por que isso importa

Todo arquiteto que já colocou um agente autônomo em produção viu a mesma curva: o protótipo custava centavos por execução, e três meses depois a fatura mensal de API virou pauta de reunião com o CFO. Isso não é um bug do fornecedor de modelo. É uma propriedade estrutural de como agentes conversam consigo mesmos: cada novo turno de raciocínio reenvia o histórico inteiro da conversa, porque o modelo não tem memória entre chamadas — o harness é quem carrega o contexto para frente, a cada requisição, do zero.

Chamamos esse fenômeno de inflação de tokens: o custo por unidade de trabalho útil cresce ao longo do tempo de vida de uma sessão, mesmo que a complexidade da tarefa não mude. Um arquiteto que não modela essa curva desenha sistemas que funcionam perfeitamente em demonstração e quebram o orçamento em produção — não porque o modelo ficou mais caro, mas porque ninguém mediu o efeito cumulativo do contexto.

Impacto direto no seu trabalho: decisões como "quantos turnos um agente pode ter antes de resetar contexto", "que tamanho de janela de contexto contratar" e "quando vale a pena sumarizar histórico" são decisões de custo, tomadas na fase de arquitetura — não ajustes de produção feitos depois que a fatura assusta alguém. Este capítulo dá o vocabulário e a matemática para tomar essas decisões com números, não com intuição.

Conceitos Fundamentais

O que é inflação de tokens

Inflação de tokens é o crescimento do número de tokens processados por unidade de trabalho útil, ao longo do tempo de vida de uma sessão, tarefa ou fluxo de negócio. Não é o preço do token que sobe — é a quantidade de tokens que uma mesma tarefa consome que cresce, porque o contexto necessário para manter o modelo "situado" cresce junto.

Turno 1: pergunta simples
  Contexto enviado: 400 tokens (prompt de sistema + pergunta)
  Resposta: 150 tokens
  Total do turno: 550 tokens

Turno 5 (mesma tarefa, sessão contínua, sem poda de contexto):
  Contexto enviado: 400 (sistema) + 4×(pergunta+resposta anteriores) ≈ 3.200 tokens
  Resposta: 150 tokens
  Total do turno: 3.350 tokens

Turno 5 custa 6x mais que o Turno 1 — para fazer o MESMO tipo de trabalho.

O ponto crítico: o modelo não ficou "mais caro". A tarefa não ficou mais difícil. O que cresceu foi o volume de contexto que o harness precisa reenviar a cada chamada para que o modelo continue com a conversa inteira "na cabeça" — porque LLMs são, por natureza, sem estado (stateless) entre chamadas de API.

Anatomia do custo de uma chamada

Toda chamada a um modelo de linguagem tem, no mínimo, quatro componentes de custo. Entender cada um separadamente é o primeiro passo para instrumentar telemetria de verdade (assunto do próximo capítulo).

Custo total da chamada =
    (tokens_entrada × preço_input)
  + (tokens_saida  × preço_output)
  + overhead_sistema
  - desconto_cache

Onde:
  tokens_entrada  = prompt de sistema + histórico + ferramentas + pergunta atual
  tokens_saida    = resposta gerada pelo modelo (inclui raciocínio interno, se exposto)
  overhead_sistema = definições de tools/skills injetadas a cada chamada (Parte 1, Capítulo 1.5)
  desconto_cache   = redução de preço quando parte do prompt já foi processada antes

Note a assimetria de preço entre entrada e saída: na maioria dos provedores de modelos de linguagem, o token de saída custa vários múltiplos do token de entrada — porque gerar é computacionalmente mais caro que ler. Isso muda o cálculo de decisões como "vale a pena pedir para o modelo justificar a resposta em texto longo, ou só o resultado final".

Uma tabela de referência ilustrativa (não são preços reais de nenhum fornecedor — servem só para o raciocínio de ordem de grandeza) ajuda a fixar a escala:

* valores hipotéticos, apenas para ilustrar ordem de grandeza e a razão input/output — não usar como referência de preço de mercado.

A razão constante de 5x entre output e input nesta tabela ilustrativa não é coincidência de exemplo: em praticamente todo provedor de mercado, o token de saída custa entre 4x e 6x o token de entrada. É por isso que respostas verbosas — o modelo "pensando alto" antes de responder — custam desproporcionalmente mais do que aumentar o contexto de entrada em volume equivalente.

O efeito cumulativo em loops de agente

Onde a inflação de tokens realmente dói é em agent loops (ReAct, Plan-Execute — Capítulo 1.6): cada iteração do loop reenvia o histórico de raciocínio e ações anteriores, porque o harness precisa que o modelo "lembre" o que já tentou. Sem poda de contexto, o crescimento não é linear — é quadrático em relação ao número de turnos.

Suponha um agente com N turnos, cada turno adicionando em média
T tokens novos ao histórico (pergunta + resposta + resultado de tool call).

Sem poda de contexto, tokens enviados no turno i = i × T
(porque o turno i reenvia o histórico acumulado dos i-1 turnos anteriores)

Total de tokens de ENTRADA processados ao longo de N turnos:
  Soma = T × (1 + 2 + 3 + ... + N) = T × N×(N+1)/2

Exemplo concreto: T = 800 tokens/turno, N = 20 turnos
  Soma = 800 × (20×21/2) = 800 × 210 = 168.000 tokens de entrada

Comparação ingênua (se cada turno custasse só os seus próprios T tokens):
  N × T = 20 × 800 = 16.000 tokens

Custo real / custo ingênuo = 168.000 / 16.000 = 10,5x

Esse fator de ~10x não é um caso extremo — é o comportamento padrão de qualquer loop de agente sem estratégia de contenção de contexto rodando por 20 turnos. Em loops mais longos (50, 100 turnos, comuns em tarefas de investigação ou depuração autônoma), o fator de inflação cresce ainda mais, porque o termo N×(N+1)/2 é quadrático — dobrar o número de turnos aproximadamente quadruplica o total de tokens processados, não apenas dobra.

Do custo por chamada ao custo por unidade de valor de negócio

Custo por chamada de API é uma métrica de infraestrutura — útil, mas não é a métrica que importa para decisão de arquitetura. A métrica que importa é o custo por unidade de valor de negócio entregue: custo por ticket de suporte resolvido, custo por Pull Request revisado, custo por documento processado, custo por decisão tomada.

Custo por unidade de valor = Custo total do fluxo / Unidades de valor entregues

Exemplo: agente de triagem de tickets de suporte
  Custo total em 1 mês: US$ 4.200 (chamadas de API, todos os tiers usados)
  Tickets triados no mês: 12.000
  Custo por ticket triado = 4.200 / 12.000 = US$ 0,35

Comparação com alternativa humana:
  Custo por ticket triado por humano (tempo médio × custo/hora): US$ 2,10

Conclusão de arquitetura: o agente é 6x mais barato por unidade —
MAS essa conclusão só é válida se a taxa de acerto do agente for
comparável à do humano. Custo sem controle de qualidade é meia métrica.

Esse reenquadramento muda a pergunta do arquiteto. Em vez de "como reduzo o custo por chamada de API", a pergunta correta é "como reduzo o custo por ticket resolvido, mesmo que isso signifique gastar mais tokens numa chamada específica que evita retrabalho depois". Um agente que gasta 3x mais tokens numa única passada, mas resolve o ticket sem precisar de correção humana posterior, pode ser mais barato no agregado do que um agente econômico por chamada que erra 20% das vezes.

Aprofundamento Técnico

Por que o crescimento é estrutural, não acidental

É tentador tratar inflação de tokens como um bug de implementação — "esquecemos de podar o histórico". Na prática, é uma tensão arquitetural inerente: o harness precisa de contexto suficiente para o modelo tomar decisões coerentes (Parte 1, Capítulo 1.2 — Engenharia de Contexto Sistêmico), e mais contexto sempre custa mais tokens. Não existe uma configuração onde esse trade-off desaparece — só existem pontos de equilíbrio diferentes.

Contexto insuficiente          Contexto excessivo
        |                              |
        v                              v
Modelo perde o fio,           Modelo processa (e paga por)
repete trabalho já feito,     informação irrelevante,
alucina decisões já tomadas   dilui atenção em ruído,
                               aumenta custo sem aumentar qualidade

                    Ponto de equilíbrio:
        contexto mínimo suficiente para decisão coerente
     (não existe fórmula fixa — depende da tarefa e do modelo)

O trabalho do arquiteto não é eliminar o crescimento de contexto — é decidir, com métricas, onde fica o ponto de equilíbrio para cada fluxo de negócio, e instrumentar o sistema para alertar quando um fluxo específico sai desse ponto (por exemplo, um agente que deveria resolver uma tarefa em 5 turnos e está indo para o turno 30 sem convergir — sintoma clássico de loop sem critério de parada, tratado no Capítulo 1.6).

O papel do cache de prompt na curva de custo

Um dos alavancas mais efetivas contra inflação de tokens é o reaproveitamento de prefixos de prompt já processados — genericamente chamado de prompt caching. A ideia central: se o início do prompt (prompt de sistema, definições de ferramentas, primeiros turnos da conversa) não muda entre chamadas, o provedor de modelo pode reaproveitar o processamento já feito, cobrando uma fração do preço normal por esses tokens "reaproveitados".

Sem cache:
  Turno 10: 6.000 tokens de contexto, todos cobrados a preço cheio
  Custo do turno = 6.000 × preço_input

Com cache (assumindo 80% do contexto é prefixo estável, reaproveitável,
e o desconto de cache hipotético é de 90% sobre o preço normal):
  4.800 tokens em cache × (preço_input × 0,10) = 4.800 × 0,10 × preço_input
  1.200 tokens novos × preço_input (preço cheio)
  Custo do turno ≈ 480×preço_input + 1.200×preço_input = 1.680×preço_input

Redução de custo no turno: (6.000 - 1.680) / 6.000 ≈ 72%

Esse mecanismo não elimina a inflação de tokens — ela ainda cresce com o número de turnos — mas achata drasticamente a inclinação da curva, porque parte crescente do contexto histórico passa a ser cobrada com desconto em vez de preço cheio. A arquitetura de payload que maximiza o aproveitamento de cache (mantendo a parte estável do prompt no início, e a parte variável no final) é o assunto central do Capítulo 5.4.

Métricas arquiteturais recomendadas

Para transformar tudo isso em prática de engenharia, três métricas merecem posição permanente em qualquer painel de FinOps de IA — o próximo capítulo (5.2) detalha como instrumentar cada uma:

Nenhuma dessas métricas substitui as outras. Custo marginal por turno é um sinal operacional de curto prazo (alerta em tempo real de loop descontrolado). Taxa de reaproveitamento de cache é um sinal de eficiência de engenharia de payload. Custo por unidade de valor é o sinal que justifica — ou não — a existência do sistema perante o negócio. Um arquiteto de IA em produção acompanha as três ao mesmo tempo, porque otimizar só uma delas isoladamente pode piorar as outras: reduzir contexto agressivamente barateia o custo marginal por turno, mas pode aumentar retrabalho e piorar o custo por unidade de valor.