优化 AWS 上生成式 AI 应用程序的成本 |亚马逊网络服务

报告生成式人工智能的经济潜力：下一个生产力前沿，由麦肯锡公司出版，估计生成式人工智能可为全球经济增加相当于 2.6 万亿至 4.4 万亿美元的价值。最大的价值将来自四个领域：客户运营、营销和销售、软件工程和研发。

如此巨大的商业价值潜力正在激励数以万计的企业在 AWS 中构建其生成式 AI 应用程序。然而，许多产品经理和企业架构师领导者希望更好地了解成本、成本优化杠杆和敏感性分析。

本文讨论了这些成本注意事项，以便您可以优化 AWS 中的生成式 AI 成本。

本文假设您基本熟悉 AWS 中的基础模型 (FM) 和大型语言模型 (LLM)、令牌、向量嵌入和向量数据库。由于检索增强生成 (RAG) 是生成式 AI 解决方案中最常用的框架之一，本文解释了 RAG 解决方案背景下的成本以及相应的优化支柱亚马逊基岩。

在本系列的第 2 部分中，我们将介绍如何估算业务价值及其影响因素。

成本和性能优化支柱

设计高性能且经济高效的生成式人工智能应用程序对于充分发挥这种变革性技术的潜力并推动组织内的广泛采用至关重要。

预测和管理生成人工智能应用程序的成本和性能由以下优化支柱驱动：

• 模型选择、选择和定制 – 我们将其定义如下：
  • 模型选择 – 此过程涉及确定满足各种用例的最佳模型，然后进行模型验证，在模型验证中您可以对高质量数据集进行基准测试，并提示识别成功的模型竞争者。
  • 型号选择 – 这是指选择合适的型号，因为不同的型号具有不同的定价和性能属性。
  • 模型定制 – 这是指选择适当的技术来使用训练数据定制 FM，以根据特定于业务的用例优化性能和成本效益。
• 令牌使用情况 – 分析令牌使用情况包括以下内容：
  • 令牌数量 – 使用生成式 AI 模型的成本取决于处理的令牌数量。这会直接影响运营成本。
  • 令牌限制 – 了解令牌限制以及推动令牌计数的因素，并采取适当措施来限制令牌计数可以帮助您优化令牌成本和性能。
  • 令牌缓存 – 在应用程序层或 LLM 层缓存常见的用户问题可以帮助减少令牌数量并提高性能。
• 推断定价计划和使用模式 – 我们考虑两种定价选项：
  • 按需 – 适用于大多数模型，根据输入/输出令牌数量收费，不保证令牌吞吐量。
  • 预配置吞吐量 — 非常适合需要保证吞吐量但成本相对较高的工作负载。
• 其他因素 – 其他因素可能包括：
  • 安全护栏 – 对个人身份信息 (PII)、有害内容、不良主题应用内容过滤器，并检测幻觉，从而提高生成式 AI 应用程序的安全性。这些过滤器可以独立于法学硕士来执行和扩展，并且其成本与过滤器和所检查的令牌的数量成正比。
  • 矢量数据库 – 矢量数据库是大多数生成式人工智能应用程序的关键组成部分。随着生成人工智能应用程序中数据使用量的增加，矢量数据库成本也会增加。
  • 分块策略 – 分块策略（例如固定大小分块、分层分块或语义分块）可能会影响生成式 AI 应用程序的准确性和成本。

让我们更深入地研究这些因素和相关的成本优化技巧。

检索增强生成

RAG 可以帮助法学硕士回答针对您的公司数据的问题，即使法学硕士从未接受过有关您的数据的培训。

如下图所示，生成式 AI 应用程序读取公司可信数据源，对其进行分块，生成向量嵌入，并将嵌入存储在向量数据库中。向量数据库中存储的向量和数据通常称为知识库。

生成式 AI 应用程序使用向量嵌入来搜索和检索与用户问题最相关的数据块，并增强问题以生成 LLM 响应。下图说明了此工作流程。

工作流程包括以下步骤：

1. 用户使用生成式人工智能应用程序提出问题。
2. 生成嵌入的请求被发送到 LLM。
3. LLM 将嵌入返回给应用程序。
4. 这些嵌入是根据向量数据库（知识库）中存储的向量嵌入进行搜索的。
5. 应用程序从知识库接收与用户问题相关的上下文。
6. 应用程序将用户问题和上下文发送给法学硕士。
7. 法学硕士利用上下文生成准确且有根据的响应。
8. 应用程序将最终响应发送回用户。

Amazon Bedrock 是一项完全托管的服务，可通过统一的 API 访问领先 AI 提供商的高性能 FM。它提供广泛的法学硕士课程可供选择。

在前面的工作流程中，生成式 AI 应用程序调用 Amazon Bedrock API 将文本发送到 LLM（例如 Amazon Titan Embeddings V2）以生成文本嵌入，并向 LLM（例如 Anthropic 的 Claude Haiku 或 Meta Llama）发送提示以生成响应。

生成的文本嵌入存储在向量数据库中，例如亚马逊开放搜索服务,亚马逊关系数据库服务（亚马逊 RDS），亚马逊极光， 或者亚马逊内存数据库。

虚拟助理或支持聊天机器人等生成式人工智能应用程序可能需要与用户进行对话。多轮对话要求应用程序存储每个用户的问答历史记录并将其发送到法学硕士以获取其他上下文。该问答历史可以存储在数据库中，例如亚马逊动态数据库。

生成式人工智能应用程序还可以使用亚马逊基岩护栏检测偏离主题的问题、对知识库的地面响应、检测和编辑 PII 信息，以及检测和阻止与仇恨或暴力相关的问题和答案。

现在我们已经很好地了解了基于 RAG 的生成式 AI 应用程序中的各个组件，接下来让我们探讨一下这些因素如何影响使用 RAG 在 AWS 中运行应用程序时的成本。

小型、中型、大型、特大型场景的定向成本

考虑一个组织希望通过虚拟助理来帮助客户，虚拟助理可以随时以高度的准确性、性能、一致性和安全性回答他们的问题。生成式人工智能应用程序的性能和成本直接取决于环境中的几个主要因素，例如每分钟的出题速度、每天的出题量（考虑高峰和非高峰）、知识库数据量，以及所使用的法学硕士。

尽管这篇文章解释了影响成本的因素，但基于某些假设了解定向成本可能很有用，可以相对了解小型、中型、大型和超大型环境等几种场景的各种成本组成部分。

下表是四种不同场景的定向成本快照，其中每月的用户问题量和知识库数据各不相同。。

Anthropic 的 Claude 3 Haiku LLM

AWS 区域 us-east-1

• 每个用户问题的标记假设：
• LLM 的总输入代币 = 2,571
• LLM 的输出代币 = 149
• 每个标记平均四个字符
  • 代币总数 = 2,720
  • 还有其他成本组件，例如 DynamoDB 来存储问答历史记录，
  • 亚马逊简单存储服务
  • （Amazon S3）存储数据，以及
• AWS Lambda或者亚马逊弹性容器服务(Amazon ECS) 以调用 Amazon Bedrock API。然而，这些成本并不像表中提到的成本构成那么重要。我们将在本文的其余部分中引用该表。在接下来的几节中，我们将介绍 Amazon Bedrock 成本以及影响其成本的关键因素、矢量嵌入成本、矢量数据库成本和 Amazon Bedrock Guardrails 成本。在最后一节中，我们将介绍分块策略将如何影响上述一些成本组成部分。

亚马逊基岩成本

Amazon Bedrock 有两种定价模型：按需（在前面的示例场景中使用）和预置吞吐量。

在按需模型中，LLM 具有每分钟最大请求数（问题）(RPM) 和每分钟令牌数 (TPM) 限制。

每个法学硕士的 RPM 和 TPM 通常是不同的。有关更多信息，请参阅Amazon Bedrock 配额。

在超大型用例中，每月有 700 万个问题，假设每天 10 小时，每月 22 个工作日，则相当于每分钟 532 个问题 (532 RPM)。这远低于 Anthropic 的 Claude 3 Haiku 的 1,000 RPM 的最大限制。

每个问题平均有 2,720 个令牌，每分钟有 532 个请求，TPM 为 2,720 x 532 = 1,447,040，远低于 Anthropic 的 Claude 3 Haiku 的最大限制 2,000,000 TPM。

但是，假设用户问题增长了 50%。RPM、TPM 或两者都可能超过阈值。在生成式 AI 应用程序需要跨越按需 RPM 和 TPM 阈值的情况下，您应该考虑 Amazon Bedrock 预置吞吐量模型。

对于 Amazon Bedrock 预置吞吐量，成本基于每个模型单位。模型单位专用于您计划使用的期限，例如每小时、1 个月、6 个月的承诺。

每个模型单元提供一定的每分钟最大代币容量。因此，模型单元的数量（和成本）由输入和输出TPM决定。

使用 Amazon Bedrock 预置吞吐量，无论您是否使用，您都会按模型单位付费。因此，预配置吞吐量模型比按需模型相对昂贵。

请考虑以下成本优化技巧：

• 从按需模型开始，并根据您选择的 LLM 测试您的性能和延迟。这将带来最低的成本。
• 如果按需无法满足所需的 RPM 或 TPM 量，请在生成 AI 应用程序测试期间从预配置吞吐量开始，并订阅 1 个月。但是，对于稳态生产，请考虑订阅 6 个月以降低预置吞吐量成本。
• 如果高峰时段较短，非高峰时段较长，请考虑在高峰时段使用按小时预置吞吐量模型，在非高峰时段使用按需模型。这可以最大限度地降低您的预置吞吐量成本。

影响成本的因素

在本节中，我们讨论可能影响成本的各种因素。

问题数量

随着按需模型问题数量的增加，成本也随之增加，如下图所示，年度成本（基于前面讨论的表格）。

输入令牌

LLM 输入标记的主要来源是系统提示、用户提示、向量数据库（知识库）中的上下文以及 QnA 历史记录中的上下文，如下图所示。

随着每个组件的大小增加，LLM 的输入令牌数量也会增加，成本也会增加。

一般来说，用户提示比较少。例如，在用户提示“Amazon DynamoDB 的性能和成本优化策略是什么？”中，假设每个令牌有四个字符，则大约有 20 个令牌。

系统提示可能很大（因此成本更高），特别是对于多次提示，其中提供多个示例以获得具有更好语气和风格的LLM响应。如果系统提示中的每个示例使用 100 个令牌，并且有 3 个示例，则为 300 个令牌，这比实际的用户提示要大得多。

来自知识库的上下文往往是最大的。例如，当文档被分块并为每个块生成文本嵌入时，假设块大小为 2,000 个字符。假设生成式人工智能应用程序将与用户提示相关的三个块发送给法学硕士。这是 6,000 个字符。假设每个标记有 4 个字符，则这相当于 1,500 个标记。与典型的用户提示或系统提示相比，这要高得多。

QnA 历史的背景也可能很高。假设用户提示中平均有 20 个标记，LLM 响应中平均有 100 个标记。假设生成式 AI 应用程序随每个问题发送三个问答对的历史记录。这意味着（每个问题 20 个标记 + 每个响应 100 个标记）x 3 个问答对 = 360 个标记。

请考虑以下成本优化技巧：

• 限制每个用户提示的字符数
• 在最终确定其值之前，使用向量数据库中的不同数量的块和块大小测试响应的准确性
• 对于需要与用户进行对话的生成式 AI 应用程序，请使用两对、三对、四对或五对 QnA 历史记录进行测试，然后选择最佳值

输出代币

LLM 的响应将取决于用户提示。一般来说，输出代币的定价比输入代币的定价高三到五倍。

请考虑以下成本优化技巧：

• 由于输出令牌很昂贵，请考虑在系统提示中指定最大响应大小
• 如果某些用户所属的组或部门对用户提示或 LLM 响应要求更高的令牌限制，请考虑使用多个系统提示，以便生成式 AI 应用程序根据用户选择正确的系统提示

向量嵌入成本

如前所述，在 RAG 应用程序中，数据被分块，文本嵌入被生成并存储在矢量数据库（知识库）中。文本嵌入是通过使用 LLM 调用 Amazon Bedrock API 生成的，例如 Amazon Titan Text Embeddings V2。这与您选择用于推理的 Amazon Bedrock 模型无关，例如 Anthropic 的 Claude Haiku 或其他法学硕士。

生成文本嵌入的定价基于输入令牌的数量。数据越大，输入的代币就越大，因此成本就越高。

例如，对于 25 GB 的数据，假设每个令牌有 4 个字符，则输入令牌总数为 67.11 亿个。由于 Amazon Titan Text Embeddings V2 的 Amazon Bedrock 按需成本为每百万代币 0.02 美元，因此生成嵌入的成本为 134.22 美元。

然而，点播有一个转速限制为 2,000适用于 Amazon Titan 文本嵌入 V2。在 2,000 RPM 的情况下，嵌入 25 GB 数据需要 112 小时。由于这是嵌入数据的一次性工作，因此在大多数情况下这可能是可以接受的。

对于每月变化率和 5% 的新数据（每月 1.25 GB），所需时间将为 6 小时。

在实际文本数据的 TB 级非常高的极少数情况下，将需要预配置吞吐量来生成文本嵌入。例如，要在 3、6 和 9 天内生成 500 GB 的文本嵌入，使用预置吞吐量的一次性成本约为 60,000 美元、33,000 美元或 24,000 美元。

通常，文件内的实际文本比 Amazon S3 或文件系统报告的文件大小小 5 到 10 倍。因此，当您看到所有需要矢量化的文件大小为 100 GB 时，文件内的实际文本很可能为 2–20 GB。

估计文件内文本大小的一种方法是执行以下步骤：

1. 选择 5–10 个文件的示例表示。
2. 打开文件，复制内容，然后将其输入到 Word 文档中。
3. 使用字数统计功能来确定文本大小。
4. 计算该大小与文件系统报告的大小的比率。
5. 将此比率应用于整个文件系统，以获得所有文件内实际文本大小的定向估计。

矢量数据库成本

AWS 提供许多矢量数据库，例如 OpenSearch Service、Aurora、Amazon RDS 和 MemoryDB。正如本文前面所解释的，向量数据库在对企业数据（其向量嵌入存储在向量数据库中）的基础响应中发挥着关键作用。

以下是影响矢量数据库成本的一些因素。为了简洁起见，我们将 OpenSearch 服务配置的集群视为向量数据库。

• 用作知识库的数据量 — 成本与数据大小成正比。更多数据意味着更多向量。更多的向量意味着向量数据库中的索引更多，这反过来又需要更多的内存，因此成本更高。为了获得最佳性能，建议调整矢量数据库的大小，以便所有矢量都存储在内存中。
• 索引压缩 – 向量嵌入可以通过 HNSW 或 IVF 算法进行索引。索引也可以被压缩。尽管压缩索引可以减少内存需求和成本，但可能会损失准确性。因此，在决定使用 HNSW 或 IVF 的压缩变体之前，请考虑进行广泛的准确性测试。例如，对于 100 GB 的大型文本数据，假设块大小为 2,000 字节、重叠率为 15%、向量维度计数为 512、3 年无需预付预留实例以及 HNSW 算法，则每年的成本约为 37,000 美元。使用 hnsw-fp16 和 hnsw-pq 进行压缩的相应成本分别为每年 21,000 美元和 10,000 美元。
• 预留实例 – 成本与您预留存储矢量数据库的集群实例的年数成反比。例如，在前面的场景中，按需实例的费用约为每年 75,000 美元，无需预付 1 年的预留实例每年费用为 52,000 美元，无需预付 3 年的预留实例每年费用为 37,000 美元。

其他因素（例如作为上下文传递给 LLM 的矢量数据库的检索次数）可能会影响输入标记，从而影响成本。但总的来说，上述因素是最重要的成本驱动因素。

亚马逊基岩护栏

假设您的生成式 AI 虚拟助理应该在您的网站上为客户回答与您的产品相关的问题。如何避免用户提出偏离主题的问题，例如科学、宗教、地理、政治或谜题？您如何避免回答用户有关仇恨、暴力或种族的问题？如何检测和编辑问题和回复中的 PII？

亚马逊基岩应用Guardrail API可以帮助您解决这些问题。Guardrails 提供多种策略，例如内容过滤器、拒绝的主题、上下文接地检查和敏感信息过滤器 (PII)。您可以有选择地将这些过滤器应用于数据的全部或特定部分，例如用户提示、系统提示、知识库上下文和 LLM 响应。

对所有数据应用所有过滤器会增加成本。因此，您应该仔细评估要对数据的哪一部分应用哪个过滤器。例如，如果您希望从 LLM 回复中检测或编辑 PII，对于每月 200 万个问题，大约成本（基于本文前面提到的输出令牌）将为每月 200 美元。此外，如果您的安全团队还想检测或编辑用户问题的 PII，则 Amazon Bedrock Guardrails 的总成本将为每月 400 美元。

分块策略

正如前面 RAG 如何工作所解释的，您的数据被分块，为这些块生成嵌入，并且块和嵌入存储在向量数据库中。这些数据块稍后会被检索，并作为上下文与用户问题一起传递给法学硕士，以生成有根据的相关响应。

以下是不同的分块策略，每种策略都会影响成本：

• 标准分块 – 在这种情况下，您可以指定默认分块（大约 300 个令牌）或固定大小分块（其中您为每个块指定令牌大小（例如 300 个令牌））。较大的块将增加输入代币，从而增加成本。
• 分层分块 – 当您想要以较小的大小（例如，300 个令牌）对数据进行分块，但将较大的数据块（例如，1,500 个令牌）发送到 LLM 以便 LLM 具有更大的工作上下文时，此策略非常有用与同时生成响应。虽然这在某些情况下可以提高准确性，但由于发送到法学硕士的数据块较多，这也会增加成本。
• 语义分块 – 当您想要基于语义而不仅仅是标记进行分块时，此策略非常有用。在这种情况下，将为一个或三个句子生成向量嵌入。使用滑动窗口来考虑下一个句子，并再次计算嵌入来识别下一个句子在语义上是否相似。该过程将持续进行，直到您达到标记的上限（例如，300 个标记）或者您发现一个句子在语义上不相似。该边界定义了一个块。LLM 的输入标记成本将类似于标准分块（基于最大标记大小），但由于块具有语义相似的句子，因此准确性可能会更好。然而，这会增加生成向量嵌入的成本，因为嵌入是为每个句子生成的，然后是为每个块生成的。但与此同时，这些都是一次性成本（对于新的或更改的数据），如果您的数据的准确性相对较好，那么这可能是值得的。
• 高级解析 – 这是分块策略的可选预处理步骤。这用于识别块边界，当您的文档包含大量复杂数据（例如表格、图像和文本）时，这尤其有用。因此，成本将是您想要用于向量嵌入的整个数据的输入和输出令牌成本。这些成本将会很高。考虑仅对那些具有大量表格和图像的文件使用高级解析。

下表是各种分块策略的相对成本比较。

结论

在这篇文章中，我们讨论了可能影响生成式人工智能应用程序成本的各种因素。这是一个快速发展的领域，我们提到的组件的成本将来可能会发生变化。将本文中的成本视为基于假设且方向准确的时间快照。如果您有任何疑问，请联系您的 AWS 客户团队。

在第 2 部分中，我们讨论如何计算业务价值以及影响业务价值的因素。

关于作者

维尼·塞尼是位于加拿大多伦多的 Amazon Web Services (AWS) 的高级生成式 AI 专家解决方案架构师。她拥有机器学习背景，在为各行业客户设计和构建基于云的转型解决方案方面拥有超过 15 年的经验。她的重点主要是扩展基于 AI/ML 的解决方案，以实现无与伦比的业务影响，并根据业务需求进行定制。

钱德拉·雷迪是位于德克萨斯州奥斯汀的 Amazon Web Services (AWS) 解决方案架构师团队的高级经理。他和他的团队帮助北美的企业客户处理 AWS 中的 AIML 和生成式 AI 用例。他在软件工程、产品管理、产品营销、业务开发和解决方案架构方面拥有 20 多年的经验。