智能路由：足够快以响应您的 prompt 的最便宜提供商
多个提供商销售相同的模型，而最便宜的提供商在长提示下通常最慢。因此，对于每个请求，UberLLM都会检查每个提供商在该提示大小下开始响应的速度，以及该请求在每个提供商上的成本，然后保留足够快的提供商（在最快速度的2x范围内，或低于1秒），并将请求发送给其中最便宜的。无需设置：它在每个聊天请求上运行，除非您传递自己的路由选项。
为什么最便宜的提供商不够好
像 DeepSeek V4.1 Flash 这样的模型由多家提供商以不同价格销售。将每个请求发送给最便宜的提供商对短提示有效。但对长提示则会失效，因为在模型写出第一个词之前，它必须读取整个提示，而有些提供商读取长提示的速度比其他提供商慢得多。
我们在 2026年10月28日 的实时流量上进行了测量。在 DeepSeek V4.1 Flash 上，最便宜的提供商对于 32k–128k token 的提示，发送第一个词需要 15 秒，对于超过 128k token 的提示则需要 34 秒。另一家提供商对于相同的提示则需要 1.5–2 秒。
这对编码代理（coding agents）来说最为重要。Claude Code、Cline 和类似工具在每次交互时都会发送整个工作上下文（working context），通常是 60k–130k token，其中大部分是缓存读取（cache read）。
仅凭价格选择在这些提示上也表现不佳。按照正常输入价格排名忽略了缓存读取（cache reads）的价格，因此一个长的缓存提示可能会发送给一个每百万缓存 token 收费 $0.07 的经销商，而另一家提供商只收取 $0.0013。这次调用更慢，并且贵了大约 50x。
每次请求会发生什么
- 按提示词大小衡量速度。 UberLLM 记录每个提供商的每个模型从接收到第一个 token 的时间，分为四种大小组别：低于 8k 个 token，8k–32k 个 token，32k–128k 个 token 以及超过 128k 个 token。同一个提供商在 1.7 秒内响应了 31 个 token 的提示词，而在 15.5 秒内响应了 105k 个 token 的提示词，因此每个提供商只用一个数字来衡量是不准确的。这些数据来自真实的调用。每 5 分钟进行一次独立的速度检查，针对大约 20k、60k 和 150k 个 token 的提示词，即使短调用很快，也能发现某个大小的减速情况。
- 对每个提供商的此精确请求进行定价。 输入、缓存输入和输出根据此请求的 token 组合分别定价。对于长代理提示词，缓存读取价格通常占账单的大部分。
- 保留速度足够快的提供商。 当提供商的典型首个 token 响应时间在最快测量提供商的 2x 范围内，或低于 1 秒时，该提供商即符合条件。速度以中位数判断。一旦提供商有至少 10 个样本，慢速异常值将按四分之一权重计算，因此一次糟糕的调用不会将一个好的提供商排除在外。
- 将请求发送给其中最便宜的提供商。 只有当更便宜的提供商太慢时，最快的提供商才会胜出。
- 保持数据最新。 5% 的请求会发送给数据不足的提供商，这样就能发现速度变快的提供商。拒绝调用的提供商将被视为不可用，并在 15 分钟内再次尝试。
如果模型尚无速度数据，请求将发送给最便宜的可用提供商。价格高于模型通常价格的提供商，只有当其价格仍比模型的官方标价低至少 50% 时，才会因速度而被选中。
长提示词：当第一个响应慢时，启用第二个提供商
即使是快速的提供商，有时也会启动缓慢。对于一个缓存的 120k token 提示词，同一个提供商在连续三次调用中分别在 0.45、3.7 和 8.5 秒内启动。选择正确的提供商无法解决这个问题，因此，长时间的流式请求会有一个备用方案：
- 32k–128k token 的提示词： 如果 1 秒后仍未收到第一个词，同样的请求也会发送给另一个快速提供商。
- 超过 128k token 的提示词： 两个请求同时开始。
- 第一个响应的提供商会流式传输回复。一旦收到第一个词，另一个请求就会被取消。
您收到一份回复，并支付一份回复的费用。我们会从固定的每日预算中支付被取消请求的费用。当预算用尽时，长请求将只发送给一个提供商，直到第二天（UTC）。
重试会转向不同的提供商
如果调用在收到任何回复之前失败，UberLLM 会在另一条路由上重试，最多 4 次。在智能路由之前，重试可能会再次落在同一个缓慢的提供商上。每次尝试都失败的调用费用为 $0。详细信息请参见 models and routing。
实时流量结果
DeepSeek V4.1 Flash，首字响应时间：
| 提示词大小 | 之前 | 之后 |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Over 128k tokens | 40 s | 3.4 s |
对于超过 32k token 的流式调用 (2026年10月28日)，最慢的 10% 的调用从 57 秒降至 8.7 秒。其中 1,000 的调用成本从 $2.49 降至 $1.04，因为缓存读取价格现在计入选择考量。在 10 月 29 日，一个 203k token 的提示词在大约 4 秒内开始响应。
一个限制是：没有提供商能立即开始处理一个 100k token 的提示词。所有提供商都需要几秒钟时间。智能路由消除了慢速提供商的额外等待时间，但它无法消除快速提供商读取提示词所需的时间。
您支付的费用
每个请求都按提供该请求的服务商所收取的费用计费，不额外收取 UberLLM 费用。每次调用及其费用都列在 Dashboard → Activity 中。要设置价格上限，请发送 provider.max_price，并附带 prompt 和 completion。智能路由将只选择低于您上限的提供商，并且请求的计费绝不会超出该上限。
使用您自己的路由
您无需进行任何更改即可获得智能路由。如果您在 provider.only、provider.ignore 或 provider.order 中指定提供商，设置 provider.sort，或在 model id 后添加 :floor 或 :nitro 后缀，您的选择将被使用，并且智能路由不会对该请求运行：
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_price 是一个例外：它与智能路由协同工作。所有选项都列在 models and routing 中。