Amazon Bedrock fait désormais apparaître les quotas de tokens par minute de son endpoint Mantle dans la console AWS Service Quotas standard. Vous pouvez lire directement, par modèle, les limites de tokens d'entrée par minute et de tokens de sortie par minute, et demander des augmentations via le même workflow que vous utilisez déjà pour tout le reste dans AWS. Cela ressemble à un petit changement de console. Pour quiconque exploite des systèmes multi-agents en production, c'est la différence entre planifier sa capacité et la découvrir sous la forme d'un mur de 429.

Le recadrage utile est le suivant : pour les charges de travail agentiques, ce sont les tokens par minute, et non les requêtes par minute, qui constituent votre vraie limite de scaling. La plupart des équipes ne l'intègrent pas avant qu'une flotte d'agents, qui fonctionnait très bien en démo, ne commence à être throttlée sous un trafic réel. Maintenant que le chiffre est visible, le travail consiste à le traiter comme un plan de capacité plutôt que comme une surprise.

Ce qu'est Mantle, en bref

L'endpoint Bedrock Mantle (bedrock-mantle) est celui qui vous donne accès à l'OpenAI Responses API, à l'OpenAI Chat Completions API et à l'Anthropic Messages API sur Bedrock, avec un minimum de modifications au code écrit pour ces API natives. C'est ce qui vous permet de pointer un agent existant au format OpenAI ou Anthropic vers Bedrock sans réécrire vos points d'appel. Le changement de quota signifie que chaque modèle derrière cet endpoint reporte désormais ses limites de TPM en entrée et en sortie comme des entrées Service Quotas à part entière.

Pourquoi le TPM est le plafond pour les agents, pas le RPM

Une application traditionnelle adossée à une API dépense des tokens à peu près proportionnellement au nombre d'utilisateurs. Une requête, une réponse, une taille prévisible. Les limites de requêtes par minute sont la chose à surveiller.

Les systèmes agentiques cassent cette proportionnalité. Une seule tâche utilisateur se ramifie : un agent planificateur la décompose, génère des sous-agents, chaque sous-agent effectue plusieurs appels d'outils, chaque appel transporte le system prompt, le contexte accumulé, les schémas d'outils, ainsi que le raisonnement du modèle qui ressort à son tour. Le coût en tokens d'une tâche visible par l'utilisateur n'est pas un prompt et une complétion. C'est des dizaines d'entre eux, et le contexte a tendance à grossir à chaque saut.

Votre consommation de tokens évolue donc avec le nombre d'agents fois le nombre d'étapes fois la taille du contexte, et non avec le nombre d'utilisateurs. Vous pouvez être très loin de toute limite de taux de requêtes et tout de même crever votre plafond de tokens par minute, parce que chaque requête est volumineuse et qu'il y en a beaucoup par tâche. C'est précisément pour cela que le chiffre de TPM par modèle est celui à surveiller, et pourquoi sa présence dans Service Quotas compte.

Le mode de défaillance, dans l'ordre

Quand vous franchissez la ligne du TPM, Bedrock renvoie une ThrottlingException (un HTTP 429). En soi, ce n'est pas grave. Le problème, c'est ce qu'un système multi-agent fait ensuite :

  • L'appel throttlé réessaie avec backoff. Tout comme les autres agents qui atteignent le même quota par modèle dans la même minute.
  • Les retries sont eux-mêmes une dépense de tokens contre le même plafond, donc une flotte sous charge peut se maintenir elle-même en throttling.
  • La latence grimpe à mesure que les appels font la queue derrière les timers de backoff. Une tâche qui prenait huit secondes en prend maintenant quarante, ou expire.
  • Les défaillances partielles laissent les agents dans des états incohérents : le planificateur croit qu'une sous-tâche s'est exécutée, le sous-agent n'a jamais reçu un seul token de sortie.

Rien de tout cela n'apparaît dans un environnement de développement mono-utilisateur, parce qu'un seul développeur ne génère jamais assez de tokens par minute pour déclencher la limite. Cela apparaît la première fois qu'une vraie concurrence arrive, ce qui est le pire moment possible pour découvrir votre plafond.

Modélisez votre budget de tokens avant de livrer

Le calcul n'est pas difficile, et il vaut la peine d'être fait sur le papier avant de l'être par un incident. Pour un modèle donné, estimez :

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

Comparez ensuite l'entrée et la sortie séparément aux quotas de TPM en entrée et de TPM en sortie que vous pouvez désormais lire, car ils sont gouvernés indépendamment et la sortie agentique (raisonnement, longs arguments d'outils) est facile à sous-estimer. Si votre chiffre projeté se situe quelque part au-dessus d'environ 70 pour cent du quota au pic attendu, vous n'avez pas de marge, vous avez un incident futur avec une date dessus.

Surveillez-le, ne le présumez pas

Vous pouvez lister les quotas directement depuis le CLI plutôt que de cliquer à travers la console :

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

Associez cela aux métriques d'usage de Bedrock dans CloudWatch et configurez une alarme à 70 à 80 pour cent du TPM de chaque modèle. L'objectif est d'apprendre que vous approchez du plafond depuis un dashboard, un mardi, et non depuis vos utilisateurs un vendredi soir.

Des mesures d'atténuation qui ne sont pas « demander plus de quota »

Demander une augmentation est le levier évident, et parfois le bon. Mais relever le chiffre ne corrige pas une architecture qui dépense des tokens sans soin. Avant de déposer le ticket :

  • Élaguez le contexte. Le plus gros gouffre à tokens agentique consiste à traîner tout l'historique et chaque schéma d'outils dans chaque saut. Ne passez que ce dont l'étape a besoin.
  • Mettez les prompts en cache. Les system prompts stables et les définitions d'outils sont les mêmes tokens à chaque appel. Le prompt caching les retire du compteur.
  • Plafonnez la concurrence et mettez en file d'attente. Un pool de workers borné devant le modèle transforme un pic de tokens en un système un peu plus lent mais survivant, plutôt qu'en tempête de throttling.
  • Routez selon la difficulté. Toutes les étapes n'ont pas besoin du modèle de pointe. Envoyez les étapes bon marché et mécaniques vers un modèle plus petit et moins coûteux, et réservez le plus cher au raisonnement qui le justifie.
  • Distinguez la discipline d'entrée et de sortie. Les longues sorties sont facturées et throttlées sur leur propre quota. Contraignez le nombre maximal de tokens de sortie par étape pour qu'une génération qui s'emballe ne puisse pas dévorer à elle seule votre TPM de sortie.

Quand vous demandez une augmentation

Ouvrez la demande dans Service Quotas sur l'entrée de TPM en entrée ou en sortie spécifique au modèle, et apportez le calcul de budget ci-dessus. AWS approuve les augmentations plus rapidement quand vous pouvez montrer la charge de pic projetée et la décomposition des tokens par tâche, plutôt qu'un chiffre rond tiré de l'optimisme. Traitez-la comme une demande de capacité, parce que c'est ce qu'elle est.

À retenir

Faire apparaître les quotas de tokens de Mantle dans Service Quotas est nécessaire, pas suffisant. La visibilité du chiffre ne vous protège pas. Elle signifie simplement que vous n'avez plus d'excuse pour en être surpris. Pour les systèmes agentiques, les tokens par minute sont la limite porteuse, et les équipes qui livrent des agents fiables sont celles qui modélisent ce budget, le surveillent et conçoivent leur consommation de tokens à la baisse avant même de demander à AWS de relever le plafond.

À lire ensuite

Pour le volet infrastructure et plateforme de l'exploitation de tout cela en toute sécurité à grande échelle, les notes de terrain cloud vivent sur ercan.cloud, y compris l'approbation multipartite pour les opérations à haut risque que les agents ne devraient jamais exécuter seuls. Pour du conseil sur AWS, l'IA et le travail de plateforme, ou simplement pour dire bonjour, commencez par ercanermis.com.