Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Questions fréquentes (FAQ)
Cette section répond aux questions courantes concernant le choix et la combinaison des mécanismes d'attribution des coûts d'Amazon Bedrock.
Choix d'une méthode
Q : Je veux une attribution par utilisateur et par invite. Quels sont mes choix ?
R : Utilisez des modèles de journaux d'appels, et non des méthodes basées sur la facturation. Les méthodes natives (Attribution principale de l'IAM, ProjetsProfils d’inférence d’applications, etEspaces de travail) ne produisent que des dollars agrégés dans AWS Cost Explorer et CUR, jamais une ligne par demande. La vue par invite n'existe que dans vos journaux, où l'utilisateur peut venir de deux endroits.
La première option consiste à définir une balise de métadonnées de demande pour chaque appel :
client.converse( modelId=..., messages=[...], requestMetadata={"user": "alice@example.com"}, )
La seconde consiste à s'appuyer sur la capture automatiqueidentity.arn, qui fonctionne si votre appelant assume son rôle IAM avec un utilisateur par utilisateur. RoleSessionName Vous calculez le coût à partir du nombre de jetons enregistrés. Si vous souhaitez également obtenir des dollars exacts par utilisateur, suivez-nous. Attribution principale de l'IAM
Q : J'ai un scénario spécifique. Quelle méthode dois-je utiliser ?
R : Associez votre scénario à une méthode à l'aide du tableau suivant.
| Scénario | Utilisation |
|---|---|
| Vous devez inscrire les dépenses de chaque équipe sur votre facture mensuelle. | Attribution principale de l'IAM(tag par équipe), ou un tag Projets ou Profils d’inférence d’applications |
| Vous avez besoin du coût par demande individuelle, par fonctionnalité. | Per-request balisage des métadonnéesavec des modèles de journaux d'invocation |
| Vous utilisez de nombreux modèles et souhaitez une seule tranche de coûts par application. | Projetsactivé bedrock-mantle : un seul projet peut couvrir de nombreux modèles |
| Vous utilisez Converse et vous voulez des dollars par application. InvokeModel | Profils d’inférence d’applications |
| Vous offrez à Amazon Bedrock une passerelle desservant de nombreux utilisateurs. | Per-user sts:AssumeRolepour les dollars de facturation, ainsi que Per-request balisage des métadonnées pour les détails par demande |
Q : Dois-je utiliser des profils d'inférence de projets ou d'applications ?
R : Les deux fournissent des dollars agrégés en AWS Cost Explorer et CUR. Choisissez par point de terminaison et par échelle.
-
Profils d’inférence d’applicationsfonctionnent sur le
bedrock-runtimepoint de terminaison (InvokeModel et sur Converse), mais ils sont spécifiques au modèle. Vous créez un profil par modèle, de sorte que le nombre de ressources augmente à mesure que vous ajoutez des modèles ou des équipes. -
Projetstravaillez sur le
bedrock-mantlepoint de terminaison (réponses et achèvement des discussions), et un seul projet peut couvrir de nombreux modèles. Ils s'adaptent mieux lorsque vous disposez de plusieurs modèles par charge de travail, mais qu'ils ne sont conçus que pour les manteaux.
Utilisez-le Attribution principale de l'IAM à côté de l'un ou l'autre pour obtenir des informations détaillées par utilisateur.
Questions relatives au rapport sur les coûts et l'utilisation
Q : Quelle est la différence entre le CUR classique et le CUR 2.0 pour l'attribution des coûts ?
R : Les balises de répartition des coûts activées à partir deProjets, Profils d’inférence d’applicationsEspaces de travail, et les balises principales IAM apparaissent à la fois dans le CUR classique et dans le CUR 2.0. La différence réside dans la colonne automatique d'identité de l'appelant qui Attribution principale de l'IAM fonctionne sans marquage. Cette colonne, les données « qui a passé l'appel », n'existe que dans une exportation CUR 2.0 (AWSData Exports) avec l'option d'identification de l'appelant sélectionnée. Si vous souhaitez une attribution native par utilisateur dans les données de vos rubriques, vous avez besoin de CUR 2.0.
Q : Puis-je voir le coût d'une invite individuelle dans AWS Cost Explorer ou CUR ?
R : Non Le CUR classique et le CUR 2.0 agrégent les coûts par type d'utilisation sur une heure ou une journée, et aucun des deux ne comporte d'identifiant par demande sur ses rubriques. Per-prompt les détails se trouvent uniquement dans les journaux d'invocation de votre modèle. Joignez les journaux au CUR selon le modèle et le type d'utilisation à des fins de rapprochement, et non pour un coût par demande.
Q : Mes coûts sont exprimés en CUR, mais mes tags et jetons sont enregistrés dans des journaux. Comment les combiner ?
R : Il existe deux modèles. Pour obtenir des totaux exacts pour les factures, joignez les logs au CUR au niveau du model/usage grain. type/day Pour le coût par invite, calculez-le à partir du nombre de jetons enregistrés et des taux par jeton publiés. La requête CloudWatch Logs Insights suivante produit les totaux de jetons par utilisateur et par modèle qui alimentent le calcul :
fields requestMetadata.user as user, modelId, input.inputTokenCount as inTokens, output.outputTokenCount as outTokens | stats sum(inTokens) as totalInput, sum(outTokens) as totalOutput, count() as calls by user, modelId
Le chiffre calculé est une estimation. Il ne reflète pas les remises, les engagements, la tarification par lots, le niveau gratuit ou le débit provisionné, sauf si vous les modélisez. Pour en savoir plus, consultez Comment calculer les coûts à partir de vos journaux.
En quoi les mécanismes diffèrent-ils
Q : Quelle est la différence entre une balise de session IAM et des métadonnées de demande ?
R : Obligation et destination. Un tag de session est défini une fois sts:AssumeRole et est constant pour chaque appel effectué avec les informations d'identification de cette session ; il apparaît uniquement sous forme de données de facturation agrégées dans AWS Cost Explorer et CUR (CUR classique et CUR 2.0). Les métadonnées des demandes sont définies par appel, varient en fonction de la demande et apparaissent dans vos journaux d'invocation.
Pour une attribution par utilisateur et par invite, utilisez les métadonnées de demande. Pour les dollars par utilisateur sur la facture, utilisez des balises de session ou fiez-vous à l'ARN de l'identité de l'appelant.
Q : Les métadonnées des demandes apparaissent-elles sur ma facture ?
R : Non Les métadonnées de demande ne sont pas une balise de répartition des coûts. Il est écrit uniquement dans les journaux d'appel de votre modèle et n'apparaît jamais dans AWS Cost Explorer ou CUR. Utilisez-le pour une analyse opérationnelle et ponctuelle, et utilisez une méthode native (telle que Attribution principale de l'IAM ouProjets) pour les dollars facturés.
Mise en œuvre
Q : Comment fonctionne l'attribution derrière une passerelle LLM ?
R : Amazon Bedrock enregistre le rôle de la passerelle en tant qu'identité de l'appelant. Pour préserver l'attribution au niveau de l'utilisateur, assumez le rôle par utilisateur, mettez en cache les informations d'identification pendant toute la durée de vie de la session et transmettez l'utilisateur en tant que tag de session (pour les dollars de facturation) en and/or tant que RoleSessionName (afin que l'utilisateur identity.arn apparaisse dans vos journaux) :
sts.assume_role( RoleArn=GATEWAY_ROLE, RoleSessionName="alice", Tags=[{"Key": "user", "Value": "alice@example.com"}], )
Pour obtenir des informations détaillées par invite sans AWS STS appel par demande, définissez plutôt l'utilisateur dans les métadonnées de la demande pour chaque appel.
Q : Puis-je exiger que chaque appel soit étiqueté ?
R : Pas du côté d'Amazon Bedrock. Les métadonnées de demande sont acceptées par appel, et Amazon Bedrock ne rejette pas les appels qui ne les omettent pas. Il ne s'agit pas d'une politique de AWS balises, qui régit uniquement les ressources. Appliquez le balisage dans un client partagé ou une passerelle LLM qui le tamponne à chaque demande. Pour une attribution toujours présente sans code par appel, utilisezAttribution principale de l'IAM, car l'identité de l'appelant est capturée automatiquement.
Q : Quels champs dois-je définir pour chaque appel, et lesquels sont automatiques ?
R : Presque tous les éléments du journal sont capturés automatiquement par Amazon Bedrock : accountId le nombre de jetons d'entrée et de sortie et les métadonnées du schéma. region modelId requestId identity.arn Le seul champ que vous fournissez par appel estrequestMetadata. Vous ne définissez pas modelId en tant que balise ; il s'agit du modèle ou du profil d'inférence que vous avez invoqué.
