Agents on Call, Teil 7. Sizing: Die Token-Rechnung, die niemand vorab macht

Eine einzige tiefe Vorfallsuntersuchung auf dieser Plattform, acht Runden Tool-Aufrufe, bevor der Triage-Agent genug Evidenz hat, um eine Diagnose vorzuschlagen, kostet 32.950 Tokens, und 31.600 davon sind Input, weil Bedrocks Converse API bei jeder Runde das gesamte wachsende Transkript erneut sendet. Multipliziert mit echtem Alarmvolumen kommt die gesamte monatliche On-Demand-Modellrechnung der Plattform auf etwa 14 $, einer der kleineren Posten in Gesamtkosten von knapp 21 $ im Monat. Provisioned Throughput am ersten Tag zu kaufen, das, was Teil 1 explizit aufgeschoben hat, hätte 15.768 $ im Monat gekostet, für einen Workload, der bei ungefähr einem Vierhundertstel der Auslastung läuft, die er zum Break-even braucht. Nichts davon ist aus einem Diagramm offensichtlich. Es zeigt sich erst, wenn jemand die Arithmetik macht, und genau das tut dieser Teil, Ende zu Ende, mit jeder Zahl rückführbar entweder auf ein Bedrock-Preisblatt oder eine vollständig gezeigte Formel.

Teil 1 hat das Szenario gesetzt, 40 Pages pro Woche über 30 Konten, und AgentCore plus Strands gegenüber den Alternativen gewählt. Teil 2 hat die Kontogrenze und die Inference-Profile-Verdrahtung gebaut und exakt die Frage benannt, die dieser Teil beantwortet: den Punkt, an dem der Stundensatz von Provisioned Throughput den Pro-Token-Satz von On-Demand schlägt. Teil 3 hat den Tool-Calling-Loop des Triage-Agenten ausgeliefert, das Ding, dessen Runden unten bepreist werden. Teil 4 hat diese Tools hinter AgentCore Gateway verschoben. Teil 5 hat den Supervisor-, den Runbook- und den Cost-Agenten hinzugefügt, die die Monatsrechnung dieses Teils jetzt abdecken muss. Teil 6 hat Guardrails auf jede Invocation gelegt, eine Entscheidung, die für die Rechnung dieses Teils mehr zählt als erwartet. Jede Zahl unten lebt in docs/sizing-model.md im begleitenden Repository unter github.com/flightlesstux/agents-on-call, zusammen mit einer Checkliste, um sie gegen echte Zahlen statt der dieser fiktiven Firma neu zu rechnen.

Die Token-Rechnung als durchgerechnetes Beispiel

Die Converse API hält keinen serverseitigen Konversationszustand. Jede Tool-Calling-Runde sendet das bisherige Transkript vollständig erneut: System-Prompt, Tool-Schemas, jeder frühere Tool-Aufruf und sein Ergebnis. Das heißt, Input-Tokens wachsen nicht linear mit den Runden, sie wachsen mit der Summe von allem bereits Gesendeten, und eine längere Untersuchung bezahlt ihre eigene Geschichte wieder und wieder. Die Bausteine, explizit deklariert statt angenommen: ein statischer Prefix von 1.800 Tokens (System-Prompt, Tool-Schemas, Guardrail-Konfiguration), identisch bei jedem Aufruf, ein initialer Alarm-Payload von 400 Tokens, 150 Tokens Assistant-Output pro Runde und 350 Tokens Tool-Ergebnis, das pro Runde angehängt wird, 500 Tokens Wachstum je Runde. Die Input-Größe von Runde r ist S + 400 + 500*(r-1).

Eine flache Untersuchung, die sich in 3 Runden auflöst, sieht so aus:

Eine tiefe Untersuchung, die 8 Runden braucht, mehr Konten, mehr Tools, mehr Hin und Her, bevor die Evidenz zusammenkommt, sieht so aus:

32.950 Tokens insgesamt, gegen die 8.700 einer flachen Untersuchung, das 3,8-Fache der Kosten für das 2,7-Fache der Rundenzahl. Diese Lücke ist die sichtbar gemachte Resend-Strafe: total_input(N) = N*(S+400) + 500*N*(N-1)/2 wächst quadratisch in der Rundenzahl, nicht linear, weil Runde 8 die Runden 1 bis 7 noch einmal komplett bezahlt.

Teil 1s On-Call-Daten stellen echtes Volumen dagegen: 40 Pages pro Woche, hier 70/30 in 28 flache und 12 tiefe Untersuchungen gesplittet. Das sind 243.600 flache Tokens und 395.400 tiefe Tokens pro Woche, 639.000 insgesamt, rund 2,77 Millionen Tokens im Monat allein für den Triage-Agenten. Der Runbook-, der Cost-Sweep- und der Supervisor-Agent legen grob weitere 1,1 Millionen drauf, für ein plattformweites Total nahe 3,87 Millionen Tokens im Monat. Die vollständige Aufschlüsselung pro Agent, einschließlich der Knowledge-Base-erweiterten Runden des Runbook-Agenten und des täglichen Sweeps des Cost-Agenten, steht im Begleitdokument; die Zahl, die man in den nächsten Abschnitt mitnehmen sollte, ist, dass nichts davon, bei diesem Volumen, groß ist.

Burst-Vorfälle gegen einen gleichmäßigen Sweep

Das Volumen des Cost-Agenten ist mit Absicht glatt: ein geplanter EventBridge-Lauf am Tag, außerhalb der Stoßzeiten, nie eine Minute mit einem Vorfall teilend. Das Volumen des Triage-Agenten ist nicht glatt, und Durchschnitte verstecken das. Gleichmäßig verteilt sind 606.000 wöchentliche Input-Tokens etwa 60 Tokens pro Minute. Echte Vorfälle korrelieren: Ein Upstream-Ausfall, der innerhalb derselben fünf Minuten in acht Alarme auffächert, startet acht Triage-Sessions, deren erste Runden im selben TPM-Fenster landen, 8 x 2.200 = 17.600 Input-Tokens in dieser einen Minute allein von Triage, bevor die eigenen Dispatch-Aufrufe des Supervisors gezählt sind. Das ist grob das 290-Fache des geglätteten Durchschnitts, in exakt den zehn Minuten, in denen ein Ausfall läuft und die Fähigkeit der Plattform, weiter zu antworten, am meisten zählt. Gegen den Peak dimensionieren, nicht gegen den Mittelwert; der Mittelwert ist das, was auf der Rechnung des nächsten Monats erscheint, der Peak entscheidet, ob ein Alarmsturm eine Antwort bekommt oder eine `ThrottlingException`.

Quotas, Throttling und Alarmieren vor dem Schmerz

Bedrocks zwei Invocation-Endpunkte setzen Quotas unterschiedlich durch, und der Unterschied ändert, was ein Burst tatsächlich trifft. Der bedrock-runtime-Endpunkt zählt Input- und Output-Tokens zusammen gegen eine einzige Pro-Modell-TPM-Quota, und RPM ist modellspezifisch: Einige Top-Tier-Modelle tragen überhaupt keine RPM-Quota, allein über Tokens gesteuert. Der bedrock-mantle-Endpunkt splittet Input und Output in separate Token-Quotas und lässt RPM ganz weg. So oder so ist die Quota konto- und regionsspezifisch, geteilt über jeden Agenten, den diese Plattform betreibt, nicht pro Agent zugeteilt, sodass die Dispatch-Aufrufe des Supervisors und die Acht-Runden-Untersuchung des Triage-Agenten während eines korrelierten Alarmsturms aus demselben Pool ziehen. Self-Service-Anträge auf Quota-Erhöhung decken seit einer Änderung Anfang dieses Jahres beide Endpunkte ab, vorher brauchte bedrock-mantle ein Support-Ticket; das schließt eine echte Lücke, ersetzt aber nicht, die Obergrenze zu kennen, bevor ein Vorfall sie findet.

Die eigene Retry-Logik des Bedrock SDK weicht bei einer Throttling-Antwort mit Backoff zurück, aber das glättet einen Burst nur, es lässt keinen Quota-Spielraum erscheinen. Der nützlichere Zug liegt vor jedem Retry: auf die Quota-Auslastung selbst alarmieren, nicht auf die erste ThrottlingException, die ein Retry bereits absorbiert hat. Ein Quota-Auslastungs-Alarm, der bei 70 % einer TPM-Obergrenze feuert, gibt der Kapazitätsplanung eine Page Tage bevor ein Alarmsturm dem On-Call-Engineer einen degradierten Triage-Agenten gibt. Zu warten, bis der Throttling-Fehler das erste Signal ist, heißt, dass der Vorfall, der die Hilfe dieser Plattform am dringendsten braucht, genau der ist, in dem das eigene Error-Budget der Plattform für Retries statt für Tool-Aufrufe ausgegeben wird.

Cross-Region-Profile als Burst-Spielraum

Teil 2 hat diese Plattform überall auf Cross-Region-Inference-Profile gesetzt, für Zuverlässigkeit und ohne zusätzliche Kosten pro Token. Der Sizing-Blickwinkel auf diese Entscheidung: Eine TPM-Quota ist auf den Endpunkt einer Region gescoped, und Cross-Region-Routing bedeutet, dass ein Burst, der die Obergrenze einer Region erschöpfen würde, stattdessen in die separate Obergrenze einer Schwesterregion überlaufen kann, statt sich hinter dem Limit einer einzelnen Region anzustellen. Es ist kein unbegrenzter Spielraum, und es ersetzt nicht, die echte Obergrenze zu kennen, aber es verwandelt die Quota einer Region in die Quota einer ganzen Geografie, zum Preis von nichts, ein besserer Tausch als der meiste Kapazitätsspielraum, den diese Plattform kauft.

Provisioned-Throughput-Ökonomie: der Break-even, und warum jetzt kaufen falsch ist

Eine Model Unit kauft einen flachen, immer abgerechneten Stundensatz im Tausch gegen eine feste Obergrenze für Input- und Output-Tokens/Minute, was auch immer Preisblatt und MU-Durchsatz für das gewählte Modell gerade sind, beides publiziert AWS nicht als feste, modellunabhängige Zahl, die Formel unten nutzt also deklarierte Platzhalterwerte, keine AWS-Fakten, und braucht die Zahlen der Live-Konsole, bevor jemand echtes Geld darauf ausgibt:

max_monthly_input  = T_in  * 60 * 730   # 730 hours in an average month
max_monthly_output = T_out * 60 * 730

on_demand_equiv_cost = (max_monthly_input  / 1000) * I
                      + (max_monthly_output / 1000) * O

pt_monthly_cost        = P * 730
break_even_utilization = pt_monthly_cost / on_demand_equiv_cost

Mit illustrativen Platzhaltern (200.000 Input- und 100.000 Output-Tokens/Minute pro MU, 0,003 $ und 0,015 $ pro 1.000 Tokens on-demand, 21,60 $ pro MU-Stunde ohne Commitment): 100 % Auslastung der Obergrenze dieser MU sind on-demand 91.980 $ im Monat wert, PT selbst kostet 15.768 $ im Monat, und der Break-even landet bei 17,14 % anhaltender Auslastung. Über diesem Anteil ist PT billiger. Darunter gewinnt On-Demand, und das Wort, das die Arbeit macht, ist anhaltend: Das ist ein Monatsdurchschnitt, und das Burst-Beispiel zwei Abschnitte weiter oben zeigt genau, warum eine Obergrenze eine Minute lang zu treffen nicht dasselbe ist wie sie zu halten.

Das tatsächliche monatliche Input-Volumen dieser Plattform, etwa 3,65 Millionen Tokens, sind 0,042 % der monatlichen Input-Obergrenze dieser MU, grob um den Faktor 411 unter dem Break-even-Punkt von 17,14 %. Eine MU am ersten Tag zu kaufen, exakt der Zug, den Teil 1 aufgeschoben und Teil 2 als "braucht erst diese Rechnung" markiert hat, würde 15.768 $ im Monat ausgeben, um einen Workload zu schützen, dessen gesamte On-Demand-Modellrechnung etwa 14 $ beträgt. Der Fehler ist nicht die Arithmetik, es ist, keine zu machen, und sich auf einen Monatssatz festzulegen, bevor die Request-Rate-Verteilung über vier Agenten überhaupt gemessen ist. On-Demand bis gemessen, provisioned erst danach, ist keine Vorsicht um ihrer selbst willen, es ist das, was die Break-even-Rechnung tatsächlich sagt.

Was Prompt Caching mit derselben Rechnung macht

Caching verwandelt die Resend-Strafe aus dem Token-Rechnungs-Abschnitt in ein größtenteils gelöstes Problem. Ein gecachter Prefix liest sich mit 90 % Rabatt; neuer Inhalt, der in den Cache geschrieben wird, kostet das 1,25-Fache des normalen Input-Preises, keine separate Gebühr über diesen Multiplikator hinaus. Runde für Runde angewendet schreibt Runde 1 ihren vollen Input in den Cache, und jede spätere Runde liest den gesamten Input der vorherigen Runde zu 10 % des Normalpreises und zahlt voll-plus-25 % nur auf die neu angehängten 500 Tokens:

billing_input(1) = input(1) * 1.25
billing_input(r) = input(r-1) * 0.10 + 500 * 1.25   # r >= 2

Für die flache Untersuchung fällt der gecachte abrechnungsäquivalente Input von 8.100 auf 4.490 Tokens, eine Reduktion um 44,6 %. Für die tiefe Untersuchung fällt er von 31.600 auf 9.715, eine Reduktion um 69,3 %, größer, weil die Resend-Strafe, die er auslöscht, mit jeder zusätzlichen Runde komponiert: Caching hilft genau dort mehr, wo die ungecachten Kosten mehr wehtun. In Dollar fallen die Gesamtkosten eines tiefen Vorfalls (Input plus Output, Output von Caching unberührt) von 0,1151 $ auf 0,0494 $, eine Reduktion um 57,1 %. Auf den vollen Wochen-Mix des Triage-Agenten angewendet fallen die monatlichen Modellkosten allein für diesen Agenten von 10,02 $ auf 5,29 $, eine Ersparnis von 4,73 $, 47,2 %. Derselbe Mechanismus gilt für die eigenen Multi-Runden-Loops des Runbook- und des Cost-Sweep-Agenten in kleinerem absolutem Maßstab, da sie weit seltener laufen; das Begleitdokument trägt die volle Neuberechnung nur für Triage, den Agenten mit dem höchsten Volumen und der höchsten Rundenzahl, wo der Effekt am größten ist.

Das monatliche Kostenmodell für die ganze Plattform

Alle Kategorien zusammengesetzt, mit den belegten AgentCore- und Guardrails-Preisen gegen die Token-Volumina oben, die Modell-Token-Zeile sowohl ohne als auch mit Triage-Agent-Caching gezeigt:

Zwei Dinge, bei denen es sich zu verweilen lohnt. Runtime, Gateway und Memory sind bei diesem Volumen Rundungsfehler: Abrechnung pro Sekunde und keine Kosten für Idle-Zeit, in der auf das Modell gewartet wird, bedeuten, dass die verwaltete Infrastruktur kaum ins Gewicht fällt, bis Parallelität und Session-Dauer um Größenordnungen steigen. Guardrails ist kein Rundungsfehler: Mit rund 30 % des Totals ohne Caching kostet es etwa das 15-Fache von Runtime, Gateway und Memory zusammen, und nachdem Caching die Modell-Zeile geschrumpft hat, ist es fast zwei Drittel so groß wie die Modellrechnung, die es scannt. Eine Sizing-Übung, die beim Token-Zählen für das Modell aufhört, verpasst ein Drittel der tatsächlichen Rechnung, sitzend in einem Service, den die meisten für Compliance dimensionieren, nicht für Kosten.

Modell-Right-Sizing pro Agent

Die Token-Rechnung oben nimmt ein Modell für jeden Agenten an, was der bequeme Default ist und nicht der richtige Endzustand. Die vier Agenten verlangen einem Modell wirklich Unterschiedliches ab. Triage macht strukturierte Diagnose aus Tool-Output, Evidenz hinein, ein begrenztes Set plausibler Root Causes heraus, Arbeit, die ein kleineres, billigeres Modell gut erledigt, sobald sein System-Prompt und seine Tool-Schemas eng sind, exakt der Workload, für den Teil 3s niedrige Temperatur-Einstellung schon getunt war. Der tägliche Sweep des Cost-Agenten ist größtenteils Aggregation und Schwellenvergleich gegen Zahlen, die ein Tool bereits geholt hat, ein noch besserer Fit für das kleinste Modell, das das Output-Format zuverlässig einhält. Der Runbook-Agent ist die eine Stelle, an der ein stärkeres Modell seinen höheren Preis pro Token verdient: Er entwirft das exakte SSM-Dokument und die Parameter, die ein Mensch gleich hinter Teil 4s Approval-Gate freigeben wird, und ein Fehler dort ist ein Fehler mit echtem Blast Radius, kein Fehler in einer Diagnose, die ohnehin jemand anderes gegenprüft. Modellgröße daran auszurichten, was ein Fehler tatsächlich kostet, statt jeden Agenten auf dasselbe Modell zu defaulten, ist derselbe Instinkt wie hinter Prompt Caching und PT: nicht für Fähigkeit ausgeben, die die Aufgabe nicht braucht, und dort ausgeben, wo eine falsche Antwort teuer ist. Teil 8s Eval-Harness ist das, was "erledigt es gut" von einer Vermutung in eine Zahl verwandelt, der man trauen kann.

Fehlerbilder, auf die man achten sollte

Vier Dinge, die man wissen sollte, bevor dieses Modell gegen ein echtes Konto läuft. Erstens hängt jede Dollarzahl oben an zwei Platzhalter-Inputs, dem On-Demand-Preis pro Token und der MU-Durchsatz-Obergrenze von Provisioned Throughput, die diese Serie bewusst nie an ein benanntes Bedrock-Modell pinnt; die Live-Preisseite einsetzen, bevor man einem Total traut, denn ein veralteter Platzhalter produziert eine selbstbewusst falsche Rechnung, keine offensichtlich falsche. Zweitens ist die 350-Token-Annahme für Tool-Ergebnisse fast sicher konservativ: Ein echter CloudWatch-Metrik-Dump oder ein Log-Auszug kann das 5- bis 10-Fache davon erreichen, und da es der Term ist, der quadratisch über Runden komponiert, unterschätzt eine zu niedrige Annahme dort jede nachgelagerte Zahl proportional, nicht um einen festen Offset. Drittens ist die Break-even-Rechnung ein Monatsdurchschnitt; eine Plattform, deren echter Traffic wie der Burst-Abschnitt aussieht, lange ruhige Strecken mit scharfen korrelierten Spitzen, kann auf dem Papier nirgendwo nahe Break-even sein und trotzdem in den zehn Minuten drosseln, die zählen, was so oder so für Cross-Region-Spielraum und Quota-Alarme statt eines PT-Kaufs spricht. Viertens hängen die Ersparnisse von Prompt Caching daran, dass Cache-Hits tatsächlich landen, ein mitten im Monat editierter System-Prompt oder ein editiertes Tool-Schema invalidiert den gecachten Prefix und führt kurz die vollen ungecachten Kosten wieder ein, bis sich der Cache neu füllt, etwas, das man nach jeder Prompt-Änderung beobachten sollte, statt es als gegeben anzunehmen.

Weiterlesen

• Teil 6, Guardrails: Der Teil, den alle überspringen, für die Stückpreise der Guardrails, auf die sich das monatliche Kostenmodell dieses Teils stützt, und das Invocation-Muster, das entscheidet, wie viel Text tatsächlich gescannt wird.
• Teil 8, Produktion: Observability, Evals und der Tag, an dem die Plattform lügt, wo die Modell-Right-Sizing-Entscheidungen oben gegen echte Traces getestet werden, statt als korrekt angenommen zu werden.
• The AWS Well-Architected Framework: A Key to Cloud Success auf ercan.cloud, für die Cost-Optimization-Säule, deren ein langes durchgerechnetes Beispiel dieser Teil in Wirklichkeit ist: messen, bevor man sich festlegt.

Das vollständige docs/sizing-model.md, einschließlich der Aufschlüsselung pro Agent für den Runbook- und den Cost-Sweep-Agenten, die aus den Tabellen oben gekürzt wurde, und einer Checkliste, um jede Zahl gegen ein echtes Konto neu zu rechnen, liegt im begleitenden Repository unter github.com/flightlesstux/agents-on-call. Für die Datenbank- und Infrastruktur-Seite, solche Plattformen in diesem Maßstab zu betreiben, gibt es die Field Notes auf ercan.cloud, und der Hub liegt auf ercanermis.com.