View a markdown version of this page

常见问题 - Amazon Bedrock
选择一种方法成本和使用情况报告问题机制有何不同实施

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

常见问题

本节回答了有关选择和组合 Amazon Bedrock 成本归因机制的常见问题。

选择一种方法

问：我想要按用户、按提示归因。我有哪些选择？

答：使用模型调用日志，而不是基于计费的方法。原生方法（IAM 主体归因、Projects应用程序推理配置文件、和Workspaces）只能在 Cost Explorer 和 CUR 中AWS生成汇总美元，而不是每个请求的行。每个提示的视图仅存在于您的日志中，用户可以来自两个地方之一。

第一个选项是在每次调用时设置请求元数据标签：

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

第二种方法是依赖自动捕获的identity.arn，如果您的呼叫者以每RoleSessionName位用户扮演其 IAM 角色，则自动捕获会起作用。您可以根据记录的令牌数量计算成本。如果你还想让每位用户获得准确的发票金额，那就顺IAM 主体归因其自然。

问：我有一个特定的场景。我应该使用哪种方法？

答：使用下表将您的场景与方法进行匹配。

场景 使用
你需要在每月账单上支付每支球队的费用。 IAM 主体归因（按队伍标记），或者标记Projects或 应用程序推理配置文件
您需要按功能划分每个提示的费用。 Per-request 元数据标记带有模型调用日志
您运行许多模型，并且希望每个应用程序都有一个成本桶。 Projectson bedrock-mantle — 单个项目可以跨多个模型
你正在使用 Converse，想要按应用程序付费。 InvokeModel 应用程序推理配置文件
你在 Amazon Bedrock 前面有一个为许多用户提供服务的网关。 Per-user sts:AssumeRole用于支付账单费用，再加上按提示显示Per-request 元数据标记的详细信息

问：我应该使用项目还是应用程序推理配置文件？

答：两者都以Cost Explorer和CUR形式提供汇总美元。AWS按端点和规模进行选择。

  • 应用程序推理配置文件适用于bedrock-runtime端点（InvokeModel 和 Converse），但它们是特定于模型的。您为每个模型创建一个配置文件，因此资源数量会随着您添加模型或团队而增加。

  • Projects在bedrock-mantle端点（回复和聊天完成）上工作，单个项目可以跨多个模型。当你的每个工作负载有许多模型时，它们可以更好地扩展，但它们仅限于披风。

IAM 主体归因与任一用户一起使用可查看每个用户的详细信息。

成本和使用情况报告问题

问：在成本归因方面，经典 CUR 和 CUR 2.0 有什么区别？

答：Projects、应用程序推理配置文件Workspaces、和 IAM 委托人标签的激活成本分配标签同时出现在经典 CUR 和 CUR 2.0 中。不同之处在于，自动来电者身份列无需IAM 主体归因标记即可工作。该列（“谁拨打了电话” 的数据）仅存在于选中来电者身份选项的 CUR 2.0（AWS数据导出）导出中。如果您希望在行项数据中使用原生的每用户归因，则需要 CUR 2.0。

问：我能否在 Cost Explorer 或 CUR 中查看单个提示的AWS费用？

答：不是。 经典 CUR 和 CUR 2.0 均按使用类型汇总一小时或一天内的成本，并且两者的行项目都没有按请求标识符。 Per-prompt 细节仅存在于您的模型调用日志中。按模型和使用类型颗粒将日志连接到 CUR 以进行对账，而不是按提示计费。

问：我的费用在 CUR 中，但我的标签和代币在日志中。如何将它们组合起来？

答：有两种模式。要获得与发票准确无误的总计，请将日志加入到 CUR 中。 model/usage type/day 对于每个提示的费用，请根据记录的令牌数量和发布的每个令牌费率进行计算。以下 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并且该标签是恒定的；它仅作为汇总账单数据显示在 AWS Cost Explorer 和 CUR（包括经典 CUR 和 CUR 2.0）中。请求元数据是为每个调用设置的，每个请求都会有所不同，并且会出现在您的调用日志中。

对于按用户、按提示归因，请使用请求元数据。对于账单上的每位用户费用，请使用会话标签或依赖来电者身份 ARN。

问：我的账单上会显示请求元数据吗？

答：不是。 请求元数据不是成本分配标签。它仅写入模型调用日志，永远不会出现在 Cost Explorer AWS 或 CUR 中。将其用于操作和按提示进行分析，并使用本机方法（例如IAM 主体归因或Projects）来计算计费金额。

实施

问：在法学硕士网关背后，归因是如何运作的？

答：Amazon Bedrock 将网关的角色记录为呼叫者的身份。要保留用户级别的归因，请按用户承担角色，缓存会话生命周期内的identity.arn凭证，并将用户作为会话标签（计费美元）传递 and/or 为RoleSessionName（这样用户就会进入您的日志）：

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 自动捕获的：accountIdregionmodelId、requestId、identity.arn、、、、输入和输出令牌计数以及架构元数据。您在每次通话中提供的唯一字段是requestMetadata。您没有设置modelId为标签；而是您调用的模型或推理配置文件。