本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 常見問答集
<a name="cost-mgmt-faq"></a>

本節回答有關選擇和組合 Amazon Bedrock 成本歸因機制的常見問題。

## 選擇方法
<a name="cost-mgmt-faq-choosing"></a>

**問：我想要每個使用者、每個提示屬性。我有哪些選擇？**

答：使用[模型調用日誌](model-invocation-logging.md)，而不是以帳單為基礎的方法。原生方法 ([IAM 主體屬性](cost-mgmt-iam-principal-tracking.md)、[應用程式推論設定檔](cost-mgmt-application-inference-profiles.md)、 [專案](cost-mgmt-projects.md)和 [工作區](cost-mgmt-workspaces.md)) 只會在 AWSCost Explorer 和 CUR 中產生彙總美元，絕不會產生每個請求資料列。每個提示檢視只會存在於您的日誌中，其中使用者可以來自兩個位置的其中之一。

第一個選項是在每次呼叫時設定請求中繼資料標籤：

```
client.converse(
    modelId=...,
    messages=[...],
    requestMetadata={"user": "alice@example.com"},
)
```

第二個是依賴自動擷取的 `identity.arn`，如果您的呼叫者使用每個使用者 擔任其 IAM 角色，則此動作會有效`RoleSessionName`。您可以從記錄的字符計數計算成本。如果您也希望每個使用者使用發票準確的美元，請[IAM 主體屬性](cost-mgmt-iam-principal-tracking.md)同時執行 。

**問：我有特定的案例。我應該使用哪種方法？**

答：使用下表將您的案例與方法配對。


| 案例 | 使用 | 
| --- | --- | 
| 您需要每個團隊在每月帳單上的花費。 | [IAM 主體屬性](cost-mgmt-iam-principal-tracking.md) （由團隊標記） 或已標記的 [專案](cost-mgmt-projects.md)或 [應用程式推論設定檔](cost-mgmt-application-inference-profiles.md) | 
| 您需要每個個別提示的成本，依功能而定。 | [每個請求中繼資料標記](cost-mgmt-request-metadata.md) 使用[模型調用日誌](model-invocation-logging.md) | 
| 您執行許多模型，並希望每個應用程式有一個成本儲存貯體。 | [專案](cost-mgmt-projects.md) on bedrock-mantle — 單一專案可以跨越許多模型 | 
| 您正在使用 InvokeModel 或 Converse，並且想要每個應用程式美元。 | [應用程式推論設定檔](cost-mgmt-application-inference-profiles.md) | 
| 您面向 Amazon Bedrock 的閘道為許多使用者提供服務。 | 每位使用者的sts:AssumeRole帳單金額，加上[每個請求中繼資料標記](cost-mgmt-request-metadata.md)每個提示的詳細資訊 | 

**問：我應該使用專案或應用程式推論描述檔嗎？**

答：兩者在AWSCost Explorer 和 CUR 中交付彙總美元。依端點和規模選擇。
+ [應用程式推論設定檔](cost-mgmt-application-inference-profiles.md) 適用於`bedrock-runtime`端點 (InvokeModel 和 Converse)，但它們是特定於模型。您可以為每個模型建立一個設定檔，因此在您新增模型或團隊時，資源計數會增加。
+ [專案](cost-mgmt-projects.md) 處理`bedrock-mantle`端點 （回應和聊天完成），而單一專案可以跨越許多模型。當您的每個工作負載有許多模型時，它們的擴展會更好，但它們僅限地幔。

[IAM 主體屬性](cost-mgmt-iam-principal-tracking.md) 搭配任一使用者使用，以取得每位使用者的詳細資訊。

## 成本和用量報告問題
<a name="cost-mgmt-faq-cur"></a>

**問：傳統 CUR 和 CUR 2.0 之間的成本歸因有何差異？**

答：來自 [專案](cost-mgmt-projects.md)、[工作區](cost-mgmt-workspaces.md)、 [應用程式推論設定檔](cost-mgmt-application-inference-profiles.md)和 IAM 主體標籤的已啟用成本分配標籤會顯示在傳統 CUR 和 CUR 2.0 中。差別在於自動呼叫者身分資料欄，可讓 在沒有標記的情況下[IAM 主體屬性](cost-mgmt-iam-principal-tracking.md)運作。該資料欄 — 「呼叫者」資料 — 僅存在於 CUR 2.0 (AWS資料匯出） 匯出中，並已選取呼叫者身分選項。如果您想要在明細項目資料中包含每位使用者的原生屬性，則需要 CUR 2.0。

**問：我可以在AWSCost Explorer 或 CUR 中查看個別提示的成本嗎？**

答：否。傳統 CUR 和 CUR 2.0 在一小時或一天內依用量類型彙總成本，且兩個 都不在其明細項目上攜帶每個請求識別符。每個提示的詳細資訊只會存在於您的[模型調用日誌](model-invocation-logging.md)中。以模型和用量類型 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
```

計算的圖形是估計值。除非您建立模型，否則不會反映折扣、承諾、批次定價、免費方案或佈建輸送量。如需詳細資訊，請參閱[從日誌取得成本](cost-mgmt-request-metadata.md#cost-mgmt-request-metadata-getting-cost)。

## 機制有何不同
<a name="cost-mgmt-faq-differences"></a>

**問：IAM 工作階段標籤和請求中繼資料之間的差異是什麼？**

答：繫結和目的地。工作階段標籤會在 設定一次`sts:AssumeRole`，並且對於使用該工作階段的登入資料進行的每次呼叫都是固定的；它只會顯示為 AWSCost Explorer 和 CUR （傳統 CUR 和 CUR 2.0) 中的彙總帳單資料。請求中繼資料會在每次呼叫時設定，每個請求會有所不同，並且會落在您的呼叫日誌中。

對於每個使用者、每個提示屬性，請使用請求中繼資料。對於帳單上的每個使用者美元，請使用工作階段標籤或依賴發起人身分 ARN。

**問：我的帳單上是否顯示請求中繼資料？**

答：否。請求中繼資料不是成本分配標籤。它只會寫入您的[模型調用日誌](model-invocation-logging.md)，絕不會出現在AWSCost Explorer 或 CUR 中。將其用於操作和每次提示分析，並使用原生方法 （例如 [IAM 主體屬性](cost-mgmt-iam-principal-tracking.md)或 [專案](cost-mgmt-projects.md)) 進行計費美元。

## 實作
<a name="cost-mgmt-faq-implementation"></a>

**問：歸因如何在 LLM 閘道後方運作？**

答：Amazon Bedrock 會將閘道的角色記錄為發起人身分。若要保留使用者層級歸因，請擔任每位使用者的角色、快取工作階段生命週期的登入資料，並將使用者做為工作階段標籤 （用於計費美元） 和/或 `RoleSessionName`（因此使用者會登陸您的日誌`identity.arn`) 傳遞給使用者：

```
sts.assume_role(
    RoleArn=GATEWAY_ROLE,
    RoleSessionName="alice",
    Tags=[{"Key": "user", "Value": "alice@example.com"}],
)
```

如需每個提示的詳細資訊，而沒有每個請求的AWS STS呼叫，請改為在每個呼叫的[請求中繼資料](cost-mgmt-request-metadata.md)中設定使用者。

**問：我可以要求每個呼叫都加上標籤嗎？**

答：不是從 Amazon Bedrock 端。請求中繼資料是每次呼叫選擇加入，Amazon Bedrock 不會拒絕省略它的呼叫。它不是AWS標籤政策，它只會管理資源。在共用用戶端或 LLM 閘道中強制標記，該閘道會在每次請求上對其進行標記。對於一律沒有每通來電代碼的屬性，請使用 [IAM 主體屬性](cost-mgmt-iam-principal-tracking.md)，因為會自動擷取發起人身分。

**問：每次呼叫時要設定哪些欄位，以及哪些欄位是自動的？**

答：Amazon Bedrock 會自動擷取日誌記錄中幾乎所有內容：`accountId`、`region`、`modelId``requestId`、`identity.arn`、、輸入和輸出字符計數，以及結構描述中繼資料。您為每個呼叫提供的唯一欄位是 `requestMetadata`。您未`modelId`設定為標籤；它是您調用的模型或推論描述檔。