LiteLLM è un proxy open source compatibile con OpenAI che esegui autonomamente: si trova davanti ai tuoi account dei fornitori e offre al tuo codice un unico endpoint e un formato unico per le chiavi (la sua documentazione). I team cercano alternative per due motivi non correlati. Operativo: un proxy self-hosted è un servizio in più da aggiornare, scalare e monitorare. Supply chain: il 24 marzo 2026 un aggressore ha pubblicato su PyPI due release di LiteLLM contenenti una backdoor, portando davanti a molti team il rischio di "un pacchetto nel processo di build", che non avevano considerato. Questa panoramica collega ogni motivazione allo strumento che la affronta davvero, compreso il caso in cui conviene restare dove si è, una scelta più solida di quanto suggeriscano le sette liste commerciali presenti in questa ricerca.
Trasparenza dichiarata fin dall'inizio: Kunavo è il nostro prodotto ed è elencato per primo. Ogni altro strumento qui sotto riceve una raccomandazione autentica; i dettagli che abbiamo verificato sono disponibili nelle pagine di confronto e i due strumenti che non abbiamo valutato vengono descritti solo al livello dichiarato dai loro stessi siti.
La lista breve
| Alternativa | Tipo | Sceglilo per |
|---|---|---|
| Kunavo | Gateway di inferenza gestito (accesso rivenduto) | Nessun proxy né account dei fornitori; sotto il listino per la maggior parte dei modelli |
| OpenRouter | Gateway di inferenza gestito (accesso rivenduto) | Il catalogo di modelli più ampio con un unico portafoglio |
| Portkey | Control plane gestito (BYO keys) | Mantieni le chiavi dei fornitori, smetti di eseguire il proxy |
| Helicone | Livello di osservabilità (con le proprie chiavi) | Il logging e il monitoraggio dei costi erano l'unico motivo per cui lo eseguivi |
| TrueFoundry | Gateway AI aziendale | Il reparto procurement vuole uno SLA e un fornitore da contattare |
| MLflow AI Gateway | Ospitato su infrastruttura propria, open source | Stessa struttura di LiteLLM, progetto diverso |
| Cloudflare AI Gateway | Proxy edge (con le proprie chiavi) | Caching, limiti di velocità e analisi sulle tue chiavi |
La distinzione più importante
LiteLLM svolge due funzioni contemporaneamente e la maggior parte delle alternative ne svolge una sola. È un proxy (un endpoint per molti fornitori) ed è uno strumento BYO-key (gli account dei fornitori restano tuoi). Un gateway di inferenza gestito — Kunavo, OpenRouter — sostituisce entrambe le funzioni: non devi eseguire alcun proxy né gestire account dei fornitori, perché il gateway conserva le credenziali upstream e ti fattura l'utilizzo. Un control plane gestito — Portkey, TrueFoundry — sostituisce solo la prima: smetti di gestire il proxy, ma mantieni gli account. Capire quale delle due metà vuoi sostituire chiarisce gran parte di questo elenco. Il modello è illustrato nella guida ai gateway LLM.
Cosa ha spinto davvero le persone a cercare
Il primo risultato di questa ricerca non è un articolo in forma di elenco, ma una discussione su Reddit relativa all'attacco alla supply chain. Ecco cosa è successo, secondo l'aggiornamento di sicurezza di LiteLLM: il 24 marzo 2026, un aggressore ha pubblicato litellm==1.82.7 e litellm==1.82.8 su PyPI con codice malevolo inserito nei wheel distribuiti. Sono rimasti disponibili dalle 10:39 UTC per circa 40 minuti, prima che PyPI li mettesse in quarantena. La compromissione è stata ricondotta alla dipendenza Trivy nel flusso di lavoro di scansione della sicurezza CI/CD di LiteLLM; l'aggressore ha aggirato il flusso ufficiale di release e ha caricato direttamente su PyPI. Secondo SecurityWeek, sono state coinvolte oltre 2.500 organizzazioni.
La remediation di LiteLLM è documentata ed è sostanziale: i pacchetti compromessi sono stati rimossi, le credenziali dei maintainer sono state ruotate, Mandiant è stata coinvolta per l'analisi forense e la v1.83.0 è stata rilasciata tramite una pipeline CI/CD ricostruita con ambienti di build isolati, controlli di release più rigorosi e immagini Docker firmate con cosign. Se usi la 1.83.0 o una versione successiva e non eseguivi una versione compromessa durante quella finestra di 40 minuti, l'incidente per te è chiuso.
Il motivo per cui l'incidente continua a spingere le persone verso questa ricerca è strutturale, non specifico di LiteLLM. Un proxy self-hosted è un pacchetto nel tuo processo di build, quindi il tuo CI/CD e il tuo cluster rientrano nel suo raggio d'impatto. È la frase su cui vale la pena riflettere: è altrettanto vera per ogni alternativa self-hosted di questa pagina, compreso MLflow AI Gateway, ed è l'unica cosa che un endpoint gestito elimina: chiami un URL HTTPS, quindi non c'è alcun pacchetto da compromettere e nulla del gateway in esecuzione nella tua rete.
L'altra metà, quella onesta: un gateway gestito non è più sicuro, ma è esposto a rischi diversi. La tua chiave API e il testo dei tuoi prompt transitano dall'infrastruttura di qualcun altro e assumi il loro rischio di violazione invece del rischio di applicare le tue patch. Se il testo dei prompt non può lasciare la tua infrastruttura, il self-hosting è la scelta corretta e il resto di questa pagina riguarda un compromesso che non dovresti accettare.
1. Kunavo — nessun proxy, nessun account dei fornitori
Kunavo è un gateway di inferenza gestito: un unico base URL compatibile con OpenAI, un'unica chiave sk-kn-, un unico saldo con pagamento a consumo; siamo noi a conservare le credenziali dei fornitori upstream, non tu. Rispetto a LiteLLM, si tratta di una diversa divisione del lavoro: non esegui un proxy e non gestisci separatamente account presso Anthropic, Google e OpenAI.
Prezzo: la maggior parte del catalogo è indicata al di sotto delle tariffe ufficiali dei fornitori — Claude Sonnet 4.6 a $2,10 / $10,50 per 1M di token rispetto alle tariffe di Anthropic di $3,00 / $15,00. LiteLLM non applica un sovrapprezzo perché non rivende nulla; ciò che paghi è quanto previsto dal tuo accordo con il fornitore, quindi il confronto è tra la nostra tariffa e la tua tariffa diretta, non con zero. Copertura: modelli per chat, immagini, video e musica con la stessa chiave e lo stesso saldo. Cosa non fa: instradare le tue chiavi dei fornitori; questa è la parte BYO-key che LiteLLM mantiene e noi non sostituiamo. Dettagli: Kunavo vs LiteLLM.
2. OpenRouter — il catalogo di modelli più ampio
L'altro gateway di inferenza gestito, da scegliere quando l'ampiezza del catalogo conta più del prezzo unitario: centinaia di modelli di numerosi fornitori in un unico portafoglio, oltre a piani gratuiti e routing con chiavi proprie, che Kunavo non offre. Se abbandoni LiteLLM perché vuoi smettere di gestire account, OpenRouter e Kunavo sono le due opzioni realistiche. Kunavo vs OpenRouter mette a confronto le due soluzioni, mentre la panoramica di OpenRouter copre il resto del settore.
3. Portkey — mantieni le chiavi, elimina la gestione operativa
Un control plane gestito sopra account dei fornitori che già possiedi: routing, fallback, guardrail e osservabilità, senza dover eseguire un proxy autonomo. È l'alternativa più vicina se hai scelto LiteLLM per le funzioni di routing e budget e vuoi rinunciare soltanto alla gestione operativa. Dettagli: Kunavo vs Portkey.
4. Helicone — se l'osservabilità era l'unico motivo
Molte installazioni di LiteLLM esistono perché qualcuno aveva bisogno dei log delle richieste e dell'attribuzione dei costi per team, e il proxy era il modo per ottenerli. Se è il tuo caso, un livello di osservabilità sopra le chiamate esistenti ai fornitori è molto più piccolo da gestire rispetto a un gateway. Dettagli: Kunavo vs Helicone.
5. TrueFoundry — quando il procurement ha bisogno di un fornitore
Occupa la posizione 2 in questa ricerca con il proprio confronto con LiteLLM. È un gateway AI aziendale venduto sulla base di overhead di latenza, flessibilità di distribuzione, SLA, governance e controlli pronti per gli audit (la sua pagina prodotto). Non lo abbiamo valutato, quindi questa voce è un riferimento, non una raccomandazione: se il tuo ostacolo è che un proxy open source non offre un contratto di supporto, questa è la categoria che risolve il problema; vale la pena leggere il confronto sapendo che è stato scritto da loro.
6. MLflow AI Gateway — il passaggio open source più simile
Posizione 3 e l'elemento di questa pagina più vicino a LiteLLM: un gateway open source e self-hosted che si pone davanti alle tue chiavi dei fornitori, mantenuto come parte del progetto MLflow. È importante dirlo chiaramente: sostituire un proxy self-hosted con un altro mantiene il modello di distribuzione e quindi anche la superficie d'attacco descritta sopra. È una scelta legittima: è ciò che vuoi se il problema era il progetto, non il modello.
7. Cloudflare AI Gateway — caching e limiti sull'edge
Un proxy sottile davanti agli account dei fornitori che già possiedi: caching delle risposte, rate limiting, tentativi automatici e analisi, senza rivendita dell'inferenza. Si integra con qualsiasi fonte di inferenza invece di sostituirla, compresi Kunavo e OpenRouter. Dettagli: Kunavo vs Cloudflare AI Gateway.
Quando LiteLLM è ancora la scelta giusta
- Il testo dei prompt non può lasciare la tua infrastruttura. Dati regolamentati, ambienti air-gapped o una policy che un gateway gestito semplicemente non può soddisfare. Il self-hosting è la risposta e l'unica domanda è quale proxy self-hosted scegliere.
- Hai contratti negoziati con i fornitori. La spesa impegnata o le tariffe aziendali presso Anthropic, OpenAI o Google valgono più di qualsiasi prezzo pubblicato da un rivenditore, e gli strumenti BYO-key sono il modo per continuare a utilizzarle.
- Usi i budget per chiave e il routing per team. Queste funzioni sono il motivo per cui esistono molte installazioni di LiteLLM; verifica che la soluzione sostitutiva le copra prima di presumere che la migrazione consista solo nel cambiare il base URL.
- Vuoi codice sorgente che puoi leggere e modificare. Un proxy open source sotto il tuo controllo è una proprietà reale e l'incidente del marzo 2026 non la elimina: si è trattato di una compromissione della pipeline di release, ormai risolta, non di un difetto del proxy stesso.
Cambiare richiede due righe
Ogni alternativa qui presente che rivende inferenza parla il protocollo wire di OpenAI, quindi abbandonare un proxy LiteLLM consiste nel sostituire base_url e la chiave; la struttura delle richieste e delle risposte non cambia:
# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
api_key=os.environ["LITELLM_MASTER_KEY"],
base_url="http://litellm.internal:4000",
)
# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
api_key=os.environ["KUNAVO_API_KEY"],
base_url="https://api.kunavo.com/v1",
)
resp = client.chat.completions.create(
model="claude-sonnet-5",
messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)La parte che non si riduce a due righe è tutto ciò che LiteLLM faceva oltre al routing: budget per chiave, distribuzione per team e callback personalizzati. Inventaria prima queste funzioni. I dettagli a livello wire sono nella guida all'API compatibile con OpenAI e cosa dovrebbe gestire per te un gateway illustra l'insieme di funzioni rispetto a cui valutare una soluzione sostitutiva.
Domande frequenti
Qual è la migliore alternativa a LiteLLM?
Dipende da cosa vuoi sostituire. Se vuoi smettere di eseguire un proxy e di gestire account dei fornitori, un gateway di inferenza gestito come Kunavo o OpenRouter sostituisce entrambe le cose in una volta sola. Se vuoi mantenere le tue chiavi dei fornitori senza gestire personalmente il proxy, Portkey o TrueFoundry sono control plane gestiti con modello BYO-key. Se eseguivi LiteLLM solo per il logging e il monitoraggio dei costi, Helicone copre esclusivamente queste esigenze. Se vuoi una soluzione open source da gestire autonomamente, MLflow AI Gateway è l'alternativa più simile a LiteLLM.
Perché nel 2026 le persone cercano alternative a LiteLLM?
Per due motivi distinti. Il primo è operativo e ordinario: un proxy self-hosted è un servizio a cui applicare patch, da scalare e per cui allertare qualcuno in caso di problemi. Il secondo è specifico: il 24 marzo 2026 un aggressore ha pubblicato su PyPI due release di LiteLLM contenenti una backdoor e, secondo SecurityWeek, l'incidente ha coinvolto oltre 2.500 organizzazioni. Da allora LiteLLM ha ruotato le credenziali e ricostruito la pipeline di release, quindi per la maggior parte dei team la domanda non è se LiteLLM sia sicuro oggi, ma se vogliano affatto una dipendenza di questo tipo nel proprio processo di build.
Quali versioni di LiteLLM sono state compromesse nell'attacco alla supply chain del marzo 2026?
litellm==1.82.7 e litellm==1.82.8. Secondo l'aggiornamento di sicurezza di LiteLLM, erano disponibili su PyPI il 24 marzo 2026 dalle 10:39 UTC per circa 40 minuti, prima che PyPI le mettesse in quarantena. LiteLLM ha ricondotto la compromissione alla dipendenza Trivy nel flusso di lavoro CI/CD di scansione, ha coinvolto Mandiant per l'analisi forense e ha rilasciato la v1.83.0 tramite una pipeline ricostruita con ambienti di build isolati e immagini Docker firmate.
Un gateway AI gestito è più sicuro che gestire LiteLLM autonomamente?
Non più sicuro: espone rischi diversi. Un gateway gestito rimuove il pacchetto dal tuo processo di build e il proxy dal tuo cluster, quindi una release compromessa non può raggiungere tramite essi il tuo CI/CD o i tuoi nodi Kubernetes. In cambio, la tua chiave API e il testo dei tuoi prompt transitano da una terza parte, e assumi il rischio di una violazione di quel fornitore invece del tuo. I team che non possono inviare il testo dei prompt fuori dalla propria infrastruttura dovrebbero usare il self-hosting; la scelta riguarda un modello di fiducia, non un punteggio di sicurezza.
Esiste un'alternativa open source a LiteLLM?
MLflow AI Gateway è l'alternativa più simile: un gateway open source e self-hosted che inoltra le tue chiavi dei fornitori tramite un unico endpoint, mantenuto come parte del progetto MLflow. Occupa la posizione 3 in questa ricerca ed è l'alternativa più simile per struttura a LiteLLM.
Come posso migrare da LiteLLM?
Se passi a un altro endpoint compatibile con OpenAI, la migrazione consiste nel sostituire base_url e la chiave API: la struttura delle richieste e delle risposte non cambia e i nomi dei modelli restano nello stesso formato. Il lavoro che non si riduce a due righe riguarda ciò che LiteLLM faceva per te oltre al routing: applicazione dei budget, distribuzione delle chiavi per team e callback personalizzati. Verifica quali di queste funzioni copre la soluzione sostitutiva prima di effettuare il passaggio.
Quando dovrei continuare a usare LiteLLM?
Continua a usarlo quando il testo dei prompt non può lasciare la tua infrastruttura, quando hai già contratti negoziati con i fornitori che vuoi continuare a utilizzare, quando ti servono le sue funzioni di budget per chiave e routing per team oppure quando vuoi un proxy open source che puoi leggere e modificare autonomamente. Sono punti di forza reali e l'incidente del marzo 2026 non ne elimina nessuno: si è trattato di una compromissione della pipeline di release, ormai risolta, non di un difetto nel funzionamento del proxy.