Ogni provider ti fornisce una chiave. Dopo la terza, le chiavi smettono di essere una comodità e iniziano a essere un sistema che devi costruire e mantenere. Hai N provider, ognuno con il proprio base URL, il proprio header di autenticazione, la propria semantica di rate limit, i propri codici di errore, la propria pagina di fatturazione. Nel momento in cui vuoi instradare una richiesta verso "il miglior modello disponibile" invece che verso "quello che ho codificato in modo fisso", hai un problema di routing, ed è quello che un gateway risolve.
Il problema non è l'API, sono le operazioni
Le chiamate API grezze sono facili. È tutto ciò che ci sta attorno che si accumula:
•Dispersione delle credenziali. Una chiave per provider, ruotata con cadenze diverse, conservata in secret manager diversi.
•Rate limit. Ogni provider applica limiti in modo diverso, e le loro risposte di errore non sono coerenti, quindi la tua logica di retry deve gestire ogni caso come eccezione a sé.
•Visibilità dell'utilizzo. Ogni provider ha la propria dashboard. Nessun singolo posto mostra la spesa totale su tutti quanti.
•Failover. Se il provider A va giù, spostare il traffico sul provider B significa ridistribuire con una nuova chiave e un nuovo endpoint.
Niente di tutto questo è visibile in una demo. Si manifesta in produzione alle 2 del mattino, quando un provider è giù e la tua coda di retry si sta accumulando.
Cos'è davvero un gateway
Un gateway si posiziona tra la tua applicazione e i provider dei modelli. La tua app comunica con un solo endpoint usando una sola chiave. Il gateway gestisce autenticazione, routing, rate limiting, contabilizzazione dell'utilizzo e fallback. Per il tuo codice appare esattamente come una singola API LLM.
+------------------+
| Your app |
+--------+---------+
| one key, one base URL
v
+--------+---------+
| LLM gateway |
| auth / routing |
| rate limiting |
| usage metering |
+--+-----+----+----+
| | |
v v v
Provider A B C
(GPT-4o) (DeepSeek) (Qwen)La decisione progettuale importante è che il gateway parla il protocollo compatibile con OpenAI sul lato inbound. Questo significa che il tuo codice SDK esistente non ha bisogno di una nuova libreria client. Cambi il base URL e la chiave, e continui a scrivere normali chiamate chat.completions.create.
Una chiave, un endpoint, molti modelli
Ecco l'intera integrazione sul lato client:
from openai import OpenAI
client = OpenAI(
base_url="https://api.token8341.com/v1",
api_key="sk-one-key-for-everything",
)
for model in ["gpt-4o", "claude-3-5-sonnet", "deepseek-chat", "qwen-max"]:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": "Reply with the word 'ok'"}],
)
print(model, "->", resp.choices[0].message.content)La stessa chiave autorizza ogni modello del catalogo. Non devi predisporre quattro account né tenere traccia di quattro saldi. Paghi un'unica fattura a consumo, e l'utilizzo è suddiviso per modello così puoi vedere dove sono finiti davvero i token.
Il gateway trasforma anche il routing in una decisione di configurazione invece che in una modifica al codice. Vuoi un modello economico per la corsia ad alto volume e un modello di frontiera per la corsia difficile? È una mappatura in un unico posto:
ROUTES = {
"summarize": "deepseek-chat",
"reason": "qwen-max",
"frontier": "gpt-4o",
}E il fallback diventa un normale flusso di controllo invece di un'integrazione multi-vendor:
def call_with_fallback(prompt, primary, backup):
try:
return ask(primary, prompt)
except Exception:
return ask(backup, prompt)Quando ti serve un gateway e quando no
Un gateway è un sovraccarico che non dovresti assumerti se non ti serve. Se usi un solo provider e un solo modello e non hai requisiti di failover, una chiave diretta è più semplice e quella è la scelta giusta. Aggiungere un hop extra e un vendor extra sul percorso critico ha un costo.
Un gateway si guadagna il suo posto quando è vero almeno uno di questi punti:
•Usi due o più modelli e vuoi passare dall'uno all'altro liberamente.
•Ti serve il fallback quando un provider è giù o soggetto a rate limit.
•Vuoi un'unica fattura e un unico posto per vedere la spesa per modello.
•Vuoi fare A/B test dei modelli sul traffico live senza ridistribuire.
Se vale uno qualsiasi di questi, il risparmio operativo supera il costo dell'hop extra. La latenza effettivamente aggiunta da un gateway ben gestito è di pochi millisecondi, abbastanza piccola da sparire accanto al tempo di inferenza del modello.
Gestito o self-hosted?
Una decisione che vale la pena prendere deliberatamente è se eseguire un gateway proprio o affittarne uno. I router self-hosted come LiteLLM e one-api sono eccellenti e ti danno il pieno controllo su tabelle di routing, chiavi e logging. Ti danno anche un servizio da eseguire, monitorare, aggiornare e mantenere in alta disponibilità, che è esattamente il carico operativo che stavi cercando di eliminare.
Un gateway gestito inverte lo scambio. Rinunci al controllo sugli interni e guadagni il non doverli gestire: qualcun altro tiene su l'endpoint, ruota le chiavi upstream e assorbe le interruzioni dei provider. Per un team piccolo di solito è l'accordo giusto. Per un team più grande con un gruppo platform in organico, il self-hosting può valere la pena solo per l'auditabilità. In ogni caso, mantieni il contratto inbound compatibile con OpenAI così la scelta resta reversibile.
SiCore TokenWorks è costruito attorno a questa idea: una chiave API, un endpoint compatibile con OpenAI su https://api.token8341.com/v1, e un catalogo che copre GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, Spark e Pangu, con fatturazione a consumo e utilizzo suddiviso per modello.