Routing intelligent : le fournisseur le moins cher qui est assez rapide pour votre prompt
Plusieurs fournisseurs vendent le même modèle, et le moins cher est souvent le plus lent sur les prompts longs. Ainsi, pour chaque requête, UberLLM vérifie à quelle vitesse chaque fournisseur commence à répondre pour cette taille de prompt et ce que cette requête coûterait sur chacun d'eux, garde les fournisseurs qui sont suffisamment rapides (à 2x du plus rapide, ou en moins de 1 seconde), et envoie la requête au moins cher d'entre eux. Il n'y a rien à configurer : cela s'exécute sur chaque requête de chat, sauf si vous passez vos propres options de routage.
Pourquoi le fournisseur le moins cher n'a pas suffi
Un modèle comme DeepSeek V4.1 Flash est vendu par plusieurs fournisseurs à des prix différents. Envoyer chaque requête au moins cher fonctionne pour les prompts courts. Cela pose problème sur les longs, car avant qu'un modèle n'écrive son premier mot, il doit lire l'intégralité du prompt, et certains fournisseurs lisent les prompts longs beaucoup plus lentement que d'autres.
Nous l'avons mesuré sur le trafic en direct le 28 octobre 2026. Sur DeepSeek V4.1 Flash, le fournisseur le moins cher a mis 15 secondes pour envoyer le premier mot pour des prompts de 32k–128k tokens, et 34 secondes au-delà de 128k. Un autre fournisseur a mis 1.5–2 secondes pour les mêmes prompts.
C'est ce qui compte le plus pour les agents de codage. Claude Code, Cline et les outils similaires envoient l'intégralité du contexte de travail à chaque tour, souvent 60k–130k tokens, et la majeure partie est une lecture de cache.
Le prix seul a également mené à de mauvais choix pour ces prompts. Le classement par le prix d'entrée normal ignorait le prix des lectures de cache, de sorte qu'un prompt long mis en cache pouvait être envoyé à un revendeur facturant $0.07 par million de tokens mis en cache alors qu'un autre fournisseur facturait $0.0013. Cet appel était plus lent et environ 50x plus cher.
Ce qui se passe à chaque requête
- Mesure de la vitesse par taille de prompt. UberLLM enregistre le temps jusqu'au premier token de chaque fournisseur pour chaque modèle, dans quatre groupes de taille : moins de 8k tokens, 8k–32k, 32k–128k et plus de 128k. Le même fournisseur a répondu à un prompt de 31 tokens en 1.7 secondes et à un prompt de 105k tokens en 15.5 secondes, donc un seul chiffre par fournisseur serait inexact. Les données proviennent d'appels réels. Des vérifications de vitesse distinctes toutes les 5 minutes, à environ 20k, 60k et 150k tokens, détectent un ralentissement à une taille donnée même lorsque les appels courts sont rapides.
- Tarification de cette requête exacte chez chaque fournisseur. L'input, l'input mis en cache et l'output sont tarifés séparément, en fonction du mélange de tokens de cette requête. Pour les prompts d'agent longs, le coût de lecture du cache représente généralement la majeure partie de la facture.
- Garder les fournisseurs suffisamment rapides. Un fournisseur est qualifié lorsque son temps typique jusqu'au premier token est à moins de 2x du fournisseur le plus rapide mesuré, ou inférieur à 1 seconde. La vitesse est jugée sur la médiane. Les valeurs aberrantes lentes comptent pour un quart de poids une fois qu'un fournisseur a au moins 10 échantillons, de sorte qu'un mauvais appel ne disqualifie pas un bon fournisseur.
- Envoyer la requête au moins cher d'entre eux. Le fournisseur le plus rapide ne l'emporte que si les moins chers sont trop lents.
- Maintenir les données à jour. 5% des requêtes sont envoyées à un fournisseur sur lequel nous avons trop peu de données, afin qu'un fournisseur devenu plus rapide soit remarqué. Un fournisseur qui refuse un appel est traité comme inutilisable et réessayé dans les 15 minutes.
Sans données de vitesse pour un modèle pour l'instant, la requête est envoyée au fournisseur disponible le moins cher. Un fournisseur dont le prix est supérieur au prix habituel du modèle n'est choisi pour sa vitesse que s'il est toujours au moins 50% en dessous du prix catalogue officiel du modèle.
Prompts longs : un fournisseur de secours quand le premier est lent
Même un fournisseur rapide démarre parfois lentement. Sur un prompt de 120k tokens mis en cache, le même fournisseur a démarré en 0.45, 3.7 et 8.5 secondes sur trois appels consécutifs. Choisir le bon fournisseur ne peut pas y remédier, c'est pourquoi les requêtes longues en streaming bénéficient d'une solution de secours :
- Prompts de 32k à 128k tokens : si aucun premier mot n'est arrivé après 1 seconde, la même requête est également envoyée à un autre fournisseur rapide.
- Prompts de plus de 128k tokens : les deux requêtes démarrent simultanément.
- Le premier fournisseur à répondre diffuse la réponse en streaming. L'autre requête est annulée dès l'arrivée du premier mot.
Vous recevez une seule réponse et ne payez que pour une seule réponse. Nous payons pour la requête annulée, à partir d'un budget quotidien fixe. Lorsque ce budget est épuisé, les requêtes longues sont envoyées à un seul fournisseur jusqu'au lendemain (UTC).
Les réessais sont dirigés vers un autre fournisseur
Si un appel échoue avant qu'une partie de la réponse ne vous parvienne, UberLLM le relance via un autre chemin, jusqu'à 4 tentatives. Avant le routage intelligent, une nouvelle tentative pouvait retomber sur le même fournisseur lent. Un appel qui échoue à chaque tentative coûte $0. Les détails sont dans modèles et routage.
Résultats sur le trafic en direct
DeepSeek V4.1 Flash, temps avant le premier mot :
| Taille du prompt | Avant | Après |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Plus de 128k tokens | 40 s | 3.4 s |
Sur les appels en streaming de plus de 32k tokens (28 octobre 2026), les 10% les plus lents des appels sont passés de 57 secondes à 8.7 secondes. Le coût de 1,000 de ces appels est passé de $2.49 à $1.04, car les prix de lecture du cache sont désormais pris en compte dans le choix. Le 29 octobre, un prompt de 203k tokens a commencé à répondre en environ 4 secondes.
Une limite : aucun fournisseur ne démarre un prompt de 100k tokens instantanément. Cela prend quelques secondes chez tous. Le routage intelligent supprime l'attente supplémentaire des fournisseurs lents. Il ne peut pas supprimer le temps dont un fournisseur rapide a besoin pour lire le prompt.
Ce que vous payez
Chaque requête est facturée au prix facturé par le fournisseur qui l'a traitée, sans aucun frais UberLLM ajouté. Chaque appel et son coût sont listés dans Tableau de bord → Activité. Pour plafonner le prix, envoyez provider.max_price avec prompt et completion. Le routage intelligent ne sélectionne alors que les fournisseurs en dessous de votre plafond, et une requête n'est jamais facturée au-delà.
Utiliser votre propre routage à la place
Vous n'avez rien à changer pour obtenir le routage intelligent. Si vous nommez des fournisseurs dans provider.only, provider.ignore ou provider.order, définissez provider.sort, ou ajoutez un suffixe :floor ou :nitro à l'ID du modèle, votre choix est utilisé et le routage intelligent ne s'exécute pas pour cette requête :
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_price est l'exception : il fonctionne avec le routage intelligent. Toutes les options sont listées dans modèles et routage.