Agents on Call, Parte 7. Sizing: La Matematica dei Token che Nessuno Fa in Anticipo

Una singola indagine profonda su un incidente su questa piattaforma, otto round di chiamate di tool prima che l'agente di triage abbia evidenze sufficienti per proporre una diagnosi, costa 32.950 token, e 31.600 di essi sono input, perché la Converse API di Bedrock rimanda l'intero transcript in crescita a ogni round. Moltiplicatelo per il volume reale di allarmi e l'intero conto mensile on-demand del modello per la piattaforma arriva a circa 14 $, una delle voci più piccole in un costo mensile totale vicino a 21 $. Comprare Provisioned Throughput dal primo giorno, la cosa che la Parte 1 ha esplicitamente rimandato, sarebbe costato 15.768 $ al mese per un workload che gira a circa un quattrocentesimo dell'utilizzo necessario per andare in pari. Nulla di tutto ciò è ovvio da un diagramma. Emerge solo quando qualcuno fa l'aritmetica, che è ciò che fa questa parte, da cima a fondo, con ogni numero riconducibile o a un listino prezzi Bedrock o a una formula mostrata per intero.

La Parte 1 ha impostato lo scenario, 40 page a settimana su 30 account, e ha scelto AgentCore più Strands rispetto alle alternative. La Parte 2 ha costruito il confine di account e il cablaggio degli inference profile, e ha nominato l'esatta domanda a cui questa parte risponde: il punto in cui la tariffa oraria del Provisioned Throughput batte la tariffa per token dell'on-demand. La Parte 3 ha rilasciato il loop di tool-calling dell'agente di triage, la cosa i cui round vengono quotati qui sotto. La Parte 4 ha spostato quei tool dietro AgentCore Gateway. La Parte 5 ha aggiunto gli agenti supervisore, runbook e cost che il conto mensile di questa parte ora deve coprire. La Parte 6 ha messo i Guardrails su ogni invocazione, una decisione che si rivela contare per il conto di questa parte più del previsto. Ogni numero qui sotto vive in docs/sizing-model.md nel repository di accompagnamento su github.com/flightlesstux/agents-on-call, insieme a una checklist per rieseguirlo contro numeri reali invece di quelli di questa azienda fittizia.

L'esempio svolto della matematica dei token

La Converse API non mantiene alcuno stato di conversazione lato server. Ogni round di tool-calling rimanda l'intero transcript fin lì: system prompt, schemi dei tool, ogni chiamata di tool precedente e il suo risultato. Questo significa che i token di input non crescono linearmente con i round, crescono con la somma di tutto ciò che è già stato inviato, e un'indagine più lunga paga la propria storia ancora e ancora. I blocchi di partenza, dichiarati esplicitamente invece che assunti: un prefisso statico di 1.800 token (system prompt, schemi dei tool, configurazione del guardrail) identico a ogni chiamata, un payload di allarme iniziale di 400 token, 150 token di output dell'assistente per round, e 350 token di risultato di tool aggiunti per round, 500 token di crescita a ogni round. La dimensione dell'input del round r è S + 400 + 500*(r-1).

Un'indagine superficiale che si risolve in 3 round appare così:

Un'indagine profonda che richiede 8 round, più account, più tool, più botta e risposta prima che le evidenze quadrino, appare così:

32.950 token totali, contro gli 8.700 di un'indagine superficiale, un costo 3,8x per un numero di round 2,7x. Quel divario è la penalità di reinvio resa visibile: total_input(N) = N*(S+400) + 500*N*(N-1)/2 cresce quadraticamente nel numero di round, non linearmente, perché il round 8 sta ripagando da capo i round da 1 a 7.

I dati on-call della Parte 1 mettono il volume reale contro questa matematica: 40 page a settimana, divise qui 70/30 in 28 indagini superficiali e 12 profonde. Sono 243.600 token superficiali e 395.400 token profondi a settimana, 639.000 in totale, circa 2,77 milioni di token al mese per il solo agente di triage. Gli agenti runbook, cost-sweep e supervisore ne aggiungono all'incirca un altro 1,1 milione, per un totale a livello di piattaforma vicino a 3,87 milioni di token al mese. La scomposizione completa per agente, inclusi i round arricchiti dalla Knowledge Base dell'agente runbook e lo sweep giornaliero dell'agente cost, è nel documento di accompagnamento; il numero che vale la pena portarsi nella prossima sezione è che nulla di tutto questo, a questo volume, è grande.

Incidenti a raffica contro uno sweep costante

Il volume dell'agente cost è liscio di proposito: un'esecuzione EventBridge schedulata al giorno, fuori orario, che non condivide mai un minuto con un incidente. Il volume dell'agente di triage non è liscio, e le medie lo nascondono. Distribuiti uniformemente, 606.000 token di input settimanali sono circa 60 token al minuto. Gli incidenti reali sono correlati: un guasto a monte che si propaga a otto allarmi negli stessi cinque minuti fa partire otto sessioni di triage i cui primi round atterrano nella stessa finestra TPM, 8 x 2.200 = 17.600 token di input in quel singolo minuto dal solo triage, prima ancora di contare le chiamate di dispatch del supervisore. Sono circa 290 volte la media livellata, esattamente nei dieci minuti in cui un'interruzione è in corso e la capacità della piattaforma di continuare a rispondere conta di più. Dimensionate sul picco, non sulla media; la media è ciò che compare sulla fattura del mese prossimo, il picco è ciò che decide se una tempesta di allarmi riceve una risposta o una `ThrottlingException`.

Quote, throttling e allarmare prima del dolore

I due endpoint di invocazione di Bedrock applicano le quote in modo diverso, e la differenza cambia cosa una raffica colpisce davvero. L'endpoint bedrock-runtime conta insieme i token di input e output contro un'unica quota TPM per modello, e l'RPM è specifico per modello: alcuni modelli di fascia alta non hanno alcuna quota RPM, governati dai soli token. L'endpoint bedrock-mantle separa input e output in quote di token distinte ed elimina del tutto l'RPM. In entrambi i casi, la quota è specifica per account e regione, condivisa tra tutti gli agenti che questa piattaforma esegue, non allocata per agente, quindi le chiamate di dispatch del supervisore e l'indagine a otto round dell'agente di triage attingono allo stesso pool durante una tempesta di allarmi correlata. Le richieste self-service di aumento quota coprono entrambi gli endpoint da una modifica di inizio anno, prima bedrock-mantle richiedeva un ticket di supporto; questo chiude un varco reale ma non elimina la necessità di conoscere il tetto prima che un incidente lo trovi.

La logica di retry propria dell'SDK Bedrock fa backoff su una risposta di throttling, ma questo liscia solo una raffica, non fa apparire margine di quota. La mossa più utile sta a monte di qualunque retry: allarmare sull'utilizzo della quota stessa, non sulla prima ThrottlingException che un retry ha già assorbito. Un allarme di utilizzo quota che scatta al 70% di un tetto TPM dà al capacity planning una page giorni prima che una tempesta di allarmi dia all'ingegnere on-call un agente di triage degradato. Aspettare che l'errore di throttling sia il primo segnale significa che l'incidente che più ha bisogno dell'aiuto di questa piattaforma è quello in cui l'error budget della piattaforma stessa viene speso in retry invece che in chiamate di tool.

Profili cross-region come margine per le raffiche

La Parte 2 ha messo questa piattaforma su inference profile cross-region ovunque, per affidabilità e senza costo aggiuntivo per token. L'angolo di sizing di quella decisione: una quota TPM ha scope sull'endpoint di una regione, e il routing cross-region significa che una raffica che esaurirebbe il tetto di una regione può riversarsi nel tetto separato di una regione sorella invece di accodarsi dietro il limite di una singola regione. Non è margine illimitato, e non sostituisce la conoscenza del tetto reale, ma trasforma la quota di una regione nella quota di un'intera geografia al costo di niente, uno scambio migliore della maggior parte del margine di capacità che questa piattaforma compra.

Economia del Provisioned Throughput: il break-even, e perché comprarlo ora è sbagliato

Una Model Unit compra una tariffa oraria piatta, fatturata sempre, in cambio di un tetto fisso di token/minuto in input e output, qualunque siano il listino del modello e il throughput della MU per il modello scelto, nessuno dei quali AWS pubblica come numero fisso indipendente dal modello, quindi la formula qui sotto usa valori segnaposto dichiarati, non fatti AWS, e ha bisogno dei numeri della console live prima che qualcuno ci spenda soldi veri:

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

Con segnaposto illustrativi (200.000 token/minuto in input e 100.000 in output per MU, 0,003 $ e 0,015 $ ogni 1.000 token on-demand, 21,60 $/MU-ora senza commitment): il 100% di utilizzo del tetto di quella MU vale 91.980 $ al mese on-demand, il PT in sé costa 15.768 $ al mese, e il break-even si colloca al 17,14% di utilizzo sostenuto. Oltre quella frazione, il PT è più economico. Sotto, vince l'on-demand, e la parola che fa il lavoro è sostenuto: è una media mensile, e l'esempio di raffica due sezioni più su mostra esattamente perché toccare un tetto per un minuto non è la stessa cosa che sostenerlo.

Il volume mensile reale di input di questa piattaforma, circa 3,65 milioni di token, è lo 0,042% del tetto mensile di input di quella MU, all'incirca 411 volte sotto il punto di break-even del 17,14%. Comprare una MU dal primo giorno, esattamente la mossa che la Parte 1 ha rimandato e che la Parte 2 ha segnalato come bisognosa prima di questa matematica, spenderebbe 15.768 $ al mese per proteggere un workload il cui intero conto on-demand del modello è di circa 14 $. L'errore non è l'aritmetica, è non farne alcuna, e vincolarsi a una tariffa mensile prima ancora di aver misurato la distribuzione del rate di richieste tra quattro agenti. On-demand finché non si misura, provisioned solo dopo, non è cautela fine a se stessa, è ciò che il calcolo del break-even dice davvero.

Cosa fa il prompt caching alla stessa matematica

Il caching trasforma la penalità di reinvio della sezione sulla matematica dei token in un problema per lo più risolto. Un prefisso in cache si legge con uno sconto del 90%; il nuovo contenuto scritto in cache costa 1,25x il normale prezzo di input, nessun costo separato oltre quel moltiplicatore. Applicato round per round, il round 1 scrive in cache il proprio input completo, e ogni round successivo legge l'intero input del round precedente al 10% del prezzo normale, pagando il pieno-più-25% solo sui 500 token appena aggiunti:

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

Per l'indagine superficiale, l'input equivalente di fatturazione con cache scende da 8.100 a 4.490 token, una riduzione del 44,6%. Per l'indagine profonda, scende da 31.600 a 9.715, una riduzione del 69,3%, più grande perché la penalità di reinvio che sta annullando si compone a ogni round in più: il caching aiuta di più esattamente dove il costo senza cache fa più male. In termini di dollari, il costo totale di un incidente profondo (input più output, con l'output non toccato dal caching) scende da 0,1151 $ a 0,0494 $, una riduzione del 57,1%. Applicato all'intero mix settimanale dell'agente di triage, il costo mensile del modello per quel solo agente scende da 10,02 $ a 5,29 $, un risparmio di 4,73 $, il 47,2%. Lo stesso meccanismo si applica ai loop multi-round degli agenti runbook e cost-sweep a una scala assoluta più piccola, dato che girano molto meno spesso; il documento di accompagnamento porta il ricalcolo completo solo per triage, l'agente con il volume e il numero di round più alti, dove l'effetto è massimo.

Il modello di costo mensile per l'intera piattaforma

Mettendo insieme ogni categoria, usando i prezzi documentati di AgentCore e Guardrails contro i volumi di token sopra, con la voce dei token del modello mostrata sia con sia senza il caching dell'agente di triage:

Due cose su cui vale la pena fermarsi. Runtime, Gateway e Memory sono errori di arrotondamento a questo volume: la fatturazione al secondo e nessun addebito per il tempo idle in attesa del modello fanno sì che l'infrastruttura gestita si noti appena, finché concorrenza e durata delle sessioni non salgono di ordini di grandezza. I Guardrails non sono un errore di arrotondamento: a circa il 30% del totale senza caching, costano più di Runtime, Gateway e Memory messi insieme di circa 15 volte, e dopo che il caching restringe la voce del modello, arrivano quasi ai due terzi del conto del modello che stanno scansionando. Un esercizio di sizing che si ferma al conteggio dei token del modello manca un terzo del conto reale, seduto in un servizio che la maggior parte delle persone dimensiona per compliance, non per costo.

Right-sizing del modello per agente

La matematica dei token sopra assume un solo modello per ogni agente, che è il default facile e non lo stato finale giusto. I quattro agenti chiedono a un modello cose genuinamente diverse. Triage fa diagnosi strutturata dall'output dei tool, evidenze in ingresso, un insieme delimitato di root cause plausibili in uscita, un lavoro che un modello più piccolo ed economico gestisce bene una volta che il suo system prompt e gli schemi dei tool sono stretti, esattamente il workload per cui l'impostazione a bassa temperatura della Parte 3 era già tarata. Lo sweep giornaliero dell'agente cost è per lo più aggregazione e confronto con soglie su numeri che un tool ha già recuperato, un adattamento ancora migliore per il modello più piccolo che segua in modo affidabile il formato di output. L'agente runbook è l'unico posto dove un modello più forte si guadagna il suo prezzo per token più alto: sta redigendo l'esatto documento SSM e i parametri che un umano sta per approvare dietro il gate di approvazione della Parte 4, e un errore lì è un errore con un raggio d'impatto reale, non un errore in una diagnosi che comunque qualcun altro ricontrolla. Abbinare la taglia del modello a quanto costa davvero un errore, invece di mettere di default lo stesso modello su ogni agente, è lo stesso istinto dietro il prompt caching e il PT: non spendere in capacità che il compito non richiede, e spenderla dove una risposta sbagliata è costosa. L'eval harness della Parte 8 è ciò che trasforma "lo gestisce bene" da una supposizione in un numero di cui fidarsi.

Modalità di fallimento da tenere d'occhio

Quattro cose da sapere prima che questo modello giri contro un account reale. Primo, ogni cifra in dollari sopra dipende da due input segnaposto, il prezzo per token on-demand e il tetto di throughput della MU del Provisioned Throughput, che questa serie deliberatamente non aggancia mai a un modello Bedrock con nome; sostituite la pagina di pricing live prima di fidarvi di un totale, perché un segnaposto stantio produce un conto sbagliato con sicurezza, non un conto sbagliato in modo evidente. Secondo, l'assunzione dei 350 token per risultato di tool è quasi certamente conservativa: un vero dump di metriche CloudWatch o un estratto di log può arrivare a 5-10 volte tanto, e poiché è il termine che si compone quadraticamente attraverso i round, una sottostima lì sottostima ogni numero a valle proporzionalmente, non di un offset fisso. Terzo, il calcolo del break-even è una media mensile; una piattaforma il cui traffico reale assomiglia alla sezione sulle raffiche, lunghi tratti quieti con picchi correlati e ripidi, può essere lontanissima dal break-even sulla carta e comunque subire throttling nei dieci minuti che contano, il che depone a favore del margine cross-region e degli allarmi di quota rispetto a un acquisto di PT in ogni caso. Quarto, i risparmi del prompt caching dipendono dal fatto che i cache hit atterrino davvero, un system prompt o uno schema di tool modificato a metà mese invalida il prefisso in cache e reintroduce brevemente il costo pieno senza cache finché la cache non si ripopola, una cosa da sorvegliare dopo ogni modifica di prompt, non da dare per scontata.

Leggi questo dopo

• Parte 6, Guardrail: La Parte che Tutti Saltano, per il pricing per unità dei Guardrails su cui si basa il modello di costo mensile di questa parte, e il pattern di invocazione che decide quanto testo viene davvero scansionato.
• Parte 8, Produzione: Observability, Eval e il Giorno in cui Mente, dove le decisioni di right-sizing del modello di cui sopra vengono testate contro trace reali invece di essere assunte corrette.
• The AWS Well-Architected Framework: A Key to Cloud Success su ercan.cloud, per il pilastro Cost Optimization di cui questa parte è in realtà un lungo esempio svolto: misura prima di vincolarti.

Il documento completo docs/sizing-model.md, inclusa la scomposizione per agente degli agenti runbook e cost-sweep tagliata dalle tabelle sopra e una checklist per rieseguire ogni numero contro un account reale, vive nel repository di accompagnamento su github.com/flightlesstux/agents-on-call. Per il lato database e infrastruttura di come far girare piattaforme come questa su scala, gli appunti tecnici sono su ercan.cloud, e l'hub è su ercanermis.com.