Vendor-agnostic: perché non mi sono legato a nessun modello AI

Nel 2023, molti hanno costruito prodotti interamente sopra le API di OpenAI. Poi sono arrivati i cambi di pricing, le deprecazioni di modelli, le modifiche ai rate limit. Chi aveva costruito direttamente su quelle API ha dovuto riscrivere codice. Chi aveva un layer di astrazione, ha cambiato una riga di configurazione.

Ho imparato da quella storia prima che mi riguardasse direttamente.

Il rischio del lock-in

Il lock-in tecnologico sui modelli AI è sottile perché non sembra un rischio immediato. Claude funziona benissimo oggi. Perché dovrei preoccuparmi di cosa succede se cambia qualcosa?

Perché l'infrastruttura AI si muove a una velocità che non ho mai visto in altri settori. In diciotto mesi ho visto provider sparire, API cambiate senza preavviso, modelli deprecati con un mese di notice, prezzi raddoppiati e dimezzati, nuovi modelli che ridefiniscono il benchmark di riferimento ogni trimestre.

Costruire un'infrastruttura di agenti direttamente sulle API di un singolo provider in questo contesto è come avere un unico fornitore per un componente critico del tuo business. Funziona finché funziona. Quando smette, ti ritrovi in emergenza.

Non voglio essere in emergenza. Voglio poter cambiare provider in un giorno, non in sei mesi.

LiteLLM — il proxy che astrae tutto

LiteLLM è un server open source che espone un'API unificata compatibile con le specifiche OpenAI. Dietro quel layer di astrazione può girare qualsiasi modello: Claude di Anthropic, GPT-4 di OpenAI, Gemini di Google, Mistral, Llama in self-hosted, qualsiasi cosa che supporti le API standard.

Sulla mia VPS gira come container Docker sulla porta 4000. Ogni agente nel sistema parla con http://localhost:4000 — non con api.anthropic.com, non con api.openai.com. Il codice degli agenti non sa da quale provider arriva la risposta. Non gli interessa.

La configurazione di routing vive in un file YAML su LiteLLM:

model_list:
  - model_name: claude-sonnet-4-6
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: fast-model
    litellm_params:
      model: anthropic/claude-haiku-3-5
      api_key: os.environ/ANTHROPIC_API_KEY

Se domani voglio passare da Claude a Gemini per un certo tipo di task, cambio due righe in quel file. Zero modifiche al codice degli agenti.

Come lo uso in pratica

Non tutti i task richiedono lo stesso modello. Questa è la prima cosa che ho imparato lavorando con un sistema multi-agente.

Classificare un documento in ingresso, estrarre metadati strutturati, formattare un output — questi task non richiedono Claude Sonnet. Un modello più piccolo e veloce li gestisce altrettanto bene, a un decimo del costo e in metà tempo. Ragionamento su architetture complesse, generazione di codice con vincoli multipli, analisi di sistemi distribuiti — qui vale la pena usare il modello migliore disponibile.

Con LiteLLM, il routing è dichiarativo. Definisco le regole una volta:

• Task di classificazione e estrazione: fast-model
• Generazione di codice e ragionamento: claude-sonnet-4-6
• Task critici che richiedono massima precisione: modello premium con fallback

LiteLLM gestisce anche i fallback automatici. Se un provider è irraggiungibile o restituisce un errore, il sistema switcha automaticamente su un'alternativa configurata. Per la maggior parte dei task, l'utente — o l'agente a valle — non vede nessuna interruzione.

Il monitoring è centralizzato: ogni chiamata passa da un punto unico, con logging completo. So esattamente quante chiamate fanno i miei agenti, a quale modello, con quale latenza e costo. Questo da solo giustifica l'architettura.

La filosofia dietro la scelta

Non sono fedele a Claude perché è prodotto da Anthropic. Sono fedele a Claude perché oggi, per i task che mi interessano, è il modello che produce i risultati migliori. Domani potrebbe essere diverso — e se fosse diverso, voglio essere in grado di cambiare senza riscrivere l'infrastruttura.

L'infrastruttura deve sopravvivere ai trend. I trend cambiano ogni tre mesi. L'infrastruttura no.

Costruire su standard aperti invece che su API proprietarie è un principio, non solo una tattica. La specifica OpenAI per le API di completamento è diventata uno standard de facto — LiteLLM la supporta, i provider più seri la supportano, il mio codice la usa. Se tra un anno emerge un framework migliore di LiteLLM con la stessa interfaccia, la migrazione è trasparente.

Cosa significa per chi vuole costruire qualcosa

Il consiglio più concreto che posso dare: metti LiteLLM tra te e i provider adesso, non dopo.

Il costo di implementarlo ora — quando hai tre agenti e due workflow — è basso. Due ore di configurazione, un container in più, e hai un'architettura che scala. Il costo di aggiungerlo dopo — quando hai quaranta agenti integrati direttamente con le API di tre provider diversi — è molto più alto. Devi refactorizzare tutto il codice di chiamata, gestire le differenze di interfaccia tra provider, testare che niente si rompa.

L'indipendenza dai vendor si costruisce prima che ne hai bisogno. Quando ne hai bisogno, è troppo tardi per costruirla senza pagare un prezzo alto.

L'ironia è che LiteLLM, aggiungendo un layer di astrazione, rende il sistema più semplice da ragionare — non più complesso. Un solo punto di configurazione per tutti i modelli. Un solo sistema di monitoring. Un solo posto dove cambio quando qualcosa cambia. Complessità nascosta che diventa semplicità operativa.