Microsoft Azure Blog

The Economics of Agent Optimization: Four ways to lower the cost

8.5内容质量
The Economics of Agent Optimization: Four ways to lower the cost

TL;DR · AI 摘要

通过优化每个请求、工作流和持续治理开支,可有效降低AI代理成本。

核心要点

  • AI工作负载复杂度差异导致80%请求无需前沿模型能力
  • 错误决策使单次结果成本增加300%以上
  • Microsoft Foundry提供4个运行时成本控制杠杆

结构提纲

按章节快速跳转。

  1. 介绍代理优化成本控制的核心挑战和关键决策点

  2. 原型设计到生产环境的架构演进导致成本失控

  3. 单一模型处理多类型任务导致80%请求过度付费

  4. 错误路径使单次结果成本增加300%以上

  5. Microsoft Foundry提供运行时成本优化的四个关键控制点

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • 代理优化成本降低
    • 核心挑战
      • 工作负载复杂度差异
      • 错误路径放大成本
    • 解决方案
      • 四维控制杠杆
      • 持续治理机制

金句 / Highlights

值得收藏与分享的关键句。

#AI优化#成本管理#Microsoft Foundry#代理系统
打开原文

_本文是系列文章Agent优化的经济学的第二部分,该系列分享了帮助您优化Agent成本并在Microsoft Foundry上将AI作为托管投资系统运行的策略、能力和实证数据。第一部分阐述了系统所依赖的三个决策:在运行时优化每个请求、随时间优化每个工作流、持续治理支出。本文将聚焦第一个决策,这个决策将影响您在AI上支出的每一分钱。_

  • * *

Agent是围绕模型的循环系统。它进行规划、调用工具、读取结果并再次推理,因此单个完成的成果可能需要数十次模型请求。这就是为什么业务真正关注的是成功成果的成本,而非单个令牌的价格。

这个循环中的每个环节仍然对应一次模型请求,每次请求都包含关于模型、运行模型的配置、重用内容以及向模型传递信息的决策。当这些决策正确时,节省的成本会在每个环节重复产生。这正是Agent优化的起点。

生产AI中最昂贵的习惯

大多数AI应用的构建方式相同。在原型阶段,您会选择最强的可用模型,将模型可能需要的所有内容放入提示中,并验证想法是否可行。这种做法对原型是正确的,但问题在于后续会发生什么。原型的默认设置会悄无声息地成为生产架构,原本用于回答"这能行吗?"的设计模式,现在却要负责回答"这能否经济地扩展?"。

这时会出现两个问题。首先,AI工作负载并不统一。单个应用会混合意图分类、提取、格式化、摘要和真正的多步骤推理——AI工作负载在复杂性上差异巨大。将所有请求都路由到前沿模型意味着在绝大多数不需要该能力的请求上支付过高费用。

其次,一个成果对应多个请求。原型只需支付单次调用费用,而Agent需要支付整个循环的费用,因此任何浪费都会被放大。这在令牌层面是如此,在错误层面更是如此。一个走错路的Agent会调用错误工具并循环恢复,浪费本不该发生的环节令牌,最终仍得到较弱的答案。每个成果的成本,很大程度上取决于您避免了多少不必要的环节,而不仅仅是每个环节中的令牌数量。

在生产环境中,目标不是最小化令牌数量。而是在保持质量、安全性和延迟的前提下,降低成功成果的成本。每个运行时决策都必须平衡这些因素,因此请求的经济学最终归结为四个决策。

运行时您可以控制的四个杠杆

Microsoft Foundry为您提供四个杠杆,使您能够有意识地做出权衡,而非被动接受原型偶然选择的方案。每个杠杆都可以独立采用,根据您的质量标准进行衡量,如果权衡不成立也可以撤销。

_Lever__Foundry capability_ 模型与功能模型路由器、部署类型、预置吞吐量、批量处理、微调。 缓存提示缓存、通过 Azure API Management 中的 AI 网关实现的语义缓存。 提示与代理优化提示优化器、代理优化器(覆盖指令、技能、工具描述和模型选择)。 可观测性与评估Foundry 可观测性与评估、代理追踪、Azure 预算、警报和成本标签。

1. 将每个请求发送到合适的模型

基本原则很简单:根据任务复杂度优化结果。常规请求不应承担前沿模型的经济成本,而复杂请求不应仅为了节省令牌而牺牲质量。

Foundry 模型中的模型路由器消除了这种权衡。它会评估每个传入请求,并实时将其路由到最合适的底层模型,通过单一端点和单一部署实现。路由模式允许您优先考虑成本、质量或两者的平衡。现在与 Azure Policy 对齐的模型子集,可将路由限制在合规边界适用的批准白名单内。内置的故障转移机制可在某个模型不可用时将请求转移到下一个最佳模型,因此路由还带来了弹性优势。

同一请求的经济性会因部署方式不同而显著变化,这也是团队最常忽略的杠杆点。组织必须决定:

  • 数据处理位置(全球、数据区域或区域)。
  • 吞吐量购买方式(按令牌付费、预置容量)。
  • 哪些工作负载真正需要交互式响应。

Foundry 提供了多种 部署选项,使这些选择能够与业务需求保持一致。大多数工作负载可以从标准部署开始,它们提供最大的灵活性和按需付费的高效成本结构。需要更快、更一致响应时间的交互式应用可通过优先处理获益,而需求可预测的高吞吐量工作负载可通过预置吞吐量单位(PTUs)实现更优经济性,溢出流量则通过按需付费容量处理。大型异步工作负载(如文档处理、分类和评估运行)通常最适合批量部署,其成本可降低高达 50%,适用于不需要即时响应的任务。

即使在单个应用中,不同体验通常也适合不同的部署策略。能够容忍一定延迟波动的开发者工具可能在标准部署上运行效率更高。交互式聊天体验可能需要优先处理,而需要持续吞吐量的代理应用则可通过 PTUs 最大化价值。背景任务(如文档分析、知识提取和大规模分类)可切换到批量部署,而不会影响用户体验,仅通过选择与工作负载匹配的部署模型即可降低成本。

微调是该功能的高级版本。路由功能在现有模型之间进行选择,而微调则改变较小模型的能力,通过充分训练使其能够胜任特定任务、语气或格式,达到与大型模型相当的水平。其优势在于降低费用并缩短提示内容。当行为稳定且使用量足够高以抵消投入时,应选择此方法。

2. 停止为相同 token 支付两次费用

代理系统具有高度缓存效率。相同的系统指令、工具模式和策略文本会在每次交互中重复发送,因此一个需要 10 次交互的代理需要支付 10 次前缀费用。提示缓存允许复用之前处理过的前缀,而无需重新处理。在标准部署中,缓存读取的费用会低于正常输入价格,而在预置部署中,折扣幅度可高达 100%。缓存的使用可同时提升性能并降低成本。

要充分利用缓存功能,主要取决于提示架构的设计,其规则非常明确:先放置稳定内容,后放置易变内容。将系统指令、工具定义和少量示例置于顶部,将用户输入、检索内容和交互历史置于底部。由于缓存依赖于提示开头的精确匹配,因此每次请求中发生变化的内容(如时间戳或用户名称)必须位于该块下方。如果将其放在顶部,缓存将永远无法匹配。

缓存功能也适用于提示内容上方。当在 Foundry 推理 API 前部署网关时,选择语义缓存感知的网关非常重要,例如 Azure API Management 中的 AI 网关。它可以保持与相同端点的会话亲和性,帮助在跨会话和用户匹配近似重复请求时最大化缓存效率。确定性的工具结果可以存储在您自己的存储中,并根据数据变化频率调整生存时间。

3. 优化提示内容,再优化代理系统

如果模型选择决定了费用率,那么指令内容决定了使用量。它也是最易于修复的部分,因为无需改动基础设施即可实现。减少 token 的实践方法与提升回答质量的方法相同:优先说明任务本身,而不是将其隐藏在大量背景信息之后;明确说明所需输出内容及其长度;用几个精心挑选的示例代替冗长的解释。然后控制交互过程中累积的内容:

  • 汇总已完成的对话,而不是重复播放完整对话记录。
  • 仅将与任务相关的工具定义纳入范围。
  • 将工作状态存储在外部内存中,并仅在需要时检索。

现在,Foundry 已自动化了过去需要手动调整的流程。提示优化器使用 提示工程最佳实践重写代理系统的指令,并展示每次修改的推理过程,因此您可以引导其优化方向,再次运行并单击应用结果。

Foundry Agent Service 中的代理优化器更进一步,形成完整闭环。它将代理部署到真实任务数据集上运行,生成候选配置方案,对每个方案进行评分并排序,使您能够选择最优方案进行推广。它可调整指令、技能、工具描述和模型选择,而数据集可来自您自身的代理追踪记录。

4. 通过可观测性与评估实现可视化

看不见的东西无法调优,未测量的节省也无法声称。Foundry 的可观测性提供每请求级别的信号,使其他三个优化手段的实施变得安全可靠:输入输出令牌数、缓存命中率、延迟、实际处理请求的模型,以及验证质量是否保持的评估分数。

此处有两个关键指标。每请求成本告诉您更便宜的路径是否仍达到标准。每完成结果成本则反映业务实际支付的总费用,涵盖所有尝试和重试过程。如果优化降低了第一个指标但增加了尝试次数,实际效果可能更差,只有第二个指标能揭示这一问题。

评估将这种可见性转化为更改的权限。将成本、延迟和任务成功率共同衡量,并维护一个所有优化方案上线前必须通过的基准评估集。这些追踪记录和评估集同时也是代理优化器的输入数据,因此这项工作具有双重价值。结合 Azure 的预算、告警和成本标签,回归问题将以通知形式出现,而非月末的意外发现。

这如何构成爬坡过程

这些手段都不是一次性节省。它们共同形成一个循环,每次迭代都会变得更便宜、更高效,这正是微软 AI 所指的构建爬坡机器:通过更优质的数据和更精准的评估,持续改进,循环往复。

  • 模型与服务选择决定每个请求的执行位置,微调可将已验证的任务永久转化为更低成本的方案。
  • 缓存降低每次循环的成本,这正是让您能频繁运行循环以产生实质影响的关键。
  • 提示词与代理优化生成下一个候选方案,并通过您的评估集验证其有效性。
  • 可观测性与评估告诉您当前所处位置,以及上一次更改是否真正生效。

爬坡是一个没有固定起点的循环,大多数团队从测量环节进入这个过程。追踪记录转化为评估数据集,这些数据集驱动优化器运行。优化器结果会显示哪些任务足够稳定可以进行微调。微调后的模型改变路由选择策略,新的路由又产生新的追踪记录。

入门指南

您是否漏看了**The Economics of Agent Optimization系列文章**