Roteamento inteligente: o provedor mais barato que é rápido o suficiente para o seu prompt
Vários provedores vendem o mesmo modelo, e o mais barato é frequentemente o mais lento em prompts longos. Então, para cada requisição, o UberLLM verifica a velocidade com que cada provedor começa a responder para aquele tamanho de prompt e qual seria o custo dessa requisição em cada um, mantém os provedores que são rápidos o suficiente (dentro de 2x do mais rápido, ou em menos de 1 segundo), e envia a requisição para o mais barato dentre eles. Não há nada para configurar: ele funciona em toda requisição de chat, a menos que você passe suas próprias opções de roteamento.
Por que o provedor mais barato não era bom o suficiente
Um modelo como DeepSeek V4.1 Flash é vendido por vários provedores a preços diferentes. Enviar cada requisição para o mais barato funciona para prompts curtos. Ele falha em prompts longos, porque antes de um modelo escrever sua primeira palavra, ele precisa ler o prompt inteiro, e alguns provedores leem prompts longos muito mais lentamente do que outros.
Nós medimos isso no tráfego ao vivo em 28 de outubro de 2026. No DeepSeek V4.1 Flash, o provedor mais barato levou 15 segundos para enviar a primeira palavra para prompts de 32k–128k tokens, e 34 segundos acima de 128k. Outro provedor levou 1.5–2 segundos para os mesmos prompts.
Isso importa mais para agentes de codificação. Claude Code, Cline e ferramentas semelhantes enviam todo o contexto de trabalho a cada turno, frequentemente 60k–130k tokens, e a maior parte é uma leitura de cache.
O preço sozinho também escolheu mal nesses prompts. A classificação pelo preço de entrada normal ignorou o preço das leituras de cache, então um prompt longo em cache poderia ir para um revendedor cobrando $0.07 por milhão de tokens em cache quando outro provedor cobrava $0.0013. Essa chamada foi mais lenta e cerca de 50x mais cara.
O que acontece em cada requisição
- Medir a velocidade pelo tamanho do prompt. UberLLM registra o tempo até o primeiro token de cada provedor para cada modelo, em quatro grupos de tamanho: abaixo de 8k tokens, 8k–32k, 32k–128k e acima de 128k. O mesmo provedor respondeu a um prompt de 31 tokens em 1.7 segundos e a um prompt de 105k tokens em 15.5 segundos, então um único número por provedor estaria errado. Os dados vêm de chamadas reais. Verificações de velocidade separadas a cada 5 minutos, com cerca de 20k, 60k e 150k tokens, detectam uma desaceleração em um determinado tamanho, mesmo quando chamadas curtas são rápidas.
- Precificar esta requisição exata em cada provedor. Input, cached input e output são precificados separadamente, com base na combinação de tokens desta requisição. Para prompts de agente longos, o preço da leitura do cache geralmente representa a maior parte da conta.
- Manter os provedores que são rápidos o suficiente. Um provedor se qualifica quando seu tempo típico até o primeiro token está dentro de 2x do provedor mais rápido medido, ou abaixo de 1 segundo. A velocidade é julgada pela mediana. Outliers lentos contam com um quarto do peso, uma vez que o provedor tenha pelo menos 10 amostras, para que uma chamada ruim não exclua um bom provedor.
- Enviar a requisição para o mais barato dentre eles. O provedor mais rápido só vence quando os mais baratos são muito lentos.
- Manter os dados atualizados. 5% das requisições vão para um provedor sobre o qual temos poucos dados, para que um provedor que ficou mais rápido seja notado. Um provedor que recusa uma chamada é tratado como inutilizável e tentado novamente dentro de 15 minutos.
Sem dados de velocidade para um modelo ainda, a requisição vai para o provedor mais barato disponível. Um provedor com preço acima do preço usual do modelo é escolhido por velocidade apenas quando ainda está pelo menos 50% abaixo do preço de tabela oficial do modelo.
Prompts longos: um segundo provedor quando o primeiro está lento
Mesmo um provedor rápido às vezes inicia lentamente. Para um prompt de 120k tokens em cache, o mesmo provedor iniciou em 0.45, 3.7 e 8.5 segundos em três chamadas consecutivas. Escolher o provedor certo não resolve isso, portanto, requisições longas com streaming recebem um backup:
- Prompts de 32k–128k tokens: se nenhuma primeira palavra chegou após 1 segundo, a mesma requisição também vai para um provedor rápido diferente.
- Prompts acima de 128k tokens: ambas as requisições iniciam ao mesmo tempo.
- O primeiro provedor a responder transmite a resposta. A outra requisição é cancelada assim que a primeira palavra chega.
Você recebe uma resposta e paga por uma resposta. Nós pagamos pela requisição cancelada, a partir de um orçamento diário fixo. Quando esse orçamento acaba, requisições longas são direcionadas a um provedor até o próximo dia (UTC).
Tentativas vão para um provedor diferente
Se uma chamada falhar antes que qualquer parte da resposta chegue até você, UberLLM a retenta em outra rota, até 4 tentativas. Antes do roteamento inteligente, uma retentativa poderia cair no mesmo provedor lento novamente. Uma chamada que falha em todas as tentativas custa $0. Os detalhes estão em modelos e roteamento.
Resultados no tráfego ao vivo
DeepSeek V4.1 Flash, tempo até a primeira palavra:
| Tamanho do prompt | Antes | Depois |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Mais de 128k tokens | 40 s | 3.4 s |
Em chamadas com streaming de mais de 32k tokens (28 de outubro de 2026), os 10% mais lentos das chamadas passaram de 57 segundos para 8.7 segundos. O custo de 1,000 dessas chamadas passou de $2.49 para $1.04, porque os preços de leitura de cache agora contam na escolha. Em 29 de outubro, um prompt de 203k tokens começou a responder em cerca de 4 segundos.
Um limite: nenhum provedor inicia um prompt de 100k tokens instantaneamente. Leva alguns segundos em todos eles. O roteamento inteligente remove a espera extra dos provedores lentos. Não pode remover o tempo que um provedor rápido precisa para ler o prompt.
O que você paga
Cada requisição é cobrada pelo que o provedor que a atendeu cobrou, sem nenhuma taxa UberLLM adicionada. Cada chamada e seu custo estão listados em Painel → Atividade. Para limitar o preço, envie provider.max_price com prompt e completion. Smart routing então seleciona apenas provedores abaixo do seu limite, e uma requisição nunca é cobrada acima dele.
Usando seu próprio roteamento em vez disso
Você não precisa mudar nada para ter o roteamento inteligente. Se você nomear provedores em provider.only, provider.ignore ou provider.order, definir provider.sort, ou adicionar um sufixo :floor ou :nitro ao ID do modelo, sua escolha será usada e o roteamento inteligente não será executado para essa requisição:
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_price é a exceção: ele funciona em conjunto com o roteamento inteligente. Todas as opções estão listadas em modelos e roteamento.