如何在不牺牲质量的情况下构建具有成本意识的 LLM 模型路由

具有成本意识的 LLM 模型路由不应意味着将每个请求发送到最便宜的可用模型。这会创建一种安静的失败模式：发票在几周内得到改善，然后产品团队就会发现架构损坏、推理较弱、语气不一致或需要更多人工清理的支持草稿。

更好的模式是 eval 支持的路由策略。对请求进行分类，定义该任务的最低可接受质量，删除无法满足能力或治理约束的路线，估计路线经济性，然后选择成本最低的合格模型。路由决策在成本审核期间变得可以解释，因为它与策略版本相关，而不是与开发人员偏好或模糊的提供商默认值相关。

成本感知路由正在优化什么

实用的路由器会优化最便宜的路线，同时仍能满足任务的操作要求。这与优化最便宜的模型不同。

事实： 主要模型提供商发布具有单独维度的令牌定价，例如输入令牌、缓存输入令牌、输出令牌、提示缓存和批处理。一些提供程序还公开报告缓存令牌行为的使用字段。这意味着成本最低的选项可以根据提示形状、预期输出长度、缓存资格以及工作负载是否可以异步运行而改变。

建议：将路由视为多模型 AI API网关内的策略问题，而不是应用程序级 switch 语句。网关在一处查看提供商能力记录、租户规则、API关键元数据、价格表、使用情况遥测和回退行为。

预测： 将路由逻辑分散在应用程序存储库中的团队稍后将很难解释成本变化。他们可能仍会减少支出，但他们对于给定请求为何使用给定模型的证据会较弱。

从任务类开始，而不是提供程序名称

路由器需要工作负载标签才能做出有用的决定。单个默认模型无法代表每个请求的风险状况。

有用的任务类包括：

• 提取：将非结构化文本转换为字段，通常会进行严格的架构验证。
• 分类：分配标签、优先级、意图、情绪或路由类别。
• 摘要：压缩长输入，同时保留关键事实和决策。
• 客户支持起草：生成可供人工查看或发送的回复。
• RAG 答案综合：从检索到的上下文中获取带有引文或基础要求的答案。
• 代码审查：检查差异或源文件的正确性、风险或样式问题。
• 长上下文分析：对合同、成绩单、日志、政策或研究包进行推理。
• 高影响力的决策支持：错误答案可能影响资金、合规性、安全性或客户信任的任何工作流程。

任务类可以来自显式请求元数据、API 键范围、应用程序路由或轻量级分类器。显式元数据通常比从提示文本推断意图更好，因为模糊的提示会迫使路由器采用保守的默认值。

为每项任务附加质量底线

成本感知路由仅在每项任务都有质量底线时才有效。如果没有一个，路由器就没有原则性的方法来拒绝更便宜的型号。

优质地板可以包括多项检查：

• 可重播的评估集：来自开发和生产的代表性示例，根据需要删除敏感数据。
• 架构有效性：输出必须根据规范架构进行解析、验证，并避免不支持的字段。
• 内容标准：答案必须遵循任务的风格、拒绝、基础和完整性规则。
• 安全标准：输出不得泄漏隐藏指令、忽略策略边界或从检索到的内容执行不受信任的指令。
• 人工审核：对于高影响力的工作流程或推广新路线而言是必需的。
• 回归阈值：候选路线在关键故障类别上必须达到或超过当前路线，而不仅仅是平均分数。

事实： 提供商文档将评估描述为根据指定内容和样式标准测试模型输出的一种方法。一种托管的评估产品计划弃用，因此路由系统应存储与提供商无关的评估数据集、预期输出、评分标准和结果，而不是依赖于一种提供商托管的评估界面。

建议：按任务类、模型、提供程序适配器版本、提示版本、架构版本和评估版本存储评估结果。一条路线不应仅仅因为型号较新或较便宜而变得符合资格。当它通过任务当前的质量门时，它就符合资格。

构建提供商能力注册表

在估算成本之前，删除任何无法满足请求的路线。此步骤可防止路由器选择缺乏所需功能的廉价型号。

能力记录应包括：

• 支持的输入和输出模式。
• 上下文窗口限制。
• 结构化输出和工具调用支持。
• 流式传输支持。
• 提示缓存支持和缓存遥测可用性。
• 批量API支持。
• 区域处理选项。
• 对您的政策至关重要的数据保留和滥用监控条款。
• 速率限制维度和当前容量。
• 适配器层中已知的输出协定差异。

此注册表应与应用程序提示分开维护。它属于路由和提供商适配器层附近，系统可以在其中比较模型，而不会将提供商特定的假设泄漏到每个应用程序中。

选择前估算路线成本

路由器无法知道执行前的最终成本，但它可以很好地估计以在符合条件的路由中进行选择。估算应包括实际移动发票的变量。

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

使用最近的遥测数据按任务类别估计输出标记。例如，提取任务的输出长度可能有限，而长上下文分析可能差异很大。使用工具的代理可能会因工具调用规划、重试和中间消息而产生额外的隐性成本。

成本估算还应考虑缓存和批次资格：

• 缓存资格：稳定的提示前缀、可重复使用的系统指令、重复检索的上下文、支持的提供程序行为以及足够的缓存命中概率。
• 批量资格：工作负载可以等待，具有幂等请求处理功能，具有持久的作业跟踪，并且不需要交互式流式传输。
• 输出令牌风险：模型往往会为同一任务生成更长或更短的答案，而截断会损害质量。
• 重试风险：提供程序或模型的错误率、架构修复率或此任务的延迟失败率较高。

这是成本路由与更广泛的LLM 成本管理相连接的地方。仅有价格表是不够的。路由器需要请求元数据、提示结构、缓存命中测量和固定的使用数据，以了解预期的节省是否实际发生。

使用模型层而不是全局默认值

分层政策比大量特定于提供商的例外情况更容易解释。每层应包含一个或多个已通过特定任务关卡的合格模型。

层	用例	典型路由规则
经济	低风险的确定性工作，例如简单提取、标记或简短分类	使用通过架构和准确度关卡的成本最低的模型
平衡	正常制作起草、摘要和 RAG 合成	优先选择具有稳定质量和延迟的经济高效模型
高级	高风险、不明确、长上下文或低置信度任务	使用更高功能的模型，除非置信度和评估历史记录支持降级
受限	受监管、敏感、区域或合同工作负载	仅允许管理政策批准的提供商和模型

不要让层取代评估。模型对于分类可能很经济，但不适合支持起草。另一种模型对于摘要来说可能很强大，但对于短确定性标记来说成本太高。

具有显式决策序列的路由

具有成本感知能力的路由器应该具有足够的确定性以进行调试。确切的实现有所不同，但决策顺序应该是稳定的。

1. 读取租户、API密钥、环境和应用程序元数据。
2. 从显式元数据或分类器输出中识别任务类。
3. 加载该租户或工作区的路由策略版本。
4. 应用数据保留、区域、模型许可名单和功能限制等治理约束。
5. 按所需功能进行过滤：上下文长度、工具、结构化输出、流式传输、模式和批量支持。
6. 按任务类的评估支持的质量下限进行过滤。
7. 使用输入令牌、预期输出令牌、缓存资格、批量资格和重试风险来估算成本。
8. 应用预算政策和租户偏好。
9. 选择成本最低的合格路线。
10. 附加后备路由、超时、重试和修复政策。
11. 使用稳定的原因代码记录决策。

在伪代码中，路由器应该看起来更像是策略评估，而不是硬编码的提供商首选项：

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

记录每个路由决策

如果财务部门询问为什么使用高级型号，或者工程部门询问为什么质量下降，路由器应该从日志中回答。不要依赖事后根据提示重建意图。

为每个请求记录这些字段：

• 请求 ID、租户 ID、API 密钥 ID、应用 ID 和环境。
• 任务分类器结果和置信度。
• 路由政策版本。
• 评估数据集版本和使用的质量门。
• 符合条件的模型和被拒绝的模型。
• 每个被拒绝的模型被排除的原因。
• 估计输入、缓存输入和输出令牌。
• 预计路线费用和最终结算费用（如果有）。
• 选择的提供商、型号、适配器版本和层级。
• 后备路由和重试政策。
• 缓存命中或未命中的遥测数据（如果可用）。
• 批处理与同步执行模式。
• 架构验证、修复尝试、拒绝状态和安全标志。

这些日志还支持LLM API成本归因，因为模型选择只是支出的一部分。团队仍然需要按租户、工作区、密钥、产品、工作流程或客户分配成本。

在推广更便宜的路线之前添加漂移控制

模型行为、定价、提示和工作负载组合变化。上个月安全的路线在经过及时修改或模型更新后可能会变得脆弱。

基本的漂移控制回路应包括：

• 按任务类别采样最近的生产请求。
• 根据政策删除或转换敏感数据。
• 通过当前路线和候选路线重播示例。
• 比较质量、架构有效性、拒绝行为、成本和延迟。
• 按类别查看失败，而不仅仅是总分。
• 仅在满足质量底线和运营限制的情况下推广更便宜的路线。
• 金丝雀是一小部分流量的新路线。
• 在架构失败、成本超支、延迟违规或人工审核升级时自动回滚。

建议：将路线升级作为变更管理活动。记录谁批准了它、它通过了哪些评估集、它影响了多少流量百分比、它何时过期或需要审核以及回滚的工作原理。

给予团队覆盖，但使其过期

有一些合理的理由需要覆盖路由：提供商事件、预算紧急情况、合规性审核、客户升级或模型回归。问题不在于覆盖。问题是覆盖变成了不可见的永久政策。

每个覆盖应包括：

• 范围：租户、应用程序、API 键、任务类、模型、提供商或区域。
• 原因：事件、预算、质量、合规性、延迟或客户请求。
• 批准者。
• 开始时间和到期时间。
• 对费用、延迟时间和质量的预期影响。
• 回滚条件。

过期的覆盖应该无法关闭正常的路由政策或需要续订。这可以防止紧急决策成为隐藏的成本或质量风险。

明确的权衡

成本感知路由具有实际的运营成本。当 LLM 支出较大时，这仍然值得做，但权衡应该是可见的。

• 元数据依赖性：路由质量取决于准确的任务标签和工作负载元数据。缺少标签会将流量推向保守的默认值。
• 评估维护：任务评估需要随着提示、产品和用户行为的变化而更新。
• 提供商复杂性：缓存和批量折扣可以提高经济效益，但会使路由逻辑更加复杂。
• 可移植性风险：提供商特定的功能应存在于适配器和功能记录中，而不是存在于产品代码中。
• 估计不确定性：最终输出长度、工具调用、重试和缓存命中在执行前并不完全已知。
• 可解释性负担：积极的优化可能会使产品行为难以解释，除非每个决策都记录有政策版本和原因代码。

实施清单

• 根据支出和业务影响定义顶级 LLM 工作流程的任务类别。
• 为每个任务类别创建评估集和质量底线。
• 构建提供程序和模型功能注册表。
• 按提供商、模型和执行模式存储当前价目表和定价修正。
• 估计输入令牌、预期输出令牌、缓存资格、批次资格和重试风险。
• 在成本优化之前根据治理限制筛选候选者。
• 仅在通过能力和质量关卡后才选择成本最低的模型。
• 使用原因代码记录所选和拒绝的路由。
• 将估算费用与已确定的使用情况和发票数据进行比较。
• 在推广更便宜的路线之前运行定期重播评估。
• 金丝雀路由更改并定义回滚触发器。
• 手动覆盖需要截止日期。

结论

实际目标不是将每个请求路由到更便宜的型号。目标是停止为日常工作支付过高的费用，同时保护质量、合同、治理规则和可解释性。

围绕任务类别、质量底线、提供商功能、成本估算和政策日志构建路由器。然后选择成本最低的合格路线。 “合格”一词是成本感知型路由与最便宜模型路由的区别。

相关阅读

• 网关级支出限制