Passa al contenuto principale

AI Gateway: LiteLLM, OpenRouter, Portkey, Vercel

Intermedio

Quando il tuo prodotto parla con più di un modello, l'approccio SDK-diretto si spacca. Ogni provider ha la sua chiave, i suoi rate limit, i suoi outage e il suo conto. Un AI gateway è il piccolo pezzo di infrastruttura che sta tra il tuo codice e ogni modello — Claude, GPT, Gemini, Llama, Kimi, DeepSeek, il tuo Ollama locale — e trasforma "N integrazioni fragili" in "un endpoint che controlli tu". Questa pagina confronta i quattro gateway che vengono effettivamente messi in produzione nel 2026 — LiteLLM, OpenRouter, Portkey e Vercel AI Gateway — e mostra il workflow killer: puntare Claude Code al tuo gateway così un solo proxy gestisce routing, budget, log e fallback per tutto il team.

What you'll learn
  • Capire cos'è un AI gateway e i cinque problemi che risolve (molti provider, un'API; fallback; chiavi virtuali; limiti di spesa; osservabilità)
  • Confrontare LiteLLM, OpenRouter, Portkey e Vercel AI Gateway su latenza, prezzo, self-hostability e dove ciascuno eccelle
  • Collegare Claude Code al tuo proxy LiteLLM con ANTHROPIC_BASE_URL e una chiave virtuale, così il team ha limiti e log condivisi
  • Configurare il fallback OpenRouter così un outage Claude promuove silenziosamente GPT o Gemini invece di mostrare un 5xx agli utenti
  • Capire l'incidente supply-chain LiteLLM di marzo 2026 e come pinnare le versioni in modo sicuro in produzione

Il problema: un SDK diretto per provider non scala​

La prima integrazione Claude è un cambio di due righe: pip install anthropic, imposta ANTHROPIC_API_KEY, fatto. La seconda — supponiamo che tu voglia fare fallback su GPT-5.4 quando Anthropic ti limita — è dove l'astrazione si rompe. Ora hai due SDK con forme di richiesta diverse, due dashboard, due bollette, due cadenze di rotazione per le API key e due set di logica di retry. Aggiungi un terzo per Gemini e un quarto per il tuo Ollama locale, e ogni decisione di prodotto ("cap questo team a $500/mese", "logga ogni prompt per review", "lascia che un cliente porti la sua chiave") diventa N implementazioni invece di una.

Un AI gateway concentra tutta quella plumbing in un solo posto. Concretamente, un gateway di produzione ti dà:

  • Una forma di richiesta per ogni provider. La maggior parte dei gateway parla l'API OpenAI Chat Completions (o Anthropic Messages, o entrambe) e traduce al provider reale sotto il cofano.
  • Fallback e routing. Prova prima Claude; su 429 o 5xx, ritenta su GPT o Gemini senza che il chiamante lo sappia. Stesso discorso per soglie di latenza e rifiuti per moderazione dei contenuti.
  • Chiavi virtuali. Emetti una chiave per-utente o per-servizio che mappa a un sottoinsieme di modelli, con il suo budget e il suo rate limit — così uno script impazzito non può prosciugare tutto l'account.
  • Spending cap e logging. Ogni richiesta viene taggata, prezzata e salvata. Puoi revocare una chiave senza toccare Anthropic o OpenAI, e puoi provare a compliance cosa è stato mandato dove.
  • Caching. Il prompt caching (match esatto) e il caching semantico (near-match) trasformano il traffico ripetuto in hit gratis.

Non tutti i team hanno bisogno di tutti e cinque. Ma nel momento in cui due di questi finiscono nella tua roadmap, far girare un gateway è più economico che reinventarli per provider.

I quattro gateway che vanno in produzione​

Non c'è un "vincitore" — i quattro leader occupano angoli diversi dello spazio di design (self-hosted vs. hosted, open-source vs. proprietario, minimalista vs. control-panel).

GatewayDeployModello di pricingMiglior punto di forzaNon adatto per
LiteLLMSelf-hosted (Docker) o SDKGratis (OSS); tier Enterprise per SSO/auditProxy di team con chiavi virtuali, budget, senza markup per token, funziona con 100+ provider via una configTeam senza DevOps per far girare Postgres + Redis
OpenRouterSolo hostedPrezzo provider + ~5,5% di fee sull'acquisto crediti, nessun markup per richiestaAccesso zero-ops a 300+ modelli con una chiave; ideale per prodotti che lasciano scegliere il modello all'utenteAziende compliance che richiedono self-hosting o data residency
PortkeyGateway OSS (npx) o cloud hostedOSS gratis; il cloud ha tier di utilizzoLatenza gateway sub-ms, caching semantico, guardrail, canary testing — l'angolo "control panel"Team che vogliono solo l'aggregatore di chiavi più semplice possibile
Vercel AI GatewaySolo hostedPrezzo provider, nessun markup token; gratis con i piani VercelDev già su Vercel che vogliono AI SDK v5/v6 + Anthropic Messages + OpenAI Responses unificateInfrastruttura non-Vercel o deploy air-gapped

L'asse importante su cui scegliere per primo: self-hosted vs. hosted. Se i tuoi dati non possono uscire dal VPC (settori regolati, residenza EU, review privacy enterprise), ti serve un gateway self-hostabile — LiteLLM o Portkey OSS. Se preferisci pagare qualcuno perché lo faccia girare, OpenRouter o Vercel AI Gateway è una faccenda one-click.

Il secondo asse: quanto control plane ti serve davvero. Se sei un prodotto one-person che vuole solo provare Kimi K3, Claude e Grok fianco a fianco senza fare tre signup, OpenRouter è tutta la storia. Se sei un'organizzazione da 20 persone dove finance vuole la spesa mensile per team, security vuole chiavi virtuali con rotazione e la piattaforma vuole metriche Grafana, stai costruendo su LiteLLM o Portkey.

Workflow killer: punta Claude Code al tuo proxy LiteLLM​

Il segreto meglio custodito di Claude Code è che rispetta ANTHROPIC_BASE_URL e ANTHROPIC_AUTH_TOKEN. Impostali sul tuo gateway e Claude Code smette di parlare direttamente con api.anthropic.com — parla con il tuo proxy, che inoltra ad Anthropic (o altrove) con l'auth che controlli tu. Per un team, questo cambia tre cose in una volta:

  • Una chiave virtuale condivisa per developer. Emetti e revochi chiavi nella UI del proxy. Niente credenziali root condivise nei file .env.
  • Budget e log per-developer. Il proxy tagga ogni richiesta, quindi "chi ha speso i $300 ieri" è una query al database, non un incident.
  • Aliasing dei modelli. Puoi pinnare claude-sonnet-4-6 al proxy così una deprecazione di modello è un cambio di config in una riga, non un grep su tutto il repo.

Avvia un proxy minimale in tre passi:

Guided walkthrough1 of 3
  1. In un venv fresco o via uv: uv tool install 'litellm[proxy]'. Questo installa il gateway server (FastAPI + admin UI) insieme all'SDK client.

Il file di config che fa funzionare tutto questo:

config.yaml — Claude Sonnet/Opus/Haiku dietro LiteLLM

model_list:
- model_name: claude-opus-4-7
  litellm_params:
    model: anthropic/claude-opus-4-7
    api_key: os.environ/ANTHROPIC_API_KEY
- model_name: claude-sonnet-4-6
  litellm_params:
    model: anthropic/claude-sonnet-4-6
    api_key: os.environ/ANTHROPIC_API_KEY
- model_name: claude-haiku-4-5-20251001
  litellm_params:
    model: anthropic/claude-haiku-4-5-20251001
    api_key: os.environ/ANTHROPIC_API_KEY

litellm_settings:
master_key: os.environ/LITELLM_MASTER_KEY
# Optional: enable exact-match prompt caching
cache: true
cache_params:
  type: redis
  host: os.environ/REDIS_HOST

Poi, dalla shell di qualsiasi developer:

Punta Claude Code al proxy (.env per-developer)

export ANTHROPIC_BASE_URL="https://llm.internal.example.com"
export ANTHROPIC_AUTH_TOKEN="sk-team-alice-9f4c..."   # a VIRTUAL key issued by the proxy

# now every Claude Code call goes through YOUR gateway
claude --model claude-sonnet-4-6

La vittoria meno ovvia è la chiave virtuale. La master key è admin-only e non finisce mai sui laptop. Ogni developer riceve una chiave virtuale che mappa solo ai modelli che permetti, ha il suo budget mensile e può essere revocata in pochi secondi senza ruotare la chiave Anthropic sottostante. Se un laptop viene perso, killi una riga in Postgres — non l'accesso di tutto il team.

Attenzione: le stesse variabili env funzionano con le integrazioni Bedrock e Vertex di Anthropic, ma ci sono edge case con le feature beta sperimentali. Per deploy Bedrock la doc LiteLLM raccomanda di impostare CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 in ~/.claude/settings.json per evitare problemi di compatibilità degli header.

Workflow killer #2: fallback silenzioso con OpenRouter​

Se non vuoi ospitare niente, l'array di fallback di OpenRouter è il percorso più breve per "ritenta silenziosamente un altro modello quando Claude fa 429". Mandi una lista ordinata; OpenRouter la percorre top-down e restituisce il primo modello che ha risposto.

Fallback Claude → GPT → Gemini in una richiesta (OpenRouter)

import openai

client = openai.OpenAI(
  api_key="YOUR_OPENROUTER_KEY",
  base_url="https://openrouter.ai/api/v1",
)

response = client.chat.completions.create(
  model="anthropic/claude-sonnet-4.5",
  extra_body={
      # Ordered fallback. If the first model 429s, is down, or is
      # rejected by moderation, OpenRouter tries the next one.
      "models": [
          "anthropic/claude-sonnet-4.5",
          "openai/gpt-5.4",
          "google/gemini-2.5-pro",
      ],
  },
  messages=[{"role": "user", "content": "Explain B-trees in one paragraph."}],
)

# 'model' in the response tells you which one actually answered.
print(response.model, "->", response.choices[0].message.content)

Tre cose che la gente non nota al primo tentativo:

  • La fattura segue il modello che ha risposto, non quello che hai chiesto. Se Claude fallisce e GPT-5.4 risponde, paghi la tariffa GPT-5.4 di OpenRouter per quella richiesta.
  • Il fallback scatta su più che solo 5xx. Rate limit, downtime del provider, errori di validazione del context length e rifiuti da moderazione dei contenuti promuovono tutti al modello successivo. Quest'ultimo è il bordo più tagliente — un rifiuto per "moderazione" da un provider può reindirizzare silenziosamente a uno più permissivo, che può essere o non essere quello che vuoi. Rivedi la tua lista di fallback con la stessa cura di una ACL.
  • Non puoi mischiare models con fallbacks. L'endpoint Messages in formato Anthropic usa un array fallbacks diverso. Mandare entrambe le chiavi nella stessa richiesta restituisce 400. Scegli il formato che parla il tuo client e attieniti a quello.

L'incidente supply-chain LiteLLM di marzo 2026: cosa fare davvero​

Il 24 marzo 2026 alle 10:39 UTC, due release PyPI malevole di LiteLLM — v1.82.7 e v1.82.8 — sono state pubblicate da un attaccante dopo che aveva rubato le credenziali PyPI del maintainer via una compromissione precedente di Trivy, un security scanner che girava nella pipeline CI/CD di LiteLLM. PyPI ha messo in quarantena i pacchetti alle 13:38 UTC (circa tre ore dopo). Durante la finestra di esposizione sono avvenuti decine di migliaia di download. Il payload era un infostealer con un meccanismo di persistenza (un file litellm_init.pth che girava a ogni invocazione Python, raccoglieva credenziali e installava una backdoor systemd). L'attribuzione è a un gruppo tracciato come TeamPCP, che ha anche compromesso Trivy e Checkmarx KICS.

Se fai girare LiteLLM in qualsiasi ambiente, applica questo una volta e poi tienilo nel playbook di piattaforma:

Guided walkthrough1 of 5
  1. v1.82.6 e precedenti sono pulite. v1.83.0 e successive (pubblicate via la pipeline CI/CD v2 ricostruita di LiteLLM) sono pulite. Tutto quello che sta in mezzo va disinstallato e l'ambiente considerato contaminato. L'immagine Docker ufficiale (ghcr.io/berriai/litellm) NON è stata compromessa — l'incidente ha riguardato solo PyPI.

La lezione più ampia non è "non usare LiteLLM" — è "considera che ogni dipendenza nel tuo stack AI, security scanner inclusi, può essere un vettore di consegna". Pinna le versioni, firma le immagini e metti il tuo gateway su un segmento di rete che raggiunge solo i provider modello.

Scegli il gateway giusto per la tua situazione​

Guided walkthrough1 of 5
  1. Uno o due provider con un team piccolo → salta il gateway; gli SDK diretti vanno bene. Tre+ provider O un team dove 'chi ha la chiave' conta → gateway. Se hai DevOps e requisiti di privacy, self-hosta LiteLLM o Portkey OSS. Se preferisci pagare qualcun altro perché lo faccia girare, OpenRouter (solo hosted) o Vercel AI Gateway (ottimo se già ci deploi).

Combinazioni comuni che vanno in produzione:

  • Solo dev / prototipo: OpenRouter diretto. Una chiave, 300+ modelli, fatto.
  • Team piccolo, Claude-first: proxy LiteLLM con Anthropic + un provider di fallback, chiavi virtuali per ingegnere, prompt caching Redis.
  • Prodotto Vercel-native: Vercel AI Gateway con l'AI SDK; aggiungi OpenRouter come fallback provider-options per modelli esotici.
  • Regolato / EU: LiteLLM o Portkey OSS self-hosted in-VPC con mascheramento PII Presidio davanti (vedi Claude + Modelli Locali per il pattern di redazione).
  • Prodotto AI con traffico ripetuto pesante: Portkey (il caching semantico tipicamente porta 30–50% di riduzione costi su carichi chat-style, secondo i case study di Portkey — verifica sul tuo traffico prima di credere ai titoloni).

Cosa NON risolve un gateway​

I gateway sono middleware — cambiano come raggiungi i modelli, non quale modello è quello giusto. Due cose richiedono ancora lavoro serio:

  • Portabilità dei prompt. Claude, GPT e Gemini rispondono allo stesso prompt in modi diversi, e le convenzioni del system prompt variano. Un gateway non riscrive il tuo prompt per il provider di fallback — a quello servono Portare i prompt tra modelli e Traduzione cross-AI.
  • Eval. Il gateway rende facile fare A/B tra due modelli sulla stessa richiesta. Non può dirti quale è stato effettivamente migliore sul TUO task. Fai una vera eval (vedi Evals) prima di cambiare il default.

Un errore comune è installare un gateway e considerare "multi-modello" fatto. Il gateway è il transport layer; portabilità ed eval sono il product layer.

Verifica te stesso

0/5
  1. Qual è il motivo principale per mettere un AI gateway tra la tua app e i provider modello, una volta che ne usi più di due?
  2. Punti Claude Code a un proxy LiteLLM con ANTHROPIC_BASE_URL. Che cosa deve essere ANTHROPIC_AUTH_TOKEN?
  3. L'array di fallback di OpenRouter promuove al modello successivo quando il primo fallisce. Su quale di questi scatta?
  4. Devi installare LiteLLM in produzione. Quali versioni sono sicure dopo l'incidente di marzo 2026?
  5. Sei un dev solo su Vercel che vuole provare Claude, GPT e Gemini in un pomeriggio. Miglior fit?
AI gateway in sintesi
Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.
1 / 9
Key takeaways
  • Un AI gateway è il router mancante tra la tua app e ogni modello — esiste per rendere chiavi virtuali, budget, fallback, logging e caching una sola implementazione invece di N per provider
  • Scegli su DUE assi prima: self-hosted vs. hosted (LiteLLM/Portkey OSS vs. OpenRouter/Vercel), e minimalista vs. control-panel (OpenRouter/Vercel vs. LiteLLM/Portkey)
  • Il workflow killer per Claude Code: punta ANTHROPIC_BASE_URL al tuo proxy LiteLLM ed emetti chiavi virtuali per-developer — il team ottiene limiti condivisi, log e revoca one-click senza toccare la chiave Anthropic root
  • L'array models[] di OpenRouter è il percorso più breve al fallback silenzioso Claude → GPT → Gemini, ma nota che i rifiuti per moderazione sono anche loro un trigger di fallback — rivedi la lista come una ACL
  • Dopo l'attacco supply-chain LiteLLM di marzo 2026, pinna a v1.82.6 o precedenti, o v1.83.0+; preferisci l'immagine Docker firmata a pip; egress-allowlist il proxy
  • Un gateway è transport, non prodotto — portabilità dei prompt ed eval richiedono ancora lavoro serio, indipendentemente da quanti modelli puoi ora raggiungere

Fonti e approfondimenti​

Correlati su questo sito: Claude + Modelli Locali: Pattern Ibridi · Portare i prompt tra modelli · Traduzione cross-AI · Evals · Quanto costano gli AI tra provider