Routing intelligente: il provider più economico e abbastanza veloce per il tuo prompt
Diversi provider vendono lo stesso modello, e il più economico è spesso il più lento con prompt lunghi. Quindi per ogni richiesta UberLLM verifica quanto velocemente ogni provider inizia a rispondere per quella dimensione di prompt e quanto costerebbe quella richiesta su ciascuno, mantiene i provider che sono abbastanza veloci (entro 2x dal più veloce, o sotto 1 secondo), e invia la richiesta al più economico tra questi. Non c'è nulla da impostare: funziona su ogni richiesta di chat a meno che tu non passi le tue opzioni di routing.
Perché il provider più economico non era abbastanza buono
Un modello come DeepSeek V4.1 Flash è venduto da diversi provider a prezzi diversi. Inviare ogni richiesta a quello più economico funziona per i prompt brevi. Si blocca su quelli lunghi, perché prima che un modello scriva la sua prima parola deve leggere l'intero prompt, e alcuni provider leggono i prompt lunghi molto più lentamente di altri.
Lo abbiamo misurato sul traffico live il 28 ottobre 2026. Su DeepSeek V4.1 Flash, il provider più economico ha impiegato 15 secondi per inviare la prima parola per prompt di 32k–128k token, e 34 secondi sopra i 128k. Un altro provider ha impiegato 1.5–2 secondi per gli stessi prompt.
Questo è particolarmente importante per gli agenti di codifica. Claude Code, Cline e strumenti simili inviano l'intero contesto di lavoro ad ogni turno, spesso 60k–130k token, e la maggior parte di essi è una lettura della cache.
Il solo prezzo ha anche selezionato male quei prompt. Classificare in base al prezzo di input normale ignorava il prezzo delle letture della cache, quindi un prompt lungo in cache poteva andare a un rivenditore che addebitava $0.07 per milione di token in cache quando un altro provider addebitava $0.0013. Quella chiamata era più lenta e circa 50x più costosa.
Cosa succede ad ogni richiesta
- Misuriamo la velocità in base alla dimensione del prompt. UberLLM registra il tempo al primo token di ogni provider per ogni modello, in quattro gruppi di dimensioni: sotto i 8k token, 8k–32k, 32k–128k e oltre 128k. Lo stesso provider ha risposto a un prompt di 31 token in 1.7 secondi e a un prompt di 105k token in 15.5 secondi, quindi un solo numero per provider sarebbe sbagliato. I dati provengono da chiamate reali. Controlli di velocità separati ogni 5 minuti a circa 20k, 60k e 150k token rilevano un rallentamento a una certa dimensione anche quando le chiamate brevi sono veloci.
- Prezziamo questa richiesta esatta su ogni provider. Input, input in cache e output sono prezzati separatamente, in base al mix di token di questa richiesta. Per prompt di agent lunghi, il prezzo di lettura della cache è solitamente la maggior parte del costo.
- Manteniamo i provider che sono abbastanza veloci. Un provider si qualifica quando il suo tempo tipico al primo token rientra in 2x rispetto al provider più veloce misurato, o è inferiore a 1 secondo. La velocità è giudicata sulla mediana. Gli outlier lenti contano con un peso di un quarto una volta che un provider ha almeno 10 campioni, quindi una singola chiamata negativa non esclude un buon provider.
- Inviamo la richiesta al più economico tra questi. Il provider più veloce vince solo quando quelli più economici sono troppo lenti.
- Manteniamo i dati aggiornati. Il 5% delle richieste va a un provider su cui abbiamo troppi pochi dati, così un provider che è diventato più veloce viene notato. Un provider che rifiuta una chiamata viene trattato come inutilizzabile e riprovato entro 15 minuti.
Senza dati di velocità per un modello, la richiesta va al provider più economico disponibile. Un provider con un prezzo superiore al prezzo abituale del modello viene scelto per la velocità solo quando è ancora almeno 50% al di sotto del prezzo di listino ufficiale del modello.
Prompt lunghi: un secondo provider quando il primo è lento
Anche un provider veloce a volte parte lentamente. Su un prompt con 120k token in cache, lo stesso provider è partito in 0.45, 3.7 e 8.5 secondi su tre chiamate consecutive. Scegliere il provider giusto non può risolvere il problema, quindi le richieste lunghe in streaming ottengono un backup:
- Prompt da 32k a 128k token: se nessuna prima parola è arrivata dopo 1 secondo, la stessa richiesta va anche a un provider veloce diverso.
- Prompt oltre 128k token: entrambe le richieste partono contemporaneamente.
- Il primo provider a rispondere trasmette la risposta in streaming. L'altra richiesta viene annullata non appena arriva la prima parola.
Ricevi una risposta e paghi per una risposta. Paghiamo noi per la richiesta annullata, attingendo a un budget giornaliero fisso. Quando quel budget si esaurisce, le richieste lunghe vanno a un solo provider fino al giorno successivo (UTC).
I tentativi vanno a un provider diverso
Se una chiamata fallisce prima che una qualsiasi parte della risposta ti raggiunga, UberLLM la ritenta su un'altra rotta, fino a 4 tentativi. Prima dello smart routing, un tentativo potrebbe finire di nuovo sullo stesso provider lento. Una chiamata che fallisce ad ogni tentativo costa $0. I dettagli sono in modelli e routing.
Risultati sul traffico live
DeepSeek V4.1 Flash, tempo alla prima parola:
| Dimensione del prompt | Prima | Dopo |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Oltre 128k tokens | 40 s | 3.4 s |
Sulle chiamate in streaming oltre 32k tokens (28 ottobre 2026), il 10% più lento delle chiamate è passato da 57 secondi a 8.7 secondi. Il costo del 1,000 di quelle chiamate è passato da $2.49 a $1.04, perché i prezzi di lettura della cache ora contano nella scelta. Il 29 ottobre un prompt da 203k tokens ha iniziato a rispondere in circa 4 secondi.
Un limite: nessun provider avvia un prompt da 100k tokens istantaneamente. Ci vogliono alcuni secondi su tutti. Lo smart routing rimuove l'attesa extra dai provider lenti. Non può rimuovere il tempo di cui un provider veloce ha bisogno per leggere il prompt.
Cosa paghi
Ogni richiesta viene fatturata al costo addebitato dal provider che l'ha gestita, senza alcuna commissione UberLLM aggiunta. Ogni chiamata e il suo costo sono elencati in Dashboard → Activity. Per limitare il prezzo, invia provider.max_price con entrambi prompt e completion. Smart routing quindi seleziona solo i provider al di sotto del tuo limite massimo, e una richiesta non viene mai fatturata al di sopra di esso.
Usare il proprio routing invece
Non è necessario cambiare nulla per ottenere lo smart routing. Se nomini i fornitori in provider.only, provider.ignore o provider.order, imposti provider.sort, o aggiungi un suffisso :floor o :nitro all'ID del modello, la tua scelta viene utilizzata e lo smart routing non viene eseguito per quella richiesta:
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_price è l'eccezione: funziona insieme allo smart routing. Tutte le opzioni sono elencate in modelli e routing.