Serve davvero il Multi-LLM Failover, o Basta un Buon Provider?

La maggior parte dei prodotti non ha bisogno del multi-LLM failover fin dal primo giorno. Si costruisce su un unico provider, si racchiude la chiamata al modello dietro un'interfaccia sottile in modo che cambiare provider in seguito sia una modifica di configurazione, e si aggiunge un secondo provider solo dopo che un'interruzione, un rate limit o una variazione di prezzo ha effettivamente avuto un costo misurabile.

Questa è la risposta scontata, ed è quella giusta per circa il 90% dei founder che ce lo chiedono. Ma la domanda continua a tornare, soprattutto ora che gli strumenti che promettono "una sola chiave API per ogni modello" (GPT, Claude, Gemini, Grok, DeepSeek, Kimi) stanno attirando attenzione. Il pitch è allettante: mai più lock-in su un unico vendor, aggiramento delle interruzioni, arbitraggio sui prezzi. La realtà è più sfumata, e sbagliare in un senso o nell'altro ha un costo.

Perché la questione sembra urgente proprio adesso

Tutti i provider hanno avuto giornate difficili. La pagina di stato di OpenAI e quella di Anthropic mostrano entrambe incidenti periodici di performance degradata, solitamente nell'ordine di minuti fino a un paio d'ore. Se il proprio prodotto invia una richiesta rivolta al cliente direttamente a un unico modello senza fallback, un'interruzione di 45 minuti si traduce in 45 minuti di prodotto non disponibile, anche se il resto dello stack funziona perfettamente.

I rate limit sono la modalità di guasto più comune. La documentazione sui rate limit di OpenAI e quella di Anthropic scalano entrambe i limiti in base al tier di utilizzo, il che significa che il momento in cui si registra un picco di traffico (un lancio di prodotto, una menzione sulla stampa, una funzionalità virale) è esattamente quando è più probabile raggiungere un tetto mai toccato prima.

La deprecazione dei modelli è quella silenziosa. I provider ritirano le versioni dei modelli secondo una pianificazione, e se i propri prompt erano stati ottimizzati sulle peculiarità di un modello specifico, il sostituto può modificare la qualità dell'output in modi che gli utenti notano prima di noi.

Le ragioni per non costruirlo adesso

Vediamo team ricorrere a un'astrazione multi-provider completa prima ancora di aver rilasciato una singola funzionalità che la utilizzi davvero. Si tratta di infrastruttura prematura, e ha un costo reale: ogni livello di indirezione tra la logica di business e la chiamata al modello è un posto dove un bug può nascondersi, ed è codice da mantenere anche se non si fa mai effettivamente failover.

Abbiamo imparato una versione di questa lezione costruendo i nostri strumenti di outreach. Analizziamo il sito di ogni prospect e scriviamo un'email personalizzata con una singola chiamata LLM che sia estrae i fatti rilevanti sia redige la bozza, senza catene multi-step, senza livelli di orchestrazione. Abbiamo provato prima la pipeline multi-call "più robusta", dando per scontato che fosse più affidabile. Non lo era: era più lenta, più costosa per email, e falliva in più punti. La singola chiamata era più economica, più veloce e più facile da debuggare. La lezione si generalizza: non si aggiunge complessità architetturale per difendersi da una modalità di guasto che non si è ancora sperimentata. La stessa logica vale per la ridondanza dei provider. Se un'interruzione non ha mai fatto perdere un cliente, probabilmente si sta ottimizzando per un problema che non esiste. È lo stesso istinto alla base del perché un design semplice a chiamata singola batte quasi sempre le catene di agenti per i task ben definiti.

Quando vale davvero la pena

Il supporto multi-provider giustifica la propria complessità in alcune situazioni specifiche:

• Si superano alcune migliaia di richieste al giorno e i rate limit sono una voce ricorrente nel log degli incidenti, non un'ipotesi.
• Il prodotto è customer-facing e sincrono (un widget di chat, un agente vocale), dove anche pochi minuti di inattività del provider sono visibili agli utenti finali in tempo reale, a differenza di un job in background che può semplicemente fare un retry tra un'ora.
• Si ha un carico di lavoro specifico sensibile ai costi in cui instradare le richieste meno costose (classificazione, estrazione) verso un modello più piccolo e riservare un modello frontier al ragionamento complesso cambia significativamente i propri unit economics. Questo si sovrappone in larga misura al lavoro generale di ottimizzazione dei costi LLM che andrebbe comunque fatto.
• Si è soggetti a un requisito contrattuale o di compliance che impone di evitare la dipendenza da un unico vendor, il che emerge più spesso in ambito sanitario e negli appalti pubblici di quanto la maggior parte dei founder si aspetti.

Se nessuna di queste condizioni si applica, si sta costruendo un'assicurazione contro un rischio che non si è ancora quantificato.

Come farlo senza eccedere

Se si è deciso che serve davvero, non si costruisca un router da zero. Progetti come OpenRouter e LiteLLM risolvono già il problema dell'API unificata: un'unica interfaccia, più backend, gestione degli errori coerente. Il lavoro di ingegneria su cui concentrarsi è invece:

1. Isolare la chiamata al modello. Un'unica funzione o modulo che si occupa di "inviare questo prompt, ricevere questa risposta." Tutto il resto nel codebase chiama quella, mai direttamente l'SDK del provider.
2. Normalizzare i prompt, non solo le chiamate API. Modelli diversi rispondono diversamente alle stesse istruzioni. Un router che cambia provider ma invia esattamente lo stesso prompt degraderà silenziosamente la qualità dell'output sul modello di fallback, a meno che non lo si sia testato.
3. Aggiungere le eval prima del failover. Non si può fare failover in sicurezza su un secondo modello se non si ha un modo per misurare se il suo output è sufficientemente buono. È la stessa disciplina raccomandata quando si negoziano le eval nei contratti con vendor AI: bisogna sapere come appare "buono" prima di doverlo dimostrare sotto pressione.
4. Definire esplicitamente la propria policy di fallback. Riprova con lo stesso provider, passa a un altro provider, o degrada in modo controllato (risposta cached, funzionalità semplificata, handoff a un operatore umano)? Ciascuna opzione ha un costo diverso e una diversa modalità di guasto, e "basta passare a GPT" non è una policy.

Il framework decisionale concreto

Prima di scrivere una riga di codice di routing, ci si faccia tre domande: quante volte nell'ultimo trimestre un'interruzione del provider o un rate limit ha effettivamente fatto perdere un cliente o causato una funzionalità rotta? Quanto costerebbe, in termini di tempo di engineering, costruire e mantenere un secondo percorso di integrazione? E il rischio contro cui ci si vuole assicurare sta aumentando o diminuendo con la maturazione dell'infrastruttura del provider? Se la risposta alla prima domanda è "mai, ma sono preoccupato," si lancia su un unico provider e si rivaluta tra tre mesi. Se è "due volte il mese scorso," il business case è già chiaro.

Il rischio legato al vendor è reale, ma lo è anche il rischio di rilasciare un sistema più complesso di quanto l'utilizzo giustifichi. Se si sta valutando questo trade-off per un prodotto specifico, parliamone di come appaiono le reali modalità di guasto prima di costruire attorno a quelle ipotetiche.