Agentic Ai 推理规模：优化性能和成本效率的五个关键维度

了解 AI Agent 的定价

1. 简介

围绕 ChatGPT（通常是生成式 AI）的讨论，现在已经演变为 agentic AI。虽然 ChatGPT 主要是一个可以生成文本回复的聊天机器人，但 AI Agent 可以自主执行复杂的任务，例如，进行销售、计划旅行、预订航班、预订承包商来完成房屋工作、订购披萨。下图说明了 agentic AI 系统的演变。

图：Agentic AI 演变（作者供图）

比尔·盖茨最近设想了一个未来，我们将拥有一个 AI Agent，它能够处理和响应自然语言并完成许多不同的任务。盖茨以计划旅行为例。

通常情况下，这将涉及您自己预订酒店、航班、餐厅等。但是，AI Agent 将能够利用其对您偏好的了解，代表您预订和购买这些东西。

虽然 AI Agent 的好处是显而易见的，但它们也伴随着高昂的价格标签 :) 在本文中，我们深入探讨了如何对编排多个 LLM Agent 的 agentic AI 系统进行定价/规模调整。

我们首先考虑影响 LLM 推理规模调整的维度，例如，

• 输入和输出上下文窗口，
• 模型大小，
• 首个 token 延迟、最后一个 token 延迟；
• 吞吐量。

然后，我们将这些维度外推到 agentic AI：

• 将 token 延迟映射到执行第一个 Agent 与完整编排的延迟；
• 将（前一个）Agent 的输出与整体执行状态/上下文理解一起考虑为后续 Agent 的输入上下文窗口大小的一部分；
• 适应 agentic 执行中固有的不确定性。

2. 生成式 AI 和 Agentic AI 架构模式

生成式和 agentic AI 解决方案的范围各不相同，我们预计它们将通过不同的应用程序/平台进入企业领域。例如，这可以通过以下方式实现：

• 直接使用基于 LLM 的应用程序，例如 ChatGPT；
• 嵌入在 SaaS 产品或企业平台中的 LLM，例如 Salesforce、ServiceNow；或
• 使用企业数据进行微调的基础模型，用于战略用例。

因此，作为第一步，我们确定并概述了当今相关的生成式 AI 和 agentic AI 架构模式。

图：生成式 AI 生命周期（作者供图）

2.1 黑盒 LLM API

这是经典的 ChatGPT 场景，我们对 LLM API/UI 具有黑盒访问权限。类似的 LLM API 可用于其他自然语言处理 (NLP) 核心任务，例如，知识检索、摘要、自动更正、翻译、自然语言生成 (NLG)。

提示是这里主要的交互机制，可以包含用户查询和任务。

图：LLM API（作者供图）

提示是指调整用户输入，为 LLM API 提供正确的上下文和指导 — 以最大限度地提高获得“正确”响应的机会。它导致了提示工程作为一门专业学科的兴起，提示工程师系统地进行试验，记录他们的发现，以得出“正确”的提示来得出“最佳”响应。

请参阅我之前关于企业提示存储的文章，详细讨论了提示工程、冲突提示的问题以及将它们整合为提示模板的形式。

2.2 嵌入式 LLM 应用程序

在本节中，我们讨论嵌入在企业平台中的 LLM，例如 Salesforce、SAP、ServiceNow；或者作为即用型企业应用程序在 LLM 提供商的应用商店中提供，例如 Google、Open AI。

企业 LLM 应用程序有可能通过提供企业就绪型解决方案来加速 LLM 的采用。但是，您需要像使用第三方机器学习 (ML) 模型一样谨慎 — 验证 LLM/训练数据所有权、知识产权 (IP)、责任条款。

数据所有权：数据对于受监督的 AI/ML 系统至关重要，特别是对于 LLM 而言，LLM 通常在公共数据集上进行训练，这些数据集的 AI/ML 训练数据使用权尚未明确定义，并且将来可能会发生变化。例如，参考Reddit 的声明，他们表示将开始对从其极其人性化的档案中学习的企业 AI/ML 模型收费。

鉴于此，不仅要协商训练数据的所有权问题，还要协商输入数据、输出数据和其他生成数据的所有权问题，这一点至关重要。另一方面，了解/评估企业应用程序提供商将如何使用由于其与用户的交互而接收/生成的数据也很重要。

图：嵌入在企业应用程序/平台中的 LLM 应用程序（作者供图）

2.3 LLM 微调/特定领域的 SLM

LLM 本质上是通用的。为了充分发挥 LLM 在企业中的潜力，需要使用企业知识（以文档、维基、业务流程等形式捕获）对其进行情境化。在大多数情况下，这种情境化是通过使用企业数据对 LLM 进行微调来实现的 — 创建一个特定领域的小型语言模型 (SLM)。

微调需要获取预先训练的 LLM，并使用（较小的）企业数据对其进行重新训练。

从技术上讲，这意味着更新训练好的神经网络的最后一层（或几层）的权重，以反映企业数据和任务。

鉴于此，需要访问基础模型权重才能执行微调，这对于封闭模型（例如 GPT）是不可能的。这就是开源预训练 LLM 派上用场的地方，例如 Meta AI 的 LLaMA 系列 LLM。斯坦福 Alpaca 项目表明，可以以 600 美元的价格对 LLaMA 进行微调 — 达到与 ChatGPT 相当的模型性能。因此，

微调 LLM 不一定需要很复杂或昂贵。

图：使用企业数据进行 LLM 微调（作者供图）

2.4 Retrieval-Augmented-Generation (RAG)

Fine-tuning 是一个计算密集型过程。

RAG 通过在提示中提供额外的上下文来提供 fine-tuning 的可行替代方案——将检索/响应建立在给定的上下文中。

这可以采用一组文档的形式，这些文档首先使用索引文档或向量搜索进行检索，然后作为上下文提供给提示以限制响应。如今，大多数 LLM 平台都允许提示相对较大，因此可以将此企业上下文嵌入为提示的一部分。

给定一个用户查询，RAG 管道实际上由以下 3 个阶段组成：

图：检索增强生成 — RAG (作者提供)

• Retrieve：将用户查询转换为嵌入（向量格式），以将其相似度分数（搜索）与其他内容进行比较。
• Augment：使用从向量存储中检索到的搜索结果/上下文，该向量存储保持最新状态并与底层文档存储库同步。
• Generate：通过使检索到的块成为提示模板的一部分来生成上下文相关的响应，该模板为 LLM 提供了关于如何回答查询的额外上下文。

2.5 Agentic AI — LLM 编排

这是企业将能够通过编排/组合多个现有 AI 代理来开发新的企业 AI 代理的未来。下图突出了此类参考 AI 代理平台的关键组件：

• 代理市场
• 编排层
• 集成层
• 共享内存层
• 治理层，包括可解释性、隐私、安全性等。

图：AI 代理平台参考架构 (作者提供)

给定一个用户任务，我们提示 LLM 进行任务分解——这与 Gen AI 有重叠。不幸的是，这也意味着今天的 agentic AI 系统受到大型语言模型 (LLM) 的推理能力的限制。例如，GPT4 任务分解的提示

生成一个量身定制的电子邮件活动，以在一个月内实现 100 万美元的销售额，适用的产品及其性能指标可在 [url] 处获得。连接到 CRM 系统 [integration] 以获取客户姓名、电子邮件地址和人口统计详细信息。

在图 3 中有详细说明：(分析产品) — (确定目标受众) — (创建量身定制的电子邮件活动)。

图 3：营销用例的 Agentic AI 执行 (作者提供)

然后，LLM 监视执行/环境并根据需要自主调整。在这种情况下，代理意识到它无法实现其销售目标，并自主添加了任务：(寻找替代产品) — (利用客户数据来个性化电子邮件) — (执行 A/B 测试)。

鉴于需要编排多个代理，因此需要一个集成层来支持不同的代理交互模式，例如，代理到代理 API、代理 API 提供供人类使用的输出、人类触发 AI 代理、带有环路中人类的 AI 代理到代理。底层 AgentOps 平台需要支持集成模式。

同样重要的是要提到，对于大多数用例，都需要与企业系统（例如，本例中的 CRM）集成。例如，请参阅 Anthropic 最近提出的模型上下文协议 (MCP)，用于将 AI 代理连接到企业数据所在外部系统。

鉴于此类复杂任务的长期性质，内存管理是 Agentic AI 系统的关键。一旦启动了最初的电子邮件活动，代理就需要监控该活动 1 个月。

这需要任务之间的上下文共享以及在较长时间内保持执行上下文。

这里的标准方法是将代理信息的嵌入表示保存到向量存储数据库中，该数据库可以支持最大内积搜索 (MIPS)。为了快速检索，使用近似最近邻 (ANN) 算法，该算法返回大约前 k 个最近邻，并以准确性为代价进行权衡，以获得巨大的速度提升。

最后，治理层。我们需要确保用户共享的特定于任务的数据，或跨任务的用户配置文件数据；仅与相关代理共享（隐私、身份验证和访问控制）。请参阅我之前关于负责任的 AI 代理的文章，讨论了用于实现一个管理良好的 AI 代理平台的关键维度，这些维度涉及幻觉护栏、数据质量、隐私、可重复性、可解释性等。

3. LLM 推理规模调整维度

在本节中，我们将深入探讨如何执行推理规模调整，以部署第 2 节中讨论的一些架构模式之后的生成式 AI 用例。

大型语言模型 (LLM) 推理规模调整取决于许多用例维度，主要包括：

• 输入和输出上下文窗口：高层次上，单词被转换为 token，像 Llama 这样的模型运行大约 4k-8k 个 token，或者大约 3000–6000 个英文单词。
• 模型大小：我们是以全精度运行模型，还是运行量化版本？
• 首个 token 延迟、token 间延迟、最后一个 token 延迟；最后，
• 吞吐量：定义为 LLM 在给定时间内可以处理的请求数量。

让我们首先考虑批处理场景。在这里，我们主要知道我们的输入和输出上下文长度；因此重点是优化吞吐量。（由于执行的离线/批处理性质，延迟在这里并不重要。）为了实现高吞吐量：

• 确定您的 LLM 是否适合一个 GPU？
• 如果不是，应用流水线/张量并行来优化所需的 GPU 数量。然后，将批处理大小增加到尽可能大。

对于流式场景，我们需要考虑吞吐量和延迟之间的权衡。为了理解延迟，让我们看一下典型 LLM 请求的处理阶段：预填充和解码（如下图所示）。

图：LLM 处理阶段：预填充和解码（作者提供）

预填充是指按下“enter”键到屏幕上出现第一个输出 token 之间的延迟。解码发生在生成响应中的其他单词时。在大多数请求中，预填充占端到端延迟的 20% 以下，而解码占 80% 以上。

鉴于此，大多数 LLM 实现倾向于在生成 token 后立即将它们输出回客户端——以减少延迟。

总而言之，在流模式下，我们主要关心首次 token 的时间，因为这是客户端等待第一个 token 的时间。之后，以下 token 的生成速度要快得多，并且生成速率通常快于普通人的阅读速度。

请注意，对于RAG 管道，即使是首个 token 延迟也可能非常高。

这是因为 RAG 通常针对整个上下文窗口，以将检索到的（相关）文档的块添加到输入上下文/提示中。在顺序模型中，我们必须等待最终结果；因此，我们关心端到端延迟。这是生成（响应）输出序列中所有 token 的时间。

最后，关于延迟和吞吐量之间的权衡——增加批处理大小（同时通过 LLM 运行多个请求）往往会使延迟变差，但吞吐量更好。当然，升级底层硬件/GPU 可以同时提高吞吐量和延迟。请参阅 Nvidia 关于LLM 推理规模调整的教程，以详细讨论此主题。

4. Agentic AI 推理规模调整注意事项

在第 3 节中，我们详细讨论了影响单个 LLM 用例的规模调整/定价维度。在本节中，我们将相同的概念扩展到 agentic AI——它可以被认为是多个 LLM 用例/agent 的编排。

Andrew Ng 最近谈到了这方面：

如今，许多 LLM 输出都供人类使用。但在一个 agentic 工作流程中，LLM 可能会被反复提示以反映和改进其输出、使用工具、计划和执行多个步骤，或实现协作的多个 agent。因此，在向用户显示任何输出之前，我们可能会生成数十万个或更多的 token。这使得快速 token 生成变得非常理想，并使较慢的生成成为充分利用现有模型的瓶颈。

下面我们重点介绍了将 LLM 扩展到 agentic AI 推理规模调整的关键步骤：

图：Agentic AI 推理规模调整/定价维度（作者提供）

4.1 Agent 可观察性

Token 延迟映射到agent 处理延迟。首个 token 与端到端 token 延迟的讨论映射到在这种情况下完整编排/分解计划的首个 agent 与端到端执行延迟。

因此，我们需要平衡在 agent 执行完成时立即流式传输 agent 执行输出的需求，以及在完整编排执行终止后输出结果的需求。

有关详细讨论，请参阅我之前关于 AI agent 的有状态表示的文章文章，该文章支持 agentic 编排的实时和批处理可观察性。

4.2 Agentic 上下文窗口大小

一个 agent 的输出成为下一个 agent 在多 agent 编排中执行的输入。因此，很可能（至少一部分）前一个 agent 的输出以及整体执行状态/上下文理解（存储在内存管理层中）将成为传递给下一个 agent 的输入上下文的一部分——这需要作为 agentic 上下文窗口大小要求的一部分来考虑。

4.3 Agentic AI 执行中的非确定性

最后，我们需要考虑 agentic AI 系统中固有的非确定性。例如，让我们考虑一下下图所示的电子商务场景。

图：具有非确定性的电子商务场景（作者提供）

执行计划中有两个非确定性运算符：“检查信用”和“交付模式”。“交付模式”的选择表明用户可以直接从商店取货或将其运送到他的地址。鉴于此，运输是一项非确定性任务，并且可能不会在实际执行期间被调用。

总而言之，考虑到编排中存在“选择”运算符，我们不知道作为特定执行的一部分将执行的确切任务/agent。

这里可以应用不同的策略，包括完全扁平化执行计划，以确定可以作为最佳情况和最坏情况（峰值）场景的一部分执行的任务/agent。

请参阅我们的 ICAART 2024 论文（约束启用的自主 agent 市场：发现和匹配），详细讨论了适用于 agentic AI 执行中非确定性的策略。

5. 结论

虽然自主 AI 系统的优势显而易见，但它们也是复杂的系统，从推理定价的角度来看，很难对其进行“规模化”。

为此，我们在本文中概述了如何对生成式和自主 AI 系统执行推理规模调整。我们首先确定了当今流行的关键架构模式。然后，我们重点介绍了影响已识别架构模式的推理规模调整的相关维度，例如 LLM API、RAG 等。然后，我们提供了一个映射，以将已识别的维度（来自单个 LLM 用例）外推到 LLM 代理的编排中——就像在自主 AI 的情况下一样。

我们认为，有效地对生成式/自主 AI 系统进行定价是将其投入生产的关键，这项工作将对推动其企业采用做出重大贡献。