Otimização
de Tokens
na AWS

INTRODUÇÃO

Por que tokens importam?

Em soluções com Large Language Models, tokens são simultaneamente a unidade de custo e a principal alavanca de latência. Cada caractere que entra ou sai do modelo tem um preço não sendo equivalentes, tokens de output costumam custar de 3 a 5 vezes mais do que tokens de input. Um agente mal arquitetado pode desperdiçar de 60% a 80% do orçamento reenviando contexto idêntico a cada requisição, sem nenhum ganho de qualidade.

O Amazon Bedrock expõe essa granularidade de forma direta: você paga por token de input e por token de output separadamente, com opções de caching que podem reduzir o custo de contexto fixo em até 90%. Entender como alocar o orçamento de tokens é tão estratégico quanto escolher o modelo certo.

ANATOMIA DO CUSTO

O que consome tokens?

Antes de otimizar, é necessário saber onde o dinheiro vai. Uma requisição típica a um LLM em produção é composta por múltiplos componentes, cada um com peso distinto no total de tokens consumidos:

Em aplicações com muitas ferramentas e histórico longo, o conteúdo da requisição pode facilmente ultrapassar 30.000 tokens antes de o usuário digitar uma palavra. Identificar qual componente domina o uso é o primeiro passo para qualquer otimização.

TÉCNICAS DE PROMPT

Escrever menos, comunicar mais

A otimização começa no próprio texto do prompt, antes de qualquer mudança de arquitetura:

• Elimine redundâncias: instruções como "responda em português", "seja preciso" e "não invente informações" repetidas em vários locais do system prompt multiplicam tokens sem acrescentar clareza. Centralize e remova duplicatas.
• Zero-shot antes de few-shot: exemplos no prompt (few-shot) custam centenas a milhares de tokens por requisição. Modelos modernos como os disponíveis no Bedrock executam bem com zero-shot em tarefas bem descritas. Reserve few-shot para casos onde a qualidade realmente exige.
• Controle o chain-of-thought: raciocínio estendido (extended thinking) melhora a qualidade em problemas complexos, mas gera grandes volumes de tokens de output. Limite o thinking budget ao mínimo necessário para a tarefa ou desative-o em fluxos operacionais simples.
• Structured output reduz verbosidade: solicitar resposta em JSON com schema definido elimina explicações desnecessárias do modelo. O output fica menor, mais previsível e dispensa pós-processamento.
• Comprima documentos antes de injetar: uma função Lambda intermediária pode sumarizar documentos longos antes de enviá-los ao LLM, reduzindo tokens de input sem abrir mão do conteúdo essencial.

PROMPT CACHING

Reutilizar é mais barato que reenviar

O Amazon Bedrock suporta caching de prompt para os modelos Claude: blocos marcados com cache_control são armazenados por até 5 minutos. Leituras subsequentes desse cache custam aproximadamente 10% do preço normal de input, gerando assim uma economia de 90% no conteúdo em cache.

Os candidatos naturais ao caching são componentes estáticos entre requisições: system prompt, tool definitions completas e documentos de referência fixos (manuais, políticas, bases de conhecimento pequenas). O conteúdo dinâmico, como mensagem do usuário ou histórico recente, nunca é cacheado e segue o preço padrão.

Estimativas baseadas em preço de input de USD 3/MTok para Claude Sonnet no Bedrock. Cache read: USD 0,30/MTok. Valores aproximados para referência.

O ponto crítico é o TTL de 5 minutos: o caching só gera economia quando o mesmo bloco de conteúdo é reutilizado em múltiplas requisições dentro desse janela. Dessa forma, agentes de uso intenso ou com padrões de uso elevados em momentos do dia se beneficiam muito dessa técnica. Por outro lado, agentes com uso intermitente vão ter ganhos marginais para um aumento de complexidade da solução, mesmo que seja um ajuste simples.

RAG vs. CONTEXT STUFFING

Recuperar é melhor que injetar tudo

Context stuffing é a prática de injetar documentos inteiros no prompt para que o modelo encontre a informação relevante. Funciona para documentos pequenos, mas escala mal: uma base de conhecimento de 500 páginas pode consumir centenas de milhares de tokens por requisição.

RAG (Retrieval-Augmented Generation) resolve esse problema recuperando apenas os trechos relevantes via busca semântica antes de construir o prompt. O Amazon Bedrock Knowledge Bases com OpenSearch realiza esse processo de forma gerenciada: o texto é dividido em chunks, vetorizado com embeddings e indexado. Na requisição, apenas os chunks com maior similaridade semântica à pergunta são recuperados e injetados no contexto.

A estratégia de chunking é o fator crítico em RAG: chunks muito pequenos perdem contexto, chunks muito grandes desperdiçam tokens. Para documentos estruturados, chunking semântico por seção supera o chunking por número fixo de tokens.

Para aprofundar a arquitetura de RAG na AWS, leia nosso artigo técnico:

DESIGN DE AGENTES

Arquitetura para eficiência

Agentes amplificam tanto a capacidade quanto o custo: cada passo do agente (raciocínio, chamada de ferramenta, resposta) consome tokens. Decisões de arquitetura têm impacto direto no orçamento:

• Agentes especializados vs. agente único: um agente generalista com 20 ferramentas envia todas as tool definitions a cada passo. Dividir em agentes especializados, cada um com 3 a 5 ferramentas, reduz o payload de instruções drasticamente. O Bedrock AgentCore suporta orquestração multi-agent com isolamento de contexto por subtarefa.
• Gestão do histórico de conversa: o histórico cresce indefinidamente se não for controlado. A estratégia mais eficiente combina uma janela deslizante (manter apenas as últimas N trocas) com sumarização periódica via Lambda: quando o histórico ultrapassa um limite de tokens, uma chamada ao LLM gera um resumo compacto que substitui as mensagens antigas no DynamoDB.
• Tool definitions enxutas: descrições de ferramentas longas e exemplos de uso dentro das definições somam tokens a cada requisição. Prefira descrições curtas e precisas; reserve exemplos para o system prompt quando forem realmente necessários.
• Evite loops desnecessários: agentes que chamam ferramentas em excesso antes de responder multiplicam o custo por cada passo. Defina critérios de parada claros no system prompt e limite o número máximo de iterações no orquestrador.
• Cache o sistema, não a conversa: o system prompt e as tool definitions são candidatos ao cache_control; a conversa em si não. Separar claramente o que é estático do que é dinâmico maximiza o aproveitamento do caching.

ESCOLHA DO MODELO

O modelo certo para cada tarefa

A escolha do LLM é uma das decisões com maior impacto no custo total de uma solução. Modelos mais capazes são significativamente mais caros e nem toda tarefa precisa deles. A tabela abaixo compara os principais modelos disponíveis no Amazon Bedrock:

Preços aproximados no Amazon Bedrock. Consulte a página de preços oficial para valores atualizados.

A regra prática é direta: use o modelo mais barato que entregue a qualidade necessária para cada subtarefa. Classificar um documento, extrair um campo estruturado ou fazer triagem de intenção são operações que modelos como o Nova Micro ou Claude Haiku executam com excelência a uma fração do custo de um Sonnet ou Opus. Reservar modelos de alta capacidade apenas para o que realmente exige raciocínio profundo é, muitas vezes, a otimização de maior impacto em uma solução.

Prompt routing no Bedrock AgentCore: em arquiteturas multi-agent, o orquestrador pode rotear cada subtarefa para o modelo mais adequado, delegando raciocínio complexo ao Sonnet ou Opus, e tarefas operacionais ao Haiku ou Nova Lite. O Bedrock AgentCore suporta essa orquestração nativamente: cada agente especializado pode ser configurado com um modelo distinto conforme o perfil da tarefa. O resultado é uma arquitetura onde qualidade e custo são otimizados em conjunto, sem comprometer a capacidade de entrega.

CONCLUSÃO

Checklist de otimização

Otimizar tokens não é cortar qualidade, é eliminar desperdício. A maior parte do custo em soluções LLM vem de contexto repetido, documentos injetados em excesso e histórico não gerenciado. As técnicas abaixo podem ser aplicadas de forma incremental, priorizando pelo impacto esperado:

• Identificar qual componente domina o uso de tokens (anatomia do custo)
• Aplicar prompt caching no system prompt e tool definitions
• Substituir context stuffing por RAG para bases de conhecimento
• Adotar structured output (JSON schema) para respostas previsíveis
• Implementar janela deslizante + sumarização no histórico de agentes
• Especializar agentes para reduzir o escopo de tool definitions por requisição
• Usar o modelo mais barato adequado a cada subtarefa e configurar prompt routing no AgentCore
• Limitar ou desativar chain-of-thought em fluxos operacionais simples
• Monitorar uso de tokens por componente no Amazon CloudWatch

Aplicadas em conjunto, essas práticas costumam reduzir o custo total de soluções com LLMs em 50 a 80% sem perda de qualidade perceptível, e com ganho de latência como bônus.