本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
每個請求中繼資料標記
請求中繼資料可讓您將金鑰值標籤連接到bedrock-runtime端點上的個別 Amazon Bedrock 推論呼叫。這些標籤會與請求一起記錄在模型調用日誌中,因此您可以將用量歸因於團隊、應用程式、環境、實驗或任何其他因呼叫而異的維度。沒有資源可事先建立或設定 - 每個呼叫都可以攜帶不同的標籤集。
下列 bedrock-runtime APIs 支援請求中繼資料:
注意
bedrock-mantle 端點上不支援請求中繼資料。如需直接流入 AWS Cost Explorer管和 AWS 成本和用量報告的屬性,請參閱 應用程式推論設定檔、 專案或 工作區。
請求中繼資料的運作方式
視您呼叫的 API 而定,您會以不同的方式將中繼資料連接至請求:
-
InvokeModel 和 InvokeModelWithResponseStream – 在請求上設定
X-Amzn-Bedrock-Request-MetadataHTTP 標頭。值是 JSON 物件,其索引鍵和值是您選擇的字串。 -
Converse 和 ConverseStream – 在請求內文中設定
requestMetadata欄位。如需詳細資訊,請參閱requestMetadata。
只有在進行呼叫的 中啟用記錄時 AWS 區域 ,請求中繼資料才會記錄在模型調用日誌中。如需設定說明,請參閱 使用 CloudWatch Logs 和 Amazon S3 監控模型調用。
下列範例顯示 InvokeModel 請求,使用團隊名稱、環境和測試案例識別符來標記呼叫:
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."}] }
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."}] }
重要
當您使用 AWS Signature 第 4 版 (SigV4) 簽署請求時,X-Amzn-Bedrock-Request-Metadata請在SignedHeaders清單中包含 。從已簽章清單中省略 標頭的請求會遭到拒絕,而 InvalidSignatureException. AWS SDKs 會將請求中繼資料公開為 參數,以自動處理此問題。
限制
請求中繼資料具有下列限制,同時適用於X-Amzn-Bedrock-Request-Metadata標頭 (InvokeModel、InvokeModelWithResponseStream) 和requestMetadata內文欄位 (Converse、ConverseStream):
每個請求最多 16 個中繼資料項目。
金鑰:最多 256 個字元。
值:最多 256 個字元。
允許字元:一組受限的英數字元和標點符號字元。
超過這些限制的請求會因驗證錯誤而遭到拒絕。
請求中繼資料出現的位置
請求中繼資料會顯示在最上層requestMetadata欄位下的 Amazon Bedrock 模型調用日誌中。下列縮寫日誌項目顯示 InvokeModel 呼叫的欄位:
{ "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": { "...": "..." } }
您可以依 Amazon CloudWatch Logs Insights、Amazon S3 查詢工具,例如 Amazon Athena 或任何其他讀取調用日誌的系統中的中繼資料欄位來篩選和彙總日誌。
考量事項
-
只有在呼叫的 中啟用模型調用記錄時,才會記錄請求中繼資料值 AWS 區域。如果未設定記錄,請求仍會成功,但中繼資料不會保留。
-
請求中繼資料不會以 AWS 成本分配標籤的形式交付,也不會出現在 AWS Cost Explorer 或 CUR 中。若要依中繼資料維度分析成本,請在 上將調用日誌與成本和用量報告聯結
requestId,或直接從日誌記錄中彙總字符計數,然後乘以 Amazon Bedrock 定價中的每個字符費率。對於原生流向 Cost Explorer 和 CUR 的屬性,請使用 應用程式推論設定檔、 專案或 工作區。 -
選擇穩定、低基數索引鍵,例如
team、feature、environment或experiment,以進行易於彙總的分析。只有在您需要追蹤個別呼叫時,才使用較高的基數值,例如工作階段或追蹤識別符。 -
避免將個人身分識別資訊 (PII)、登入資料或其他敏感資料放在請求中繼資料中。值會存放在您的模型調用日誌和讀取這些日誌的任何系統中。
-
請求中繼資料可與其他 Amazon Bedrock 用量追蹤方法搭配使用。您可以IAM 主體屬性針對每個身分屬性使用 應用程式推論設定檔 ,以及針對相同工作負載上的資源層級成本分配標籤使用 。