什么是 LLM 路由？规则、权重与成本感知策略详解

什么是 LLM 路由？规则、权重与成本感知策略详解

LLM 路由是指为特定 AI 请求选择应由哪个模型、提供商路径或回退路径来处理的过程。该决策可以固定在应用程序代码中，由显式规则制定，根据加权标准计算，或委托给学习型分类器。其目的并不是让每个请求都走不同的路径，而是让每条路径都有明确意图、可测试且安全。

如果您在问什么是 LLM 路由，实用的答案是：它是位于应用程序请求与模型调用之间的策略层。路由器首先排除无法满足请求的选项，然后根据团队设定的优先级——例如能力、质量、延迟、成本、可用性和数据策略——选择符合条件的路由。

这一区别很重要。对于面向客户的工作流，廉价模型并不自动意味着是安全的默认选择。对于简单的分类任务，高能力模型也不自动就是正确选择。只有当回退路径能保留应用程序所期望的输出、工具和数据契约时，它才有用。

简而言之：良好的 LLM 路由始于硬性约束，仅对兼容的候选项进行排序，记录选择原因，并且仅在备用方案符合契约安全要求时才进行回退。

这正是对什么是 LLM 路由的生产级回答应达到的标准：工程师能够检查、测试和修改这一决策，而无需猜测是哪条隐藏规则改变了流量走向。

LLM 路由究竟是什么？

什么是 LLM 路由？它是一种决策过程，可将传入请求映射到最适合该请求且已获批准的执行路径。该路径可以指定某个特定模型、提供商、区域、模型组或经过测试的回退方案。

路由器可以部署在您的应用程序、API 网关或托管式模型路由服务中。例如，Amazon Bedrock 智能提示路由会根据预测的响应质量和成本，在一个模型系列中符合条件的模型之间进行选择。Microsoft Foundry 的模型路由器提供均衡、质量导向和成本导向的路由模式。这些都是同一底层理念的实现：有意识地进行选择，而不是将每个提示都视为相同。

LLM 路由不同于：

• 负载均衡器。负载均衡器将请求分配到相似的服务器之间。LLM 路由器还会考虑模型能力和任务结果。
• 重试循环。重试同一路由可以解决瞬态错误；但它并不决定另一个模型是否适用于该任务。
• 未经审核的模型切换。将请求转移到会改变 JSON 结构、工具行为、隐私边界或回答质量的备用方案，可能会造成比显式错误更严重的故障。
• 模型训练。路由是在请求时选择服务路径，并不会改变模型权重。

如需更广泛地了解承载这些决策的边界，请参阅我们的指南：什么是 LLM 网关，以及它何时变得有用。

LLM 路由器如何做出决策

最可靠的设计会将资格判定与偏好分开。首先，排除无法满足请求的选项。然后，根据当前流量类别对其余路由进行评分。

1. 在进行任何评分之前应用硬性约束

硬性约束不可协商。即使某个模型价格低或速度快，只要不满足其中一项，它就不应保留在候选集中。

典型筛选条件包括：

这一顺序可以避免常见的路由错误：将所有模型视为可互换的。事实并非如此。必须针对您计划路由到的确切端点和流量类别证明其兼容性。

2. 对符合条件的候选项评分

筛选后，路由可以使用透明的加权评分。一个简单模式如下：

路由评分 =
  质量权重 × 预期质量
  + 延迟权重 × (1 - 归一化延迟)
  + 成本权重 × (1 - 归一化成本)
  + 可靠性权重 × 近期路由健康度

这个公式是一种决策框架，而非通用基准。重要的是各项采用一致的归一化方式，权重归属于某个流量类别，并且在事故发生后能够解释该策略。

例如，后台标注任务可能更重视成本和吞吐量。面向客户的支持代理可能更重视质量、工具兼容性和尾延迟。受监管的工作流可能将数据驻留作为绝对过滤条件，而非评分项。

3. 执行、观察并使用有界回退

路由器应记录所选路由、评分输入、策略版本、请求 ID、延迟、成本估算或用量记录，以及结果状态。如果主路由失败，回退决策需要有自己的规则：

1. 该错误是否足够短暂，可以在同一路由上重试？
2. 该请求是否幂等，还是重试可能会重复执行外部操作？
3. 回退是否保留输出和工具契约？
4. 是否允许回退超出请求的预算或数据边界？
5. 如果不允许，系统是否应改为排队、优雅降级，或返回受控错误？

这就是为什么回退是一种路由技术，而不是路由的同义词。我们的模型回退策略指南更详细地介绍了恢复决策。

六种应有意识地使用的 LLM 路由技术

没有唯一最佳的路由器。应从能够满足工作负载需求的最简单技术开始，只有当测量结果证明合理时再增加复杂性。

1. 静态路由

工作负载中的每个请求都发送到一个指定的模型或端点。

适用场景：正在建立基线、需要稳定的评估目标，或拥有仅使用一个已批准模型的狭窄工作负载。

注意事项：静态路由可能掩盖对简单任务使用高能力模型的成本，或依赖单一上游路径的可靠性风险。

2. 基于规则的路由

显式条件决定路由：将包含图像的请求发送到支持视觉的路径；仅将带有工具调用的请求发送给支持已批准工具契约的模型；将内部批量摘要发送到经济型路由。

适用场景：可以根据请求元数据解释决策，并且规则数量足够少，便于审查。

注意事项：规则蔓延。应将规则放在版本化的策略文件或服务中，而不是将提供商检查分散在应用程序代码中。

3. 基于能力的路由

路由器从模型能力注册表出发，而不只依赖提示文本。它会根据端点系列、上下文、支持的模态、工具行为、结构化输出支持、区域和账户额度进行过滤。

适用场景：应用程序具有多种端点类型，或模型之间的契约存在实质性差异。

注意事项：过时的目录数据。应将模型 ID、能力和弃用信息视为需要定期验证的运营数据。

4. 加权成本、质量、延迟和可靠性路由

符合条件的路由会根据当前目标获得评分。当团队希望获得比固定规则更细致的方案、但仍需要可解释的策略时，这正是什么是 LLM 路由这一问题的常见答案。

适用场景：能够定义可衡量的验收信号，并且拥有足够的路由遥测数据来比较候选方案。

注意事项：虚假的精确性。评分的价值取决于其背后的质量数据、成本假设、健康信号和权重。不要暗示小数评分能够证明某个模型在所有情况下都更好。

5. 基于分类器的路由

小型分类器或基于 LLM 的分类器会为请求打上标签——例如简单提取、代码生成、复杂推理或安全敏感内容——然后将其交给为该类别预定义的策略。

适用场景：提示意图能强烈预测合适的模型层级，并且可以将分类器错误与模型错误分开评估。

注意事项：在模型调用之前加入不透明的决策。应保留低置信度路径、记录分类结果，并针对具有代表性的请求评估分类器。

6. 健康感知的回退路由

主路径按常规方式选择，但路由器会针对超时、过载、速率限制或健康状况下降作出响应，采取有界重试、等效备用方案、排队或受控失败。

适用场景：可用性很重要，并且已确定哪些备用方案与契约兼容。

注意事项：悄然跨越语义边界。对于可重试的文本补全，回退可能是合适的；但对于使用工具的代理、会改变状态的工作流，或必须符合严格架构的输出，则未必如此。请参阅我们的多模态代理路由指南，了解模态变化会使回退规则更严格的示例。

构建成本感知策略，同时避免对质量视而不见

成本感知并不意味着“始终选择最便宜的模型”。它意味着在通过所需的能力、策略和契约检查后，为成本赋予明确的作用。

一种实用模式是在设置权重之前先创建流量类别：

然后比较真正重要的指标：每个被接受结果的成本，而不只是每次请求的成本。价格较低的路由如果导致额外重试、人工审核、架构修复或工具调用失败，则每个已完成任务的成本可能更高。

Amazon 的路由文档在不同语境中提出了同样的实践性提醒：自动路由存在局限，包括特定路由的训练数据和支持边界。它建议持续审查性能和成本，而不是假设某个路由决策会永远保持最优。你自己的策略应根据你自己的请求组合进行评估。

使用伪代码实现安全的路由策略

这个简化示例让决策过程保持可审计。它并不假设每条路由都能处理每个请求。

const candidates = catalog
  .filter(route => route.isHealthy)
  .filter(route => route.supports(request.modality))
  .filter(route => route.supportsTools(request.requiredTools))
  .filter(route => route.allows(request.dataClass))
  .filter(route => route.withinBudget(request.budget));

if (candidates.length === 0) {
  return failClosed("No approved route for this request");
}

const primary = candidates
  .map(route => ({
    route,
    score: score(route, request.trafficClass),
  }))
  .sort((a, b) => b.score - a.score)[0];

const result = await call(primary.route, request);

if (isTransient(result.error) && request.isIdempotent) {
  return retryWithinBudget(primary.route, request);
}

if (canUseEquivalentFallback(result.error, request, primary.route)) {
  return call(selectApprovedFallback(candidates, primary.route), request);
}

return returnControlledError(result.error);

该策略应输出路由原因，例如 tool_contract_required、budget_preferred、primary_unhealthy 或 no_contract_safe_fallback。与笼统的“模型失败”消息相比，这个小细节能让系统更容易调试。

如何衡量 LLM 路由是否有帮助

路由成功并不只是因为它产出了一个模型名称。只有在不带来不可接受风险的前提下，它改善了既定工作负载的结果，才算成功。

按流量类别、策略版本和所选路由跟踪结果：

• 被接受结果率：通过业务、架构或人工审核验收测试的响应占比。
• 每个被接受结果的成本：模型、重试和修复的总成本除以被接受的任务数。
• P50、P95 和 P99 延迟：按请求大小和路由分段统计；平均值可能掩盖令人痛苦的长尾延迟。
• 回退恢复率：回退产生可接受结果的频率，而不仅仅是返回 HTTP 200 的频率。
• 契约失败率：无效的结构化输出、不受支持的工具、流式传输不兼容或缺少必填字段。
• 路由分布：新策略是否意外地将大部分流量发送到昂贵或性能下降的路径。
• 策略拒绝率：不存在安全候选项的频率——这通常表明应扩展已批准的能力，而不是放松防护措施。

有关实用的评分卡，请参阅 真正重要的 AI 路由 API 指标。当路由变更看似降低了 token 成本、却减少了被接受结果时，这些指标尤其有用。

何时需要 LLM 路由？

当单一提供商、单一端点和单一稳定工作负载已经满足你的要求时，你可能不需要路由器。固定模型，设置明确的超时和重试机制，并先衡量基线。

当以下至少一项为真时，LLM 路由就会变得有价值：

• 不同请求类型需要不同的能力、成本范围或延迟目标。
• 你需要将提供商、模型和区域选择置于策略边界之后。
• 服务中断、配额问题或弃用需要安全的响应路径。
• 你希望在不重写每个调用方的情况下比较候选方案。
• 你需要记录哪条路由处理了某个请求以及原因。

如果这听起来像是您的技术栈，网关可以让运营边界更易于管理。Flatkey 文档介绍了一个与 OpenAI 兼容的基础 URL，以及一个用于受支持模型的 API 密钥；调用方可在每个请求中选择模型 ID，而该平台也说明了自动上游故障转移功能。先固定一个模型并记录结果，然后再为真正需要它的流量类别引入明确的路由策略。有关下一步架构规划，请阅读我们的 AI API 网关需求清单。

如需了解路由策略、策略模板和生产代码，请阅读我们的模型路由指南。

常见问题

LLM 路由与模型回退有什么区别？

LLM 路由是用于选择执行路径的更广泛决策过程。模型回退是该过程中的一种恢复操作，仅在主路由失败且针对同一请求契约已批准备用路由时使用。

多提供商 API 中的 LLM 路由是什么？

在多提供商 API 中，LLM 路由不仅可以选择模型，也可以选择提供商路径。在将两个提供商视为等效之前，策略应验证端点兼容性、数据策略、模型能力、定价单位、运行状况和回退行为。

新团队应从哪种 LLM 路由技术开始？

从静态路由、明确的能力检查和可观测性开始。为明显不同的流量类别添加规则。只有在具备有代表性的测试以及衡量已接受结果的方法之后，才转向加权路由或基于分类器的路由。

LLM 路由器可以自动选择最便宜的模型吗？

可以，但成本绝不应绕过硬性约束。先根据已批准的能力和契约兼容性进行筛选，再在符合条件的路由中优化价格。应使用每个已接受结果的成本来验证结果，而不应只看令牌价格。

“什么是 LLM 路由？”的实用答案

对于什么是 LLM 路由这一问题，实用的答案不是“选择一个聪明的模型”，而是“编码团队能够辩护的选择”。从已批准的能力和硬性约束入手；仅将权重用于真实的权衡；保持回退范围有限且契约安全；并充分记录每一项决策，以便日后改进。

如果您正在集中管理模型访问，请利用这一边界运行受控的路由实验，而不是将提供商逻辑分散到每个服务中。有关更多信息，请参阅 Flatkey API 文档。

来源与延伸阅读

• Amazon Bedrock：了解智能提示路由
• Microsoft Foundry：使用模型路由器
• Google SRE Book：处理过载
• Flatkey 文档
• Flatkey：AI API 网关需求