Enrutamiento inteligente: el proveedor más barato que es lo suficientemente rápido para tu prompt
Varios proveedores venden el mismo modelo, y el más barato suele ser el más lento con prompts largos. Así que para cada solicitud, UberLLM comprueba la rapidez con la que cada proveedor empieza a responder para ese tamaño de prompt y cuánto costaría esa solicitud en cada uno, mantiene a los proveedores que son lo suficientemente rápidos (dentro de 2x del más rápido, o en menos de 1 segundo), y envía la solicitud al más barato de ellos. No hay nada que configurar: se ejecuta en cada solicitud de chat a menos que pases tus propias opciones de enrutamiento.
¿Por qué el proveedor más barato no fue lo suficientemente bueno?
Un modelo como DeepSeek V4.1 Flash es vendido por varios proveedores a diferentes precios. Enviar cada solicitud al más barato funciona para prompts cortos. Falla en los largos, porque antes de que un modelo escriba su primera palabra tiene que leer todo el prompt, y algunos proveedores leen prompts largos mucho más lento que otros.
Lo medimos en tráfico real el 28 de octubre de 2026. En DeepSeek V4.1 Flash, el proveedor más barato tardó 15 segundos en enviar la primera palabra para prompts de 32k–128k tokens, y 34 segundos por encima de 128k. Otro proveedor tardó 1.5–2 segundos para los mismos prompts.
Eso importa más para los agentes de codificación. Claude Code, Cline y herramientas similares envían todo el contexto de trabajo en cada turno, a menudo 60k–130k tokens, y la mayor parte es una lectura de caché.
El precio por sí solo también eligió mal en esos prompts. Clasificar por el precio de entrada normal ignoraba el precio de las lecturas de caché, así que un prompt largo en caché podría ir a un revendedor que cobra $0.07 por millón de tokens en caché cuando otro proveedor cobraba $0.0013. Esa llamada fue más lenta y aproximadamente 50x más cara.
Qué ocurre en cada solicitud
- Medir la velocidad por tamaño de prompt. UberLLM registra el tiempo hasta el primer token de cada proveedor para cada modelo, en cuatro grupos de tamaño: menos de 8k tokens, 8k–32k, 32k–128k y más de 128k. El mismo proveedor respondió a un prompt de 31 tokens en 1.7 segundos y a un prompt de 105k tokens en 15.5 segundos, por lo que un solo número por proveedor sería incorrecto. Los datos provienen de llamadas reales. Comprobaciones de velocidad separadas cada 5 minutos, con aproximadamente 20k, 60k y 150k tokens, detectan una ralentización en un tamaño incluso cuando las llamadas cortas son rápidas.
- Tarificar esta solicitud exacta en cada proveedor. El input, el input en caché y el output se tarifican por separado, según la combinación de tokens de esta solicitud. Para prompts de agente largos, el precio de lectura de caché suele ser la mayor parte de la factura.
- Mantener los proveedores que son lo suficientemente rápidos. Un proveedor califica cuando su tiempo típico hasta el primer token está dentro de 2x del proveedor medido más rápido, o por debajo de 1 segundo. La velocidad se juzga por la mediana. Los valores atípicos lentos cuentan con un cuarto de peso una vez que un proveedor tiene al menos 10 muestras, para que una mala llamada no descarte a un buen proveedor.
- Enviar la solicitud al más barato de ellos. El proveedor más rápido solo gana cuando los más baratos son demasiado lentos.
- Mantener los datos actualizados. 5% de las solicitudes van a un proveedor del que tenemos muy pocos datos, para que se detecte a un proveedor que se haya vuelto más rápido. Un proveedor que rechaza una llamada se considera inutilizable y se intenta de nuevo en 15 minutos.
Sin datos de velocidad para un modelo todavía, la solicitud va al proveedor disponible más barato. Un proveedor con un precio superior al precio habitual del modelo solo se elige por velocidad cuando aún está al menos 50% por debajo del precio de lista oficial del modelo.
Prompts largos: un segundo proveedor cuando el primero es lento
Incluso un proveedor rápido a veces empieza lento. En un prompt en caché de 120k tokens, el mismo proveedor tardó 0.45, 3.7 y 8.5 segundos en tres llamadas consecutivas. Elegir el proveedor adecuado no puede solucionar eso, por lo que las solicitudes largas con streaming obtienen un respaldo:
- Prompts de 32k–128k tokens: si no ha llegado la primera palabra después de 1 segundo, la misma solicitud también se envía a otro proveedor rápido.
- Prompts de más de 128k tokens: ambas solicitudes se inician a la vez.
- El primer proveedor en responder transmite la respuesta. La otra solicitud se cancela tan pronto como llega la primera palabra.
Obtienes una respuesta y pagas por una respuesta. Nosotros pagamos por la solicitud cancelada, de un presupuesto diario fijo. Cuando ese presupuesto se agota, las solicitudes largas van a un solo proveedor hasta el día siguiente (UTC).
Los reintentos van a otro proveedor
Si una llamada falla antes de que te llegue la respuesta, UberLLM la reintenta por otra ruta, hasta 4 intentos. Antes del enrutamiento inteligente, un reintento podría volver a caer en el mismo proveedor lento. Una llamada que falla en todos los intentos cuesta $0. Los detalles están en modelos y enrutamiento.
Resultados en tráfico real
DeepSeek V4.1 Flash, tiempo hasta la primera palabra:
| Tamaño del prompt | Antes | Después |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Más de 128k tokens | 40 s | 3.4 s |
En llamadas con streaming de más de 32k tokens (28 de octubre de 2026), el 10% más lento de las llamadas pasó de 57 segundos a 8.7 segundos. El costo de 1,000 de esas llamadas pasó de $2.49 a $1.04, porque los precios de lectura de caché ahora cuentan en la elección. El 29 de octubre, un prompt de 203k tokens empezó a responder en unos 4 segundos.
Una limitación: ningún proveedor inicia un prompt de 100k tokens al instante. Tarda unos segundos en todos ellos. El enrutamiento inteligente elimina la espera adicional de los proveedores lentos. No puede eliminar el tiempo que un proveedor rápido necesita para leer el prompt.
Lo que pagas
Cada solicitud se factura según lo que cobró el proveedor que la atendió, sin añadir ninguna comisión de UberLLM. Cada llamada y su coste se lista en Dashboard → Activity. Para limitar el precio, envía provider.max_price con prompt y completion. El enrutamiento inteligente entonces solo elige proveedores por debajo de tu límite, y una solicitud nunca se factura por encima de este.
Usando tu propio enrutamiento en su lugar
No necesitas cambiar nada para obtener enrutamiento inteligente. Si nombras proveedores en provider.only, provider.ignore o provider.order, estableces provider.sort, o añades un sufijo :floor o :nitro al ID del modelo, se usa tu elección y el enrutamiento inteligente no se ejecuta para esa solicitud:
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_price es la excepción: funciona junto con el enrutamiento inteligente. Todas las opciones se enumeran en modelos y enrutamiento.