Amazon Bedrock 可观测性数据湖：跨账户集中查询每次模型调用

如果需要为您的 Amazon Bedrock 工作负载构建一个可观测性数据湖，有此需求的不止您一人。当您每天跨多个账户运行数千次模型调用时，请求发出之后，您可能会想知道：究竟发生了什么？您能看到总账单，却看不到每次调用内部的情况。

您可能会开始提出这些问题：发送了什么提示词、模型返回了什么、消耗了多少 token、由哪个模型处理，以及响应质量如何！如果您是管理多个团队 Amazon Bedrock 工作负载的平台工程师或机器学习（ML）工程师，这就是一个实实在在的问题。您无法调试用量激增问题，无法发现浪费的提示词，也无法区分各个团队的使用情况。

我们构建了一个解决方案来提供帮助：一个针对 Amazon Bedrock 调用的集中式可观测性数据湖。在本文中，我将介绍您可以获得哪些原生数据，以及我们如何设计这个数据湖。我还会展示如何利用它查看您的提示词并推导出每次调用的成本。AWS CloudFormation 模板、AWS Lambda 代码和 SQL 查询都位于 AWS Sample Bedrock Invocation Data Lake GitHub 存储库中。本文将逐步讲解架构和部署步骤。该存储库包含部署所需的一切内容。

您目前对 Amazon Bedrock 有哪些可见性？

Amazon Bedrock 提供模型调用日志记录功能，确实非常强大。您可以在使用 Bedrock 的每个 AWS 账户的设置中开启调用日志。它会将请求和响应的完整记录传送到 Amazon Simple Storage Service (Amazon S3) 或 Amazon CloudWatch。

数据是存在的，但它被锁定在各个单独的账户内。您真正想要的是对整个组织中每一次调用的单一、快速、可查询的视图。这正是这个数据湖带给您的。

什么是 Amazon Bedrock 可观测性数据湖？

集中式的 Amazon Bedrock 调用日志数据湖会从您的关联账户中提取原始模型调用日志并汇集到 Amazon CloudWatch。订阅日志筛选器随后将这些记录转发到您的中央账户。中央账户通过 Amazon Data Firehose 处理数据，并通过 Amazon Athena 将其呈现为一张干净整洁的表，供您在整个组织范围内进行查询。

图 1：跨中央账户和关联账户的 Amazon Bedrock 调用可观测性数据湖架构

所有内容均使用两个 AWS CloudFormation 模板以基础设施即代码的方式部署，因此您可以在组织中的每个账户中重复部署。相关内容可在 AWS Sample Bedrock Invocation Data Lake GitHub 存储库中找到。

每条 Amazon Bedrock 调用日志会捕获什么？

运行此解决方案后，您将在所部署到的关联账户中获得一个汇总数据集，以便使用 Athena 进行查询。日志被扁平化处理到 processed 表之后，每次调用您将获得：

提示词，即用户或应用程序发送的内容。
模型响应，即返回的结果。
输入和输出 token 计数，以便衡量每次调用的真实开销。
所使用的模型，以便了解各团队对模型的使用情况。
停止原因（例如，max_tokens），它会告诉您响应何时被截断。
账户和时间戳，这样你可以对所有内容进行归因并按时间切分。
该 AWS Identity and Access Management (IAM) 角色，这样你就能看到是谁发送了该提示。

每次调用都被这样记录下来后，你就能从“我们在 Amazon Bedrock 上使用了 X 个 token”变成“这里确切展示了每次模型调用的内容及其效率如何。”这正是平台和 ML 团队一直缺失的可视化能力。

Amazon Bedrock 数据湖是如何设计的？

数据湖将每次调用经过五个阶段流转，从 Amazon Bedrock 写入日志的那一刻起，直到你可以在 Athena 中查询它。

1. Amazon Bedrock 写入调用日志

每当应用程序调用 Amazon Bedrock 模型时，Amazon Bedrock 都可以记录发生了什么：哪个模型、哪个账户、哪个 IAM 身份发起了调用、使用了多少输入和输出 token，以及提示词和响应文本。你只需通过一次 API 调用为每个账户开启此功能，将 Amazon Bedrock 指向一个 CloudWatch 日志组，并授予它一个可以在那里写入的角色。

2. CloudWatch 将日志转发到中央账户

每个源账户在其 Amazon Bedrock 日志组上设置一个订阅筛选器。可以把它想象成一条永久的转发规则：“将每个新事件发送到这个地址。”这个地址是位于你的中央账户中的 Amazon CloudWatch Logs 目的地。源账户不需要中央管道的权限。它们将事件交给目的地，然后由中央账户自己的角色接手后续处理。

3. 一个小型 Lambda 整理每条记录

CloudWatch 交出的并不是干净的 JSON。它将事件打包成批次，并进行压缩和编码封装，所以到达的内容看起来像乱码，直到你解开它。一个小型 Lambda 函数做三件事：

将批次解开还原为单条日志记录。
剔除噪声。CloudWatch 会发送偶尔出现的维护消息以及诸如“Amazon Bedrock 日志的权限已正确设置”这样的纯文本通知。这些不是调用数据，如果让它们通过会破坏下一个阶段。
展平一个嵌套字段。调用者的身份在下一层嵌套中到达。Lambda 将它提升到顶层，以便日后查询时更加直接。

4. Amazon Data Firehose 转换为 Parquet 并写入 S3

Amazon Data Firehose 缓冲这些记录，并将它们写入 Amazon S3 存储桶，在传输过程中从 JSON 转换为 Parquet。Firehose 还会将每个对象按日期路径归档（year=2026/month=08/day=27/）。

5. 使用 Athena 查询数据并将其连接到成本数据

一个 AWS Glue 表告诉 Athena 如何读取这些文件，这样你就可以用普通 SQL 查询数据湖。你可以看到哪些用户使用的 token 最多、哪些模型被常用，以及人们在提示什么。如果需要，你还可以将其连接到 AWS Cost and Usage Report（CUR），按天获取用户提示词的花费。

开始之前需要准备什么？

在部署之前需要准备好以下几项：

为每个账户配置好凭证的 AWS 命令行界面（AWS CLI）。
CloudFormation CAPABILITY_IAM 和 CAPABILITY_NAMED_IAM 权限。
至少一个关联账户（运行你的 Amazon Bedrock 工作负载的账户）和一个中央账户用于接收复制的日志（它们可以是同一个账户）。
带 Boto3 的 Python 3（pip install boto3），用于端到端测试脚本。
克隆的代码仓库，包含所有资源。

如何部署它？

这里的顺序很重要。必须先创建中央账户堆栈，关联账户堆栈才能引用它。

第 1 阶段：部署中央数据湖堆栈

首先将中央 CloudFormation 堆栈部署到拥有该管道的账户中。在继续之前，请记下堆栈输出中的两个值：CloudWatch Logs 目标 ARN（每个源账户都需要）和 AWS Quick Sight 角色 ARN（如果之后要部署仪表板，则需要用到）。

第 2 阶段：在每个源账户中部署日志堆栈

部署关联账户 CloudFormation。对每个运行 Amazon Bedrock 工作负载的账户重复此操作。源堆栈很小，只需一个输入：第 1 阶段的目标 ARN。

第 3 阶段：开启 Amazon Bedrock 模型调用日志记录

部署堆栈并不会启动日志记录。Amazon Bedrock 日志记录是账户级设置，而不是 CloudFormation 资源。在每个源账户中激活一次，将 Amazon Bedrock 指向第 2 阶段的日志组和日志记录角色。只开启 CloudWatch 投递。

第 4 阶段：验证数据是否到达

在源账户中运行一次测试调用，等待 Amazon Data Firehose 刷新其缓冲区（大约一分钟，有时更长），然后确认 Parquet 对象已出现在数据湖的 data/ 前缀下。最后，检查你的 S3 存储桶以查看数据。

第 5 阶段：创建 Athena 视图并查询数据

中央堆栈会将视图定义保存为命名的 Athena 查询，但不会运行它。执行一次该保存的查询以创建扁平化视图。在专用的 Athena 工作组中运行查询，可以针对原始表或扁平化视图。该视图很简单：token 数量、缓存 token、停止原因以及提示/响应预览都已经是扁平的列。

如何查看 Amazon Bedrock token 的费用？

当你想要针对所有这些数据得出一个美元金额时，可以将处理后的表与你的 CUR 2.0 数据进行联接。联接键是 IAM ARN。你可以在 Bedrock Data Lake SQL 文件中使用以下示例查询。

这一步联接让可观测性数据湖同时具备了成本归因能力：哪些提示成本最高、每天每个团队或账户的成本，以及你效率最低的调用实际花费了多少。这是一个很棒的补充，但在达到这一步之前，这个数据湖已经物有所值了。

什么是 Tokenomics（token 经济学），为什么这个数据湖对它很重要？

Tokenomics，即管理人工智能（AI）token 消耗经济性的实践，在 2026 年 FinOps 基金会大会上被宣布为一个正式的 FinOps 领域。它建立在与云财务管理相同的 See、Save、Run 和 Plan 支柱之上，只是应用于 token 而非基础设施。挑战在于，你无法优化无法衡量的东西。如今大多数组织缺乏回答基本 tokenomics 问题所需的细粒度数据：哪些团队消耗的 token 最多，哪些提示是浪费的。通过每次调用的 token 和成本可见性，团队可以为每个工作负载匹配适合它的模型。这正是这个数据湖带给你的。借助对每次调用的提示、响应、token 数量、模型和 IAM 身份的可见性，你就拥有了启动 tokenomics 实践的基础，而不仅仅是跟踪一张 Amazon Bedrock 账单。

创建 Amazon Bedrock 调用日志仪表板

如果您想可视化您的 token 消耗情况，我们提供了一个 AWS Quick Sight 仪表板。它会随时间推移展示表中的数据，方便您与组织中的利益相关者分享。使用 AWS Quick Sight，您可以自定义仪表板并添加组织元数据（例如团队信息），使其更符合您的需求。要部署它，请使用 cid-cmd deploy CLI 命令。完整的分步部署说明见仓库 README，其中包括 AWS Quick Sight 角色配置和数据源设置。

图 2：AWS Quick Sight Amazon Bedrock 仪表板

现在您可以用 Amazon Bedrock 调用日志做什么？

有了将每次调用都汇聚到一个快速、可查询的表中，您终于可以轻松回答那些曾经令人头疼的问题：

调试和审计调用 – 在某个账户中获取特定调用的确切提示词和响应，无需翻查原始日志文件。
衡量 token 效率 – 比较各团队的 input_tokens 与 output_tokens 以及模型选择，找出在哪些地方毫无必要地消耗了大量 token。
发现提示词工程的机会 – 找出响应被截断（stop_reason = max_tokens）的请求，这通常表明提示词或配置需要改进。
审查模型家族 – 数据显示哪个模型服务于每种模式，团队可以据此确认每个模型与其工作负载相匹配。
治理跨团队的使用 – 每次调用都与一个账户关联，因此您知道谁在运行什么。

数据治理

由于此解决方案将所有团队的完整提示词和补全内容集中到一个 Amazon S3 存储桶中，因此安全性和治理从一开始就融入了架构设计。该存储桶受 AWS Key Management Service (AWS KMS) 服务器端加密保护，因此数据在静态状态下默认加密。对存储桶以及 Amazon Athena 查询结果的访问通过 AWS Identity and Access Management (IAM) 策略进行控制。您可以将权限范围限定为需要的团队和角色。提示词可能包含个人身份信息（PII），具体取决于用户与 Amazon Bedrock 的交互方式。我们建议审查您的 IAM 策略和 Amazon S3 存储桶策略，确认只有获得授权的主体才能访问这些数据。

清理资源

如果您希望删除所创建的资源，请先清空存储桶中的对象，然后删除 CloudFormation 模板。请注意，在删除之前要先清空 S3 存储桶，并手动删除 Athena 工作组。

总结

现在，您有了一种将 Amazon Bedrock 的原始调用日志转化为单一、快速、覆盖全组织的可观测性层的方法。您得到的不是一个封闭系统，而是对跨账户的每个提示词、响应、token 计数和模型选择的清晰视图。需要时，您还能直接查看每一项的成本。

与任何系统项目一样，不要试图一口吃成胖子。先从一两个关联账户开始，熟悉对调用表的查询，然后再扩展到整个组织。您的 Amazon Bedrock 使用量只会不断增长，因此越早建立这种可见性，未来每一次关于调试、效率和成本的讨论就越简单直接。

如果您有任何问题，或者想分享您如何在自己的工作负载中构建可观测性，请访问 AWS Sample Bedrock Invocation Data Lake GitHub 仓库。