Agents on Call, partie 7. Dimensionnement : le calcul de tokens que personne ne fait en amont

Une seule investigation d'incident profonde sur cette plateforme, huit tours d'appels d'outils avant que l'agent de triage ait assez de preuves pour proposer un diagnostic, coûte 32 950 tokens, dont 31 600 en entrée, parce que l'API Converse de Bedrock renvoie l'intégralité de la transcription grandissante à chaque tour. Multipliez cela par un volume d'alarmes réel et la facture mensuelle complète de modèles à la demande de la plateforme ressort à environ 14 $, un des plus petits postes d'un coût mensuel total proche de 21 $. Acheter du Provisioned Throughput dès le premier jour, la chose que la Partie 1 a explicitement différée, aurait coûté 15 768 $ par mois pour une charge tournant à environ un quatre-centième de l'utilisation nécessaire pour atteindre la rentabilité. Rien de tout cela n'est évident sur un diagramme. Cela n'apparaît qu'une fois que quelqu'un fait l'arithmétique, ce que fait cette partie, de bout en bout, chaque nombre traçable soit vers une grille tarifaire Bedrock soit vers une formule montrée en entier.

La Partie 1 a posé le scénario, 40 pages par semaine à travers 30 comptes, et choisi AgentCore plus Strands face aux alternatives. La Partie 2 a construit la frontière de compte et le câblage des inference profiles, et nommé la question exacte à laquelle cette partie répond : le point où le tarif horaire du Provisioned Throughput bat le tarif par token de l'à-la-demande. La Partie 3 a livré la boucle d'appels d'outils de l'agent de triage, celle dont les tours sont chiffrés ci-dessous. La Partie 4 a déplacé ces outils derrière AgentCore Gateway. La Partie 5 a ajouté le superviseur et les agents runbook et coûts que la facture mensuelle de cette partie doit maintenant couvrir. La Partie 6 a mis des Guardrails sur chaque invocation, une décision qui s'avère compter davantage pour la facture de cette partie que prévu. Chaque nombre ci-dessous vit dans docs/sizing-model.md dans le dépôt compagnon à github.com/flightlesstux/agents-on-call, avec une checklist pour le rejouer contre des nombres réels au lieu de ceux de cette entreprise fictive.

Le calcul de tokens, exemple complet

L'API Converse ne conserve aucun état de conversation côté serveur. Chaque tour d'appels d'outils renvoie la transcription complète jusque-là : system prompt, schémas d'outils, chaque appel d'outil antérieur et son résultat. Les tokens d'entrée ne croissent donc pas linéairement avec les tours, ils croissent avec la somme de tout ce qui a déjà été envoyé, et une investigation plus longue paie sa propre histoire encore et encore. Les briques de base, déclarées explicitement plutôt que supposées : un préfixe statique de 1 800 tokens (system prompt, schémas d'outils, configuration de guardrail) identique à chaque appel, un payload d'alarme initial de 400 tokens, 150 tokens de sortie d'assistant par tour, et 350 tokens de résultat d'outil ajoutés par tour, soit 500 tokens de croissance à chaque tour. La taille d'entrée du tour r est S + 400 + 500*(r-1).

Une investigation superficielle qui se résout en 3 tours ressemble à ceci :

Tour	Tokens d'entrée	Tokens de sortie
1	2 200	150
2	2 700	150
3	3 200	300 (synthèse)
Total	8 100	600

Une investigation profonde qui exige 8 tours, plus de comptes, plus d'outils, plus d'allers-retours avant que les preuves ne s'additionnent, ressemble à ceci :

Tour	Tokens d'entrée	Tokens de sortie
1	2 200	150
2	2 700	150
3	3 200	150
4	3 700	150
5	4 200	150
6	4 700	150
7	5 200	150
8	5 700	300 (synthèse)
Total	31 600	1 350

32 950 tokens au total, contre les 8 700 d'une investigation superficielle, un coût multiplié par 3,8 pour un nombre de tours multiplié par 2,7. Cet écart est la pénalité de renvoi rendue visible : total_input(N) = N*(S+400) + 500*N*(N-1)/2 croît quadratiquement avec le nombre de tours, pas linéairement, parce que le tour 8 paie une nouvelle fois les tours 1 à 7.

Les données d'astreinte de la Partie 1 confrontent cela au volume réel : 40 pages par semaine, réparties ici 70/30 en 28 investigations superficielles et 12 profondes. Cela fait 243 600 tokens superficiels et 395 400 tokens profonds par semaine, 639 000 au total, environ 2,77 millions de tokens par mois pour le seul agent de triage. Les agents runbook, balayage de coûts et superviseur ajoutent environ 1,1 million de plus, pour un total à l'échelle de la plateforme proche de 3,87 millions de tokens par mois. La ventilation complète par agent, y compris les tours augmentés par Knowledge Base de l'agent runbook et le balayage quotidien de l'agent de coûts, est dans le doc compagnon ; le nombre à emporter dans la section suivante est que rien de tout cela, à ce volume, n'est grand.

Des incidents en rafale contre un balayage régulier

Le volume de l'agent de coûts est lisse à dessein : une exécution EventBridge planifiée par jour, hors heures ouvrées, ne partageant jamais une minute avec un incident. Le volume de l'agent de triage n'est pas lisse, et les moyennes le masquent. Étalés uniformément, 606 000 tokens d'entrée hebdomadaires font environ 60 tokens par minute. Les vrais incidents sont corrélés : une défaillance amont qui se déploie en huit alarmes dans les mêmes cinq minutes lance huit sessions de triage dont les premiers tours atterrissent dans la même fenêtre TPM, 8 x 2 200 = 17 600 tokens d'entrée dans cette seule minute pour le seul triage, avant même de compter les propres appels de dispatch du superviseur. C'est environ 290 fois la moyenne lissée, exactement dans les dix minutes où une panne est en cours et où la capacité de la plateforme à continuer de répondre compte le plus. Dimensionnez contre le pic, pas contre la moyenne ; la moyenne est ce qui apparaît sur la facture du mois prochain, le pic est ce qui détermine si une tempête d'alarmes obtient une réponse ou une `ThrottlingException`.

Quotas, throttling, et alerter avant la douleur

Les deux endpoints d'invocation de Bedrock appliquent les quotas différemment, et la différence change ce qu'une rafale frappe réellement. L'endpoint bedrock-runtime compte tokens d'entrée et de sortie ensemble contre un unique quota TPM par modèle, et le RPM est propre au modèle : certains modèles haut de gamme ne portent aucun quota RPM du tout, gouvernés par les tokens seuls. L'endpoint bedrock-mantle sépare entrée et sortie en quotas de tokens distincts et abandonne entièrement le RPM. Dans les deux cas, le quota est propre au compte et à la région, partagé entre tous les agents que cette plateforme fait tourner, pas alloué par agent, si bien que les appels de dispatch du superviseur et l'investigation en huit tours de l'agent de triage puisent dans le même réservoir pendant une tempête d'alarmes corrélée. Les demandes d'augmentation de quota en self-service couvrent les deux endpoints depuis un changement plus tôt cette année, bedrock-mantle exigeait auparavant un ticket de support ; cela ferme une vraie brèche mais ne dispense pas de connaître le plafond avant qu'un incident ne le trouve.

La logique de retry propre au SDK Bedrock recule devant une réponse de throttling, mais cela ne fait que lisser une rafale, cela ne fait pas apparaître de marge de quota. Le geste plus utile est en amont de tout retry : alerter sur l'utilisation du quota elle-même, pas sur la première ThrottlingException qu'un retry a déjà absorbée. Une alarme d'utilisation de quota qui se déclenche à 70 % d'un plafond TPM donne à la planification de capacité une page des jours avant qu'une tempête d'alarmes ne donne à l'ingénieur d'astreinte un agent de triage dégradé. Attendre que l'erreur de throttling soit le premier signal signifie que l'incident qui a le plus besoin de l'aide de cette plateforme est celui où le propre budget d'erreur de la plateforme se dépense en retries au lieu d'appels d'outils.

Les profils cross-region comme marge de rafale

La Partie 2 a mis cette plateforme sur des inference profiles cross-region partout, pour la fiabilité et sans surcoût par token. L'angle dimensionnement de cette décision : un quota TPM est scopé à l'endpoint d'une région, et le routage cross-region signifie qu'une rafale qui épuiserait le plafond d'une région peut déborder vers le plafond distinct d'une région sœur au lieu de faire la queue derrière la limite d'une seule région. Ce n'est pas une marge illimitée, et cela ne remplace pas la connaissance du vrai plafond, mais cela transforme le quota d'une région en un quota à l'échelle d'une géographie pour un coût nul, un meilleur échange que la plupart des marges de capacité que cette plateforme achète.

L'économie du Provisioned Throughput : le point de rentabilité, et pourquoi l'acheter maintenant est une erreur

Un Model Unit achète un tarif horaire fixe, facturé en permanence, en échange d'un plafond fixe de tokens/minute en entrée et en sortie, quels que soient la grille tarifaire du modèle et le débit du MU pour le modèle choisi, deux valeurs qu'AWS ne publie pas comme des nombres fixes indépendants du modèle, si bien que la formule ci-dessous utilise des valeurs de substitution déclarées, pas des faits AWS, et exige les nombres de la console en direct avant que quiconque n'y engage de l'argent réel :

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

Avec des valeurs de substitution illustratives (200 000 tokens d'entrée et 100 000 de sortie par minute et par MU, 0,003 $ et 0,015 $ par 1 000 tokens à la demande, 21,60 $ par MU-heure sans engagement) : une utilisation à 100 % du plafond de ce MU vaut 91 980 $ par mois à la demande, le PT lui-même coûte 15 768 $ par mois, et le point de rentabilité tombe à 17,14 % d'utilisation soutenue. Au-delà de cette fraction, le PT est moins cher. En deçà, l'à-la-demande gagne, et le mot qui fait le travail est soutenue : c'est une moyenne mensuelle, et l'exemple de rafale deux sections plus haut montre exactement pourquoi toucher un plafond pendant une minute n'est pas la même chose que le soutenir.

Le volume d'entrée mensuel réel de cette plateforme, environ 3,65 millions de tokens, représente 0,042 % du plafond d'entrée mensuel de ce MU, environ 411 fois sous le point de rentabilité de 17,14 %. Acheter un MU dès le premier jour, le geste exact que la Partie 1 a différé et que la Partie 2 a signalé comme exigeant d'abord ce calcul, dépenserait 15 768 $ par mois pour protéger une charge dont la facture de modèles à la demande entière est d'environ 14 $. L'erreur n'est pas l'arithmétique, c'est de n'en faire aucune, et de s'engager sur un tarif mensuel avant même que la distribution du débit de requêtes à travers quatre agents soit mesurée. À la demande jusqu'à mesure, provisionné seulement après, n'est pas de la prudence pour elle-même, c'est ce que le calcul de rentabilité dit réellement.

Ce que le prompt caching fait au même calcul

Le caching transforme la pénalité de renvoi de la section sur le calcul de tokens en un problème en grande partie résolu. Un préfixe en cache se lit avec une remise de 90 % ; le contenu nouvellement écrit dans le cache coûte 1,25 fois le prix d'entrée normal, sans frais séparés au-delà de ce multiplicateur. Appliqué tour par tour, le tour 1 écrit son entrée complète dans le cache, et chaque tour ultérieur lit l'entrée entière du tour précédent à 10 % du prix normal, ne payant plein tarif plus 25 % que sur les 500 tokens nouvellement ajoutés :

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

Pour l'investigation superficielle, l'entrée équivalente facturée avec cache tombe de 8 100 à 4 490 tokens, une réduction de 44,6 %. Pour l'investigation profonde, elle tombe de 31 600 à 9 715, une réduction de 69,3 %, plus grande parce que la pénalité de renvoi qu'elle annule se compose à chaque tour supplémentaire : le caching aide davantage exactement là où le coût sans cache fait le plus mal. En dollars, le coût total d'un incident profond (entrée plus sortie, la sortie n'étant pas affectée par le caching) tombe de 0,1151 $ à 0,0494 $, une réduction de 57,1 %. Appliqué à tout le mix hebdomadaire de l'agent de triage, le coût mensuel de modèle pour ce seul agent tombe de 10,02 $ à 5,29 $, une économie de 4,73 $, soit 47,2 %. Le même mécanisme s'applique aux propres boucles multi-tours des agents runbook et balayage de coûts à une échelle absolue plus petite, puisqu'ils tournent bien moins souvent ; le doc compagnon ne porte le recalcul complet que pour le triage, l'agent au plus gros volume et au plus grand nombre de tours, là où l'effet est le plus grand.

Le modèle de coût mensuel pour toute la plateforme

En rassemblant chaque catégorie, avec les prix sourcés d'AgentCore et de Guardrails contre les volumes de tokens ci-dessus, la ligne des tokens de modèle étant montrée avec et sans caching sur l'agent de triage :

Catégorie	Sans caching	Caching appliqué au triage
Tokens de modèle (les 4 agents)	14,18 $	9,45 $
Compute AgentCore Runtime	0,05 $	0,05 $
AgentCore Gateway	0,004 $	0,004 $
AgentCore Memory	0,35 $	0,35 $
Bedrock Guardrails	6,19 $	6,19 $
AgentCore Identity	0,00 $	0,00 $
Total	20,76 $	16,03 $

Deux choses méritent qu'on s'y attarde. Runtime, Gateway et Memory sont des erreurs d'arrondi à ce volume : la facturation à la seconde et l'absence de frais pour le temps d'inactivité en attente du modèle font que l'infrastructure managée s'enregistre à peine tant que la concurrence et la durée de session ne grimpent pas de plusieurs ordres de grandeur. Guardrails n'est pas une erreur d'arrondi : à environ 30 % du total sans caching, il coûte environ 15 fois plus que Runtime, Gateway et Memory réunis, et une fois que le caching a réduit la ligne de modèle, il pèse près des deux tiers de la facture de modèle qu'il scanne. Un exercice de dimensionnement qui s'arrête au compte de tokens du modèle manque un tiers de la facture réelle, logé dans un service que la plupart des gens dimensionnent pour la conformité, pas pour le coût.

Le bon calibre de modèle par agent

Le calcul de tokens ci-dessus suppose un seul modèle pour chaque agent, ce qui est le défaut facile et pas le bon état final. Les quatre agents demandent des choses réellement différentes à un modèle. Le triage fait du diagnostic structuré à partir de sorties d'outils, des preuves en entrée, un ensemble borné de causes racines plausibles en sortie, un travail qu'un modèle plus petit et moins cher gère bien une fois son system prompt et ses schémas d'outils resserrés, exactement la charge pour laquelle le réglage basse température de la Partie 3 était déjà accordé. Le balayage quotidien de l'agent de coûts est surtout de l'agrégation et de la comparaison de seuils contre des nombres qu'un outil a déjà récupérés, un ajustement encore meilleur pour le plus petit modèle qui suit le format de sortie de façon fiable. L'agent runbook est le seul endroit où un modèle plus fort mérite son prix par token plus élevé : il rédige le document SSM exact et les paramètres qu'un humain est sur le point d'approuver derrière la porte d'approbation de la Partie 4, et une erreur là est une erreur avec un vrai rayon d'impact, pas une erreur dans un diagnostic que quelqu'un d'autre revérifie de toute façon. Ajuster la taille du modèle à ce qu'une erreur coûte réellement, plutôt que de donner par défaut le même modèle à chaque agent, est le même réflexe que derrière le prompt caching et le PT : ne dépensez pas pour une capacité dont la tâche n'a pas besoin, et dépensez-la là où une mauvaise réponse coûte cher. Le harnais d'évals de la Partie 8 est ce qui transforme « il gère bien » d'une intuition en un nombre digne de confiance.

Modes de défaillance à surveiller

Quatre choses à savoir avant que ce modèle ne tourne contre un vrai compte. D'abord, chaque montant en dollars ci-dessus dépend de deux entrées de substitution, le prix par token à la demande et le plafond de débit du MU de Provisioned Throughput, que cette série n'épingle délibérément jamais à un modèle Bedrock nommé ; substituez la page de tarification en direct avant de faire confiance à un total, car une valeur de substitution périmée produit une facture fausse avec assurance, pas une facture visiblement fausse. Ensuite, l'hypothèse de 350 tokens par résultat d'outil est presque certainement prudente : un vrai dump de métriques CloudWatch ou un extrait de logs peut faire 5 à 10 fois cela, et comme c'est le terme qui se compose quadratiquement à travers les tours, une sous-estimation là sous-estime chaque nombre en aval proportionnellement, pas d'un décalage fixe. Troisièmement, le calcul de rentabilité est une moyenne mensuelle ; une plateforme dont le trafic réel ressemble à la section rafale, de longues plages calmes avec des pics corrélés et brusques, peut être loin de la rentabilité sur le papier tout en throttlant pendant les dix minutes qui comptent, ce qui plaide pour la marge cross-region et les alarmes de quota plutôt que pour un achat de PT dans les deux cas. Quatrièmement, les économies du prompt caching dépendent de hits de cache qui atterrissent réellement, un system prompt ou un schéma d'outil modifié en cours de mois invalide le préfixe en cache et réintroduit brièvement le coût complet sans cache jusqu'à ce que le cache se repeuple, à surveiller après tout changement de prompt, pas à supposer résolu.