当你的应用向 LLM 发送请求时，总得有人决定由哪个模型来处理。简单的做法是把决策写死——每个请求都发给同一个供应商的同一个模型。但在生产环境中，当你每分钟要处理成千上万个不同场景的请求时，这种做法意味着性能和成本上的双重浪费。
智能模型路由，是按明确的路由模式与当前运行信号选择模型-provider 线路。这篇文章既解释通用原理，也写清 Router One 当前更窄的产品合同。
什么是模型路由？
模型路由是位于你的应用和 LLM 供应商之间的决策层。根据路由模式，它可以遵循精确模型选择，也可以评估受支持的候选集。
最简单的路由就是静态映射：「永远使用 Claude Sonnet」。Router One 生产流量默认采用 model_name 策略，因此精确模型请求不会自动变成一次自适应评分。使用 model="auto" 时，网关使用服务端候选集，并可用延迟、成本与可靠性信号选择和重试候选。
路由的价值随着你接入的模型和供应商数量增加而增长。只有一个模型时，没什么可路由的。但当你有十个模型、分布在四个供应商时，路由决策就能在每一个请求上显著影响成本、速度和可靠性。
候选路由的三类信号
Router One 受支持的候选路由可使用三类运行信号。这不代表每个请求都会自适应打分。
延迟
这个模型的响应速度有多快？延迟不仅因模型而异，同一模型在不同供应商之间也会有差异，而且全天会随负载波动。一个凌晨两点响应只需 200 毫秒的模型，到了高峰时段可能需要 2 秒。
已观测延迟可帮助区分当前负载下的模型-provider 线路。这对聊天机器人、自动补全、交互式 agent 等实时应用很重要，因为用户正在等待响应。
成本
这个请求要花多少钱？不同模型和供应商之间的定价差异巨大。同一个请求在小模型上可能只花 $0.001，在旗舰模型上可能要 $0.05——差了 50 倍。对于高流量的工作负载，这种差异会直接转化为每月数千美元的开支。
公示 token 定价提供了可比较的成本信号，可与延迟、可靠性一起考虑；Router One 不承诺最便宜的线路一定胜出。
可靠性
这条模型-provider 线路最近的尝试是否成功？已观测的成功与失败会形成可靠性信号，用于受支持的候选路由与符合条件的重试。
响应质量仍由应用在选择模型时负责。Router One 的公开路由合同不提供质量评分或用户可配置的质量权重。
EWMA 评分如何追踪延迟
静态的延迟基准对路由决策几乎没用，因为供应商性能一直在变化。你需要的是一个实时信号——它能适应当前状况，同时平滑掉单个请求的随机波动。
这正是 EWMA——指数加权移动平均（Exponentially Weighted Moving Average）——所提供的。
EWMA 计算观测延迟的滚动平均值，其中近期的测量值权重更高。公式很直观：
EWMA_new = alpha * latency_observed + (1 - alpha) * EWMA_previous
Router One 使用 alpha=0.20。指标按模型和 provider 作为 key，并在 15 分钟后过期，避免旧观测无限期保持权威；它不是固定的最近 50 个请求窗口。
当受支持的候选路由路径生效时，当前 EWMA 观测可帮助比较可用的模型-provider 线路。精确模型请求仍遵循默认 model_name 策略，不会自动在全部模型间重新打分。
这种方式为候选路由提供近期延迟信号，同时允许陈旧记录过期。
默认路由与候选路由模式
Router One 有意区分精确模型选择和自适应候选路由：
- 默认
model_name策略 —— 标准 OpenAI 兼容请求里的模型 id 就是模型选择合同。 model="auto"路由 —— 网关管理候选集，可比较延迟、公示成本与可靠性，并在全局 auto-route 重试预算内处理符合条件的失败。
公开合同不提供项目级或 API Key 级的延迟/成本/质量权重、质量评分，也不要求请求体携带自定义 router 对象。不能因为内部存在路由信号，就推断这些控制能力已经公开。
自动故障转移：检测故障并重新路由
供应商宕机和服务降级不是小概率事件——它们经常发生。任何依赖单一供应商而没有故障转移的生产系统，都在承担不必要的停机风险。
Router One 的候选重试路径有三个相关边界：
可靠性信号。 已观测到的成功与失败可影响受支持的候选路由。Router One 不把“十秒内三个 500”之类固定规则作为用户可配置的公开合同。
候选重试。 当一次上游失败符合重试条件且仍有可用候选时，网关可按路由策略自动尝试该候选。
信号新鲜度。 延迟 EWMA 记录在 15 分钟后过期，并由新观测重建。公开合同不承诺特定的主动探测或渐进恢复算法。
Router One 如何实现智能路由
Router One 的路由引擎首先保持默认行为明确：生产环境使用 model_name 策略。精确模型请求因此保留模型选择，而不是自动在每个可用模型间自适应打分。
使用 model="auto" 时，引擎可比较模型-provider 的 EWMA 延迟、公示成本与可靠性，并在服务端候选集中处理符合条件的失败。这不代表存在质量评分或项目/API Key 权重控制。
每请求 Trace 会记录最终处理调用的线路，包括模型、provider、Token 用量、成本、延迟与状态；它不承诺展示每一次中间失败尝试的完整链路，也不虚构可配置的评分面板。
这让运维人员能查清实际发生了什么，同时让公开路由合同保持在内部实现能力以内。
开始更智能的路由
如果你仍把所有 LLM 流量发给单一 provider，受支持的候选路由可以降低这种依赖，同时保持精确模型请求可预期。
在 router.one 注册账号，保持标准 OpenAI 兼容请求结构，并用已文档化的路由模式与 Trace 在自己的工作负载上验证实际行为。