AI 模型路由详解：延迟 vs 成本 vs 质量

当你的应用向 LLM 发送请求时，总得有人决定由哪个模型来处理。简单的做法是把决策写死——每个请求都发给同一个供应商的同一个模型。但在生产环境中，当你每分钟要处理成千上万个不同场景的请求时，这种做法意味着性能和成本上的双重浪费。

智能模型路由，就是根据实时状态和可配置的优先级，动态地为每个请求选择最佳模型和供应商。这篇文章深入解析它的底层工作原理。

什么是模型路由？

模型路由是位于你的应用和 LLM 供应商之间的决策层。对于每个传入的请求，路由器会评估所有可用模型，选出最符合当前优化目标的那个。

最简单的路由就是静态映射：「永远使用 Claude Sonnet」。最复杂的形式则会综合考量实时延迟测量、每 token 成本差异、质量基准、供应商健康状态，以及预算限制等组织级约束——所有这些评估在微秒级内完成，然后请求才被转发出去。

路由的价值随着你接入的模型和供应商数量增加而增长。只有一个模型时，没什么可路由的。但当你有十个模型、分布在四个供应商时，路由决策就能在每一个请求上显著影响成本、速度和可靠性。

每个路由决策都需要在三个相互竞争的目标之间做出权衡：

这个模型的响应速度有多快？延迟不仅因模型而异，同一模型在不同供应商之间也会有差异，而且全天会随负载波动。一个凌晨两点响应只需 200 毫秒的模型，到了高峰时段可能需要 2 秒。

针对延迟优化，意味着持续测量实际响应时间，并将请求路由到当前最快的供应商。这对实时应用至关重要——聊天机器人、自动补全、交互式 agent，用户在等着响应。

这个请求要花多少钱？不同模型和供应商之间的定价差异巨大。同一个请求在小模型上可能只花 $0.001，在旗舰模型上可能要 $0.05——差了 50 倍。对于高流量的工作负载，这种差异会直接转化为每月数千美元的开支。

针对成本优化，意味着选择能胜任请求的最便宜的模型。这需要理解每个请求的复杂度和每个模型的能力——这就是质量评分发挥作用的地方。

响应质量有多好？不是所有模型都能产出同等水平的输出。旗舰模型在处理细微推理、复杂指令和边缘情况时表现更好。但对于简单直接的任务，质量差异可以忽略不计。

针对质量优化，意味着将复杂请求路由到能力强的模型，将简单请求路由到高效的模型。这是最难评分的维度，因为质量与任务相关且带有主观性，但基准数据和实证测试可以提供可用的信号。

静态的延迟基准对路由决策几乎没用，因为供应商性能一直在变化。你需要的是一个实时信号——它能适应当前状况，同时平滑掉单个请求的随机波动。

这正是 EWMA——指数加权移动平均（Exponentially Weighted Moving Average）——所提供的。

EWMA 计算观测延迟的滚动平均值，其中近期的测量值权重更高。公式很直观：

EWMA_new = alpha * latency_observed + (1 - alpha) * EWMA_previous

alpha 参数（通常在 0.1 到 0.3 之间）控制着平均值对新数据的适应速度。alpha 越高，评分对近期变化反应越快，但也更容易受异常值影响。alpha 越低，稳定性更好，但适应速度更慢。

在实践中，路由器为每个「模型-供应商」组合维护一个 EWMA 分数。每个响应都会更新该分数。做出路由决策时，路由器比较当前的 EWMA 分数，找出此刻真正更快的供应商——而不是一小时前更快的，或者官方基准测试里更快的。

这种方法能自然地应对瞬时变慢、渐进退化和恢复，无需任何人工干预或阈值配置。

在生产环境中，你很少只想针对单一维度优化。纯成本优化会始终选最便宜的模型，哪怕响应质量不可接受。纯延迟优化则完全忽略成本。解决方案是加权路由。

加权策略为每个维度分配一个优先级，以百分比表示：

路由器为每个可用模型计算综合得分——将每个维度归一化到 0-1 的范围，然后应用权重：

score = (w_latency * latency_score) + (w_cost * cost_score) + (w_quality * quality_score)

综合得分最高的模型赢得该请求。整个计算在微秒级完成，且可以按项目或按 API key 灵活配置。

供应商宕机和服务降级不是小概率事件——它们经常发生。任何依赖单一供应商而没有故障转移的生产系统，都在承担不必要的停机风险。

有效的自动故障转移包含三个环节：

检测。 路由器实时监控每个供应商的响应状态码、延迟飙升和超时率。单个失败请求可能只是瞬时错误。但如果出现模式性故障——十秒内三个 500 错误，或延迟超过 EWMA 基线的 5 倍——就会触发供应商健康状态降级。

重新路由。 当供应商被标记为降级时，路由器将其从候选池中移除，并将流量重新分配到健康的备选方案。这一切透明地发生——你的应用从另一个供应商收到响应，无需任何代码改动或客户端重试逻辑。

恢复。 路由器定期向降级的供应商发送探测请求。当持续收到健康响应后，该供应商会逐步重新加入候选池。这可以防止刚恢复的供应商立刻被全量流量冲垮，也避免在短暂的虚假恢复后过早重新纳入。

Router One 的路由引擎将这些原则作为一等特性构建——而非事后补丁。

每个发送到统一 POST /llm.invoke 端点的请求，都会根据所有可用模型的当前 EWMA 分数、成本表和质量基线进行评估。路由权重可以在项目和 API key 层级通过 Dashboard 或 API 配置，因此同一组织内的不同工作负载可以有不同的优化优先级。

故障转移是自动的，无需任何配置。供应商降级的瞬间，流量就会转移。供应商恢复的瞬间，流量就会重新平衡。完整的决策轨迹——哪些模型被考虑了、它们各自的得分是多少、为什么最终选择了优胜者——都会被记录下来，并在可观测性 Dashboard 中对每个请求可见。

这不仅给你智能路由，还让你完全透明地看到每一个路由决策是如何做出的。

如果你还在把所有 LLM 请求发送到单一供应商的单一模型，那么你正在为此多花钱、跑得更慢、并且承担着本不必要的可靠性风险。智能路由同时解决这三个问题。

在 router.one 注册免费账号，试试 Router One 的路由引擎。配置你的权重，实时观察 EWMA 分数的自适应变化，第一天就能感受到智能路由带来的差异。