How to reduce LLM costs without sacrificing quality

如何在不牺牲质量的前提下降低LLM成本 - Arize AI

关键要点

• 为追踪添加成本信息，以便将支出与产生该支出的请求、模型调用、工具或代理步骤关联起来。

• 在决定削减哪些内容之前，先比较相同流量的成本和质量。

• 在进行大规模调整前，先调查模型选择、上下文增长、重试次数、工具输出和评估器使用情况。

• 每次优化都要针对固定数据集和相同质量标准进行验证。

您的LLM账单上涨了。账单会告诉您上涨了多少，但不会说明是哪种行为导致了增加，或者额外支出是否改善了结果。

成本激增可能源于更难处理的请求类型、重试循环、臃肿的工具响应，或使用了更昂贵但效果无法量化的模型。其中部分支出是浪费，部分支出则在完成有价值的工作。

更便宜的模型并不一定意味着更便宜的系统，我们在廉价模型改变多代理经济模式时也观察到了这一现象。当任务需要更多上下文、重试、代理轮次或人工返工时，总成本可能超过更强大模型的成本。真正重要的指标不是每token成本，而是每个验证结果的成本。

在降低这部分成本的同时保护对应用有提升作用的支出，需要在一个工作流中结合成本数据、追踪信息和评估结果。它们共同帮助您发现昂贵的模式，测试单次变更，并确认节省的成本不会以牺牲质量为代价。

为什么LLM成本优化应从追踪开始

编码代理和生产应用可能出现在同一张AI账单上，但它们产生支出的方式不同。

编码代理可能反复检查文件、携带不断增长的仓库上下文，或在提交拉取请求前探索多种方法。生产代理可能检索客户数据、在子代理间路由、调用工具并生成最终响应。

在这两种情况下，成本都取决于两个输入：

• 模型价格：输入、输出、缓存或推理token的费率。

• Token使用量：所有经过处理的内容，包括提示、历史记录、工具结果、重试和响应。

从宏观层面来看：

Total request cost =
Σ(tokens processed by type × model rate for that token type)

尽管价格较低的模型可能不会保证更便宜的工作流。当该模型需要更多上下文、重试或代理轮次来完成任务时，总成本可能超过更强大模型的成本。

因此，模型价格仅能解释账单的一部分。您还需要了解工作流的行为方式，以及结果是否通过了质量检查。

在做出任何更改之前，先定义成功结果的标准。对于编码代理，这可能是一个经过更少评审周期合并的拉取请求。对于支持代理，这可能是在不升级的情况下正确解决问题。

选择一个主要质量指标和少量辅助指标，并让这些指标成为后续所有优化的约束条件。

步骤1：追踪完整的流程

首先对完整的问题解决路径进行监控，包括模型调用、检索步骤、工具使用、路由决策和代理步骤。

有用的追踪应包含：

• 模型和提供商

• 输入和输出token数量

• 工具调用和响应

• 重试和重复模型调用

• 延迟时间

• 最终输出

• 相关评估结果

对于生产应用，使用兼容OpenTelemetry的监控工具将追踪发送到Arize AX项目。

对于编码代理，安装适当的追踪集成，将其连接到项目并运行测试交互。确认生成的追踪包含代理的模型调用、工具活动和中间步骤。

一键式代理监控

AX 自动监控文档描述了 npx evals 流程。从项目根目录运行此命令，可启动支持的编码代理，连接或创建 Arize AX 账户，安装所需的追踪工具，对应用或代理工作流进行监控，并确认首次追踪数据已成功发送。

npx evals

这种可见性可以揭示发票无法体现的行为，例如重复的文件读取、失控的上下文增长、停滞的工具、不必要的重试，或从未产生可用更改的昂贵会话。

步骤 2：附加定价并定位昂贵的追踪段

令牌数量显示系统执行的工作量，但要理解支出，这些令牌需要正确的计费率。

在 AX 中，为每个模型配置适用的输入、输出、缓存令牌和推理令牌价格。这还允许团队在协商价格与公开定价不一致时使用协商价格。

AX 成本跟踪文档涵盖了这种行为：当传入的追踪段已包含成本属性时，AX 会使用这些属性。否则，它会将模型和提供商与配置的费率进行匹配。AX 为常见模型提供了默认成本配置，且成本不会追溯生效，因此在导入要分析的追踪之前请先配置定价。

主要成本属性包括 llm.cost.prompt、llm.cost.completion 和 llm.cost.total。AX 会将追踪中 LLM 段的成本相加，以显示请求的总成本。

接下来，打开一个代表性追踪，从总成本倒推至负责该成本的追踪段。

检查以下内容：

• 总追踪成本
• 按追踪段划分的成本
• 提示和完成令牌
• 缓存令牌使用情况
• 工具响应大小
• 重试次数
• 评估结果

然后提出三个问题：

• 哪个追踪段产生了大部分成本？
• 为什么它处理了这么多令牌或需要这么多调用？
• 请求是否仍然满足其质量要求？

一个返回五年数据来回答最近季度问题的工具，与一个真正受益于更强模型的困难请求需要不同的修复方案。追踪会告诉你你面对的是哪种情况。

步骤 3：在质量指标旁监控成本

单个追踪可以解释一个请求，但监控可以揭示这种模式是否正在扩散。

跟踪以下指标：

• 总 LLM 成本
• 每个请求的成本
• 每个请求的提示令牌数
• 模型调用次数
• 工具调用次数
• 评估通过率

当监控指标超过阈值时，打开导致变化的追踪。

追踪项目监控可以使用追踪段属性或自定义 Arize 查询语言 (AQL) 指标；自定义指标文档展示了如何在需要先过滤或聚合源数据时定义 AQL 指标。这为你提供了一条从生产环境峰值直接追溯到背后模型、工具、上下文或重试模式的路径。

随后应将成本与相同流量和时间窗口内的质量进行对比，与代理评估指标中描述的从令牌到结果的转变进行对比：

| 成本 | 质量 | 推荐操作 | |------|------|-----------| | 高 | 弱 | 削减或简化该模式 | | 高 | 强 | 仔细调查并保护重要支出 | | 低 | 弱 | 修复工作流或升级模型、上下文或工具 | | 低 | 强 | 在类似工作负载中复现该模式 |

该框架可防止团队将每次昂贵的请求都视为浪费。目标是找到在持续满足应用质量阈值的前提下，成本最低的模式。

第4步：使用托管代理调查重复出现的浪费

监控工具可以标记问题，但仍需有人检查追踪记录，发现重复行为并提出改进建议。

托管代理可以自动化完成大部分调查工作。在网络研讨会的工作流程中，代理在隔离的沙盒环境中运行，可访问AX项目中的追踪记录和评估结果。它还可以从GitHub仓库或相关技能中接收额外上下文信息。托管代理工具文档详细描述了工具、沙盒环境、可选技能和仓库上下文的配置方式。

以下两个模板特别实用。

成本代理

当调查重点是支出时，使用成本代理。它可以识别：

• 处理低复杂度任务的昂贵模型
• 过大的提示和工具响应
• 冗余的模型或工具调用
• 高成本任务或时间窗口
• 潜在的路由变更
• 建议改进方案的预估节省成本

信号代理

当需要进行更广泛的行分析时，使用信号代理。它可以揭示：

• 无节制的上下文累积
• 重复探索行为
• 运行缓慢或停滞的工具
• 低效的路由策略
• 无法压缩或重启的会话
• 增加成本或延迟的重复失败

成本代理聚焦于账单本身，而信号代理则更全面地分析产生账单的行为。要使用自己的追踪记录进行此类分析，请参考信号教程。

示例：隐藏在小型模型中的上下文膨胀

在网络研讨会演示中，成本代理分析了500多个跨度。该应用已经在相对小型的模型上运行，因此切换模型并非最大的优化机会。

代理发现了一个财务数据工具返回了超过五年的历史数据。28个跨度包含超过5000个提示标记，成本是平均值的七倍以上，占测量账单的约24%。

它还发现了一个过大的监督提示和一个信息已由其他工具提供的冗余工具。

建议的改进方案很简单：仅返回最近两个财务周期的数据，缩短监督提示，并移除重复工具。代理估计这些更改可将测量账单减少约34%。

该百分比来自演示工作负载，而非通用基准。更关键的启示是：上下文和工具设计可能产生的成本问题，可能比模型本身更严重。

第5步：修复追踪揭示的模式

大多数LLM成本问题都属于少数几类。

按测量难度路由

使用能持续通过质量门槛的最小模型。简单的分类或提取任务可能在小型模型上表现良好，而复杂推理或困难重构可能仍需要前沿模型。

用数据验证这一假设，而非单纯根据模型价格进行路由。当推理成本变得明显时，切换到更便宜模型时同样适用先评估再路由的策略。

重复搜索、文件读取、重试和子代理轮转可能在不提升答案质量的情况下增加成本。

利用追踪信息设置更清晰的停止条件、重试限制、上下文上限或压缩规则。

缓存稳定提示内容

将稳定指令和参考资料与请求特定输入分离。当提供者支持提示缓存时，这可以降低重复处理相同上下文的成本。

合理规划评估规模

评估成本可能变得显著，尤其是当每个请求都触发LLM评判时。

从最经济的评估器开始，该评估器能可靠地衡量行为。评估器类型文档涵盖代码、人工和LLM作为评判者的评估器，结果与成本文档涵盖评估成本、采样和过滤。

• 对可编码表达的要求使用确定性检查。
• 当任务部分需要语义判断时，结合代码和LLM。
• 对主观或开放性标准使用LLM评判者。
• 仅将代理作为评判者的流程保留给需要多步骤调查的评估。

采样和过滤可进一步将昂贵的评估限制在能创造最大价值的流量中。

Arize AX衡量这些变更的效果。路由、缓存和工作流修改仍发生在您的应用程序、网关或代理框架中。

第6步：在发布前验证优化

一个有希望的追踪信息足以形成假设，但不足以部署变更。

创建包含以下内容的数据集：

• 常见请求
• 高成本请求
• 已知失败案例
• 困难边界情况
• 当前系统处理良好的请求

将当前工作流作为基准运行。然后创建一个候选方案，仅变更一个变量，如模型、提示、上下文大小、工具输出、重试策略、路由逻辑或评估器。AX数据集文档描述了该工作流的数据集部分。使用实验工作流对比两个版本。

在相同数据集和相同质量标准下评估两个版本。这就是评估驱动开发中使用的相同循环：变更一个变量，测量成本和质量，然后决定。

候选变更 | 成本测量 | 质量保障 ---|---|--- 使用较小模型 | 每请求成本 | 任务成功率 精简上下文 | 提示令牌数 | 答案正确性 限制工具输出 | 工具和提示令牌数 | 完整性 减少重试 | 调用次数和延迟 | 成功完成率 采样评估器 | 评估成本 | 回归覆盖率

仅当候选方案降低成本且持续满足质量阈值时才接受。

然后遵循正常交付流程：

• 审查提议的代码、提示、工具或配置变更。
• 运行CI和相关评估数据集。
• 确认成本下降且没有显著质量退化。
• 需要人工批准。
• 部署并继续监控生产流量。

当更便宜的模式持续有效时，将其编码为共享技能、路由规则、提示模板、工具响应限制或代理配置。这使整个团队都能受益于优化，而不是每次会议都重新发现它。

可重复的LLM成本优化工作流

以下步骤将整个方法浓缩为一个循环，您可以在成本上升时随时运行：

追踪、测量、调查、变更一个变量，并分享仍满足质量标准的更便宜模式。

费用降低只有在应用仍能产生用户所需结果时才具有意义。

一旦将追踪、评估和实验连接起来，成本激增将变成可调试的生产行为。你可以清晰看到资金消耗的具体位置，判断其是否创造了价值，并基于实证数据推送修复方案。

在我们的网络研讨会《在不牺牲质量的前提下降低LLM成本》中，你可以完整看到这一工作流程。随后，通过Arize AX将相同的成本追踪与评估可见性应用到你的应用程序中。