正文 · AI 翻译
如果你需要为 Amazon Bedrock 工作负载建立可观测性数据湖，你并不孤单。当你每天在多个账户中运行数千次模型调用时，请求发出后，你可能会想：发生了什么？你能看到汇总账单，却看不到每次调用内部发生了什么。你可能开始问：发送了什么提示词，模型返回了什么，使用了多少令牌，由哪个模型处理，以及响应质量如何！如果你是负责多个团队的 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 调用可观测性数据湖架构。所有组件都使用 2 个 AWS CloudFormation 模板，以基础设施即代码的方式部署，因此你可以在组织的每个账户中重复部署。这些模板可在 AWS Sample Bedrock Invocation Data Lake GitHub 存储库中找到。每条 Amazon Bedrock 调用日志记录了什么？运行此解决方案后，你将获得在部署该方案的关联账户之间汇总的数据，并可使用 Athena 查询。日志展平到处理后的表后，每次调用可获得以下信息：用户或应用程序发送的提示词。模型返回的响应。输入和输出令牌数，让你衡量每次调用的实际规模。使用的模型，让你了解各团队使用不同模型的情况。停止原因（例如 max_tokens），表明响应何时被截断。账户和时间戳，让你能够归属数据并按时间分析。AWS Identity and Access Management（IAM）角色，让你了解是谁发送了提示词。像这样捕获每次调用后，你就能从“我们在 Amazon Bedrock 上使用了 X 个令牌”，进一步了解到“每次模型调用具体包含什么，以及效率如何”。这正是平台和 ML 团队一直缺少的可见性。Amazon Bedrock 数据湖是如何设计的？从 Amazon Bedrock 写入日志，到你能够在 Athena 中查询，数据湖让每次调用的数据经过 5 个阶段。1. Amazon Bedrock 写入调用日志。每当应用程序调用 Amazon Bedrock 模型时，Amazon Bedrock 都可以记录发生了什么：使用了哪个模型、哪个账户、由哪个 IAM 身份发起调用、使用了多少输入和输出令牌，以及提示词和响应文本。你只需在每个账户中通过一次 API 调用开启此功能，指定一个 CloudWatch 日志组，并提供一个可向其中写入日志的角色。2. CloudWatch 将日志转发到中央账户。每个源账户都要在其 Amazon Bedrock 日志组上设置订阅筛选器。可以把它理解为一条永久转发规则：“将每个新事件发送到这个地址。”这个地址是位于中央账户中的 Amazon CloudWatch Logs 目标。源账户不会获得中央处理管道的权限。它们将事件交给该目标，之后由中央账户自己的角色接手。3. 一个小型 Lambda 函数整理每条记录。CloudWatch 传来的并不是干净的 JSON。它将事件打包成批次，并进行压缩和编码，因此收到的数据在解包前看起来像乱码。一个小型 Lambda 函数完成 3 项工作：将批次解包为单独的日志记录。过滤掉无关内容。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 查询数据湖。你可以查看哪些用户使用的令牌最多、哪些模型经常被选用，以及人们输入了什么提示词。如果需要，你还可以将这些数据与 AWS Cost and Usage Report（CUR）关联，获得按天统计的用户提示词支出。开始前需要准备什么？部署前需要准备以下几项：已配置每个账户凭证的 AWS Command Line Interface（AWS CLI）。CloudFormation CAPABILITY_IAM 和 CAPABILITY_NAMED_IAM 权限。至少 1 个关联账户（运行 Amazon Bedrock 工作负载的账户）和 1 个用于接收复制日志的中央账户（两者可以是同一账户）。用于端到端测试脚本的 Python 3 和 Boto3（pip install boto3）。包含所有资源的已克隆存储库。如何部署？这里的顺序很重要。中央账户堆栈必须先存在，关联账户堆栈才能引用它。阶段 1：部署中央数据湖堆栈。首先在拥有处理管道的账户中部署中央 CloudFormation 堆栈。继续之前，记下堆栈输出中的 2 个值：CloudWatch Logs 目标 ARN（每个源账户都需要）和 AWS Quick Sight 角色 ARN（如果之后部署仪表板，就需要它）。阶段 2：在每个源账户中部署日志记录堆栈。部署关联账户的 CloudFormation 堆栈。对每个运行 Amazon Bedrock 工作负载的账户重复此操作。源账户堆栈很小，只需 1 个输入值：阶段 1 的目标 ARN。阶段 3：开启 Amazon Bedrock 模型调用日志记录。部署堆栈并不会自动开始记录日志。Amazon Bedrock 日志记录是账户级设置，而不是 CloudFormation 资源。在每个源账户中启用一次，并让 Amazon Bedrock 指向阶段 2 创建的日志组和日志记录角色。仅开启向 CloudWatch 传送日志。阶段 4：验证数据是否到达。在源账户中运行一次测试调用，等待 Amazon Data Firehose 刷新缓冲区（约 1 分钟，有时更久），然后确认数据湖的 data/ 前缀下出现了 Parquet 对象。最后，检查 S3 存储桶以查看数据。阶段 5：创建 Athena 视图并查询数据。中央堆栈将视图定义保存为命名的 Athena 查询，但不会执行它。执行一次这个已保存的查询，以创建展平后的视图。在专用 Athena 工作组中，对原始表或展平后的视图运行查询。这个视图很直观：令牌数、缓存令牌数、停止原因以及提示词和响应预览都已经是展平后的列。如何查看 Amazon Bedrock 令牌的成本？如果你想为这些数据对应到具体金额，可以将处理后的表与 CUR 2.0 数据连接。连接键是 IAM ARN。你可以使用 Bedrock Data Lake SQL 文件中的示例查询。仅凭这一次连接，可观测性数据湖就能用于成本归属：哪些提示词成本最高、每个团队或账户每天的成本是多少，以及效率最低的调用实际花费了多少。这是一项很好的补充，但即使尚未完成这一步，数据湖也已经很有价值。什么是令牌经济学，为什么这个数据湖对它很重要？令牌经济学是管理人工智能（AI）令牌消耗成本的实践，在 2026 年 FinOps Foundation 大会上被宣布为正式的 FinOps 领域。它沿用云财务管理的“看清、节省、运行和规划”（See、Save、Run、Plan）支柱，但应用对象是令牌，而非基础设施。难点在于，无法衡量的东西就无法优化。如今，大多数组织缺乏足够细致的数据，无法回答基本的令牌经济学问题：哪些团队消耗的令牌最多，哪些提示词造成了浪费。凭借每次调用的令牌和成本可见性，团队可以为每个工作负载匹配合适的模型。这正是这个数据湖所提供的。能够逐次查看提示词、响应、令牌数、模型和 IAM 身份，你便有了开展令牌经济学实践的基础，而不只是追踪 Amazon Bedrock 账单。创建 Amazon Bedrock 调用日志仪表板。如果你想将令牌消耗可视化，我们提供了一个 AWS Quick Sight 仪表板。它会展示表中的数据随时间的变化，方便你与组织中的利益相关者分享。使用 AWS Quick Sight，你可以自定义仪表板，并添加团队信息等组织元数据，使其符合自己的需求。要部署它，请使用 cid-cmd deploy CLI 命令。存储库的 README 中提供了完整的分步部署说明，包括 AWS Quick Sight 角色配置和数据源设置。图 2：AWS Quick Sight Amazon Bedrock 仪表板。现在你能用 Amazon Bedrock 调用日志做什么？当每次调用都汇集到一张速度快、可查询的表中，你终于能够回答过去很难回答的问题：调试和审计调用——无需翻查原始日志文件，就能提取某个账户中特定调用的确切提示词和响应。衡量令牌效率——比较各团队的 input_tokens、output_tokens 和模型选择，找出无谓消耗令牌的地方。发现提示词工程改进机会——找出响应被截断的请求（stop_reason = max_tokens），这通常表明提示词或配置需要调整。审查模型系列——数据会显示每种使用模式由哪个模型提供服务，帮助团队确认模型是否适合相应工作负载。管理各团队的使用情况——每次调用都关联到一个账户，因此你知道谁在运行什么。数据治理。由于此解决方案将每个团队的完整提示词和模型输出集中到单个 Amazon S3 存储桶，安全和治理从一开始就融入了架构。存储桶使用 AWS Key Management Service（AWS KMS）进行服务器端加密，因此静态数据默认处于加密状态。对存储桶和 Amazon Athena 查询结果的访问通过 AWS Identity and Access Management（IAM）策略控制。你可以将权限限定给需要访问的团队和角色。根据用户与 Amazon Bedrock 的交互方式，提示词可能包含个人身份信息（PII）。我们建议检查 IAM 策略和 Amazon S3 存储桶策略，确认只有获得授权的主体才能访问数据。清理。如果希望删除创建的资源，请先清空存储桶中的对象，再删除 CloudFormation 模板。请注意，在删除之前清空 S3 存储桶，并手动删除 Athena 工作组。总结。现在，你可以将 Amazon Bedrock 的原始调用日志转换为覆盖整个组织的统一、快速的可观测性层。你能清楚看到各账户中的每条提示词、响应、令牌数和模型选择。如果需要，还能直接了解每次调用的成本。与任何系统项目一样，不要试图一口气完成所有工作。从 1 个或 2 个关联账户开始，熟悉如何查询调用表，然后再扩展到整个组织。你对 Amazon Bedrock 的使用只会增长，因此越早建立这种可见性，今后讨论调试、效率和成本就越容易。如果你有任何问题，或想分享自己如何为工作负载建立可观测性，请访问 AWS Sample Bedrock Invocation Data Lake GitHub 存储库。关于作者。Steph Gooch。Steph 是首席技术倡导者。她是指导客户优化当前及未来 AWS 支出的领域专家。她帮助客户组织和解读账单与使用数据，从中找出可采取行动的洞见，并制定可持续的策略，将成本意识融入组织文化。