O Amazon Bedrock agora exibe as quotas de tokens por minuto do seu endpoint Mantle no console padrão do AWS Service Quotas. Você consegue ler diretamente os limites de input-tokens-per-minute e output-tokens-per-minute por modelo, e solicitar aumentos pelo mesmo fluxo de trabalho que já usa para tudo o mais na AWS. Isso parece uma pequena mudança de console. Para quem roda sistemas multi-agente em produção, é a diferença entre planejar sua capacidade e descobri-la como uma parede de 429s.

O reenquadramento útil é este: para cargas de trabalho agênticas, tokens por minuto, não requisições por minuto, é o seu limite real de escala. A maioria dos times não internaliza isso até que uma frota de agents que funcionava bem em uma demo comece a ser estrangulada sob tráfego real. Agora que o número está visível, o trabalho é tratá-lo como um plano de capacidade em vez de uma surpresa.

O que é o Mantle, rapidamente

O endpoint Mantle do Bedrock (bedrock-mantle) é o que entrega a OpenAI Responses API, a OpenAI Chat Completions API e a Anthropic Messages API no Bedrock, com mudanças mínimas em código escrito contra essas APIs nativas. É o que permite apontar um agent existente, no formato OpenAI ou Anthropic, para o Bedrock sem reescrever seus pontos de chamada. A mudança de quota significa que cada modelo por trás desse endpoint agora reporta seus limites de TPM de input e output como entradas de primeira classe no Service Quotas.

Por que TPM é o teto para agents, e não RPM

Um app tradicional baseado em API gasta tokens aproximadamente em proporção ao número de usuários. Uma requisição, uma resposta, tamanho previsível. Limites de requisições por minuto são o que você observa.

Sistemas agênticos quebram essa proporcionalidade. Uma única tarefa de usuário se ramifica: um agent planejador a decompõe, gera sub-agents, cada sub-agent faz várias chamadas de tool, cada chamada carrega o system prompt, o contexto acumulado, os schemas das tools e o raciocínio do modelo de volta. O custo em tokens de uma tarefa visível para o usuário não é um prompt e uma conclusão. São dezenas deles, e o contexto tende a crescer a cada salto.

Então o seu gasto de tokens escala com agents vezes passos vezes tamanho do contexto, não com usuários. Você pode estar longe de qualquer limite de taxa de requisições e ainda assim estourar direto o seu teto de tokens por minuto, porque cada requisição é grande e há muitas delas por tarefa. É exatamente por isso que o número de TPM por modelo é o que se deve observar, e por que tê-lo no Service Quotas importa.

O modo de falha, em ordem

Quando você cruza a linha de TPM, o Bedrock retorna um ThrottlingException (um HTTP 429). Por si só, isso não é problema. O problema é o que um sistema multi-agente faz em seguida:

  • A chamada estrangulada tenta de novo com backoff. O mesmo fazem os outros agents que atingiram a mesma quota por modelo no mesmo minuto.
  • As retentativas são, elas próprias, gasto de tokens contra o mesmo teto, então uma frota sob carga consegue se manter estrangulada.
  • A latência sobe à medida que as chamadas se enfileiram atrás de temporizadores de backoff. Uma tarefa que levava oito segundos agora leva quarenta, ou expira.
  • Falhas parciais deixam agents em estados inconsistentes: o planejador acha que uma subtarefa rodou, o sub-agent nunca recebeu um token de output.

Nada disso aparece em um ambiente de desenvolvimento de usuário único, porque um único desenvolvedor nunca gera tokens por minuto suficientes para disparar o limite. Aparece na primeira vez em que chega concorrência real, que é o pior momento possível para descobrir o seu teto.

Modele seu orçamento de tokens antes de subir para produção

A conta não é difícil, e vale a pena fazê-la no papel antes que ela seja feita por um incidente. Para um dado modelo, estime:

tokens_per_minute =
    concurrent_tasks
  × agents_per_task
  × model_calls_per_agent
  × avg_tokens_per_call        # input + output
  × (1 / task_duration_minutes)

Depois compare input e output separadamente contra as quotas de input-TPM e output-TPM que você agora consegue ler, porque elas são governadas de forma independente e o output agêntico (raciocínio, argumentos longos de tool) é fácil de subestimar. Se o seu número projetado fica em qualquer ponto acima de cerca de 70 por cento da quota no pico esperado, você não tem folga, você tem um incidente futuro com uma data marcada.

Monitore, não presuma

Você pode listar as quotas direto pela CLI em vez de clicar pelo console:

aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'tokens per minute')].[QuotaName,Value]" \
  --output table

Combine isso com as métricas de uso do Bedrock no CloudWatch e configure um alarme em 70 a 80 por cento do TPM de cada modelo. O objetivo é descobrir que está se aproximando do teto a partir de um dashboard, numa terça-feira, e não a partir dos seus usuários numa sexta à noite.

Mitigações que não são "pedir mais quota"

Solicitar um aumento é a alavanca óbvia, e às vezes a certa. Mas elevar o número não conserta uma arquitetura que gasta tokens com descuido. Antes de abrir o chamado:

  • Reduza o contexto. O maior ralo de tokens agêntico é arrastar todo o histórico e cada schema de tool para dentro de cada salto. Passe apenas o que o passo precisa.
  • Faça cache de prompts. System prompts estáveis e definições de tool são os mesmos tokens em cada chamada. O prompt caching os tira do contador.
  • Limite a concorrência e enfileire. Um pool de workers com limite na frente do modelo transforma um pico de tokens em um sistema um pouco mais lento, mas que sobrevive, em vez de uma tempestade de throttling.
  • Roteie por dificuldade. Nem todo passo precisa do modelo de fronteira. Mande os passos baratos e mecânicos para um modelo menor e mais barato e reserve o caro para o raciocínio que o justifica.
  • Separe a disciplina de input e output. Outputs longos são cobrados e estrangulados na própria quota deles. Restrinja o máximo de output tokens por passo para que uma geração descontrolada não consuma sozinha o seu output TPM.

Quando você de fato solicitar um aumento

Abra a solicitação no Service Quotas contra a entrada específica de TPM de input ou output do modelo, e leve a conta de orçamento acima. A AWS aprova aumentos mais rápido quando você consegue mostrar a carga de pico projetada e a decomposição de tokens por tarefa, em vez de um número redondo tirado do otimismo. Trate como uma solicitação de capacidade, porque é o que ela é.

A conclusão

Expor as quotas de tokens do Mantle no Service Quotas é necessário, não suficiente. O número estar visível não te protege. Apenas significa que você não tem mais desculpa para ser surpreendido por ele. Para sistemas agênticos, tokens por minuto é o limite que sustenta tudo, e os times que entregam agents confiáveis são os que modelam esse orçamento, monitoram-no e dimensionam o gasto de tokens para baixo antes mesmo de pedir à AWS para elevar o teto.

Leia isto a seguir

Para o lado de infraestrutura e plataforma de rodar isso com segurança em escala, as anotações de campo sobre cloud estão em ercan.cloud, incluindo aprovação multipartes para as operações de alto risco que os agents nunca deveriam rodar sozinhos. Para consultoria em AWS, AI e trabalho de plataforma, ou só para dizer olá, comece em ercanermis.com.