Mesmo depois de ajustados os prompts e a lógica da aplicação, a fatura de inferência do Amazon Bedrock pode continuar a crescer. As decisões tomadas em cada requisição ainda influenciam quantos tokens o serviço processa e a tarifa aplicada a eles. Quatro configurações em particular — duração do cache, nível de serviço, esforço de raciocínio e maxTokens — podem alterar o custo sem mudar o modelo nem o prompt.
O comportamento de cada opção depende do modelo e da carga de trabalho. A publicação original explica como cada alternativa foi testada e como verificar seu efeito a partir dos metadados de resposta, dos logs e dos dados de faturamento.
Quem quiser reproduzir essas configurações pode começar pelos notebooks do Amazon Bedrock Samples Mixed TTL Caching e Tenant Isolation with Prompt Caching. Para maxTokens e esforço de raciocínio, a pasta 01-low-effort do repositório do GitHub sample-code-for-genai-cost-management-workshop contém os exemplos correspondentes. Cada amostra define seu próprio ID de modelo, que deve ser substituído, junto com os parâmetros de inferência, para corresponder ao modelo utilizado. A disponibilidade de modelos por região da AWS está em Models at a glance, enquanto decisões mais amplas — seleção de modelos, inferência em lote, roteamento e destilação — são tratadas em Effective cost optimization strategies for Amazon Bedrock.
De onde vem o custo de inferência
Toda resposta do Amazon Bedrock traz metadados de uso. Os tokens de entrada e saída são cobrados pela tarifa do modelo e do nível que atendeu a requisição. Leituras e escritas de cache têm contadores de tokens próprios, e os tokens de raciocínio são cobrados como tokens de saída.
Duração do cache de prompts
Quando uma entrada de cache expira antes da chegada da próxima requisição, instruções de sistema, definições de ferramentas ou contexto de referência repetidos voltam a ser processados. O guia Prompt caching for faster model inference documenta valores de TTL de 5 minutos e 1 hora para os modelos Anthropic compatíveis e um TTL mínimo de 30 minutos para os modelos GPT-5.6 compatíveis. A compatibilidade e os campos de API variam conforme o modelo, por isso a matriz de suporte vigente deve ser consultada antes de escolher uma duração.
O Amazon Bedrock também oferece cache implícito de prompts em modelos compatíveis: ele tenta reutilizar prefixos de prompt elegíveis sem controles de cache na requisição. Como o cache implícito é de melhor esforço e não garante acerto, as opções de duração desta seção se referem ao cache explícito.
Nos modelos que o suportam, esta assinatura da API Converse solicita uma entrada de 1 hora:
{ "cachePoint": { "type": "default", "ttl": "1h" } }
Nos modelos Anthropic compatíveis, o InvokeModel coloca o mesmo valor ttl dentro de cache_control.
Uma duração maior não é automaticamente mais barata. A página Amazon Bedrock Pricing publica tarifas distintas para escritas de 5 minutos, escritas de 1 hora e leituras de cache. No Amazon Bedrock, uma escrita de 5 minutos para Anthropic Claude Sonnet 5 e Anthropic Claude Opus 5 custa 1,25 vez a tarifa de entrada; uma escrita de 1 hora custa 2 vezes e uma leitura de cache custa 0,1 vez.
Essas tarifas definem o ponto de equilíbrio, supondo que cada requisição reutilize o mesmo prefixo e que cada leitura renove o TTL. Um cache de 5 minutos se paga na primeira reutilização dentro desses 5 minutos. Se as requisições com o mesmo prefixo chegarem com mais de 5 minutos de intervalo, cada uma reescreve a entrada a 1,25 vez a tarifa de entrada; nesse padrão, o cache de 1 hora sai mais barato a partir da segunda requisição dentro da hora.
As tarifas de cache e os mínimos de checkpoints diferem por modelo, portanto a comparação deve ser refeita na página de preços e no guia de cache de prompts do modelo utilizado e depois confirmada com os tokens de leitura e escrita de cache após a implantação.
Orientações práticas: manter o conteúdo estável antes do dinâmico, cumprir o mínimo de checkpoints do modelo e usar inferência sob demanda, pois o cache de prompts não funciona com inferência em lote.
Alterar um prefixo em cache — seja uma instrução de sistema ou uma definição de ferramenta — gera uma falha de cache e uma nova escrita. Os checkpoints são avaliados na ordem ferramentas, sistema e mensagens, de modo que uma mudança numa seção anterior também invalida as posteriores. Prompts que mudam com frequência devem ser versionados para que cada versão receba sua própria entrada de cache. No teste do autor, seis chamadas ao Claude Sonnet 5 com um checkpoint de 1 hora, alterando uma vez o prompt de sistema e uma vez a definição de ferramenta, produziram em cada mudança zero leituras de cache e uma nova escrita.
A AWS descreve as entradas de cache como limitadas à conta e à região, não aos locatários. Em uma aplicação multilocatário, um hash SHA-256 específico do locatário pode ser prefixado ao trecho armazenável em cache, padrão descrito em Optimizing cost and latency with Amazon Bedrock prompt caching for Anthropic models. A autorização do locatário deve ser aplicada antes da montagem do prompt. O hash particiona as entradas dentro de uma mesma conta; cargas de trabalho reguladas que exijam uma fronteira rígida de dados devem manter cada locatário em uma conta AWS separada.
O padrão de 5 minutos é adequado para reutilização frequente. Vale passar para uma duração maior suportada quando o mesmo prefixo se repete pelo menos duas vezes por hora com intervalos maiores que 5 minutos. Para superar a ausência total de cache, o cache de 1 hora precisa de três requisições por hora.
Níveis de serviço para cargas tolerantes a latência
Trabalhos em segundo plano, arneses de avaliação, sumarizações noturnas e backfills nem sempre precisam do perfil de latência do tráfego interativo. Nos modelos que suportam Flex, ele é selecionado com esta assinatura de requisição:
{ "serviceTier": { "type": "flex" } }
O nível Standard é solicitado com default, não com standard, e o serviceTier também pode ser omitido:
{ "serviceTier": { "type": "default" } }
O suporte a níveis é específico de cada modelo e deve ser registrado por versão exata. Os cartões de modelo do Amazon Nova 2 Lite e do OpenAI gpt-oss-120b listam Flex como suportado, enquanto os do Anthropic Claude Sonnet 5 e do Anthropic Claude Opus 5 no Amazon Bedrock o marcam como não suportado. Uma requisição Flex enviada a um modelo não suportado falha com uma ValidationException em vez de rodar silenciosamente em Standard: a requisição do autor ao Claude Sonnet 5 retornou exatamente esse erro.
Se a política permitir Standard como alternativa, o erro de nível não suportado pode ser capturado e repetido uma vez com default. Nem toda ValidationException deve ser repetida, pois requisições malformadas geram a mesma exceção. As repetições no nível da aplicação devem ser limitadas; a estratégia de repetição limitada do SDK da AWS já trata limitação e erros transitórios.
As requisições Flex precisam de um prazo definido por quem as chama. Uma resposta suportada informa o nível resolvido, que também pode ser verificado pela métrica ResolvedServiceTier do Amazon CloudWatch. As tarifas exatas constam em Service tiers for optimizing performance and cost e na página Amazon Bedrock Pricing do modelo em questão.
O teste de Flex do autor no Amazon Nova 2 Lite usou 200 requisições default e 200 flex enviadas em pares intercalados. Os dois níveis processaram a mesma quantidade de tokens de entrada e saída, todas as 400 requisições foram resolvidas no nível solicitado e a diferença mediana de latência foi pequena demais para se separar do ruído. No momento da redação, a tarifa Flex publicada para o Nova 2 Lite em us-west-2 era a metade da tarifa Standard, e a fatura refletiu isso. O tráfego sensível à latência deve permanecer em default.
Esforço de pensamento adaptativo
Os tokens de raciocínio são cobrados como tokens de saída. Claude Sonnet 5 e Claude Opus 5 executam o pensamento adaptativo com esforço high por padrão, mesmo quando a requisição omite o campo thinking. Uma aplicação migrada do Claude Sonnet 4.6 sem alterações passa então a ser cobrada por tokens de pensamento, e o maxTokens agora limita o pensamento mais o texto da resposta. Claude Haiku 5.5 usa medium por padrão. Os três modelos aceitam low, medium, high, xhigh e max. O esforço de uma tarefa é reduzido com esta assinatura de requisição:
{
"thinking": { "type": "adaptive" },
"output_config": { "effort": "low" }
}
O valor de effort pertence a output_config, não ao interior de thinking. A documentação Adaptive thinking deve ser consultada sempre que o modelo mudar.
O autor testou um agente com chamadas de ferramentas sobre o Claude Opus 5. Suas três tarefas seguem o desenho de Build long-horizon agents with Grok 4.7 on Amazon Bedrock e cada uma tem uma única resposta correta. Cada tarefa foi executada oito vezes em cada nível de esforço. Mediana de tokens de saída:
| Esforço | Execuções corretas | Mediana de tokens de saída | Mudança em relação a low (intervalo de 95%) |
|---|---|---|---|
| low | 24 de 24 | 936 | referência |
| medium | 24 de 24 | 1.484 | +59% (50% a 78%) |
| high (padrão) | 24 de 24 | 2.521 | +169% (112% a 190%) |
| xhigh | 24 de 24 | 2.964 | +217% (170% a 260%) |
| max | 24 de 24 | 3.762 | +302% (180% a 402%) |
Se um esforço menor preserva a precisão depende do modelo e da tarefa, portanto a medição deve ocorrer em tarefas semelhantes à carga real.
Na carga de trabalho Invoke Bedrock model for code generation do Amazon Bedrock Samples, a mediana de tokens de saída foi de 676 em low e de 743 em high, diferença dentro da variação entre execuções, e os programas avaliados passaram em todos os níveis.
As contagens de tokens de saída por requisição, a métrica AWS/Bedrock OutputTokenCount do CloudWatch, os logs de invocação e uma taxa de acerto por tarefa permitem avaliar o ajuste. Tarefas rotineiras e bem delimitadas podem começar abaixo de high; high deve ser mantido onde os testes de qualidade mostrarem que a tarefa precisa dele. Uma redução de tokens que quebra a tarefa não é economia.
Limites de tokens de saída
O maxTokens funciona como um teto de saída no nível da aplicação: limita o que um prompt ruim, uma regressão ou um loop podem gerar antes de a requisição parar. A regra de cota está documentada em How tokens are counted in Amazon Bedrock: o serviço deduz os tokens de entrada mais o maxTokens quando a requisição começa, de modo que um valor superdimensionado reduz a concorrência.
Um teto de saída não é um controle de segurança. O Amazon Bedrock Guardrails continua sendo o controle padrão de IA responsável em cargas de IA generativa em produção: pode filtrar conteúdo, detectar ataques de prompt e verificar o aterramento em entradas e respostas compatíveis, conforme descrito em Detect and filter harmful content by using Amazon Bedrock Guardrails.
O maxTokens deve ser definido por tipo de tarefa após a observação de uma distribuição representativa de tokens de saída:
{ "inferenceConfig": { "maxTokens": 155 } }
Os parâmetros de requisição estão documentados em Inference using Converse API.
No teste do autor no Claude Sonnet 5, cinco saídas normais atingiram no máximo 103 tokens, então foi escolhida uma cerca ilustrativa de 155 tokens com folga. Em seguida, o mesmo prompt deliberadamente verboso foi enviado duas vezes com o pensamento adaptativo desativado: uma sob um teto de 2.048 tokens e outra sob a cerca de 155. A primeira gerou 2.048 tokens de saída e a segunda 155, ou seja, a cerca evitou 1.893 tokens de saída. As duas requisições pararam em max_tokens, portanto ambas as respostas foram truncadas. Uma cerca limita o gasto, mas não torna útil um prompt inadequado, e dentro de uma cadeia de vários turnos ou agêntica um turno truncado pode quebrar as etapas seguintes.
Para a calibração em produção, os percentis 95 e 99 (P95 e P99) de cada tipo de tarefa devem ser comparados, com folga adicionada ao percentil escolhido. Com o pensamento adaptativo ativado, o maxTokens também limita os tokens de pensamento, então a calibração deve ser feita com o pensamento habilitado. P95 restringe a exposição de forma mais agressiva, mas aceita maior risco de truncamento; P99 preserva mais respostas válidas de cauda longa com um teto mais alto. Paradas por max_tokens devem ser monitoradas e a requisição investigada antes de elevar o limite da tarefa.
Juntando tudo
O mesmo ciclo de teste vale para cada configuração: confirmar o suporte do modelo, alterar uma única opção de requisição, medir tokens ou custo e acompanhar qualidade ou conclusão. Equipes que roteiam entre modelos devem manter um registro de capacidades por versão de modelo, região e API — duração de cache suportada, níveis de serviço, níveis de raciocínio e teto de saída —, validar cada requisição contra esse registro antes do envio e depois conferir na resposta o nível resolvido e os contadores de cache.
| Configuração | Estado padrão ou permissivo | Resultado | Risco a aceitar |
|---|---|---|---|
| Duração do cache | TTL específico do modelo | Pelas tarifas publicadas do Sonnet 5 e do Opus 5, um cache de 1 hora vence a partir da segunda requisição por hora quando os intervalos passam de 5 minutos | Uma escrita de 1 hora custa 2 vezes a entrada, então reutilização baixa perde dinheiro; particionar os prefixos por locatário |
| Nível de serviço | default | No momento da redação, o Flex do Nova 2 Lite estava publicado à metade da tarifa Standard e a fatura medida confirmou | Processamento mais longo; definir prazo próprio e alternativa |
| Esforço de raciocínio | high no modelo adaptativo testado | De low a high: +169% na mediana de tokens de saída no teste do agente, sem diferença confiável na geração de código | A qualidade pode cair perto do limite de capacidade da tarefa; acompanhar a taxa de acerto junto com os tokens |
| maxTokens | Teto permissivo de 2.048 tokens | Uma cerca ilustrativa de 155 tokens evitou 1.893 tokens de saída em um teste | O truncamento pode se propagar em cadeias de vários turnos ou agênticas; verificar stopReason antes de elevar o limite |
Sinais a observar
| Configuração | Sintoma | Verificar com | Primeira resposta |
|---|---|---|---|
| Duração do cache | O contexto repetido não produz o benefício esperado de latência ou custo | Telemetria de latência e custo da aplicação | Verificar estabilidade do prefixo, intervalo de reutilização e suporte do modelo antes de mudar o TTL |
| Nível de serviço | O nível solicitado não é suportado ou o nível de atendimento difere do esperado | serviceTier da resposta e ResolvedServiceTier do CloudWatch | Usar um nível suportado ou devolver o tráfego sensível a latência para default |
| Esforço de raciocínio | Os tokens de saída sobem enquanto a qualidade se mantém | Telemetria por requisição, OutputTokenCount do CloudWatch, logs de invocação e taxa de acerto da tarefa | Reduzir o esforço para essa classe de tarefa e repetir seu teste de qualidade |
| maxTokens | stopReason é max_tokens | Motivo de parada da resposta e distribuição de tokens de saída por tarefa | Inspecionar o prompt e a cerca da tarefa antes de elevar o limite |
Os percentis P95 e P99 de cada tipo de tarefa devem ser derivados da telemetria da aplicação marcada por tarefa ou dos logs de invocação.
Conclusão
As quatro escolhas ficam dentro da requisição de inferência. O suporte do modelo deve ser verificado novamente sempre que o modelo mudar; depois, uma configuração por vez pode ser alterada e seu efeito medido na aplicação.
Recursos para avaliar essas opções por carga de trabalho: o console do Amazon Bedrock em console.aws.amazon.com/bedrock; Prompt caching for faster model inference; Service tiers for optimizing performance and cost; Adaptive thinking; Detect and filter harmful content by using Amazon Bedrock Guardrails; Effective cost optimization strategies for Amazon Bedrock; e as amostras e publicações relacionadas Invoke Bedrock model for code generation e Build long-horizon agents with Grok 4.7 on Amazon Bedrock.