Amazon Bedrock ora mostra le quote di token al minuto dell'endpoint Mantle nella console standard AWS Service Quotas. Puoi leggere direttamente i limiti per modello di input-tokens-per-minute e output-tokens-per-minute, e richiedere aumenti attraverso lo stesso flusso di lavoro che usi già per tutto il resto in AWS. Sembra un piccolo cambiamento di console. Per chiunque gestisca sistemi multi-agente in produzione, è la differenza tra pianificare la propria capacità e scoprirla come un muro di 429.

La riformulazione utile è questa: per i carichi di lavoro agentic, il vero limite di scalabilità sono i token al minuto, non le richieste al minuto. La maggior parte dei team non lo interiorizza finché una flotta di agent che funzionava bene in una demo non inizia a essere limitata sotto traffico reale. Ora che il numero è visibile, il compito è trattarlo come un piano di capacità anziché come una sorpresa.

Cos'è Mantle, in breve

L'endpoint Bedrock Mantle (bedrock-mantle) è quello che ti offre la OpenAI Responses API, la OpenAI Chat Completions API e la Anthropic Messages API su Bedrock, con modifiche minime al codice scritto contro quelle API native. È ciò che ti permette di puntare un agent esistente, modellato su OpenAI o Anthropic, verso Bedrock senza riscrivere i punti di chiamata. Il cambiamento sulle quote significa che ogni modello dietro quell'endpoint ora riporta i propri limiti di TPM in input e output come voci di prima classe in Service Quotas.

Perché per gli agent il soffitto è il TPM, non l'RPM

Un'app tradizionale basata su API spende token più o meno in proporzione al numero di utenti. Una richiesta, una risposta, dimensione prevedibile. I limiti di richieste al minuto sono ciò che tieni d'occhio.

I sistemi agentic rompono quella proporzionalità. Un singolo task utente si dirama: un agent planner lo scompone, genera sub-agent, ogni sub-agent effettua diverse chiamate a strumenti, ogni chiamata porta con sé il system prompt, il contesto accumulato, gli schemi degli strumenti e di nuovo in uscita il ragionamento del modello. Il costo in token di un singolo task visibile all'utente non è un prompt e una risposta. Sono dozzine di essi, e il contesto tende a crescere a ogni passaggio.

Quindi la tua spesa in token scala con agent per passi per dimensione del contesto, non con gli utenti. Puoi essere lontanissimo da qualsiasi limite di tasso di richieste e sfondare comunque il tuo soffitto di token al minuto, perché ogni richiesta è grande e ce ne sono molte per ogni task. È esattamente per questo che il numero di TPM per modello è quello da tenere d'occhio, ed è per questo che averlo in Service Quotas conta.

La modalità di fallimento, in ordine

Quando superi la linea del TPM, Bedrock restituisce una ThrottlingException (un HTTP 429). Di per sé va bene. Il problema è cosa fa dopo un sistema multi-agente:

  • La chiamata limitata riprova con backoff. Lo stesso fanno gli altri agent che colpiscono la stessa quota per modello nello stesso minuto.
  • I retry sono essi stessi spesa in token contro lo stesso soffitto, quindi una flotta sotto carico può mantenersi limitata da sola.
  • La latenza sale man mano che le chiamate si accodano dietro i timer di backoff. Un task che richiedeva otto secondi ora ne richiede quaranta, oppure va in timeout.
  • I fallimenti parziali lasciano gli agent in stati incoerenti: il planner pensa che un sub-task sia stato eseguito, il sub-agent non ha mai ricevuto un token di output.

Niente di tutto questo si manifesta in un ambiente di sviluppo a utente singolo, perché un singolo sviluppatore non genera mai abbastanza token al minuto da far scattare il limite. Si manifesta la prima volta che arriva la concorrenza reale, che è il momento peggiore possibile per scoprire il proprio soffitto.

Modella il tuo budget di token prima di rilasciare

I conti non sono difficili, e vale la pena farli sulla carta prima che li faccia un incidente. Per un dato modello, stima:

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

Poi confronta input e output separatamente con le quote di input-TPM e output-TPM che ora puoi leggere, perché sono governate in modo indipendente e l'output agentic (ragionamento, lunghi argomenti per gli strumenti) è facile da sottostimare. Se il numero che proietti si colloca da qualche parte sopra circa il 70 percento della quota al picco previsto, non hai margine: hai un incidente futuro con una data sopra.

Tienilo d'occhio, non darlo per scontato

Puoi elencare le quote direttamente dalla CLI invece di navigare la console a colpi di clic:

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

Abbinalo alle metriche di utilizzo di Bedrock in CloudWatch e imposta un allarme al 70-80 percento del TPM di ciascun modello. L'obiettivo è scoprire che ti stai avvicinando al soffitto da una dashboard, di martedì, non dai tuoi utenti un venerdì sera.

Mitigazioni che non sono "chiedere più quota"

Richiedere un aumento è la leva ovvia, e a volte quella giusta. Ma alzare il numero non sistema un'architettura che spende token con leggerezza. Prima di aprire il ticket:

  • Riduci il contesto. Il più grande pozzo di token agentic è trascinare l'intera cronologia e ogni schema di strumento in ogni passaggio. Passa solo ciò che serve al passo.
  • Fai caching dei prompt. System prompt stabili e definizioni di strumenti sono gli stessi token a ogni chiamata. Il prompt caching li toglie dal contatore.
  • Limita la concorrenza e accoda. Un pool di worker delimitato davanti al modello trasforma un picco di token in un sistema un po' più lento ma sopravvissuto, anziché in una tempesta di throttling.
  • Instrada per difficoltà. Non ogni passo ha bisogno del modello di frontiera. Manda i passi economici e meccanici a un modello più piccolo e più economico, e riserva quello costoso al ragionamento che lo merita.
  • Separa la disciplina di input e output. Gli output lunghi vengono fatturati e limitati sulla loro stessa quota. Vincola il numero massimo di token di output per passo così che una generazione fuori controllo non possa consumare da sola il tuo output TPM.

Quando richiedi davvero un aumento

Apri la richiesta in Service Quotas contro la voce specifica di input o output TPM del modello, e porta con te i conti del budget visti sopra. AWS approva gli aumenti più rapidamente quando puoi mostrare il carico di picco previsto e la ripartizione dei token per task, anziché un numero tondo pescato dall'ottimismo. Trattala come una richiesta di capacità, perché è esattamente questo.

La conclusione

Esporre le quote di token di Mantle in Service Quotas è necessario, non sufficiente. Il fatto che il numero sia visibile non ti protegge. Significa solo che non hai più una scusa per esserne sorpreso. Per i sistemi agentic, i token al minuto sono il limite portante, e i team che rilasciano agent affidabili sono quelli che modellano quel budget, lo monitorano e progettano al ribasso la propria spesa in token prima ancora di chiedere ad AWS di alzare il soffitto.

Leggi questo dopo

Per il lato infrastruttura e piattaforma di gestire tutto questo in sicurezza su larga scala, le note dal campo sul cloud vivono su ercan.cloud, incluso il multi-party approval per le operazioni ad alto rischio che gli agent non dovrebbero mai eseguire da soli. Per consulenza su AWS, AI e lavoro di piattaforma, o anche solo per un saluto, parti da ercanermis.com.