Deriva del provider: come il routing predefinito fa aumentare i costi degli LLM

Hai attivato il prompt caching. Il contatore degli hit ogni tanto sale, ma la fattura è rimasta quasi invariata. Prima di dare la colpa alla struttura del prompt, controlla un dato che la dashboard non mostra: quale upstream ha effettivamente gestito ogni richiesta.

I gateway multi-provider distribuiscono uno stesso modello tra diversi provider upstream, scegliendone uno per ogni richiesta. Le prompt cache sono separate per provider, e spesso anche per nodo all’interno dello stesso provider. Se una seconda richiesta identica finisce su un upstream diverso dal primo, avrai un cache miss anche se il prompt non è cambiato di un solo byte. Questo fenomeno è il provider drift e, con una tariffazione per token, moltiplica i costi senza farsi notare.

TL;DR

• Con il routing predefinito, un gateway multi-provider ha distribuito 20 chiamate identiche tra 9 upstream, ottenendo solo 4 cache hit su 20.
• Un gateway con un solo backend ha ottenuto 19/20 sullo stesso workload. A causa del drift, il test è costato circa 3.9x in più ($0.0102 contro $0.0026).
• Sul modello della famiglia DeepSeek usato nel test, un cache miss è costato circa 4x rispetto a un hit ($0.00062 contro $0.00015 come mediana per chiamata).
• Il drift dipende dal modello: lo stesso gateway ha instradato un modello di classe GPT verso un solo upstream per tutte e 20 le chiamate, ottenendo 19/20.

Le due condizioni che lo attivano

Non è una configurazione errata che hai scelto di adottare. È il comportamento predefinito:

1. Routing automatico predefinito. La richiesta viene inviata al modello senza fissare un upstream, quindi il gateway ne sceglie uno a ogni chiamata.
2. Ordinamento predefinito dei provider = “default (balanced)”. Il gateway bilancia il carico tra gli upstream disponibili, invece di usare sempre lo stesso.

Entrambe sono impostazioni di fabbrica. Il drift si verifica senza modificare nulla; per evitarlo devi intervenire sulla configurazione.

Come appaiono 20 richieste identiche

Abbiamo inviato per 20 volte consecutive lo stesso prefisso di circa 8K token a un noto gateway multi-provider, usando le impostazioni predefinite indicate sopra. Per ogni richiesta abbiamo recuperato i campi relativi al provider e alla cache riportati dall’upstream. Con un modello della famiglia DeepSeek dotato di cache su disco:

• Le 20 chiamate sono state gestite da 9 upstream distinti: N***a, S***w, M***h, D***a, A***L, P***l, S***e, V***e, A***d.
• Cache hit rate: 4/20 (20%). Si è verificato un hit solo quando la richiesta è finita per caso su un upstream che aveva già memorizzato il prefisso nella cache.

Eseguendo le stesse 20 chiamate su un gateway con un solo backend (un modello, un upstream, nessun bilanciamento), l’hit rate è stato 19/20 (95%). Modello, prompt e numero di chiamate erano identici. L’unica variabile era la presenza o meno del drift nel routing.

Come confronto, sullo stesso gateway multi-provider un modello di classe GPT è stato instradato verso un solo upstream (A***e) per tutte e 20 le chiamate, ottenendo 19/20. Il drift non è uniforme: colpisce i modelli che il gateway decide di distribuire. In questo test è toccato al modello della famiglia DeepSeek.

Conclusione A: il costo previsto e quello effettivo

Sul modello soggetto a drift, il costo per chiamata si divideva nettamente in base all’esito della cache:

Su questo modello, un miss costa circa 4x rispetto a un hit. Considerando solo i token di input, la differenza pubblicata è ancora maggiore, circa 50x. Vediamo ora il totale sulle 20 chiamate:

Stesso modello, stesso prompt, stesse 20 richieste. Il provider drift ha fatto costare il test ~3.9x in più. Il caching è rimasto attivo per tutto il tempo, ma il livello di routing ha addebitato la maggior parte dei token alla tariffa prevista per i miss. Su un endpoint di produzione che riutilizza per tutto il giorno un prefisso lungo e stabile, questa differenza rappresenta gran parte della spesa per i token di input.

Conclusione B: senza cache si perde anche il vantaggio sulla latenza

Il caching non serve solo a ridurre i costi. Con il prefill già in cache, il primo token arriva prima. Quando il drift rende la cache irraggiungibile, perdi anche questo vantaggio. Abbiamo misurato il time-to-first-token (TTFT) su chiamate identiche ripetute:

Modello di classe GPT (instradato sempre verso lo stesso upstream, cache raggiungibile):

Il caching riduce di circa il 36% il tempo necessario per ricevere il primo token, con risultati stabili: tutte le chiamate warm rientrano in un intervallo ristretto.

Modello della famiglia DeepSeek (drift predefinito, cache raramente raggiungibile):

• Cache hit su 10 chiamate ripetute: 0.
• Il TTFT variava da ~1000 ms a ~4500 ms tra una chiamata e l’altra, con occasionali risposte vuote.

Poiché quasi ogni richiesta raggiunge un upstream nuovo, la latenza resta quella del prefill cold e si aggiunge la variabilità del provider che risponde. Grazie a una cache raggiungibile, il modello GPT ha migliorato il TTFT del 36%. Il modello soggetto a drift non ha ottenuto alcun miglioramento e ha mostrato una differenza di 4.5x tra la chiamata più veloce e quella più lenta.

Verifica la tua configurazione in cinque minuti

Non fidarti di questi numeri, né di quelli di altri. Invia più volte lo stesso prefisso lungo e controlla due campi. Non ci sono domini hardcoded: configura il tuo gateway tramite le variabili d’ambiente.

import os, uuid
from openai import OpenAI

client = OpenAI(api_key=os.environ["GW_KEY"], base_url=os.environ["GW_BASE"])
SYS = f"[probe {uuid.uuid4().hex}]\n\n" + ("You are a support assistant. " * 300)

seen, hits = {}, 0
for i in range(20):
    r = client.chat.completions.create(
        model=os.environ["GW_MODEL"], max_tokens=16,
        messages=[{"role": "system", "content": SYS},
                  {"role": "user", "content": f"q{i}"}],
        extra_body={"usage": {"include": True}})
    d = r.model_dump()
    det = r.usage.prompt_tokens_details
    cached = (getattr(det, "cached_tokens", 0) or 0) if det else 0
    seen[d.get("provider")] = seen.get(d.get("provider"), 0) + 1   # populated when exposed
    hits += 1 if cached else 0

print(f"hit rate {hits}/20; upstreams seen: {len(seen)}")

Se lo stesso modello usa più di un upstream, c’è drift. Se l’hit rate è molto più basso rispetto alla stabilità del prompt, il drift ti sta facendo spendere di più. Il metodo completo è descritto in Il tuo gateway LLM mente sulla cache?.

Cosa controllare

La soluzione al drift è strutturale: instrada un determinato modello verso un backend stabile, in modo che la cache warm sia raggiungibile alla richiesta successiva. Evita di bilanciare ogni chiamata verso un upstream nuovo che non ha mai visto il tuo prefisso. Quando valuti un gateway, invia lo stesso prefisso 20 volte e conta gli upstream. Il risultato desiderato è uno. Nove sono un costo aggiuntivo.

Il prompt caching è best-effort ovunque. Sui modelli con cache su disco, l’hit rate può comunque calare dopo lunghi periodi di inattività, anche usando un solo backend. Eliminare il drift non rende la cache infinita. Rimuove però la causa di miss più rilevante e costosa: quella che non hai scelto e che non puoi vedere.

Conclusione

“Supporta il prompt caching” e “la cache è raggiungibile” sono due affermazioni diverse. Un gateway che distribuisce un modello tra upstream sempre diversi può dichiarare correttamente il supporto alla cache, ma produrre comunque un hit rate del 20%, una fattura ~4x più alta e una latenza del primo token che varia di 4.5x. Non basta controllare se il caching è dichiarato. Devi misurare l’hit rate e il numero di upstream raggiunti da richieste identiche. Esegui il test e lascia decidere ai dati.

Per il metodo di verifica completo, consulta Il tuo gateway LLM mente sulla cache?. Per capire perché esistono le cache, leggi Come funzionano KV Cache e TTL.

Domande frequenti

È una configurazione errata da parte mia? No. Succede con le impostazioni di fabbrica: routing automatico e ordinamento dei provider impostato su “default (balanced).” Per evitare il drift devi fissare esplicitamente un upstream, non il contrario.

Fissare un solo upstream risolve il problema? Elimina il drift tra provider, ma spesso un singolo upstream usa più repliche senza affinità per il prefisso. Gli hit possono quindi continuare ad alternarsi ai miss. Dopo aver fissato l’upstream, misura i risultati invece di darli per scontati.

Perché il modello di classe GPT non ha subito drift? In questo test, il gateway lo ha instradato per caso verso un solo upstream. Il drift dipende dal modello e dal numero di upstream disponibili tra cui il gateway bilancia il traffico; non è uniforme.

La differenza di costo è davvero ~4x? Nei costi totali per chiamata che abbiamo misurato, un miss è costato ~4x rispetto a un hit. Nei prezzi pubblicati per i soli token di input di questa classe di modelli, la differenza tra hit e miss è più vicina a 50x. In entrambi i casi, la spesa deriva dalla trasformazione degli hit previsti in miss.

Qual è la singola metrica da monitorare? L’hit rate della cache per modello nel tempo, insieme al numero di upstream distinti usati da ogni modello. Se l’hit rate scende o il numero di upstream aumenta, il costo effettivo per token è appena salito.

← Torna al blog