企业如何降低 LLM API 成本？Switchyard + AI Gateway 成本优化实践

账单上涨、模型调用次数却没有明显增加，通常意味着成本被无效上下文、错误路由、重复请求或失败重试放大了。

最快的解法不是全局更换低价模型，而是先拆分请求类型和质量门槛，再使用 Switchyard 做模型路由实验，由 AI Gateway 统一完成预算、用量、权限和成本核算。

谁适合采用这套方法

这篇文章适合需要为不同业务设置模型预算的平台工程团队，也适合正在核算 Agent 与多模型应用成本的技术负责人。

如果企业准备部署路由实验、缓存策略和按项目统计的用量监控环境，下面的实施顺序可以减少“账单下降、质量也一起下降”的风险。

Last updated：2026 年 8 月 13 日；路由能力、缓存计费与网关治理信息核实自 Switchyard 官方文档、NVIDIA NeMo Relay 配置文档、Anthropic 官方计费说明 与 OpenAI 官方 API 价格页。

先定位成本放大的五个入口

LLM API 成本持续上涨，往往不是单一模型价格导致，而是一次业务请求在系统内部触发了更多输入、输出和重复调用。

成本放大入口	常见症状	优先检查项
模型错配	简单分类、改写任务也调用高能力模型	请求类型、风险等级、输出质量门槛
上下文膨胀	每轮都重复发送系统提示、历史消息和工具结果	输入 Token、重复字段、检索片段长度
缓存缺失	相同问题或相同中间结果反复请求	请求稳定性、缓存命中率、数据时效
重试放大	超时、限流或无效输出后连续重复调用	错误类型、重试次数、退避时间
预算失控	账单能看到总额，却找不到哪个项目浪费	租户、项目、环境、用途和请求 ID

其中最容易被低估的是“单次业务请求实际触发了多少次模型调用”。一个用户请求可能包含规划、工具调用、结果校验、格式修复和失败回退；如果网关只记录最后一次成功响应，财务报表就会低估真实消耗。

因此，成本基线至少要同时记录请求 ID、业务项目、环境、模型、输入用量、输出用量、缓存读写用量、延迟、错误类型和重试次数。没有这些字段，后续的模型路由只能凭感觉调参。

把模型路由放在质量门槛之后

Switchyard 更适合承担“路由实验和请求分发”角色，而不是直接替代企业的预算治理系统。其官方架构将客户端请求接收、格式归一化、路由、后端执行和响应转换分开处理，并支持 OpenAI Chat、Anthropic Messages 等客户端格式与不同后端之间的转换。Switchyard 架构说明对此有明确描述。

企业可以先把请求分成几类：

• 低风险、结构固定：分类、抽取、改写、标签生成。
• 中等复杂度：摘要、检索增强问答、普通代码修改。
• 高风险或高难度：复杂推理、关键决策、长流程 Agent、失败恢复。

低成本模型只能承接已经通过验收的任务，不能因为价格更低就默认承接全部流量。对于关键任务，应设置升级条件，例如结构化输出校验失败、引用缺失、工具调用参数不合法、测试未通过或人工抽检不合格。

Switchyard 的 stage-router 可以根据工具结果历史和错误信号在高能力模型与高效率模型之间切换；官方示例中，confidence_threshold 的默认值为 0.5，上下文窗口溢出时会向备用目标发起 1 次回退尝试。Switchyard stage-router 配置说明中的这些参数可以作为实验起点，但不能直接当成生产最优值。

路由实验配置对照

路由方式	适合场景	成本优势	主要风险	验收方式
固定模型	业务刚上线、流量较小	逻辑简单，成本容易估算	高价模型覆盖所有请求	先建立质量基线
规则路由	请求类型和风险标签稳定	解释性强，便于审计	标签错误会导致错路由	抽样核对分类准确性
分类器路由	请求类型复杂、规则难维护	能处理更多语义差异	分类器本身也会产生调用	单独统计分类器成本
阶段路由	Agent 有明显探索、执行、恢复阶段	只在必要阶段升级	工具历史不足时判断不稳	按阶段比较质量与成本

建议先使用观测模式：记录 Switchyard 会选择哪个模型，但仍由默认模型实际执行。只有当验证集显示错误路由、升级率和失败率处于可接受范围，才切换到强制路由。

压缩上下文而不是删除审计记录

重复上下文通常来自四个位置：系统提示、历史对话、检索内容和工具返回结果。直接截断历史消息可能降低输入量，却也可能删除合规审计、权限判断或错误恢复所需的信息。

更稳妥的做法是把上下文拆成三层：

1. 必须原样保留：权限约束、系统规则、用户确认、审计事件。
2. 可摘要保留：已经完成的对话、旧的工具结果、已验证的中间结论。
3. 可按需加载：大型文档、代码文件、检索候选和历史日志。

摘要不能只保留自然语言结论，还应保留来源、时间、状态和未解决事项，否则后续模型可能把过期信息当成当前事实。工具结果也不应整段塞回模型，可以只传递状态码、关键字段、错误原因和下一步需要的参数。

用缓存减少重复输入，但先处理隔离问题

缓存适合确定性高、更新频率低、允许复用的内容，例如稳定的系统提示、版本化规则、相同文档的摘要和可重复计算的中间结果。

缓存键至少应包含以下字段：

• 模型或后端标识；
• 提示词版本；
• 租户或权限范围；
• 数据版本或更新时间；
• 工具结果版本；
• 语言、区域和输出格式。

如果缓存键只使用用户问题，就可能把一个租户的结果返回给另一个租户；如果不包含提示版本，升级系统提示后仍可能命中旧答案；如果不包含数据时效，价格、库存或权限信息就可能过期。

公开计费规则也说明，缓存不是“开启后必然省钱”。Anthropic 文档显示，缓存读取按基础输入价格的 0.1 倍计费，而缓存写入可能按 1.25 倍计费；只有在重复读取次数、缓存有效期和请求稳定性满足条件时，缓存才有经济意义。Anthropic 官方计费说明显示了相关计费规则。OpenAI 也提供了缓存 Token 使用信息，企业应根据实际返回的用量字段核算，而不是只看请求次数。OpenAI Prompt Caching 说明

缓存策略选择

内容类型	是否建议缓存	关键条件	失效方式
固定系统提示	✅ 建议	提示版本稳定、权限一致	版本变更立即失效
用户私有资料	⚠️ 谨慎	租户、权限和数据版本必须入键	权限变化或资料更新
实时库存与价格	❌ 通常不建议	只有明确时效窗口才可复用	按数据更新时间失效
Agent 工具结果	✅ 有条件使用	结果可复现且副作用为零	工具参数或状态变化
自由聊天历史	⚠️ 先摘要	内容变化快，整段命中率不稳定	摘要版本变化

把重试和回退限制在错误类型内

失败重试不能统一处理。网络短暂断开、供应商限流、请求超时、上下文超限和无效结构化输出，解决方式并不相同。

错误类型	推荐动作	不应采用的做法
网络错误	短退避后有限重试	无限循环
限流错误	根据响应头退避，必要时换健康后端	立即并发重试
超时	缩短上下文或切换备用模型	原样重复提交
上下文超限	摘要、裁剪或转移到更大窗口	连续发送同一请求
输出格式错误	修复提示或走结构化回退	无限要求模型重写

每一次重试都应生成同一个业务请求 ID 下的子调用记录，并记录 attempt、错误类型和实际模型。这样才能区分“用户发起了 1 次请求”和“系统实际调用了 4 次模型”。

如果企业使用 AI Gateway 作为统一入口，还应把超时、限流、回退、缓存和权限策略集中管理，而不是散落在多个后端服务中。网关预算功能则应按租户、项目、环境和用途设置限额，并将预算告警与请求 ID 关联。LiteLLM 官方文档将项目级预算和用量追踪列为 Proxy Server 能力之一，可作为网关治理功能的对照参考。LiteLLM Proxy Server 文档

用质量护栏控制模型降级

模型切换到较低成本的后端后，质量不能依靠主观感觉判断，而应通过任务级验证集、人工抽检和明确的升级条件进行控制。

验证集应覆盖正常样本、边界样本和失败样本，至少检查：

• 结构化字段是否完整；
• 事实引用是否存在且格式正确；
• 工具调用参数是否符合约束；
• 代码或查询是否通过现有测试；
• 敏感任务是否触发人工复核；
• 低成本模型失败后是否能升级；
• 升级后的结果是否真正解决了原错误。

对于客服摘要、数据抽取和格式转换等任务，可以先设定字段完整率、格式通过率和人工抽检结果等门槛；对于代码生成或工具调用，则应加入测试通过、参数校验和副作用检查。只有达到对应门槛的请求类型，才适合长期交给低成本模型。

路由实验不要只比较平均回答质量，还应同时比较平均输入用量、输出用量、失败率、升级率、尾延迟和每个业务请求的实际调用次数。单看单价，可能把成本从主模型转移到了分类器、重试、缓存写入或人工审核环节。

按顺序上线成本治理

成本优化项目建议采用“先看清，再收缩，最后自动路由”的顺序，而不是第一天就切换模型。

上线阶段对照

阶段	先完成的工作	通过标准	暂缓条件
基线阶段	统一日志、请求 ID、Token 与模型记录	能按项目解释账单	无法区分租户和环境
收缩阶段	上下文摘要、字段裁剪、重试限制	质量不低于基线	关键审计信息被删除
复用阶段	缓存中间结果和稳定提示	缓存键完成权限隔离	数据时效无法确认
路由阶段	Switchyard 观测、验证集、升级策略	错误路由可检测并回退	分类器成本不可见
治理阶段	AI Gateway 预算、告警、限额	超预算请求可阻断或降级	业务负责人没有成本归属

上线前可以使用下面的检查清单：

• [ ] 每个请求都带有业务请求 ID、项目、租户、环境和用途。
• [ ] 日志区分输入 Token、输出 Token、缓存读写 Token 与重试调用。
• [ ] 已建立按任务类型划分的质量验证集。
• [ ] Switchyard 路由先以观测模式运行，再逐步启用强制分发。
• [ ] 分类器调用使用独立配额或独立成本标签。
• [ ] 缓存键包含模型、提示版本、权限和数据时效。
• [ ] 网络错误、限流、超时和无效输出拥有不同重试策略。
• [ ] AI Gateway 已设置项目预算、告警阈值和硬限制。
• [ ] 验收同时包含成本、质量、延迟和失败率，不能只看账单。
• [ ] 供应商价格、计费单位和缓存规则变更后，会重新计算成本模型。

企业可以先从一周真实调用记录开始，找出最常见的高输入请求、最高重试请求和最常被高价模型处理的低风险请求。完成基线后，再将 Switchyard 接入隔离环境进行回放；如果需要查看控制台、环境管理或部署支持，可参考 nuvcloud 帮助中心 与 nuvcloud 控制中心。

当前方案与 Mac 实验环境的取舍

直接在现有生产服务器上改模型路由，通常有三个现实缺点：实验流量容易与正式流量互相影响，日志和密钥隔离不充分，出现质量回退时也难以快速复现；如果使用临时云主机，还可能遇到环境初始化、权限交接和按量计费边界不清的问题。

更稳妥的方式是把 Switchyard、AI Gateway、回放脚本和验证集放进独立实验环境，先完成路由与缓存验证，再迁入生产。若企业只需要临时算力来隔离环境、回放流量和测试多模型调用，可以根据实验周期选择 nuvcloud 的 Mac 方案；但长期稳定重负载、必须接入物理设备或需要固定专用网络的场景，仍应优先评估自购设备或正式服务器，而不是把租赁当成生产基础设施替代品。