Vai al contenuto

Guide alla migrazioneDa LiteLLM

Da un proxy LiteLLM che gestisci tu a uno che non gestisci

LiteLLM è due cose: un SDK Python che parla con più di 100 provider e un proxy che distribuisci con Postgres e Redis, che aggiunge chiavi virtuali, budget, fallback e caching. Entrambi funzionano sulle tue chiavi provider, come INFRO. Ciò che cambia è chi gestisce il proxy. Questa pagina fa corrispondere la configurazione del proxy a INFRO e mostra come tenere l'SDK.

Open source MIT di BerriAI, più un'edizione Enterprise con licenza; self-hosted

Gli account INFRO sono self-service. Il catalogo, la documentazione e il contratto dell'API sono pubblici, il gateway è in produzione e tutto ciò che va oltre la v1 è indicato come "Più avanti". Piani e prova

A che punto siamo

Licenza ed edizioni

Tutto ciò che sta fuori dalla directory enterprise/ è MIT; Enterprise è la stessa immagine con una chiave di licenza, che aggiunge SSO, SCIM, log di audit, gestori di segreti e supporto.

Avvisi di sicurezza nel 2026

Il blog di LiteLLM elenca una compromissione su PyPI di litellm 1.82.7 e 1.82.8 il 2026-03-24 (l'immagine Docker ufficiale non è stata coinvolta; la versione pulita 1.83.0 è uscita il 2026-03-30), una SQL injection nella verifica delle chiavi del proxy corretta nella 1.83.7 (2026-04-29) e un bypass dell'autenticazione tramite header Host corretto nella 1.84.0 (2026-06-01). Gestire il proxy significa seguire questi aspetti da soli.

Su quale account viene servita la richiesta

Tuoi, in entrambi i prodotti. LiteLLM non detiene mai un account provider e nemmeno INFRO; i tuoi provider ti fatturano direttamente.

LiteLLM è gratuito, aperto e funziona ovunque. Se sono i motivi per cui l'hai scelto, restano buoni motivi.

  • Il traffico non deve uscire dalla tua rete, oppure devi poter leggere e correggere il codice del gateway. INFRO è ospitato e a codice chiuso; il self-hosted o ibrido è un accordo enterprise.
  • Usi la cache semantica, i fallback per finestra di contesto o per policy dei contenuti, il gateway di agenti A2A o callback verso uno specifico vendor di logging. INFRO ha la cache a corrispondenza esatta, le regole di errore delle route, un gateway MCP e l'esportazione OpenTelemetry.
  • Chiami provider che INFRO non collega, oppure endpoint che non serve: batch, file, fine-tuning, Realtime, embedding su provider diversi da OpenAI, Azure OpenAI, Mistral o un endpoint compatibile con OpenAI.
  • Gestirlo ti costa poco perché un team di piattaforma possiede già Postgres, Redis e gli aggiornamenti.

Le modifiche, una riga ciascuna. Tutto ciò che non è elencato qui resta com'è.

 LiteLLMINFRO
URL di baseIl tuo proxy, ad esempio http://0.0.0.0:4000.https://api.infro.io/v1
ChiaveUna chiave virtuale LiteLLM (sk-...) da /key/generate.Una chiave del gateway INFRO, creata nella console o tramite l'API di gestione. Le chiavi provider passano da litellm_params alle connessioni INFRO.
Id del modelloUn model_name da model_list, come gpt-4o.Una route con lo stesso nome, così i chiamanti continuano a inviarlo, oppure vendor/model direttamente.
Campi del corpometadata { tags, trace_id, trace_user_id, generation_name }, cache { ttl, namespace }, user.metadata { user_id, session_id, tags }, cache per la cache delle risposte, X-INFRO-Trace-Id per un id di trace.

Prima · LiteLLM proxy

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://0.0.0.0:4000",
  apiKey: process.env.LITELLM_API_KEY, // virtual key
});

await client.chat.completions.create({
  model: "claude-default", // model_name in model_list
  messages: [{ role: "user", content: "Hello" }],
  user: "user-123",
  // @ts-expect-error LiteLLM extension
  metadata: { tags: ["production"] },
});

Dopo · INFRO

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.infro.io/v1",
  apiKey: process.env.INFRO_API_KEY,
});

await client.chat.completions.create({
  model: "claude-default", // an INFRO route, same name
  messages: [{ role: "user", content: "Hello" }],
  // @ts-expect-error INFRO extension
  metadata: { user_id: "user-123", tags: { env: "production" } },
});

`model_list` diventa route

Ogni model_name con più deployment diventa una route con quelle destinazioni; i pesi rpm diventano destinazioni ponderate; i router_settings.fallbacks diventano le destinazioni successive della route oppure fallbacks.

Tieni l'SDK

Il provider compatibile con OpenAI di LiteLLM invia tutto ciò che segue openai/ come id del modello, quindi openai/anthropic/claude-sonnet-5.5 arriva a INFRO come anthropic/claude-sonnet-5.5. I fallback avvengono poi in INFRO, non nell'SDK.

Oppure tieni il proxy dietro INFRO

Collega il proxy come connessione openai-compatible durante il passaggio. Tieni presente che INFRO vede allora solo il proxy come un unico provider, quindi failover e costo per provider avvengono ancora dentro LiteLLM finché non colleghi direttamente i provider.

Gli oggetti di LiteLLM a confronto con quelli di INFRO, dalla documentazione pubblica di LiteLLM letta il 19 ottobre 2026 e verificati con ciò che il gateway implementa. Una riga dice che INFRO non ha nulla.

LiteLLMCosa fa lìIn INFRO
`model_list` e `litellm_params`stessa formaDeployment per nome del modello, con le chiavi provider nella configurazione.Connessioni ai provider (chiavi sigillate, più di una per provider) e route su di esse.
Chiavi virtualistessa formaChiavi emesse dal proxy con modelli consentiti, budget, tpm e rpm, team e utente.Chiavi del gateway con modelli, provider, intervalli IP, un ambiente, un limite di spesa e un livello di frequenza delle richieste consentiti; rotazione e un interruttore di spegnimento.
Team, utenti, budgetstessa formamax_budget e budget_duration per chiave, team o utente.Budget per organizzazione, progetto, membro, chiave e cliente finale, mantenuti sotto concorrenza, 402 al tetto prima della chiamata al provider.
limiti tpmdiversoLimiti di token al minuto per chiave o deployment.Livelli di frequenza delle richieste per chiave e budget in dollari. Nessun limite di token al minuto.
Fallback e retrystessa formafallbacks, num_retries, cooldown, allowed_fails.Destinazioni di route e regole di errore per tipo (ritenta, fai failover o fermati); fallbacks per richiesta.
Fallback per finestra di contesto e per policy dei contenutidiversoUn modello diverso quando il prompt è troppo lungo o la policy di un provider lo rifiuta.Una regola di errore moderation può fare failover sulla destinazione successiva. Nessun fallback per la finestra di contesto.
CachingdiversoCache esatte e semantiche su Redis, S3, GCS, Qdrant e altri.Corrispondenza esatta, da attivare, per i chat completions, ospitata. Nessuna cache semantica.
GuardraildiversoGuardrail collegabili; diverse integrazioni richiedono Enterprise.Regole a pattern che bloccano, oscurano o segnalano, e controlli su un modello decisionale, in ogni piano che include i guardrail.
Callback di loggingdiversoCallback verso Langfuse e altri strumenti; log di spesa in Postgres.Il log delle richieste, le esportazioni e gli span verso il tuo collector OpenTelemetry.
Monitoraggio della spesadiversoCosto dalla mappa dei prezzi dei modelli di LiteLLM.Costo stimato del provider dalle tue tariffe negoziate o dalla tariffa di listino del vendor, unpriced quando non è noto, riconciliato con le API dei costi di OpenAI e Anthropic.
Gateway MCPstessa formaServer MCP dietro il proxy.Un gateway MCP per i tuoi server MCP, con strumenti approvati e autorizzazioni per chiave.
Gateway di agenti A2AnienteTraffico tra agenti attraverso il proxy.Nulla.
Gestirlo in propriodiversoMIT, Docker o pip, ovunque.Hosted. Self-hosted o ibrido è un accordo enterprise.Enterprise — Disponibile con un contratto enterprise anziché in self-service.

È la nostra lettura della documentazione pubblicata da LiteLLM, non una prova o un benchmark. Se abbiamo letto male qualcosa, diccelo e correggeremo la riga.

Cosa non fa INFRO

  • Funzionare sulla tua infrastruttura senza un accordo enterprise, oppure lasciarti leggere il suo codice sorgente.
  • Cache semantica, fallback per finestra di contesto, A2A.
  • Servire batch, file, fine-tuning o Realtime, oppure embedding su provider diversi da OpenAI, Azure OpenAI, Mistral o un endpoint compatibile con OpenAI.
  • Limiti di token al minuto; INFRO limita per frequenza delle richieste e per dollari.

Cosa non si porta con sé

  • Log di spesa e cronologia delle richieste nel tuo Postgres di LiteLLM. Non esiste un importatore.
  • Chiavi virtuali. Emetti chiavi del gateway INFRO e passa gradualmente i chiamanti.
  • Callback e hook personalizzati. Usa l'esportazione OpenTelemetry, oppure tieni quella logica nel tuo codice.

Domande

Posso continuare a usare l'SDK Python di LiteLLM?
Sì. Chiama INFRO tramite il provider compatibile con OpenAI di LiteLLM: model="openai/<INFRO model id>" con api_base="https://api.infro.io/v1" e la tua chiave INFRO.
INFRO è open source come LiteLLM?
No. INFRO è un servizio ospitato; un deployment self-hosted o ibrido è disponibile con un accordo enterprise.
Chi paga i provider dei modelli?
Tu, direttamente, come con LiteLLM. INFRO è un abbonamento e aggiunge lo 0% alla spesa per i modelli.

Migra con noi, o da solo

Il programma di migrazione mappa in una call la tua configurazione LiteLLM su connessioni, route e budget di INFRO e migra con te il primo servizio. I tuoi provider continuano a fatturarti direttamente; INFRO è un abbonamento e aggiunge 0% alla spesa per i modelli.

Prova di 14 giorni Prenota una sessione di migrazioneINFRO vs LiteLLMLeggi il quickstart

Fonti

Ogni affermazione su LiteLLM in questa pagina proviene da una di queste fonti, lette il 19 ottobre 2026. Nulla è dedotto da una prova, un benchmark o una conversazione.