Quand votre facture Amazon Bedrock bondit et que personne ne peut dire quelle fonctionnalité en est la cause, vous n'avez pas un problème de tarification. Vous avez un problème d'observabilité. La facture vous dit que le compte a dépensé plus en tokens. Elle ne vous dit pas quel agent, quel tenant, ou quel chemin de code a dépensé, et sans cette attribution, chaque conversation sur les coûts est une supposition. Vous ne pouvez pas optimiser ce que vous ne pouvez pas mesurer, et la plupart des équipes mesurent le total et rien en dessous.

La dépense en tokens a une propriété qui aggrave cela par rapport au coût cloud ordinaire : elle est générée par un système non déterministe. Un changement de prompt, une boucle de reprise, un agent bavard, ou un utilisateur qui a trouvé un moyen de faire réfléchir le modèle plus fort peuvent tous faire bouger la facture, et aucun d'eux n'apparaît comme une nouvelle ressource sur la facture. La dépense se cache à l'intérieur d'une seule ligne budgétaire Bedrock. Le travail consiste à décomposer cette ligne avant qu'elle ne vous surprenne, pas après.

L'attribution est tout le jeu

La question qui compte n'est jamais « combien avons-nous dépensé sur Bedrock ». C'est « combien ceci a-t-il dépensé, et est-ce que ça en vaut la peine ». Répondre à cela nécessite une dimension sur chaque unité de dépense en tokens. Au minimum, taguez chaque appel avec :

  • La fonctionnalité ou l'aire produit, pour pouvoir demander si le résumeur ou l'assistant de chat est le moteur de coût.
  • Le tenant ou le client, pour voir si un compte est subventionné par les autres et si votre tarification couvre votre coût de service.
  • L'agent ou le workflow, pour que le coût d'un pipeline à plusieurs étapes soit visible par étape plutôt que comme un total opaque.
  • Le modèle, pour pouvoir repérer quand du trafic coûteux va vers un modèle frontière qu'un modèle moins cher aurait pu gérer.

Sans ces dimensions, l'optimisation des coûts se dégrade en mesures générales : plafonner tout le monde, ou désactiver des fonctionnalités et observer quelle plainte arrive. Avec elles, vous pouvez pointer le chemin exact qui a grossi et décider s'il a mérité cette croissance.

Deux couches d'instrumentation

Les tags d'allocation de coûts pour la facture

Les tags d'allocation de coûts AWS sont la couche grossière. Taguez les ressources et requêtes qui pilotent l'usage Bedrock pour que les données de facturation elles-mêmes portent vos dimensions, et les rapports de coûts peuvent se regrouper par fonctionnalité ou environnement au lieu de montrer un seul chiffre Bedrock indifférencié. C'est la vue dans laquelle vivent la finance et les propriétaires de plateforme. Elle est granulaire au mois et bonne pour la conversation « où va l'argent », pas pour attraper un pic sur le moment.

Les métriques CloudWatch pour l'image en temps réel

La facture est un indicateur retardé. L'indicateur avancé est le débit de tokens, et cela appartient à CloudWatch. Bedrock émet des métriques d'usage, et vous pouvez publier vos propres métriques personnalisées dimensionnées par agent, par tenant, ou par fonctionnalité directement depuis l'application :

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

Maintenant, la dépense est un graphique sur lequel vous pouvez alarmer. Une métrique de tokens par agent qui triple en une nuit déclenche une alerte le mardi, au lieu d'une question de la finance en fin de mois. Lisez l'entrée et la sortie séparément, car la sortie est tarifée plus cher et une génération incontrôlée apparaît là en premier.

Ce que la visibilité vous permet de faire

Une fois que chaque token est attribué, les optimisations cessent d'être grossières. Vous pouvez router les appels bon marché et mécaniques qu'une métrique par agent révèle vers un modèle plus petit, et garder le modèle frontière pour le raisonnement qui le mérite. Vous pouvez trouver le tenant dont le coût de service dépasse son forfait et corriger la tarification ou l'usage. Vous pouvez attraper la boucle de reprise qu'un changement de prompt a introduite, car son nombre de tokens a explosé alors que son nombre de requêtes non. Chacun de ces mouvements nécessite de savoir quelle tranche de la facture couper, ce que l'instrumentation vous donne exactement et que la facture brute ne vous donnera jamais.

À retenir

Une facture Bedrock que vous ne pouvez pas décomposer est une facture que vous ne pouvez pas gérer. Traitez la dépense en tokens comme de la télémétrie, pas juste une ligne de facture : taguez-la avec des tags d'allocation de coûts pour la vue facturation, émettez des métriques de tokens par agent et par tenant vers CloudWatch pour la vue temps réel, et alarmez sur l'indicateur avancé pour qu'un pic soit une alerte, pas un post-mortem. Les équipes dont les coûts LLM restent maîtrisés ne sont pas celles avec les meilleurs prix. Ce sont celles qui peuvent voir, à tout moment, exactement quelle fonctionnalité, quel tenant, et quel agent dépense l'argent.

À lire ensuite

Pour le playbook FinOps et de visibilité des coûts cloud au-delà des LLM, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.