LiteLLM vs OpenRouter: costi, controllo e failover

Scegliere un gateway per gli LLM non dipende tanto dal fatto che LiteLLM e OpenRouter espongano un’API in stile OpenAI, quanto da chi gestisce il livello di routing. OpenRouter è il punto di partenza più semplice se il team non gestisce già un’infrastruttura gateway in produzione; LiteLLM giustifica il lavoro aggiuntivo quando networking privato, policy personalizzate o un utilizzo intenso rendono utile investire in controllo e gestione interna.

Non è una gara sul formato delle API: è una scelta operativa

LiteLLM è un software open source che può essere eseguito come SDK Python oppure come proxy self-hosted. OpenRouter è invece un’API gestita e un catalogo di modelli: gestisce il gateway, aggrega l’accesso ai provider e offre un unico account per utilizzare i modelli.

Entrambi possono presentare un’interfaccia compatibile con OpenAI, ma distribuiscono le responsabilità in modo diverso:

La differenza rende possibile anche un’architettura combinata: LiteLLM può occuparsi delle policy interne e della contabilità, mentre OpenRouter gestisce l’accesso selezionato ai modelli.

Scegli in base al vincolo che diventerà un problema per primo

La scelta giusta dipende dal primo requisito a cui il team non può rinunciare.

Segui il denaro: dal costo dei token al costo per il team tecnico

LiteLLM e OpenRouter applicano costi su livelli diversi. OpenRouter trasferisce il prezzo dei modelli sottostanti senza un markup sull’inferenza, poi applica una commissione del 5.5% quando acquisti crediti. Il proxy open source di LiteLLM non prevede una commissione gateway per token, ma devi sostenere i costi dell’infrastruttura e delle persone necessarie per gestirlo.

La pagina dei prezzi di OpenRouter è la fonte aggiornata per i termini delle commissioni. Il costo è legato all’acquisto dei crediti, non a un semplice markup del 5% sul prezzo dei token di ogni modello.

Quando la commissione di OpenRouter costa meno

Se un team acquista abbastanza crediti OpenRouter da coprire la spesa mensile per l’inferenza:

• Con un utilizzo mensile di $500, la commissione del 5.5% sull’acquisto dei crediti è pari a $27.50.
• Su $20,000, la stessa percentuale equivale a $1,100.
• Su $50,000, arriva a $2,750.

Queste cifre indicano quanto LiteLLM debba essere più conveniente dopo aver considerato hosting, deployment, patch, alert, backup e tempo del team tecnico. Con $500 al mese, OpenRouter è spesso l’opzione con il minor carico operativo per un team che non gestisce già un gateway, a meno che il networking privato non sia obbligatorio. Con $20,000, un team che possiede e gestisce la piattaforma dovrebbe valutare seriamente LiteLLM.

Quando l’assenza di una commissione gateway rende davvero più conveniente LiteLLM

LiteLLM diventa interessante dal punto di vista economico quando il suo costo operativo fisso è già assorbito dal team di piattaforma, oppure quando la percentuale risparmiata supera il costo incrementale di gestione del proxy.

Il quickstart ufficiale Docker distingue un proxy semplice, senza database, da un deployment con database. Nel flusso Compose, PostgreSQL viene utilizzato per modelli, chiavi e log della spesa. Senza database, LiteLLM dichiara che chiavi virtuali, tracciamento della spesa e applicazione effettiva dei budget non sono disponibili; un max_budget configurato non costituisce un limite massimo rigido affidabile.

Redis introduce un’altra soglia tipica degli ambienti di produzione. I requisiti Redis di LiteLLM raccomandano uno stato Redis condiviso quando il proxy esegue più di un worker o replica. Senza Redis, limiti di frequenza, budget, cooldown, voci della cache e osservazioni sul routing restano distribuiti tra i worker. Un test con un solo worker costa poco; un gateway di produzione scalato orizzontalmente è un sistema più articolato.

Usa questo confronto invece di guardare soltanto al prezzo dei token:

Costo totale LiteLLM = fatture dei provider + infrastruttura + gestione operativa + responsabilità sulla sicurezza
Costo totale OpenRouter = inferenza dei provider + commissione sull’acquisto dei crediti

Non esiste un punto di pareggio valido per tutti. Gli elementi da considerare sono la spesa mensile per l’inferenza, l’hosting, le ore del team tecnico, la copertura on-call e qualsiasi sovrapprezzo legato alla compliance.

Confronta il control plane che dovrai gestire

LiteLLM offre al team di piattaforma più controllo, ma non crea l’accesso ai provider al posto tuo. OpenRouter semplifica la scoperta dei modelli e la fatturazione centralizzata, ma il catalogo hosted non equivale a possedere un rapporto diretto con i provider.

Sulla resilienza i due prodotti seguono strade diverse

Entrambi possono effettuare retry o failover, ma lo fanno secondo modelli di responsabilità diversi. OpenRouter gestisce il pool di provider; LiteLLM ti permette di definirlo, ma deve essere gestito come parte dello stack di affidabilità.

La documentazione sul routing dei provider di OpenRouter spiega che il comportamento predefinito distribuisce il carico tra i provider disponibili, tenendo conto del prezzo e delle interruzioni recenti dei servizi. Puoi richiedere un ordine specifico dei provider, consentire o disabilitare i fallback, imporre parametri precisi, filtrare in base alla policy sui dati oppure ordinare per prezzo, throughput o latenza. La guida ai fallback dei modelli descrive una lista ordinata models; la fatturazione utilizza il modello che alla fine gestisce la richiesta.

La documentazione sul routing di LiteLLM descrive selezione ponderata o casuale, routing basato sull’utilizzo, sulla latenza, sul minor carico, sui costi e strategie personalizzate. Supporta anche priorità dei deployment, cooldown, retry e gruppi di fallback. Sono controlli più programmabili, ma la loro correttezza dipende dalla configurazione, dagli health check, dallo stato condiviso e dalla risposta agli incidenti.

Latenza degli agenti, caching e variazioni dei provider

Un singolo hop di rete aggiuntivo può essere irrilevante per una risposta lunga trasmessa in streaming. Diventa più importante quando un agente esegue decine di chiamate brevi al modello, perché gateway, rete e retry aggiungono ritardi a ogni passaggio. Un proxy LiteLLM self-hosted può stare vicino all’applicazione; OpenRouter aggiunge un hop verso un servizio gestito prima del provider selezionato. La documentazione generica dei due vendor non sostituisce un test nella tua regione, con il tuo modello, la modalità streaming e il livello di concorrenza previsto.

Il routing può cambiare anche l’economia della cache. OpenRouter può selezionare endpoint di provider diversi per lo stesso modello, mentre LiteLLM può distribuire le richieste tra deployment configurati. Se un workflow dipende dal prompt caching lato provider, un cambio di route può modificare la località della cache e il costo dei token. Considera il comportamento della cache parte integrante dei test sul carico di lavoro.

Inoltre, uno stesso model slug non garantisce un comportamento identico. Le implementazioni dei provider possono differire per limiti di contesto, supporto alle chiamate di tool, latenza, quantizzazione, caching e parametri specifici del provider. OpenRouter espone filtri come require_parameters, mentre LiteLLM normalizza le chiamate ai provider in un’interfaccia comune. Testa gli schemi esatti dei tool e i parametri del modello utilizzati dal tuo agente.

Scenari di errore da prevedere

OpenRouter trasforma gli incidenti infrastrutturali in una dipendenza dal vendor. LiteLLM li trasforma in incidenti che il team di piattaforma può analizzare e modificare.

Osservabilità e privacy hanno confini diversi

“Self-hosted” e “privato” non sono sinonimi, così come “gestito” non significa “registra ogni prompt”. La domanda importante è quale livello conserva i contenuti, quale conserva i metadati e quali provider ricevono la richiesta.

La documentazione Zero Data Retention di OpenRouter spiega che ZDR può essere applicato all’intero account, a un gruppo di modelli, a un guardrail o a una singola richiesta. Distingue gli endpoint senza conservazione dai provider che non usano i dati per il training ma possono conservarli temporaneamente. ZDR si applica al routing dell’inferenza; strumenti e plugin abilitati richiedono una verifica separata.

LiteLLM ti offre più controllo sulla rete, sul database, sull’autenticazione e sui log del gateway, ma la responsabilità resta tua. Devi proteggere il proxy, applicare le patch al software, limitare le route amministrative, custodire le chiavi dei provider e verificare i termini di conservazione e training di ogni provider upstream.

L’architettura ibrida è spesso la risposta più pratica

Metti LiteLLM davanti a OpenRouter quando ti serve un endpoint interno stabile con governance, ma non vuoi aprire un account diretto per ogni modello o provider. Invia il traffico sensibile o prevedibile direttamente ai provider approvati e usa OpenRouter per il traffico esplorativo o dipendente dal catalogo.

Un pattern di configurazione semplificato è questo:

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

In questo modo LiteLLM diventa il punto in cui applicare chiavi interne, budget, tag e log. Questo non elimina la commissione di OpenRouter, il transito hosted o il confine delle policy del provider per le richieste che passano dalla route OpenRouter. Aggiunge inoltre un hop e un altro dominio di errore: non instradare quindi automaticamente ogni richiesta attraverso entrambi i livelli.

Una suddivisione sensata è:

1. Route dirette verso i provider per dati sensibili, modelli di produzione stabili o contratti negoziati con i provider.
2. Route OpenRouter per scoprire nuovi modelli, raggiungere provider di nicchia e sfruttare il fallback gestito tra provider.
3. Controlli LiteLLM per chiavi applicative, team, budget e attribuzione interna dei costi.
4. Dashboard e alert separati per il traffico diretto ai provider e quello che passa da OpenRouter.

Migrazione: cosa cambia e cosa resta uguale

Spostare un client compatibile con OpenAI tra i due gateway può richiedere poche modifiche. Portare un workload in produzione, però, non significa soltanto cambiare la base URL.

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter usa comunemente https://openrouter.ai/api/v1 (API reference); un proxy LiteLLM espone di norma un endpoint privato come http://localhost:4000 (proxy quickstart). ID dei modelli, prefissi dei provider, autenticazione e parametri opzionali possono comunque differire.

Prima di spostare il traffico di produzione, testa:

1. Comportamento dello streaming e dei timeout.
2. Chiamate ai tool con i tuoi schemi JSON esatti.
3. Output strutturati e gestione rigorosa del JSON.
4. Reasoning, caching e parametri specifici del provider.
5. Comportamento del fallback quando il modello principale restituisce 429, 5xx o un errore di validazione.
6. Attribuzione dei costi, perché l’evento di fatturazione può verificarsi a un livello diverso rispetto alla richiesta dell’applicazione.

La compatibilità delle API semplifica la prima integrazione. Non garantisce però output, latenza, selezione del provider o semantica della fatturazione identici.

Le domande più comuni prima della scelta

LiteLLM e OpenRouter possono essere usati insieme?

Sì. LiteLLM può usare OpenRouter come route upstream, lasciando a LiteLLM la gestione di chiavi interne, budget, log o policy, mentre OpenRouter fornisce l’accesso selezionato ai modelli e il routing tra provider. Il percorso combinato aggiunge un hop e mantiene la commissione OpenRouter e il relativo confine dei dati hosted per quel traffico.

Quale costa meno per un’API di produzione?

OpenRouter è spesso l’opzione con il minor carico operativo per un piccolo team che non gestisce già un’infrastruttura gateway. LiteLLM può costare meno con volumi elevati quando il team gestisce già l’infrastruttura necessaria e vuole evitare commissioni gateway percentuali; confronta il costo totale, non soltanto il prezzo dei token.

LiteLLM dà accesso all’intero catalogo di OpenRouter?

Non da solo. LiteLLM documenta il supporto a 100+ LLM e a un’ampia gamma di provider nel suo proxy quickstart, ma può raggiungere soltanto i provider e le credenziali che configuri. Aggiungere OpenRouter come upstream può ampliare il catalogo raggiungibile, ma quelle richieste seguiranno la disponibilità dei modelli e dei provider di OpenRouter.

Quale soluzione è migliore per privacy e compliance?

LiteLLM self-hosted offre più controllo su deployment, log, credenziali e confine di rete del gateway. OpenRouter offre controlli sulla registrazione dei contenuti, filtri sulle policy dei provider, routing ZDR e opzioni regionali Enterprise per EU/US, ma resta parte del percorso della richiesta; verifica il provider specifico e il requisito contrattuale prima di scegliere.

Scegli il confine operativo che il tuo team è in grado di gestire: confronta la commissione percentuale con il costo reale di gestione del gateway, stabilisci quali richieste possono passare da un intermediario hosted e testa i guasti rispetto al comportamento di routing e alle chiamate ai tool richiesti dalla tua applicazione. Se non puoi farti carico di database, Redis, aggiornamenti e responsabilità on-call di LiteLLM, OpenRouter è la scelta predefinita più realistica; se disponi già di queste competenze e risorse di piattaforma, LiteLLM o un’architettura ibrida possono restituirti controllo e ridurre le commissioni gateway ricorrenti.

Per una panoramica più ampia delle alternative a OpenRouter, consulta OpenRouter alternatives; questo confronto è volutamente più circoscritto e si concentra sulla scelta del modello operativo di LiteLLM.