本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
常見問答集
本節回答有關選擇和組合 Amazon Bedrock 成本歸因機制的常見問題。
選擇方法
問：我想要每個使用者、每個提示屬性。我有哪些選擇？
答：使用模型調用日誌，而不是以帳單為基礎的方法。原生方法 (IAM 主體屬性、應用程式推論設定檔、 專案和 工作區) 只會在 AWSCost Explorer 和 CUR 中產生彙總美元，絕不會產生每個請求資料列。每個提示檢視只會存在於您的日誌中，其中使用者可以來自兩個位置的其中之一。
第一個選項是在每次呼叫時設定請求中繼資料標籤：
client.converse( modelId=..., messages=[...], requestMetadata={"user": "alice@example.com"}, )
第二個是依賴自動擷取的 identity.arn，如果您的呼叫者使用每個使用者 擔任其 IAM 角色，則此動作會有效RoleSessionName。您可以從記錄的字符計數計算成本。如果您也希望每個使用者使用發票準確的美元，請IAM 主體屬性同時執行 。
問：我有特定的案例。我應該使用哪種方法？
答：使用下表將您的案例與方法配對。
| 案例 | 使用 |
|---|---|
| 您需要每個團隊在每月帳單上的花費。 | IAM 主體屬性 （由團隊標記） 或已標記的 專案或 應用程式推論設定檔 |
| 您需要每個個別提示的成本，依功能而定。 | 每個請求中繼資料標記 使用模型調用日誌 |
| 您執行許多模型，並希望每個應用程式有一個成本儲存貯體。 | 專案 on bedrock-mantle — 單一專案可以跨越許多模型 |
| 您正在使用 InvokeModel 或 Converse，並且想要每個應用程式美元。 | 應用程式推論設定檔 |
| 您面向 Amazon Bedrock 的閘道為許多使用者提供服務。 | 每位使用者的sts:AssumeRole帳單金額，加上每個請求中繼資料標記每個提示的詳細資訊 |
問：我應該使用專案或應用程式推論描述檔嗎？
答：兩者在AWSCost Explorer 和 CUR 中交付彙總美元。依端點和規模選擇。
IAM 主體屬性 搭配任一使用者使用，以取得每位使用者的詳細資訊。
成本和用量報告問題
問：傳統 CUR 和 CUR 2.0 之間的成本歸因有何差異？
答：來自 專案、工作區、 應用程式推論設定檔和 IAM 主體標籤的已啟用成本分配標籤會顯示在傳統 CUR 和 CUR 2.0 中。差別在於自動呼叫者身分資料欄，可讓 在沒有標記的情況下IAM 主體屬性運作。該資料欄 — 「呼叫者」資料 — 僅存在於 CUR 2.0 (AWS資料匯出） 匯出中，並已選取呼叫者身分選項。如果您想要在明細項目資料中包含每位使用者的原生屬性，則需要 CUR 2.0。
問：我可以在AWSCost Explorer 或 CUR 中查看個別提示的成本嗎？
答：否。傳統 CUR 和 CUR 2.0 在一小時或一天內依用量類型彙總成本，且兩個 都不在其明細項目上攜帶每個請求識別符。每個提示的詳細資訊只會存在於您的模型調用日誌中。以模型和用量類型 grain 將日誌聯結至 CUR 以進行對帳，而不是針對每個提示成本。
問：我的成本以 CUR 為單位，但我的標籤和字符則以日誌為單位。如何結合它們？
答：有兩種模式。對於發票準確的總計，請在 model/usage-type/day grain 將日誌加入 CUR。對於每個提示成本，請從記錄的字符計數和每個字符的發佈費率進行計算。下列 CloudWatch Logs Insights 查詢會產生饋送計算的每個使用者、每個模型字符總計：
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
計算的圖形是估計值。除非您建立模型，否則不會反映折扣、承諾、批次定價、免費方案或佈建輸送量。如需詳細資訊，請參閱從日誌取得成本。
機制有何不同
問：IAM 工作階段標籤和請求中繼資料之間的差異是什麼？
答：繫結和目的地。工作階段標籤會在 設定一次sts:AssumeRole，並且對於使用該工作階段的登入資料進行的每次呼叫都是固定的；它只會顯示為 AWSCost Explorer 和 CUR （傳統 CUR 和 CUR 2.0) 中的彙總帳單資料。請求中繼資料會在每次呼叫時設定，每個請求會有所不同，並且會落在您的呼叫日誌中。
對於每個使用者、每個提示屬性，請使用請求中繼資料。對於帳單上的每個使用者美元，請使用工作階段標籤或依賴發起人身分 ARN。
問：我的帳單上是否顯示請求中繼資料？
答：否。請求中繼資料不是成本分配標籤。它只會寫入您的模型調用日誌，絕不會出現在AWSCost Explorer 或 CUR 中。將其用於操作和每次提示分析，並使用原生方法 （例如 IAM 主體屬性或 專案) 進行計費美元。
實作
問：歸因如何在 LLM 閘道後方運作？
答：Amazon Bedrock 會將閘道的角色記錄為發起人身分。若要保留使用者層級歸因，請擔任每位使用者的角色、快取工作階段生命週期的登入資料，並將使用者做為工作階段標籤 （用於計費美元） 和/或 RoleSessionName（因此使用者會登陸您的日誌identity.arn) 傳遞給使用者：
sts.assume_role( RoleArn=GATEWAY_ROLE, RoleSessionName="alice", Tags=[{"Key": "user", "Value": "alice@example.com"}], )
如需每個提示的詳細資訊，而沒有每個請求的AWS STS呼叫，請改為在每個呼叫的請求中繼資料中設定使用者。
問：我可以要求每個呼叫都加上標籤嗎？
答：不是從 Amazon Bedrock 端。請求中繼資料是每次呼叫選擇加入，Amazon Bedrock 不會拒絕省略它的呼叫。它不是AWS標籤政策，它只會管理資源。在共用用戶端或 LLM 閘道中強制標記，該閘道會在每次請求上對其進行標記。對於一律沒有每通來電代碼的屬性，請使用 IAM 主體屬性，因為會自動擷取發起人身分。
問：每次呼叫時要設定哪些欄位，以及哪些欄位是自動的？
答：Amazon Bedrock 會自動擷取日誌記錄中幾乎所有內容：accountId、region、modelIdrequestId、identity.arn、、輸入和輸出字符計數，以及結構描述中繼資料。您為每個呼叫提供的唯一欄位是 requestMetadata。您未modelId設定為標籤；它是您調用的模型或推論描述檔。
