为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，他们面临着管理与Token计费模式相关的成本的挑战。Amazon Bedrock 提供了一种按使用量付费的定价结构，如果使用情况未得到仔细监控，可能会导致意外和过高的账单。传统的成本监控方法，例如预算提醒和成本异常检测，可以帮助发现意外的高使用量，但它们本质上是被动的。为了主动应对成本，使用领先指标和滞后指标至关重要。

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

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

解决方案概述

Amazon Bedrock 按 Token 使用量收费，费用基于输入和输出的Token使用量。收取的费率取决于所使用的模型和执行推理的 AWS 区域。开发人员必须在其应用程序中实施稳健的 Token 管理策略，以帮助防止成本失控，确保生成式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 推理请求继续之前，会根据配置的限制来验证 Token 使用情况。此解决方案确保生成式AI应用程序保持在预定义的预算范围内，从而提供了成本的可预测性和控制力。

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

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

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

该解决方案遵循无服务器架构方法，使用 Step Functions、AWS Lambda、DynamoDB 和 CloudWatch 等托管 AWS 服务，以提供可扩展、可扩展且具有成本效益的实施。

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

• 主动预算 – 在允许推理请求之前强制执行 Token 使用限制，有助于防止意外超支
• 特定模型预算 – 支持根据不同 Amazon Bedrock 模型的定价和使用模式设置单独的预算
• 默认预算回退 – 如果未为模型定义特定预算，可以应用默认限制以实现成本控制
• 监控 – 使用 CloudWatch 指标集成来跟踪 Token 使用情况，从而实现准确的预算执行
• 无服务器架构 – 使用 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 函数检索当前月份的开始和结束日期，用于查询适当时间范围内的 Token 使用指标。
2. 工作流查询 CloudWatch，以检索指定 Amazon Bedrock 模型当前月份的 Token 使用指标。
3. 工作流从 DynamoDB 中检索指定 Amazon Bedrock 模型的配置的 Token 使用限制。如果没有找到特定限制，它将回退到检索默认限制。
4. 工作流将当前的 Token 使用量与配置的限制进行比较，以确定预算是否已超出。
5. 如果 Token 使用量在预算范围内，此步骤将调用 Amazon Bedrock 模型路由器状态机以执行实际的推理请求。
6. 根据预算检查的结果，工作流返回格式化的推理结果或指示预算已超出的错误。

下图说明了 Step Functions 工作流。

Amazon Bedrock 模型路由器工作流

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

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

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

下图说明了 Step Functions 工作流。

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

使用 CloudWatch 指标跟踪 Token 使用情况

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

{
   "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 指标查询检索指定时间范围内的总输入和输出 Token 计数，使速率限制工作流能够根据实时使用数据准确地执行预算。

使用 DynamoDB 进行预算配置

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

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

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

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

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

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

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

• 快速响应（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 个事件。这种可预测性对于工作负载管理和资源规划至关重要，尤其是在处理不同请求复杂性和 Token 输出时。

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

成本分析

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

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

请查阅 AWS 定价计算器了解定价详情并运行您自己的场景。

结论

在此解决方案中，我们使用 Step Functions 构建了一个系统，该系统通过跟踪速率限制和 Token 使用情况充当领先指标，使我们立即了解何时接近使用限制。在第 2 部分中，我们将讨论如何将此与滞后指标相结合，以保持对使用情况和成本的了解。

关于作者

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

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

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