为 Amazon Bedrock 构建主动式 AI 成本管理系统 - 第 1 部分

📢 转载信息

原文链接：https://aws.amazon.com/blogs/machine-learning/build-a-proactive-ai-cost-management-system-for-amazon-bedrock-part-1/

原文作者：Jason Salcido

随着组织拥抱由 Amazon Bedrock 驱动的生成式 AI，他们面临着管理与基于令牌的定价模型相关的成本的挑战。Amazon Bedrock 提供按使用付费的定价结构，如果使用情况没有得到仔细监控，可能会导致意外和过高的账单。传统的成本监控方法，例如预算提醒和成本异常检测，可以帮助发现意外的高使用量，但本质上是被动的。为了主动解决成本问题，使用前瞻性指标和滞后性指标至关重要。

前瞻性指标是预测信号，可帮助您在未来趋势或潜在问题完全显现之前预测它们。这些指标提供主动的见解，以便及时干预。相比之下，滞后性指标是追溯性的测量结果，用于确认已经发生的事情。通过理解和跟踪这两种指标，组织可以制定更具战略性和响应性的决策过程。

在本两部分系列文章中，我们介绍了一个用于主动管理 Amazon Bedrock 推理成本的全面解决方案。我们的方法采用了一种成本哨兵机制，旨在建立和执行令牌使用限制，为组织提供控制生成式 AI 支出的稳健框架。在本文中，我们重点介绍核心架构、成本哨兵设计、令牌使用跟踪和初始预算执行策略。在第 2 部分中，我们将探讨高级监控技术、自定义标记、报告和长期成本优化最佳实践。目标是为 Amazon Bedrock 部署提供一种可预测、经济高效的方法，以符合组织的财务限制。

解决方案概述

Amazon Bedrock 基于令牌使用策略进行计费，费用基于使用的输入和输出令牌。收取的费率取决于所使用的模型和执行推理的 AWS 区域。开发人员必须在其应用程序中实施稳健的令牌管理策略，以帮助防止成本失控，确保生成式 AI 应用程序包含与预算限制一致的断路器和消耗限制。

为解决此问题，您可以配置 Amazon CloudWatch 警报，或使用账单提醒和预算来监控成本，但这些机制是在事后查看已产生的成本或使用情况。另一个选择是 AWS 解决方案库中的生成式 AI 网关解决方案，它使用 LiteLLM 来对 Amazon Bedrock 和其他模型提供商的预算限制进行执行。

本解决方案旨在识别一种主动的、集中的机制，可以将生成式 AI 的使用限制在一个可以调整的特定预算内。这种方法使用无服务器工作流和原生的 Amazon Bedrock 集成，这提供了较低的运营复杂性，同时提供了大规模的性能和扩展能力。

在使用 Amazon Bedrock 构建应用程序时，通过已开发的 API 访问该服务是一种常见做法，可以通过 REST API 同步访问，也可以通过队列系统异步访问。下图比较了这些架构。

对于同步交互，客户端直接向 Amazon Bedrock 发出 REST API 调用，传入必要的参数。在异步架构中，客户端将推理请求提交到队列或消息代理，例如 Amazon Simple Queue Service (Amazon SQS)。后端处理系统（通常实现为无服务器函数或容器化应用程序）会持续监控队列并处理传入的请求。这种方法将客户端与推理处理解耦，从而在处理请求突发时实现了可扩展性和弹性。

此解决方案是一种集中的机制，可用于与 Amazon Bedrock 交互，作为主动的成本哨兵。它使用无服务器架构设计，利用 AWS Step Functions 来编排一个工作流，该工作流在允许 Amazon Bedrock 推理请求继续之前，根据配置的限制来验证令牌使用情况。此解决方案确保生成式 AI 应用程序保持在预定义的预算范围内，从而提供成本可预测性和控制。

下图说明了我们将在本文中构建的架构。

此解决方案的核心组件包括：

• 速率限制工作流 – 一个 Step Functions 工作流，它从 CloudWatch 检索当前的令牌使用指标，将其与存储在 Amazon DynamoDB 中的预定义限制进行比较，并决定是继续还是拒绝 Amazon Bedrock 推理请求。
• Amazon Bedrock 模型路由器 – 一个单独的 Step Functions 状态机，作为调用各种 Amazon Bedrock 模型的集中网关。此组件抽象了处理每个模型所需的各种 I/O 参数的复杂性。
• 令牌使用跟踪 – 使用与 Amazon Bedrock 的 CloudWatch 指标集成来检索跨所有或特定模型的输入和输出令牌的当前使用数据。
• 预算配置 – 通过将所需的预算值存储在 DynamoDB 中，允许按模型设置令牌使用限制。还可以设置一个默认限制，应用于未定义特定预算的模型。
• 成本和使用情况可见性 – 通过 CloudWatch 仪表板和 AWS Cost Explorer 中随时间推移的成本报告，提供 AI 使用情况的可见性。

该解决方案遵循无服务器架构方法，使用 Step Functions、AWS Lambda、DynamoDB 和 CloudWatch 等托管 AWS 服务，以提供可扩展、可扩展且经济高效的实现。

目标是提供一种主动方法来设置生成式 AI 使用限制，该限制作为前瞻性指标来限制使用：

• 主动预算编制 – 在允许推理请求之前强制执行令牌使用限制，有助于防止意外超支
• 特定于模型的预算 – 支持根据不同 Amazon Bedrock 模型的定价和使用模式设置单独的预算
• 默认预算回退 – 如果未为模型定义特定预算，可以应用默认限制以实现成本控制
• 监控 – 使用 CloudWatch 指标集成来跟踪令牌使用情况，从而实现准确的预算执行
• 无服务器架构 – 使用 Step Functions、Lambda、DynamoDB 和 CloudWatch 实现可扩展且经济高效的解决方案
• 可扩展性 – 模块化设计允许无缝集成额外的 Amazon Bedrock 模型或替代的推理方法

Step Functions 工作流

在本节中，我们将探讨该解决方案如何使用 Step Functions 来实现速率限制和模型路由工作流。

速率限制工作流

速率限制工作流旨在接收一个最小 JSON 文档作为输入，格式如下：

{
  "modelId": "string",       // e.g. "anthropic.claude-3-sonnet-20240229-v1:0"
  "prompt": {
     "messages": [
       {
         "role": "string",    // "system", "user", or "assistant"
         "content": "string"
      }
    ]
  }
}

此工作流是执行预算控制的核心组件。关键步骤如下：

1. 一个 Lambda 函数检索当前月份的开始和结束日期，用于查询适当时间范围的令牌使用指标。
2. 工作流查询 CloudWatch，以检索指定 Amazon Bedrock 模型当前月份的令牌使用指标。
3. 工作流从 DynamoDB 中检索指定 Amazon Bedrock 模型的配置令牌使用限制。如果未找到特定限制，它将回退到检索默认限制。
4. 工作流将当前令牌使用量与配置的限制进行比较，以确定预算是否已超出。
5. 如果令牌使用量在预算范围内，此步骤将调用 Amazon Bedrock 模型路由器状态机以执行实际的推理请求。
6. 根据预算检查的结果，工作流返回格式化的推理结果或指示预算超出的错误。

下图说明了 Step Functions 工作流。

Amazon Bedrock 模型路由器工作流

Amazon Bedrock 模型路由器工作流是一个单独的 Step Functions 状态机，负责根据请求参数调用适当的 Amazon Bedrock 模型。它抽象了处理各种 Amazon Bedrock 模型所需的各种 I/O 格式的复杂性，并将结果组合成标准化格式。

工作流中的关键步骤包括：

1. 根据提供的模型 ID，工作流确定要调用的特定 Amazon Bedrock 模型。
2. 工作流使用所需的输入参数调用适当的 Amazon Bedrock 模型。
3. 工作流将来自 Amazon Bedrock 模型的输出标准化为一致的格式，以供进一步处理或返回给客户端。
4. 工作流将转换后的推理结果返回给调用工作流（预算哨兵工作流）。

下图说明了 Step Functions 工作流。

您可以实施额外的步骤来处理错误情况并适当格式化输出。在此示例中，Anthropic 流程包括错误处理。

使用 CloudWatch 指标进行令牌使用跟踪

Amazon Bedrock 成本哨兵使用 CloudWatch 与 Amazon Bedrock 的集成来检索当前的令牌使用指标。这些指标用于主动强制执行预算限制。例如，请看以下查询：

{
   "sparkline": false,
   "metrics": [
      	[ { "expression": "SEARCH('{AWS/Bedrock} MetricName=\"InputTokenCount\"', 'Sum', 60)", "region": "us-east-1" } ],
      	[ { "expression": "SEARCH('{AWS/Bedrock} MetricName=\"OutputTokenCount\"', 'Sum', 60)", "region": "us-east-1" } ]
  	],
   "legend": {
      	"position": "right"
  	},
   "title": "InputTokenCount, OutputTokenCount",
   "region": "us-east-1",
   "liveData": true,
   "view": "gauge",
   "stacked": false,
   "period": 2592000,
   "table": {
      	"summaryColumns": [
        		"SUM"
     ]
  	},
   "yAxis": {
      	"left": {
        		"min": 0,
        		"max": 1000000
     }
  	},
   "setPeriodToTimeRange": true,
   "trend": false,
   "startTime": "2024-05-01T00:00:00Z",
   "endTime": "2024-05-30T23:59:59Z"
}

此 CloudWatch 指标查询检索指定时间范围内输入和输出令牌的总计数，从而允许速率限制工作流根据实时使用数据准确执行预算。

使用 DynamoDB 进行预算配置

Amazon Bedrock 成本哨兵将令牌使用限制存储在 DynamoDB 表中，从而可以无缝配置和更新单个模型预算或默认限制。例如，请看以下代码：

{
   "modelId": "anthropic.claude-3-sonnet-20240229-v1:0",
   "limit": {
        "input": 1000000,
        "output": 3000000
   }
}

在此示例中，指定 Amazon Bedrock 模型（anthropic.claude-3-sonnet-20240229-v1:0）的令牌使用限制设置为 1,000,000 个输入令牌和 3,000,000 个输出令牌。

管理员可以通过修改相应的 DynamoDB 记录快速更新这些限制，从而在需要时灵活调整预算。

速率限制工作流的性能分析

为了评估引入工作流对性能的影响，我们使用了一系列推理请求。测试用例包括旨在生成从简洁答案到 500 多个词的详细解释的各种提示，有效地测试了工作流在不同输出令牌大小下的性能。该工作流在 501 次成功执行中表现出卓越的性能特征，处理了从简短响应到广泛内容生成的各种推理请求。

在处理总持续时间从 6.76 秒到 32.24 秒的请求时，工作流保持一致的执行模式，差异主要反映了每个请求不同的输出令牌需求：

• 快速响应（少于 10 秒） – 通常处理简洁的答案和简单的查询
• 中等长度内容（11-22 秒） – 常用于详细解释和多段落响应
• 扩展生成（最长 32 秒） – 处理需要超过 500 个词的全面响应

下图说明了我们的时间分布发现。

时间分布分析揭示了高度优化的资源利用率：

• Amazon Bedrock 模型路由器 – 5.80–31.99 秒（占运行时的 98.26%）
• 其他工作流步骤 – 0.11–4.74 秒（占运行时的 1.65%）
• 系统开销 – 平均 0.02 秒（占运行时的 0.09%）

此性能配置文件符合工作流编排的最佳实践，其中最小化开销和保持一致的执行模式对于可靠性至关重要。工作流的效率体现在其极低的 0.09% 系统开销上，这表明无论生成的响应大小如何，都能有效利用 Step Functions 的内置控制和状态管理功能。

执行一致性尤其值得注意，每次执行的事件模式都具有可预测性，为 47-49 个事件，无论推理请求的复杂性或输出大小如何。这种可预测性对于工作负载管理和资源规划至关重要，尤其是在处理不同的请求复杂性和令牌输出时。

这些指标表明了一个设计良好的工作流，它有效地利用了Step Functions Express 工作流的能力来处理大批量事件，同时对简单查询和复杂的、令牌密集型的推理请求都保持最小的开销和一致的性能特征。

成本分析

为了分析成本影响，我们使用 AWS 定价计算器估算了标准和 Express Step Functions 工作流的成本，假设每月 100,000 次请求。下表总结了这些估计。

成本分析显示，与标准工作流相比，Step Functions Express 工作流提供了更具成本效益的解决方案，对于相同的工作负载，潜在成本节省高达 90%。如果可以优化步骤数量，则标准工作流有潜力降低成本。例如，可以删除一些格式化传递步骤，但这些步骤有助于格式化后续步骤的下游输入。

请查阅AWS 定价计算器以获取更多定价详细信息并运行您自己的场景。

结论

在此解决方案中，我们使用 Step Functions 构建了一个系统，该系统通过跟踪速率限制和令牌使用情况充当前瞻性指标，立即提醒我们何时接近使用限制。在第 2 部分中，我们将讨论将此与滞后性指标相结合，以随时了解使用情况和成本。

关于作者

Jason Salcido 是初创企业高级解决方案架构师，拥有近 30 年的经验，致力于为初创企业到大型企业组织开创创新解决方案。他的专业知识涵盖云架构、无服务器计算、机器学习、生成式 AI 和分布式系统。Jason 将深厚的技术知识与前瞻性方法相结合，设计出可创造价值的可扩展解决方案，同时将复杂的概念转化为可行的策略。

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。