View a markdown version of this page

Per-request balisage des métadonnées - Amazon Bedrock

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.

Per-request balisage des métadonnées

Les métadonnées de demande vous permettent d'associer des balises clé-valeur à des appels d'inférence Amazon Bedrock individuels sur le terminal. bedrock-runtime Les balises sont enregistrées avec la demande dans vos modèles de journaux d'invocation. Vous pouvez ensuite attribuer l'utilisation à une équipe, à une application, à un environnement, à une expérience ou à toute autre dimension qui varie selon les appels. Il n'y a aucune ressource à créer ou à configurer à l'avance : chaque appel peut comporter un ensemble de balises différent.

Les métadonnées des demandes sont prises en charge par les bedrock-runtimeAPI suivantes :

Note

Les métadonnées de demande ne sont pas prises en charge sur le bedrock-mantlepoint de terminaison. Pour une attribution directement intégrée dans AWS Cost Explorer et AWS Cost and Usage Reports sous forme de balises de répartition des coûtsProfils d’inférence d’applications, voirProjets, ouEspaces de travail.

Comment fonctionnent les métadonnées des demandes

Vous associez des métadonnées à une demande différemment en fonction de l'API que vous appelez :

  • InvokeModel et InvokeModelWithResponseStream — Définissez l'en-tête X-Amzn-Bedrock-Request-Metadata HTTP de la demande. La valeur est un objet JSON dont les clés et les valeurs sont des chaînes que vous choisissez.

  • Converse et ConverseStream — Définissez le requestMetadata champ dans le corps de la demande. Pour de plus amples informations, veuillez consulter requestMetadata.

Les métadonnées de demande sont enregistrées dans les journaux d'invocation de votre modèle uniquement lorsque la journalisation est activée dans le Région AWS lieu où l'appel est effectué. Pour les instructions de configuration, voirSurveillez l'invocation du modèle à l'aide de CloudWatch Logs et d'Amazon S3.

L'exemple suivant montre une InvokeModel demande qui étiquette l'appel avec un nom d'équipe, un environnement et un identifiant de scénario de test :

POST /model/anthropic.claude-3-haiku-20240307-v1:0/invoke HTTP/1.1 Content-Type: application/json X-Amzn-Bedrock-Request-Metadata: {"team": "orchestrator", "environment": "preview-test", "test_case": "invoke_model_sync"} { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 50, "messages": [{"role": "user", "content": "Say hello in one word."}] }

Le même en-tête est pris en charge sur InvokeModelWithResponseStream :

POST /model/anthropic.claude-3-haiku-20240307-v1:0/invoke-with-response-stream HTTP/1.1 Content-Type: application/json X-Amzn-Bedrock-Request-Metadata: {"team": "orchestrator", "environment": "preview-test", "test_case": "invoke_model_stream"} { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 50, "messages": [{"role": "user", "content": "Say hello in one word."}] }
Important

Lorsque vous signez des demandes avec AWS Signature Version 4 (SigV4), incluez-les X-Amzn-Bedrock-Request-Metadata dans la SignedHeaders liste. Les demandes qui omettent l'en-tête de la liste signée sont rejetées avec unInvalidSignatureException. AWS Les SDK qui exposent les métadonnées des demandes sous forme de paramètre gèrent cela automatiquement.

L'exemple suivant définit les métadonnées de requête avec le AWS SDK pour Python (Boto3) lors d'un appel Converse. Le SDK inclut les métadonnées dans les SigV4-signed en-têtes pour vous.

import boto3 client = boto3.client("bedrock-runtime") response = client.converse( modelId="us.anthropic.claude-opus-4-8", # or an inference profile ARN messages=[{"role": "user", "content": [{"text": "Summarize this ticket."}]}], requestMetadata={ "user": "alice@example.com", "team": "growth", "feature": "summarizer", "environment": "prod", }, )

Restrictions

Les métadonnées de la demande ont les limites suivantes, qui s'appliquent à la fois à l'X-Amzn-Bedrock-Request-Metadataen-tête (InvokeModel, InvokeModelWithResponseStream) et au champ requestMetadata body (Converse, ConverseStream) :

  • Maximum de 16 entrées de métadonnées par demande.

  • Clés : 256 caractères maximum.

  • Valeurs : 256 caractères maximum.

  • Caractères autorisés : ensemble restreint de caractères alphanumériques et de ponctuation.

Les demandes qui dépassent ces limites sont rejetées avec une erreur de validation.

Où apparaissent les métadonnées de la demande

Les métadonnées de demande apparaissent dans les journaux d'invocation de votre modèle Amazon Bedrock sous le champ de niveau supérieurrequestMetadata. L'entrée de journal abrégée suivante indique le champ correspondant à un InvokeModel appel :

{ "schemaType": "ModelInvocationLog", "schemaVersion": "1.0", "timestamp": "2024-01-15T12:00:00Z", "accountId": "123456789012", "region": "us-east-1", "requestId": "abcd1234-5678-efgh-ijkl-mnopqrstuvwx", "operation": "InvokeModel", "modelId": "anthropic.claude-3-haiku-20240307-v1:0", "requestMetadata": { "team": "orchestrator", "environment": "preview-test", "test_case": "invoke_model_sync" }, "input": { "...": "..." }, "output": { "...": "..." } }

Vous pouvez filtrer et agréger les journaux par champs de métadonnées dans Amazon CloudWatch Logs Insights, dans les outils de requête Amazon S3 tels qu'Amazon Athena ou dans tout autre système qui lit les journaux d'invocation.

Comment calculer les coûts à partir de vos journaux

Les métadonnées des demandes et le nombre de jetons sont consignés dans les journaux d'invocation de votre modèle, et non dans votre facture. Il existe deux manières de les transformer en coûts.

Calculer à partir du nombre de jetons

Chaque enregistrement de journal contient le nombre de jetons d'entrée, de sortie, de lecture en cache et d'écriture en cache pour la demande. Multipliez-les par les taux par jeton indiqués dans les tarifs d'Amazon Bedrock et regroupez-les par n'importe quelle balise de métadonnées. Cette approche est ponctuelle et en temps quasi réel, mais il s'agit d'une estimation. Vous conservez la carte tarifaire. 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.

La requête CloudWatch Logs Insights suivante indique le total des jetons par utilisateur et par modèle lorsque les journaux d'invocation sont envoyés à CloudWatch Logs :

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 | sort totalInput desc

Pour les journaux envoyés à Amazon S3, la requête Amazon Athena suivante permet d'estimer le coût par équipe. Remplacez les taux par jeton par les taux actuels issus des tarifs d'Amazon Bedrock, et ajustez les références du tableau et des colonnes pour qu'elles correspondent à la définition de votre AWS Glue tableau.

SELECT requestMetadata.team AS team, modelId, SUM(input.inputTokenCount) AS input_tokens, SUM(output.outputTokenCount) AS output_tokens, SUM(input.inputTokenCount) * 0.000015 AS est_input_cost, SUM(output.outputTokenCount) * 0.000075 AS est_output_cost FROM bedrock_invocation_logs GROUP BY requestMetadata.team, modelId ORDER BY est_input_cost DESC;
Réconciliez-vous avec le CUR

Joignez vos journaux d'appels à votre rapport sur les AWS coûts et l'utilisation pour obtenir des totaux exacts sur les factures. Ni le CUR classique ni le CUR 2.0 n'incluent d'identifiant par demande sur leurs rubriques. Les deux coûts agrégés par type d'utilisation sur une heure ou une journée. Traitez ce chemin comme une réconciliation entre le modèle et le type d'utilisation, les journaux fournissant les détails par demande ci-dessous.

Note

Les métadonnées de demande et les balises de session IAM sont des mécanismes différents. Les métadonnées des demandes sont définies par appel et varient en fonction de la demande. Il apparaît dans vos journaux d'invocation. Les balises de session IAM sont liées par session et apparaissent uniquement sous forme de données de facturation agrégées dans AWS Cost Explorer et CUR. Pour une attribution par utilisateur et par invite, utilisez des métadonnées de demande ou une identité par utilisateur dans l'ARN plutôt que des balises de session.

Considérations

  • Les valeurs des métadonnées des demandes ne sont enregistrées que lorsque la journalisation des appels du modèle est activée dans les appels. Région AWS Si la journalisation n'est pas configurée, la demande aboutit tout de même, mais les métadonnées ne sont pas conservées.

  • Les métadonnées de demande ne sont pas fournies sous forme de balise de répartition des AWS coûts et n'apparaissent pas dans AWS Cost Explorer ou CUR. Pour analyser les coûts par dimension de métadonnées, associez vos journaux d'appels à votre rapport sur les coûts et l'utilisation surrequestId. Vous pouvez également agréger le nombre de jetons directement à partir des enregistrements du journal et le multiplier par les taux par jeton dans la tarification d'Amazon Bedrock. Pour une attribution qui est transmise nativement à Cost Explorer et CUR, utilisez Profils d’inférence d’applicationsProjets, ouEspaces de travail.

  • Choisissez des clés stables à faible cardinalité telles queteam, environmentfeature, ou experiment pour des analyses faciles à agréger. Utilisez des valeurs de cardinalité plus élevées, telles que les identifiants de session ou de suivi, uniquement lorsque vous devez suivre des appels individuels.

  • Évitez de placer des informations personnelles identifiables (PII), des informations d'identification ou d'autres données sensibles dans les métadonnées des demandes. Les valeurs sont stockées dans les journaux d'appel de votre modèle et dans tout système qui lit ces journaux.

  • Les métadonnées des demandes sont fournies par appel et ne sont pas appliquées par Amazon Bedrock. Les demandes qui l'omettent aboutissent toujours, et il n'existe aucune politique côté service qui l'exige. Pour garantir la couverture au sein d'une organisation, définissez les métadonnées des demandes dans un client partagé ou une passerelle LLM. Pour une attribution toujours présente sans code par appel, utilisezAttribution principale de l'IAM. Il capture automatiquement l'identité de l'appelant.

  • Les métadonnées des demandes fonctionnent parallèlement aux autres méthodes de suivi de l'utilisation d'Amazon Bedrock. Vous pouvez utiliser des balises Attribution principale de l'IAM pour l'attribution par identité et Profils d’inférence d’applications pour la répartition des coûts au niveau des ressources sur la même charge de travail.