OC

使用 Amazon Bedrock 跟踪、分配和管理您的生成式 AI 成本和使用情况 |亚马逊网络服务

2024-11-01 19:34:06 英文原文

随着企业越来越拥抱生成式人工智能，他们在管理相关成本方面面临挑战。随着跨项目和多个业务线对生成式人工智能应用程序的需求激增，准确分配和跟踪支出变得更加复杂。组织需要根据业务影响和重要性优先考虑其生成式人工智能支出，同时保持跨客户和用户群体的成本透明度。这种可见性对于为生成式人工智能产品设置准确的定价、实施退款以及建立基于使用情况的计费模型至关重要。

如果没有可扩展的成本控制方法，组织就会面临预算外使用和成本超支的风险。手动支出监控和定期使用限制调整效率低下，并且容易出现人为错误，从而导致潜在的超支。虽然多种 Amazon Bedrock 资源支持标记– 包括预置模型、自定义模型、代理和代理别名、模型评估、提示、提示流、知识库、批量推理作业、自定义模型作业和模型复制作业 – 以前没有按需标记的功能基础模型。这种限制增加了生成式人工智能计划的成本管理的复杂性。

为了应对这些挑战，亚马逊基岩已经推出了组织可以使用的功能标签按需模型并监控相关成本。组织现在可以使用以下标签标记所有 Amazon Bedrock 模型AWS 成本分配标签，使使用与特定的组织分类法（例如成本中心、业务单位和应用程序）保持一致。为了明智地管理他们的生成人工智能支出，组织可以使用诸如AWS 预算设置基于标签的预算和警报来监控使用情况，并接收异常或预定义阈值的警报。这种可扩展的编程方法消除了低效的手动流程，降低了超额支出的风险，并确保关键应用程序获得优先级。增强对人工智能相关费用的可见性和控制，使组织能够最大限度地利用其生成式人工智能投资并促进创新。

推出 Amazon Bedrock 应用程序推理配置文件

亚马逊基岩最近推出跨区域推理，实现跨 AWS 区域自动路由推理请求。该功能使用系统定义的推理概况（由 Amazon Bedrock 预定义），它配置来自不同区域的不同模型 Amazon 资源名称 (ARN)，并将它们统一到单个模型标识符（模型 ID 和 ARN）下。虽然这增强了模型使用的灵活性，但它不支持附加自定义标签来跟踪、管理和控制跨工作负载和租户的成本。

为了弥补这一差距，Amazon Bedrock 现在推出了应用程序推理配置文件是一项新功能，允许组织应用自定义成本分配标签来跟踪、管理和控制其 Amazon Bedrock 按需模型成本和使用情况。此功能使组织能够为 Bedrock 基础模型创建自定义推理配置文件，添加特定于租户的元数据，从而简化各种 AI 应用程序的资源分配和成本监控。

创建应用程序推理配置文件

应用程序推理配置文件允许用户为推理请求和资源管理定义自定义设置。这些配置文件可以通过两种方式创建：

  1. 单一模型 ARN 配置：使用单个按需基础模型 ARN 直接创建应用程序推理配置文件，从而允许使用所选模型进行快速设置。
  2. 从系统定义的推理配置文件复制：复制现有的系统定义的推理模板来创建应用推理模板，该推理模板将继承跨区域推理能力等配置，以增强可扩展性和弹性。

应用程序推理配置文件 ARN 具有以下格式，其中推理配置文件 ID 组件是 Amazon Bedrock 在创建配置文件时生成的唯一 12 位字母数字字符串。

arn:aws:基岩:<区域>:<帐户ID>:应用程序推理配置文件/<推理配置文件 ID>

系统定义与应用程序推理配置文件的比较

系统定义的推理配置文件和应用程序推理配置文件之间的主要区别在于它们类型ARN 命名空间内的属性和资源规范：

  • 系统定义的推理配置文件：它们的类型属性为系统定义并利用推理概要资源类型。它们旨在支持跨区域和多模型功能，但由 AWS 集中管理。
    {���"inferenceProfileArn": "arn:aws:bedrock:us-east-1:<帐户ID>:inference-profile/us-1.anthropic.claude-3-sonnet-20240229-v1:0","inferenceProfileId": "us-1.anthropic.claude-3-sonnet-20240229-v1:0","inferenceProfileName": "US-1 Anthropic Claude 3 Sonnet",“状态”：“活动”，“类型”：“SYSTEM_DEFINED”，���}
  • 应用推理配置文件：这些配置文件有一个类型的属性应用并使用应用程序推理配置文件资源类型。它们是用户定义的，提供对模型配置的精细控制和灵活性，并允许组织使用 AWS Identity and Access Management (IAM) 通过基于属性的访问控制 (ABAC) 定制策略。这使得更精确的 IAM 策略创作能够更安全、更高效地管理 Amazon Bedrock 访问。
    {���"inferenceProfileArn": "arn:aws:bedrock:us-east-1:<帐户ID>:应用程序推理配置文件/<自动生成的ID>“，“推理配置文件 ID”：<自动生成的ID>,“推理配置文件名称”：<用户定义的名称>,“状态”：“活动”，“类型”：“应用程序”���}

这些差异在集成时很重要亚马逊 API 网关或其他 API 客户端，以帮助确保正确的模型调用、资源分配和工作负载优先级。组织可以根据个人资料应用定制策略类型，增强分布式人工智能工作负载的控制和安全性。两种模型如下图所示。

建立成本管理的应用程序推理配置文件

想象一下，一家保险提供商踏上了通过生成式人工智能增强客户体验的旅程。该公司发现了自动化索赔处理的机会，提供个性化的政策建议，并为不同地区的客户改进风险评估。然而，为了实现这一愿景，组织必须采用强大的框架来有效管理其生成式人工智能工作负载。

该旅程从保险提供商创建适合其不同业务部门的应用程序推理配置文件开始。通过分配 AWS 成本分配标签，组织可以有效监控和跟踪其 Bedrock 支出模式。例如，索赔处理团队建立了一个应用程序推理配置文件，其中包含以下标签：部门：索赔,团队：自动化， 和应用程序：claims_chatbot。这种标记结构对成本进行分类，并允许根据预算评估使用情况。

用户可以使用 Bedrock API 或 boto3 SDK 管理和使用应用程序推理配置文件：

  • 创建推理配置文件：启动新的推理配置文件，允许用户配置该配置文件的参数。
  • 获取推理配置文件：检索特定推理配置文件的详细信息，包括其配置和当前状态。
  • 列出推理配置文件：列出用户帐户内所有可用的推理配置文件，提供已创建的配置文件的概述。
  • 标签资源：允许用户将标签附加到特定的 Bedrock 资源（包括应用程序推理配置文件），以便更好地组织和成本跟踪。
  • 资源列表标签：获取与特定基岩资源关联的标签，帮助用户了解其资源的分类方式。
  • 取消标记资源：从资源中删除指定标签，以便管理资源组织。
  • 使用应用程序推理配置文件调用模型:
    • 匡威 API：使用指定的推理配置文件调用模型进行对话交互。
    • ConverseStream API：与 Converse API 类似，但支持实时交互的流式响应。
    • 调用模型API：针对一般用例调用具有指定推理配置文件的模型。
    • InvokeModelWithResponseStream API：调用模型并流式传输响应，对于处理大数据输出或长时间运行的流程很有用。

请注意，无法通过 AWS 管理控制台访问应用程序推理配置文件 API。

使用 Converse API 通过应用程序推理配置文件调用模型

以下示例演示了如何创建应用程序推理配置文件，然后调用 Converse API 以使用该配置文件进行对话 –

def create_inference_profile（profile_name，model_arn，标签）："""使用基本模型 ARN 创建推理配置文件"""响应 = bedrock.create_inference_profile(inferenceProfileName=配置文件名称，描述=“测试”，modelSource={'copyFrom': model_arn},标签=标签）打印（“CreateInferenceProfile响应：”，响应['ResponseMetadata'] ['HTTPStatusCode']），打印（f“{响应}\n”）返回响应# 创建推理配置文件print("测试 CreateInferenceProfile...")标签 = [{'key': 'dept', 'value': 'claims'}]base_model_arn = "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0"Claims_dept_claude_3_sonnet_profile = create_inference_profile（“claims_dept_claude_3_sonnet_profile”，base_model_arn，标签）# 提取 ARN 并检索应用程序推理配置文件 IDClaims_dept_claude_3_sonnet_profile_arn = Claims_dept_claude_3_sonnet_profile['inferenceProfileArn']def converse(model_id, messages):"""使用 Converse API 与指定模型进行对话"""响应 = bedrock_runtime.converse(modelId=model_id,消息=消息，推理配置={'maxTokens': 300, # 如果需要指定最大令牌数}）status_code = response.get('ResponseMetadata', {}).get('HTTPStatusCode')print("反向响应：", status_code)parsed_response = parse_converse_response(响应)打印（解析响应）返回响应# 具有应用程序推理配置文件的 Converse API 示例print("\n测试 Converse...")Prompt = "\n\n人类：告诉我有关 Amazon Bedrock 的信息。\n\n助理："messages = [{“角色”：“用户”，“内容”：[{“文本”：提示}]}]响应 = 交谈（claims_dept_claude_3_sonnet_profile_arn，消息）

使用应用程序推理配置文件进行标记、资源管理和成本管理

应用程序推理配置文件中的标记允许组织通过特定的生成式人工智能计划分配成本，确保精确的费用跟踪。应用程序推理配置文件使组织能够在创建时应用成本分配标签，并通过现有的支持附加标签标签资源和取消标记资源API，允许元数据与各种 AWS 资源关联。自定义标签，例如项目ID,成本中心,型号版本， 和环境帮助对资源进行分类，提高成本透明度，并允许团队根据预算监控支出和使用情况。

通过应用程序推理配置文件和成本分配标签可视化成本和使用情况

利用成本分配标签等工具AWS 预算,AWS 成本异常检测,AWS 成本管理器,AWS 成本和使用情况报告（当前），和亚马逊云观察为组织提供支出趋势洞察，帮助及早发现和解决成本高峰，以保持在预算范围内。

借助 AWS Budgets，组织可以设置基于标签的阈值，并在支出接近预算限制时接收警报，从而提供主动方法来保持对 AI 资源成本的控制并快速解决任何意外激增的问题。例如，通过将以下标签应用到应用程序推理配置文件，可以将每月 10,000 美元的预算应用于销售部门支持团队的特定聊天机器人应用程序：部门：销售,团队：支持， 和应用程序：聊天应用程序。AWS 成本异常检测还可以监控标记资源的异常支出模式，从而通过自动识别和标记不规则成本，更轻松地操作成本分配标签。

以下 AWS Budgets 控制台屏幕截图说明了超出的预算阈值：

为了进行更深入的分析，AWS Cost Explorer 和 CUR 使组织能够每天、每周和每月分析标记的资源，支持有关资源分配和成本优化的明智决策。通过基于元数据属性（例如标签键/值和 ARN）可视化成本和使用情况，组织可以获得可操作的、精细的支出视图。

以下 AWS Cost Explorer 控制台屏幕截图展示了按标签键和值筛选的成本和使用情况图表：

以下 AWS Cost Explorer 控制台屏幕截图展示了按 Bedrock 应用程序推理配置文件 ARN 筛选的成本和使用情况图表：

组织也可以使用亚马逊云观察监控 Bedrock 应用程序的运行时指标，提供有关性能和成本管理的更多见解。指标可以通过应用程序推理配置文件绘制成图表，团队可以根据标记资源的阈值设置警报。这些警报触发的通知和自动响应可以实时管理成本和资源使用情况，防止预算超支并保持生成人工智能工作负载的财务稳定性。

以下 Amazon CloudWatch 控制台屏幕截图突出显示了按 Bedrock 应用程序推理配置文件 ARN 筛选的 Bedrock 运行时指标：

以下 Amazon CloudWatch 控制台屏幕截图突出显示了由 Bedrock 应用程序推理配置文件 ARN 过滤的调用限制警报：

通过结合使用标记、预算、异常检测和详细的成本分析，组织可以有效地管理其人工智能投资。通过利用这些 AWS 工具，团队可以清晰地了解支出模式，从而做出更明智的决策并最大化其生成式 AI 计划的价值，同时确保关键应用程序保持在预算范围内。

根据模型调用的标签检索应用程序推理配置文件 ARN

组织在调用 Amazon Bedrock API（包括模型推理调用）时通常使用生成式 AI 网关或大型语言模型代理。随着应用程序推理配置文件的引入，组织需要检索推理配置文件 ARN 以调用按需基础模型的模型推理。有两种主要方法可以获取适当的推理配置文件 ARN。

  • 静态配置方式：此方法涉及在中维护静态配置文件AWS Systems Manager 参数存储或者AWS 秘密管理器将租户/工作负载密钥映射到其相应的应用程序推理配置文件 ARN。虽然这种方法实现起来很简单，但它有很大的局限性。随着推理配置文件的数量从数十个扩展到数百甚至数千，管理和更新此配置文件变得越来越麻烦。此方法的静态性质需要在发生更改时进行手动更新，这可能会导致不一致并增加维护开销，特别是在组织需要根据标签动态检索正确的推理配置文件的大规模部署中。
  • 使用资源组 API 进行动态检索：第二种更强大的方法利用 AWS 资源组获取资源用于根据资源和标签过滤器动态检索应用程序推理配置文件 ARN 的 API。该方法允许使用租户ID、项目ID、部门ID、工作负载ID、模型ID、区域等各种标签键进行灵活查询。这种方法的主要优点是其可扩展性和动态性，能够根据当前标签配置实时检索应用程序推理配置文件 ARN。

然而，有一些注意事项需要牢记。这获取资源API有限制，需要实施缓存机制。组织应根据 API 的输出维护具有生存时间 (TTL) 的缓存，以优化性能并减少 API 调用。此外，实现线程安全至关重要，有助于确保组织在根据 TTL 刷新缓存时始终读取最新的推理配置文件 ARN。

如下图所示，这种动态方法涉及客户端向具有特定资源类型和标签过滤器的资源组服务发出请求。该服务返回相应的应用程序推理配置文件 ARN，然后将其缓存一段时间。然后，客户端可以使用此 ARN 通过以下方式调用 Bedrock 模型：调用模型或者交谈API。

通过采用这种动态检索方法，组织可以创建更灵活和可扩展的系统来管理应用程序推理配置文件，从而更直接地适应不断变化的需求和配置文件数量的增长。

上图中的架构展示了两种基于标签动态检索推理配置文件 ARN 的方法。让我们描述一下这两种方法的优缺点：

  1. Bedrock 客户端使用 TTL 维护缓存：该方法涉及客户端直接查询AWS资源组服务使用获取资源基于资源类型和标签过滤器的API。客户端使用 TTL 将检索到的密钥缓存在客户端维护的缓存中。客户端负责通过调用刷新缓存获取资源API以线程安全的方式。
  2. 基于 Lambda 的方法：此方法使用 AWS Lambda 作为调用客户端和被调用客户端之间的中介。资源组API。该方法采用Lambda 扩展核心使用内存缓存，可能会减少 API 调用的数量资源组。它还与 Parameter Store 交互，可用于配置管理或持久存储缓存数据。

两种方法都使用相似的过滤条件（资源类型过滤器和标签过滤器）来查询资源组API，允许根据租户、模型和区域等属性精确检索推理配置文件 ARN。这些方法之间的选择取决于预期请求量、所需延迟、成本考虑以及额外处理或安全措施的需要等因素。基于 Lambda 的方法提供了更大的灵活性和优化潜力，而直接 API 方法更易于实现和维护。

Amazon Bedrock 资源标记功能概述

Amazon Bedrock 的标记功能已显着发展，为跨多账户的资源管理提供了全面的框架AWS 控制塔设置。这种演变使组织能够跨开发、过渡和生产环境管理资源，帮助组织跟踪、管理和分配其 AI/ML 工作负载的成本。

Amazon Bedrock 资源标记系统的核心涵盖多个操作组件。组织可以有效地标记其批量推理作业、代理、自定义模型作业、知识库、提示和提示流。这种基础级别的标记支持对运营资源的精细控制，从而能够精确跟踪和管理不同的工作负载组件。Amazon Bedrock 的模型管理方面引入了另一层标记功能，包括自定义模型和基础模型，并区分预置模型和按需模型，每个模型都有自己的标记要求和功能。

随着应用程序推理配置文件的引入，组织现在可以管理和跟踪其按需的 Bedrock 基础模型。由于团队可以创建从系统定义的推理配置文件派生的应用程序推理配置文件，因此他们可以在应用程序级别配置更精确的资源跟踪和成本分配。此功能对于在不同环境中运行多个 AI 应用程序的组织特别有价值，因为它可以在粒度级别上提供对资源使用情况和成本的清晰可见性。

下图直观地展示了多账户结构，并演示了如何跨不同 AWS 账户实施这些标记功能。

结论

在这篇文章中，我们介绍了 Amazon Bedrock 的最新功能：应用程序推理配置文件。我们探讨了它的运作方式并讨论了关键考虑因素。此功能的代码示例可在此处找到GitHub 存储库。这项新功能使组织能够标记、分配和跟踪按需模型推理工作负载以及整个运营的支出。组织可以根据其特定的组织分类（例如租户、工作负载、成本中心、业务部门、团队和应用程序）使用标签来标记所有 Amazon Bedrock 模型并监控使用情况。此功能现已在提供 Amazon Bedrock 的所有 AWS 区域全面推出。

关于作者

Kyle T. Blocksom凯尔·T·布洛克索姆是位于南加州的 AWS 高级解决方案架构师。Kyle 热衷于将人们聚集在一起并利用技术提供客户喜爱的解决方案。工作之余，他喜欢冲浪、吃饭、与狗摔跤以及宠爱他的侄女和侄子。

Dhawal Patel达瓦尔·帕特尔是 AWS 的首席机器学习架构师。他曾与从大型企业到中型初创公司的组织合作解决与分布式计算和人工智能相关的问题。他专注于深度学习，包括 NLP 和计算机视觉领域。他帮助客户在 SageMaker 上实现高性能模型推理。

关于《使用 Amazon Bedrock 跟踪、分配和管理您的生成式 AI 成本和使用情况 |亚马逊网络服务》的评论

暂无评论

发表评论



摘要

### 应用程序推理配置文件的动态检索方法概述为了优化从 Amazon Bedrock 检索应用程序推理配置文件 ARN，同时遵守 API 限制，组织可以实施具有生存时间 (TTL) 功能的缓存机制。本节探讨两种方法：在客户端维护缓存和使用 AWS Lambda 作为中介。#### 客户端维护的带有 TTL 的缓存**描述：**- 客户端根据特定资源类型和标签过滤器使用“GetResources” API 直接查询 AWS ResourceGroups 服务。- 检索到的密钥（应用程序推理配置文件 ARN）缓存在客户端维护的本地缓存中，其中包含 TTL 以确保新鲜度。- 通过以线程安全的方式调用“GetResources” API 定期刷新缓存。**优点：**- **简单性：** 直接查询和缓存数据提供了简单的实现，无需额外的基础设施复杂性。- **控制：** 组织可以完全控制缓存的刷新频率，并可以根据其特定需求进行定制。**缺点：**- **可扩展性问题：** 随着请求数量的增加，有效管理缓存新鲜度变得具有挑战性。#### 基于 Lambda 的方法**描述：**- AWS Lambda 充当客户端和 ResourceGroups API 之间的中介。它利用内存缓存来减少 API 调用并优化性能。- 使用 Lambda Extensions 核心来增强功能，例如通过 Parameter Store 或 DynamoDB 进行持久存储。**优点：**- **可扩展性：** 通过使用 Lambda，您可以处理不同的请求量，而无需大量基础设施开销。- **灵活性：** 提供在调用 API 之前添加自定义处理逻辑（例如日志记录、验证）的能力。**缺点：**- **复杂性：** 与直接客户端缓存相比，设置和维护 Lambda 函数会带来额外的操作复杂性。- **成本：** 根据请求量，成本可能会因 AWS Lambda 执行费用而增加。### Amazon Bedrock 中的标记功能Amazon Bedrock 的标记功能允许跨多账户设置对资源进行精细管理。关键组件包括：**核心运营资源：**- 批量推理作业- 代理商- 自定义模型作业- 知识库- 提示和提示流程**模型管理层：**- 支持自定义模型和基本模型，区分预配模型和按需模型。**应用推理配置文件：**- 能够在应用程序级别跟踪按需基岩基础模型。- 促进跨各种环境（开发、分期、生产）的精确成本分配和资源监控。＃＃＃ 结论Amazon Bedrock 中引入应用程序推理配置文件使组织能够更有效地管理 AI/ML 工作负载。此功能允许根据组织分类（例如租户、工作负载、业务部门等）标记、跟踪和分配成本，从而增强资源使用情况的可见性。#### 关键考虑因素：- 使用 TTL 实施缓存机制以优化 API 调用。- 根据可扩展性需求和操作偏好，在客户端缓存管理或基于 Lambda 的中介之间进行选择。- 利用标记功能跨多账户设置进行详细的成本跟踪和合规性。### 关于作者**凯尔·T·布洛克索姆：**AWS 高级解决方案架构师，专门提供以客户为中心的解决方案。喜欢冲浪并与家人和宠物共度时光。**达瓦尔·帕特尔：**AWS 首席机器学习架构师，专注于使用 SageMaker 等工具进行高性能模型推理。在分布式计算和 AI/ML 领域拥有丰富经验。

相关新闻

相关讨论