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

# 成本优化
<a name="cost-optimization"></a>

随着无服务器和 AI 工作负载的扩展，成本可见性和控制成为可持续运营的基础。与传统计算不同，在传统计算中，每实例小时的成本是可以预测的，而无服务器和生成式人工智能服务则引入了新的成本维度：
+ 按令牌使用量计算的推理成本（例如 Amazon Bedrock）
+ 按次调用计费（例如和） AWS Lambda AWS Step Functions
+ 事件量驱动的触发器（例如，Amazon EventBridge 和 Amazon S3）
+ 知识库、工具调用和检索增强生成 (RAG) 扩展动态

如果不进行仔细的计划和监控，组织就有可能出现意想不到的账单高峰，尤其是在大规模的大型语言模型 (LLMs) 或无限的事件循环中。

## 为什么成本优化在无服务器 AI 中至关重要
<a name="section-cost-importance"></a>

以下因素会影响无服务器 AI 系统的成本：
+ **LLM 尺寸选择** — 更高级别的型号（例如 A [mazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/what-is-nova.html) Premier）每个代币的价格要高得多。
+ **提示长度和详细程度 — 较长的输入和输出会线性增加 Amazon B** edrock 的成本。
+ **工具调用蔓延** — 使用过多或冗余工具的代理可能会增加 Lambda 和数据传输费用。
+ **Step Functions 工作流程精细度** — 过于分散的工作流程会增加状态转换和执行时间。
+ **数据移动** — 过多的跨区域流量、不必要的 RAG 索引或重复获取知识库可能会变得代价高昂。

## 成本优化策略
<a name="section-cost-strategies"></a>

考虑实施以下策略来优化无服务器 AI 工作负载的成本：
+ **使用分层模型选择** — Amazon Nova、Amazon Titan 和 Anthropic Claude 等型号提供不同的定价模型，并在成本、速度和准确性方面进行权衡。要实施此策略，请将低复杂度的提示发送到 Amazon Nova Micro，并仅在信心较低时才上报。
+ **修剪提示和输出** — 代币数量是 Amazon Bedrock 中最大的成本驱动因素。要实现此策略，请强制执行最大提示大小，使用简洁的措辞，并避免冗长的完成。
+ **控制 RAG 检索范围** — 知识库中的无界文档可以激发上下文。要实现此策略，请使用元数据过滤器和前 K 排名。此外，仅向 LLM 提示符中注入相关内容。
+ **用于推理的批处理事件 — 单个推**理调用比批处理更昂贵。要实现此策略，请对输入（例如情绪分析和总结）进行分组，然后每批运行一次推理。
+ **使用 Step Functions 进行聚合，而不是微观管理** — 过度使用原子状态转换会导致持续时间长。要实现此策略，请将相关逻辑分组为 Lambda 单元，避免状态爆炸模式。
+ **异步响应处理** — 不要因为等待慢速模型而阻塞计算。要实施此策略，请[EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)与[亚马逊简单队列服务](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) (Amazon SQS) 和 Lambda 一起使用延迟响应模式（例如，异步汇总）。
+ **使用 Amazon Bedrock 成本分配标签** — 标签允许根据应用程序和团队进行可见性。要实施此策略，请在 Amazon Bedrock 调用中应用标准化标签（例如`Project=MarketingAI`和`Team=GenOps`）。
+ **调整重试和置信逻辑** — 不必要的重试或后备链会增加成本。要实施此策略，请使用结构化置信阈值和提前退出来限制重试。
+ **使用缓存进行工具调用** — 许多代理工具调用都会重复数据获取。要实施此策略，请在 [Amazon Dynamo](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) DB 中存储包含生存时间 (TTL) 的最新工具结果，如果未更改，则可重复使用。
+ **利用预留的并发或预配置的并发**（如果需要）— 在大量情况下，此策略可以减少冷启动和成本不确定性。通过仅为流量可预测且预热时间长的功能启用此策略。

## 示例：具有成本意识的生成式 AI 助手
<a name="section-cost-example-assistant"></a>

支持助手是使用 [Amazon Bedrock Agen](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html) ts 构建的。它还使用基于 Lambda 的集成工具，用于实时数据访问（例如，用户订单和退货政策）。最后，它使用包含产品文档和政策 PDF 文件的知识库。 FAQs

该助手的功能如下：

1. 它通过 [Amazon API Gatew](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) ay 通过聊天（前端）接收自然语言请求。

1. 对于诸如策略查询之类的简单问题，它会执行以下操作：
   + 调用轻量级法学硕士（Amazon Nova Lite）来制定答案。
   + 从 Amazon Bedrock 知识库中提取基础背景。

1. 对于更复杂的查询（例如多步解析），它会执行以下操作：
   + 使用以目标为导向的编排激活 Amazon Bedrock 代理。
   + 使用 Lambda 工具`getOrderStats(userId)`，比如`initiateReturn(orderId)`、和。`lookupDeliveryOptions(zipCode)`

1. 对响应进行后处理以执行以下操作：
   + 移除多余的输出。
   + 验证与策略一致的消息。
   + 记录交互数据。

以下成本优化策略适用于此示例 AI 助手：
+ **分层模型路由**通过使用较小的模型处理较小的请求来降低成本。这种方法使用Amazon Nova Lite进行常见问题解答式的提示，而Claude 3 Sonnet仅用于需要推理或多次调用工具的10％的案例。
+ **即时修剪和模板控制**可保持一致的、可预测的成本使用量。提示有令牌上限，由结构化模板构建（例如，带上下文的最多 400 个令牌）。
+ **上下文 RAG 作用域**可避免在 LLM 提示中注入多余的文档。知识库使用元数据筛选将检索限制在相关的产品类别或策略领域。
+ **工具调用结果缓存可避免用户**在改写措辞时重复调用 Lambda。来自`getOrderStatus`和的结果将缓存`lookupReturnWindow`在 DynamoDB 中，TTL 为 10 分钟。
+ **基于信心的模型升级**在体验质量和法学硕士成本控制之间取得平衡。如果 Amazon Nova Lite 响应置信度（按结构和正则表达式启发式方法衡量）较低，请回退到 Anthropic Claude 或人工升级队列。
+ **响应验证器 Lambda 将不必要的输出令牌减少了大**约 25%。这种方法可以去除冗长的模型补全，将响应格式化为简洁的输出，并记录令牌的大小。
+ **成本标签**允许按功能和环境进行 FinOps 报告。所有 Amazon Bedrock 通话都标有`Application=SupportAssistant``Environment=Production`、和。`Team=CustomerSuccess`

此示例展示了智能架构选择（例如分层模型路由、缓存、范围检索和推理审计）如何降低运营成本，同时仍能提供高质量、可扩展的支持自动化。生成式 AI 助手示例提供了一个可重复使用的模板，该模板适用于人力资源助理、IT 服务台、合作伙伴入职机器人或客户教育助理等领域。在每种情况下，该模板都可以帮助实现成本效率、信任和规模的平衡。

## 监控和警报以实现成本优化
<a name="section-cost-monitoring"></a>

以下内容 AWS 服务 有助于监控和优化无服务器 AI 工作负载的成本：
+ [CloudWatch指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)跟踪亚马逊 Bedrock 代币使用情况、Step Functions 步骤持续时间和 Lambda 调用成本。
+ [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)当突破成本阈值（例如，每日代币成本）时向团队发出警报。
+ [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html)和 C [ost C](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) ategories 提供按应用、团队或模型计算的支出视图。
+ [Amazon Bedrock API](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#br-cloudwatch-metrics) 日志（通过 CloudWatch）可以分析提示结构和响应大小。
+ [Amazon](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) Athena 和 A [mazon](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html) S3 日志支持对 AWS CloudTrail 从或自定义日志导出的使用数据进行一次性或临时查询。

## 成本优化警告信号
<a name="section-cost-warning-signals"></a>

监控以下信号以识别潜在的成本优化问题：
+ **代币使用量激增** — 可能表示快速更改、新模型版本或 RAG 检索过多。
+ **Amazon Bedrock 延迟增加** — 可能导致 Lambda 持续时间延长，并增加每次推理的成本。
+ **每次代理会话的工具调用次数激增** — 暗示工具滥用或提示逻辑效率低下。
+ **长时间运行的 Step Functions 步骤** — 可能是由于过度分解状态或异步事件被阻塞所致。
+ **未充分利用的模型等级** — 表示为低风险请求的高级精度付费。

## 成本优化摘要
<a name="section-cost-summary"></a>

在人工智能驱动的无服务器中，成本优化不仅仅是为了最大限度地减少支出。这是为了使计算和模型的使用与每个决策的业务价值保持一致。有了正确的战略，组织就可以负责任和自信地扩大规模，在创新与成本控制之间取得平衡。

通过将分层模型策略、提示和代币纪律、工作流程调整以及可观察性和标记相结合，企业可以在不超支预算的情况下从人工智能投资中获得最大价值。