OpenRouter o accesso diretto: scegliere come chiamare gli LLM

I tre modi per mettere in produzione una chiamata a un LLM

1) API diretta del fornitore

Ti integri con l’endpoint di un unico fornitore e gestisci tutto il resto: tentativi ripetuti, alternative di riserva, monitoraggio dell’utilizzo, rotazione delle chiavi e failover.

È la strada più lineare quando:

• sai già quale modello vuoi usare,
• la latenza è importante,
• i requisiti di conformità richiedono una catena di fornitori più ristretta,
• e il tuo traffico è abbastanza stabile da consentirti di pianificare tenendo conto dei limiti di un solo fornitore.

2) Gateway / aggregatore / relay

Invii le richieste a un livello intermedio che le inoltra a uno dei numerosi fornitori. OpenRouter è l’esempio più noto, ma questo schema va oltre qualsiasi singola azienda.

È una soluzione interessante quando:

• vuoi poter scegliere tra più modelli con un’unica integrazione,
• hai bisogno di instradamento verso alternative di riserva,
• sperimenti spesso con i modelli,
• oppure non vuoi gestire più SDK di fornitori e account di fatturazione.

3) Hosting autonomo

Esegui un modello aperto sulla tua infrastruttura, solitamente dietro un tuo router.

È la scelta migliore quando:

• il controllo dei dati non è negoziabile,
• il volume è abbastanza elevato da mantenere l’hardware occupato,
• oppure hai bisogno di costi per token prevedibili e puoi sostenere l’onere della gestione operativa.

Cosa cambia nella pratica

Ecco l’aspetto che spesso sfugge: la scelta migliore di solito non dipende soltanto dal prezzo puro dei token. Dipende dall’intera catena dei possibili guasti.

La tabella nasconde una verità importante: un gateway raramente fa risparmiare per magia. Fa risparmiare quando evita una progettazione eccessivamente complessa, riduce i tempi di inattività o consente di instradare automaticamente le attività verso il modello più economico che soddisfa i requisiti.

Dove si generano davvero i risparmi

Se usi un unico modello per tutto, chiamarlo direttamente è spesso la soluzione più semplice ed economica. Ma la maggior parte dei sistemi reali è più complessa:

• la chat del prodotto usa un modello premium,
• le bozze per l'assistenza usano un modello più economico,
• la generazione di riassunti usa un modello piccolo e veloce,
• e i picchi di traffico richiedono capacità aggiuntiva.

È qui che un relay può essere utile. Non perché abbia prezzi di listino inferiori, ma perché consente di prendere decisioni di instradamento in modo centralizzato.

Una policy semplice potrebbe essere questa:

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

Questa configurazione non è specifica di un fornitore; è la struttura di un router ben progettato. In pratica, i risparmi derivano dall'eliminazione degli sprechi:

• non inviare ogni attività di estrazione al modello più costoso,
• non continuare all'infinito a riprovare con un fornitore instabile,
• non mantenere attiva una seconda integrazione solo per quel 2% di traffico che aumenta il venerdì.

Un'insidia comune: se la tua app effettua chiamate a strumenti o produce effetti collaterali, i nuovi tentativi possono duplicare le azioni. Se un gateway ripete una richiesta dopo un timeout, il modello potrebbe generare nuovamente la stessa chiamata di funzione. Senza chiavi di idempotenza e una progettazione attenta degli strumenti, il «fallback utile» diventa «ticket duplicato» o «pagamento addebitato due volte».

Quando un gateway è davvero utile

Sceglierei un aggregatore o un relay quando si verifica una o più di queste condizioni:

• Stai ancora imparando a conoscere il carico di lavoro. All'inizio non sai se GPT-5.5, Claude Opus 4.8, Sonnet 4.6, Gemini 3 o un modello aperto sarà la scelta migliore per la tua attività.
• Vuoi instradare in base all'attività, non al fornitore. Un classificatore può inviare i prompt brevi a un modello economico e veloce e le attività con contesti lunghi a un modello come Fable 5, quando è effettivamente più adatto.
• Ti serve una strategia di fallback rapido. Se un fornitore inizia a limitare la frequenza delle richieste, il relay può spostare il traffico prima che gli utenti se ne accorgano.
• Non vuoi cinque sistemi di fatturazione. Una sola fattura e una sola integrazione sono più facili da gestire rispetto a più chiavi, quote e dashboard di spesa.
• Ti serve un livello di astrazione per prodotti multi-tenant. Un gateway consente di cambiare fornitore dietro le quinte senza riscrivere l'app.

Questo è particolarmente utile se il tuo team è piccolo. Ho visto team di startup dedicare più tempo a implementare logiche di retry specifiche per ciascun fornitore che a creare valore nel prodotto. Un relay può concentrare quel lavoro in un unico punto.

Quando la chiamata diretta è la scelta migliore

Le API dirette dei fornitori sono generalmente la scelta migliore quando ti interessa uno qualsiasi dei seguenti aspetti:

• Latenza minima. Un passaggio in meno conta quando il budget di latenza del prodotto è ridotto. Se vuoi un'interazione da 300 ms che «sembri istantanea», aggiungere il sovraccarico di rete e instradamento può consumarne una parte considerevole.
• Confini rigorosi di conformità. Ogni responsabile del trattamento aggiuntivo comporta un'altra relazione, un altro insieme di regole di conservazione e un'altra revisione contrattuale.
• Funzionalità specifiche del fornitore. Alcuni fornitori offrono funzionalità che gli aggregatori eliminano durante la normalizzazione o supportano in ritardo.
• Volumi elevati e prevedibili. Quando l'utilizzo diventa stabile, un instradamento personalizzato può essere più economico che pagare un livello intermedio.
• Canali di assistenza più chiari. Quando qualcosa si guasta, ci sono meno scaricabarile.

Il vantaggio nascosto è la chiarezza operativa. Se il percorso delle chiamate è diretto, la causa principale di un errore è più facile da isolare. Se una chiamata fallisce, di solito il problema è nel tuo codice o nel fornitore. Con un gateway, devi anche chiederti se la responsabilità sia del relay, del suo livello di instradamento o del fornitore a monte.

Il self-hosting è un'altra partita

Ospitare autonomamente modelli aperti non significa semplicemente avere «un'API più economica, ma sul mio server». È un problema di gestione dei sistemi.

Devi considerare:

• il dimensionamento e l'utilizzo delle GPU,
• l'elaborazione in batch,
• la quantizzazione,
• la pressione sulla cache KV,
• il ridimensionamento automatico,
• gli avvii a caldo,
• i filtri di sicurezza,
• gli aggiornamenti dei modelli,
• e le procedure di rollback.

Il vantaggio è il controllo. Se il carico di lavoro è stabile e sufficientemente elevato, il self-hosting può essere economicamente interessante. Ma i conti tornano solo se mantieni l'hardware occupato. Le GPU inattive sono costose. Lo è anche il tempo di sviluppo necessario per far funzionare correttamente sotto pressione uno stack di erogazione dei modelli.

L'altra insidia comune è la deriva della qualità. Un modello aperto potrebbe essere sufficiente per generare riassunti oggi, ma le tue valutazioni possono peggiorare drasticamente quando cambiano la lunghezza dei prompt, i requisiti di stile o l'uso degli strumenti. Non presumere che «aperto» significhi automaticamente «abbastanza economico da sostituire un'API gestita».

Un approccio ibrido pratico

Nei sistemi reali, l'architettura migliore è spesso mista:

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

E all'interno dell'app:

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

Questo approccio mantiene semplice il percorso critico, offrendo comunque flessibilità nell'instradamento. Ho riscontrato che spesso è qui che i team arrivano dopo il primo mese in produzione: chiamate dirette per l'esperienza utente principale, gateway per la sperimentazione e il traffico in eccesso, self-hosting solo dove i vantaggi economici o di privacy sono indiscutibili.

Privacy, latenza e fiducia

È qui che l'ingegneria si traduce in politiche.

Privacy

Un gateway modifica il perimetro di fiducia. Anche se i prompt vengono inoltrati a monte, devi comunque rispondere a queste domande:

• Il relay registra i prompt?
• Per quanto tempo vengono conservati?
• Quali sub-responsabili del trattamento possono vederli?
• Puoi mantenere determinati tenant su un percorso con restrizioni?
• È supportato il vincolo a una regione specifica?

Per i carichi di lavoro soggetti a regolamentazione, «il fornitore ha promesso di comportarsi bene» non basta. Ti servono una traccia documentale e una progettazione coerente con essa.

Latenza

Un relay aggiunge un altro passaggio. Questo non rende automaticamente lenta l'app, ma aggiunge incertezza. Se la tua app scambia molte richieste e lo streaming dei token è importante, ogni livello aggiuntivo può rendere meno prevedibile il tempo di arrivo del primo token.

Limiti di frequenza

Le integrazioni dirette espongono senza mediazioni i limiti del fornitore. I gateway possono attenuarli distribuendo il traffico tra più fornitori, ma possono anche introdurre limitazioni proprie. In altre parole: potresti sostituire un limite con un altro. Il vantaggio è l'elasticità, non l'immunità.

La regola decisionale che uso

Se dovessi riassumere la scelta in una frase: usa chiamate dirette quando conosci il modello e ti interessa il percorso delle chiamate; usa un gateway quando ti interessano la flessibilità di scelta e la resilienza; scegli il self-hosting quando il controllo e un utilizzo costante giustificano i costi operativi.

Alcune regole pratiche concrete:

• Inizia con chiamate dirette se stai rilasciando la tua prima funzionalità in produzione e ti serve un solo modello.
• Aggiungi un gateway quando hai almeno due classi distinte di modelli o quando il failover inizia a emergere nelle analisi degli incidenti.
• Scegli il self-hosting solo quando disponi di dati reali sull'utilizzo e di un motivo chiaro per gestire lo stack in proprio.
• Usa un gateway per sperimentare con l'instradamento, ma mantieni idempotente il percorso critico.
• Misura il costo complessivo, non soltanto il prezzo dei token.

Indicazioni pratiche

• Preferisci le API dirette per una latenza più lineare, un debug più semplice e il miglior supporto specifico del fornitore.
• Preferisci un gateway/aggregatore quando ti servono instradamento tra più modelli, copertura di fallback o un'unica integrazione per molti fornitori.
• Preferisci il self-hosting solo quando puoi mantenere l'hardware occupato e accettare la complessità operativa.
• Implementa l'idempotenza e una gestione rigorosa dei nuovi tentativi prima di aggiungere fallback automatici.
• Confronta costo totale: token, maggiorazioni, nuovi tentativi, tempo di sviluppo e ripristino dopo gli incidenti.
• Mantieni privacy e conservazione dei dati nella decisione fin dal primo giorno, non dopo che l'ufficio acquisti solleva la questione.
• Usa un' architettura ibrida se il tuo carico di lavoro include sia percorsi premium sia percorsi standard.

Se vuoi, posso trasformarlo in una versione con una posizione più netta, rivolta a un pubblico specifico, come chi sviluppa startup, i team di piattaforma o i team aziendali con requisiti di conformità stringenti.