Amazon Bedrock zeigt jetzt die Tokens-pro-Minute-Quotas seines Mantle-Endpunkts in der standardmäßigen AWS-Service-Quotas-Konsole an. Sie können die Limits für Input-Tokens pro Minute und Output-Tokens pro Minute pro Modell direkt ablesen und Erhöhungen über denselben Workflow beantragen, den Sie bereits für alles andere in AWS nutzen. Das klingt nach einer kleinen Änderung an der Konsole. Für alle, die Multi-Agent-Systeme in Produktion betreiben, ist es der Unterschied zwischen geplanter Kapazität und der Entdeckung dieser Grenze als Wand aus 429s.

Die nützliche Umdeutung lautet so: Bei agentischen Workloads ist Tokens pro Minute, nicht Requests pro Minute, Ihre echte Skalierungsgrenze. Den meisten Teams wird das erst klar, wenn eine Agent-Flotte, die in der Demo einwandfrei lief, unter echtem Traffic gedrosselt wird. Jetzt, da die Zahl sichtbar ist, besteht die Aufgabe darin, sie wie einen Kapazitätsplan zu behandeln und nicht wie eine Überraschung.

Was Mantle ist, kurz erklärt

Der Bedrock-Mantle-Endpunkt (bedrock-mantle) ist derjenige, der Ihnen die OpenAI Responses API, die OpenAI Chat Completions API und die Anthropic Messages API auf Bedrock bietet, mit minimalen Änderungen an Code, der gegen diese nativen APIs geschrieben wurde. Er erlaubt es, einen bestehenden OpenAI- oder Anthropic-förmigen Agent auf Bedrock zu richten, ohne Ihre Aufrufstellen umzuschreiben. Die Quota-Änderung bedeutet, dass jedes Modell hinter diesem Endpunkt seine Input- und Output-TPM-Limits jetzt als erstklassige Service-Quotas-Einträge meldet.

Warum TPM die Obergrenze für Agenten ist, nicht RPM

Eine klassische, API-gestützte App verbraucht Tokens ungefähr proportional zur Anzahl der Nutzer. Ein Request, eine Response, vorhersehbare Größe. Requests-pro-Minute-Limits sind das, worauf Sie achten.

Agentische Systeme brechen diese Proportionalität auf. Eine einzelne Nutzeraufgabe fächert sich auf: Ein Planner-Agent zerlegt sie, spawnt Sub-Agenten, jeder Sub-Agent macht mehrere Tool-Calls, jeder Call trägt den System-Prompt, den angesammelten Kontext, die Tool-Schemas und die Argumentation des Modells wieder mit hinaus. Die Token-Kosten einer einzelnen, für den Nutzer sichtbaren Aufgabe sind nicht ein Prompt und eine Completion. Es sind Dutzende davon, und der Kontext neigt dazu, bei jedem Sprung zu wachsen.

Ihr Token-Verbrauch skaliert also mit Agenten mal Schritten mal Kontextgröße, nicht mit Nutzern. Sie können meilenweit von jedem Request-Rate-Limit entfernt sein und trotzdem direkt durch Ihre Tokens-pro-Minute-Obergrenze brechen, weil jeder Request groß ist und es viele davon pro Aufgabe gibt. Genau deshalb ist die TPM-Zahl pro Modell diejenige, die man im Auge behalten muss, und deshalb ist es wichtig, dass sie in den Service Quotas steht.

Der Fehlermodus, der Reihe nach

Wenn Sie die TPM-Linie überschreiten, gibt Bedrock eine ThrottlingException (ein HTTP 429) zurück. Für sich genommen ist das in Ordnung. Das Problem ist, was ein Multi-Agent-System als Nächstes tut:

  • Der gedrosselte Call wird mit Backoff erneut versucht. Genauso wie die anderen Agenten, die in derselben Minute auf dieselbe Modell-Quota stoßen.
  • Retries sind selbst Token-Verbrauch gegen dieselbe Obergrenze, sodass eine Flotte unter Last sich selbst dauerhaft drosseln kann.
  • Die Latenz steigt, während Calls hinter Backoff-Timern in der Warteschlange stehen. Eine Aufgabe, die acht Sekunden dauerte, dauert jetzt vierzig oder läuft in einen Timeout.
  • Teilausfälle hinterlassen Agenten in inkonsistenten Zuständen: Der Planner glaubt, eine Teilaufgabe sei gelaufen, der Sub-Agent hat nie ein Token Output erhalten.

Nichts davon zeigt sich in einer Single-User-Dev-Umgebung, weil ein einzelner Entwickler nie genug Tokens pro Minute erzeugt, um das Limit auszulösen. Es zeigt sich beim ersten Mal, wenn echte Parallelität eintrifft, was der denkbar schlechteste Zeitpunkt ist, um seine Obergrenze kennenzulernen.

Modellieren Sie Ihr Token-Budget, bevor Sie ausliefern

Die Rechnung ist nicht schwer, und sie lohnt sich auf Papier, bevor sie von einem Incident gemacht wird. Schätzen Sie für ein gegebenes Modell:

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

Vergleichen Sie dann Input und Output getrennt mit den Input-TPM- und Output-TPM-Quotas, die Sie jetzt ablesen können, denn sie werden unabhängig voneinander geregelt, und agentischer Output (Reasoning, lange Tool-Argumente) wird leicht unterschätzt. Wenn Ihre prognostizierte Zahl bei erwartetem Peak irgendwo über etwa 70 Prozent der Quota liegt, haben Sie keinen Puffer, sondern einen künftigen Incident mit einem festen Datum.

Beobachten Sie es, nehmen Sie es nicht an

Sie können die Quotas direkt über die CLI auflisten, anstatt sich durch die Konsole zu klicken:

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

Kombinieren Sie das mit den Bedrock-Nutzungsmetriken in CloudWatch und setzen Sie einen Alarm bei 70 bis 80 Prozent der TPM jedes Modells. Das Ziel ist, von einem Dashboard zu erfahren, dass Sie sich der Obergrenze nähern, an einem Dienstag, und nicht von Ihren Nutzern an einem Freitagabend.

Maßnahmen, die nicht "mehr Quota beantragen" sind

Eine Erhöhung zu beantragen ist der naheliegende Hebel und manchmal der richtige. Aber die Zahl zu erhöhen behebt keine Architektur, die Tokens achtlos verbraucht. Bevor Sie das Ticket einreichen:

  • Kürzen Sie den Kontext. Der größte agentische Token-Schlund ist es, die vollständige Historie und jedes Tool-Schema in jeden Sprung mitzuschleppen. Geben Sie nur das weiter, was der Schritt braucht.
  • Cachen Sie Prompts. Stabile System-Prompts und Tool-Definitionen sind bei jedem Call dieselben Tokens. Prompt Caching nimmt sie aus dem Zähler.
  • Begrenzen Sie Parallelität und stellen Sie in Warteschlangen. Ein begrenzter Worker-Pool vor dem Modell verwandelt eine Token-Spitze in ein etwas langsameres, aber überlebendes System statt in einen Throttling-Sturm.
  • Routen Sie nach Schwierigkeit. Nicht jeder Schritt braucht das Frontier-Modell. Schicken Sie die billigen, mechanischen Schritte an ein kleineres, günstigeres Modell und reservieren Sie das teure für Reasoning, das es rechtfertigt.
  • Trennen Sie Input- und Output-Disziplin. Lange Outputs werden über ihre eigene Quota abgerechnet und gedrosselt. Begrenzen Sie die maximalen Output-Tokens pro Schritt, damit eine ausufernde Generierung nicht im Alleingang Ihre Output-TPM auffrisst.

Wenn Sie doch eine Erhöhung beantragen

Eröffnen Sie den Antrag in den Service Quotas gegen den spezifischen Input- oder Output-TPM-Eintrag des Modells und bringen Sie die obige Budget-Rechnung mit. AWS genehmigt Erhöhungen schneller, wenn Sie die prognostizierte Spitzenlast und die Token-Aufschlüsselung pro Aufgabe vorlegen können, statt einer aus Optimismus gegriffenen runden Zahl. Behandeln Sie es als Kapazitätsantrag, denn genau das ist es.

Die Kernaussage

Mantles Token-Quotas in den Service Quotas sichtbar zu machen ist notwendig, aber nicht hinreichend. Dass die Zahl sichtbar ist, schützt Sie nicht. Es bedeutet nur, dass Sie keine Ausrede mehr haben, davon überrascht zu werden. Für agentische Systeme ist Tokens pro Minute die tragende Grenze, und die Teams, die zuverlässige Agenten ausliefern, sind diejenigen, die dieses Budget modellieren, überwachen und ihren Token-Verbrauch heruntergestalten, bevor sie AWS überhaupt bitten, die Obergrenze anzuheben.

Lesen Sie als Nächstes

Für die Infrastruktur- und Plattformseite, um dies sicher im großen Maßstab zu betreiben, finden Sie die Cloud-Feldnotizen unter ercan.cloud, einschließlich Multi-Party-Approval für die hochriskanten Operationen, die Agenten niemals allein ausführen sollten. Für Beratung zu AWS, AI und Plattformarbeit, oder einfach um Hallo zu sagen, beginnen Sie bei ercanermis.com.