Un profil d'inférence applicatif est un wrapper taggé autour d'un ARN de modèle, et c'est la seule chose qui se dresse entre vous et une facture Bedrock affichant un seul chiffre pour toute l'entreprise. Vous créez un profil qui pointe vers un modèle, vous attachez des tags d'allocation de coûts, et vous invoquez l'ARN du profil au lieu de l'ID du modèle. Les tags remontent jusqu'à Cost Explorer et au Cost and Usage Report. C'est tout le mécanisme, et ça prend un après-midi.

L'après-midi n'est pas le problème. Le problème, c'est qu'un schéma de tagging est un engagement organisationnel, et la plupart des équipes en choisissent un en dix minutes et vivent avec pendant deux ans. Alors l'API mérite vingt minutes de cet article et la conception des tags mérite le reste.

Le problème que ça résout

Sans profils, l'usage Bedrock apparaît comme de l'usage Bedrock. Vous obtenez la dépense par modèle et par région, ce qui vous dit que Claude Sonnet vous a coûté cher le mois dernier et rien sur laquelle de vos neuf applications en est responsable. Le rapport par défaut ne peut pas répondre à la seule question que la finance pose jamais, à savoir de quel budget ça sort. J'ai écrit sur la forme plus large de ce problème dans Your LLM Bill Is an Observability Problem. Les profils sont le contrôle spécifique pour le volet attribution.

Comment ça marche

Créez un profil pointant vers un modèle de fondation ou un profil cross-région défini par le système, avec des tags :

aws bedrock create-inference-profile \
  --inference-profile-name "support-assistant-prod" \
  --model-source copyFrom=arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --tags key=team,value=support key=app,value=assistant key=env,value=prod

Puis invoquez l'ARN du profil partout où vous passiez un ID de modèle :

response = client.converse(
    modelId="arn:aws:bedrock:eu-central-1:123456789012:application-inference-profile/abc123",
    messages=messages,
)

Trois détails opérationnels faciles à manquer :

  • Les profils sont spécifiques à un modèle. Un profil enveloppe un seul modèle. Six applications fois quatre modèles, ça fait vingt-quatre profils. Cette multiplication est la raison pour laquelle votre conception de tags compte plus qu'il n'y paraît : vous ne nommez pas une ressource, vous définissez une grille.
  • Les tags ne sont pas rétroactifs. Activer un tag d'allocation de coûts dans la console de facturation étiquette la dépense à partir de ce moment-là. Rien de ce que vous avez fait le mois dernier n'est étiqueté. Activez les clés de tag avant d'avoir besoin des données, pas quand quelqu'un les demande.
  • La granularité est journalière, par type d'usage. Les profils vous donnent des dollars facturés dans Cost Explorer et le CUR à la granularité du jour. Ils ne vous donnent pas le coût par requête. Si vous voulez l'économie par requête, c'est de la journalisation de tokens côté application, un système différent avec un propriétaire différent.

Concevoir le schéma de tags

Le piège, c'est de tagger ce qui est facile à voir plutôt que ce sur quoi quelqu'un peut agir. Chaque clé de tag devrait répondre à une question qu'une vraie personne pose dans une vraie réunion.

Quatre clés couvrent la plupart des organisations :

  • team : qui paie. Faites correspondre exactement votre taxonomie de centres de coûts existante. Si la finance l'appelle cc-4471, n'inventez pas platform-eng ; vous passerez l'année suivante à maintenir une table de traduction en laquelle personne ne croit.
  • app : quelle charge de travail. L'unité que vous éteindriez réellement.
  • env : prod, staging, dev. C'est celle qui se rentabilise le plus vite, parce que le premier chiffre vraiment surprenant dans la plupart des factures Bedrock, c'est combien coûte le dev.
  • feature : optionnel, pour les applications où une fonctionnalité peut dominer la dépense. À utiliser avec parcimonie. Chaque clé supplémentaire multiplie votre nombre de profils.

Délibérément absent de la liste : les tags par utilisateur. Ne créez pas de profil par utilisateur. Vous atteindrez des limites de ressources, et la maintenance devient sans limite. Pour l'attribution au niveau identité, Bedrock prend en charge l'allocation de coûts basée sur le principal IAM, qui attribue la dépense à l'identité appelante sans profil par personne. Utilisez les profils pour la granularité équipe et application, et l'attribution par principal IAM quand vous devez savoir quel humain ou quel rôle de service a causé le pic. Ils se combinent.

Le rendre structurel

Un schéma de tagging qui dépend de la discipline se dégrade. Deux contrôles le font tenir.

D'abord, créez les profils dans votre IaC, à côté de l'application qui les utilise, et tirez les valeurs de tag des mêmes variables qui taguent le reste des ressources de cette application. Un profil créé à la main dans la console est un profil qui sera taggé test pour toujours.

Ensuite, fermez le chemin direct. Une fois que les profils existent, une application qui appelle un ID de modèle brut produit de la dépense non taguée, et la dépense non taguée est exactement la ligne que personne ne revendique. Une politique IAM qui refuse bedrock:InvokeModel et bedrock:Converse sur les ARN de modèles de fondation tout en les autorisant sur les ARN de profils d'inférence applicatifs fait du chemin taggé le seul chemin. C'est le même instinct que de circonscrire un rôle à une tâche, et je ne répéterai pas l'argument de IAM for LLM Apps: Least Privilege When the Caller Is a Model, je note simplement que ça s'applique à votre facture autant qu'à votre rayon d'impact.

Faites ça le premier jour. Retrofitter une politique de refus sur six applications qui appellent déjà des ID de modèle est une migration accompagnée d'un gel des changements.

Ce que vous obtenez, et ce que vous n'aurez toujours pas

Après un mois de données taguées, vous pouvez grouper Cost Explorer par team et voir la répartition, filtrer sur env=dev et trouver le job batch que quelqu'un a laissé tourner, et interroger le CUR pour le coût par application et par jour et le mettre sur un dashboard à côté du volume de requêtes. La détection d'anomalies devient utile aussi, parce qu'une alerte budgétaire sur une application est du signal là où une alerte sur la dépense totale Bedrock est du bruit.

Ce que vous n'aurez toujours pas : le coût par requête, le coût par client dans une application multi-tenant, et une idée de si la dépense en valait la peine. Le premier, c'est de la journalisation de tokens. Le second a besoin d'un contexte tenant que le système de facturation ne voit jamais, ce qui explique pourquoi l'attribution multi-tenant reste un problème d'application. Le troisième n'est même pas une question de facturation. Les profils vous disent où l'argent est parti. Ils n'ont aucun avis sur s'il aurait dû l'être.

Ce qu'il faut retenir

Les profils d'inférence applicatifs transforment une facture Bedrock inattribuable en lignes par équipe et par application, pour le coût d'envelopper un ARN de modèle. Activez les clés de tag avant d'avoir besoin de l'historique, gardez le schéma à quelques clés qui correspondent à la façon dont votre organisation budgète réellement, créez les profils en IaC, et refusez le chemin non taggé avec IAM pour que l'attribution ne dépende de personne qui s'en souvienne. L'API, c'est un après-midi. La conception des tags survit aux gens qui l'ont choisie.

À lire ensuite

La discipline générale d'allocation de coûts dont ceci s'inspire, la stratégie de tagging à travers un parc AWS, se trouve dans les notes de terrain sur ercan.cloud. Le hub est sur ercanermis.com.