LLM 路由与负载均衡：团队最常混淆的四种策略

路由根据任务或策略选择目标；负载均衡只在已被视为等价的目标之间分配请求。故障切换与重试则是两种独立的失败响应。

发布 2026-08-15 · 更新 2026-08-15 · KeepRouter Editorial · 8 分钟阅读

区分模型路由与端点负载均衡的决策图 — 路由选择合格模型路径，负载均衡在等价资源池内分配流量。

先给结论：LLM 路由根据请求、任务、租户或策略选择目标；负载均衡则只在已经被声明为对当前工作负载可互换的目标之间分配请求。故障切换是在失败后转向另一个合格目标，重试则是重复一次尝试。把它们统称为“智能路由”，会掩盖四套完全不同的安全规则。

四种策略对照

策略	触发条件	必要前提	主要风险	应保留的证据
路由	请求或策略属性	确定性规则与合格目标集合	悄然发生质量或能力错配	规则版本、匹配条件、最终目标
负载均衡	容量或分配目标	目标对该契约等价	实际输出差异打破等价假设	候选集合、最终目标、分配状态
故障切换	已分类的失败	第二目标能安全延续操作	重复副作用或语义漂移	首次失败、资格理由、回退目标
重试	可重试失败或传输中断	操作幂等或有去重 Key	重复计费、工具动作或延迟放大	尝试次数、错误类别、退避、最终结果

Cloudflare 的动态路由文档说明了按请求属性与百分比灰度的规则；Portkey 记录条件路由与回退行为；OpenRouter 的供应商路由文档允许调用方影响供应商顺序、回退、参数支持和数据策略；LiteLLM 则记录跨部署的可靠性策略。这些都是有用的原语，但没有任何一个能证明两个不同模型对你的提示词、工具 Schema 或安全边界可以互换。

先定义资格，再谈算法

从能力谓词开始，而不是从供应商名单开始。合格目标可能必须支持指定端点、工具调用、结构化输出 Schema、最低上下文需求、数据策略、区域与已批准模型快照。只有通过这些硬条件，才可以继续应用成本、延迟、容量或灰度策略。

一份紧凑且可审查的策略可以写成：

eligible = endpoint_ok
        && tool_schema_ok
        && data_policy_ok
        && model_is_approved

target = route_by_task(eligible)
target = balance_within_equivalent_deployments(target)
result = retry_if_idempotent(target)
result = fail_over_only_to_preapproved_targets(result)

如果通过 KeepRouter 显式选择模型，模型路由功能与模型目录描述公开接口；API 可观测性说明重建一次决策所需的证据，错误文档用于判断哪些失败可重试。不要因为模型出现在目录中，就把它推断为自动回退候选。

实施清单

[ ] 每条路由规则都有负责人、版本、测试集与回滚路径。
[ ] 将能力硬过滤与优化评分分开。
[ ] 对输出稳定性敏感时固定模型 ID；把别名当作可变配置进行测试。
[ ] 重试前让工具调用与其他副作用具备幂等性。
[ ] 限制整个重试加回退链的总尝试次数，而非只限制单个目标。
[ ] 在请求记录中保留原始错误与每个尝试目标。
[ ] 除 HTTP 状态外，也评估结果质量。
[ ] 测试服务降级、流式中途失败、取消以及回退链耗尽。

边界：成功响应不等于模型等价

两个目标都能返回合法 JSON，仍可能在指令遵循、工具参数、安全行为、token 计量或响应时间上不同。只在应用能够承受的差异范围内路由。更完整的架构见 AI Gateway 指南，验证方法见如何评估 AI Gateway。

常见问题

故障切换属于负载均衡吗？

不是。负载均衡在正常情况下向合格等价目标分配流量；故障切换则因为一次尝试失败或目标失去资格而更换目标。

不同模型家族可以自动互相回退吗？

只有应用专属评估证明回退模型满足相同端点、工具、数据与质量契约时才可以；仅有 HTTP 成功不够。

参考的一手资料

本文最近复核 2026-08-15