Self-Hosting di un LLM vs. API: Quando Conviene Davvero

Il self-hosting di un LLM conviene in due situazioni: si gestisce un volume sufficientemente alto da rendere il costo GPU per token inferiore al costo API per token, oppure si hanno requisiti di residenza dei dati che le chiamate API non possono soddisfare a prescindere dal prezzo. Al di fuori di questi due casi, chiamare l'API di OpenAI, Anthropic o Google è più economico, più rapido da mettere in produzione e più facile da mantenere rispetto a gestire un proprio stack di inferenza.

Questa domanda arriva spesso da founder nel settore healthcare e govtech, perché "i dati possono uscire dalla nostra rete?" non è quasi mai una questione di costi, bensì una questione legale. Per questo il framework qui sotto separa la decisione in due dimensioni — costo e compliance — perché di solito si ha bisogno di una sola delle due risposte, non di entrambe.

I conti sul costo, nel dettaglio

Una singola NVIDIA A100 80GB costa circa $2-3 all'ora on-demand da provider come Lambda o CoreWeave. Farla girare 24/7 per un mese significa $1.500-2.200, indipendentemente dal fatto che elabori una richiesta o un milione. Questo è il problema centrale del self-hosting: si paga per la capacità, non per l'utilizzo.

A confronto, i prezzi API prevedono un pagamento per token e nulla quando il sistema è inattivo. Per un workload che elabora, diciamo, 5 milioni di token al giorno su un modello di fascia media, i costi API si attestano generalmente ben sotto i $1.500/mese, con zero onere operativo. Il punto di pareggio in cui una GPU dedicata inizia a essere conveniente si trova di solito oltre i 20-50 milioni di token/giorno di traffico sostenuto e prevedibile — e anche in quel caso è necessario qualcuno che mantenga lo stack di serving (vLLM, TGI o simili) e gestisca guasti GPU, aggiornamenti driver e scaling.

Abbiamo affrontato una versione di questo calcolo in prima persona. Il nostro tool di cold outreach effettua lo scraping del sito di ciascun prospect con un'istanza Firecrawl in self-hosting e un modello locale per estrarre informazioni e bozzare un'email in una singola chiamata. Al nostro volume, eseguire questo step in locale era più economico e ci dava maggiore controllo sui rate limit rispetto a instradare ogni scraping attraverso un'API hosted — ma non abbiamo messo in self-hosting il copywriting commerciale vero e proprio: quello passa ancora da un modello hosted, perché il volume non giustifica una GPU dedicata e il livello qualitativo richiesto è più alto. Combinare i due approcci — self-hosted per task deterministici a basso costo, API per la generazione ad alto impatto — è di solito la forma giusta per i prodotti in fase early-stage. È lo stesso ragionamento che esponiamo in ottimizzazione dei costi LLM: abbinare il livello del modello e il modello di hosting al task, non il contrario.

Da dove vengono i costi "nascosti" del self-hosting

• Infrastruttura di serving. vLLM o Text Generation Inference gestiscono il batching e il KV-cache, ma qualcuno deve operarli, aggiornarli e gestire i crash OOM sotto carico.
• Aggiornamenti del modello. I modelli open-weight migliorano rapidamente. Scegliere il self-hosting significa farsi carico del ciclo di fine-tuning e valutazione ogni volta che esce un modello base migliore, invece di lasciare che sia il provider a sostituirlo in modo trasparente.
• Ridondanza. Un singolo nodo GPU è un single point of failure. Un uptime reale richiede almeno due nodi, il che raddoppia grosso modo il costo base indicato sopra.

Il caso compliance, che è un'altra questione entirely

Se il driver è la residenza dei dati, il PHI o un contratto con un cliente che vieta l'invio di dati a terze parti, il calcolo economico di cui sopra è in larga misura irrilevante. Non si confrontano dollari, si confronta "possiamo farlo legalmente oppure no". È la situazione in cui si trovano molti dei nostri clienti in ambito healthcare e pubblico, ed è lo stesso territorio che trattiamo in architettura court-ready per l'AI in sanità.

Alcune precisazioni importanti:

• Il self-hosting risolve il problema "i dati escono dalla nostra rete", ma di per sé non rende conformi a HIPAA. Servono comunque cifratura a riposo e in transito, logging degli accessi e una policy di retention documentata attorno al modello e ai suoi log.
• I provider di API gestite offrono endpoint coperti da BAA e idonei a HIPAA (sia OpenAI che Anthropic li propongono ai clienti enterprise), quindi "abbiamo bisogno della conformità HIPAA" non implica automaticamente "dobbiamo fare self-hosting". È opportuno verificare questa opzione prima di assumere di aver bisogno di GPU proprie.
• I contratti con enti governativi e della difesa sono un discorso a parte. Molti richiedono che il modello e i dati risiedano in un ambiente accreditato (FedRAMP, IL4/IL5 o completamente air-gapped), dove un'API pubblica è esclusa a prescindere da qualsiasi BAA. È in questo contesto che il self-hosting cessa di essere opzionale.

La qualità dei modelli open-weight, senza filtri

Per task circoscritti — classificazione, estrazione, triage strutturato, intent routing — un modello open-weight fine-tuned o ben prompting sul proprio dominio può eguagliare un modello closed frontier, garantendo al tempo stesso pieno controllo su latenza e privacy. La famiglia Llama di Meta e i modelli Qwen di Alibaba sono entrambi punti di partenza ragionevoli per deployment in self-hosting.

Per il ragionamento aperto, i documenti lunghi o qualsiasi scenario in cui il rischio è "una risposta sottilmente sbagliata che suona convincente", i modelli frontier via API hanno ancora un vantaggio. Non conviene fare self-hosting per risparmiare su un task in cui il giudizio del modello è il prodotto, rischiando una regressione qualitativa.

Un percorso decisionale pratico

1. Stimare il volume reale di token, non di richieste. Moltiplicare i token medi per richiesta per il numero di richieste giornaliere. Se si è sotto i 10-20M token/giorno, conviene iniziare con un'API.
2. Verificare se un endpoint HIPAA/BAA-eligible da un provider principale soddisfa il requisito di compliance. In caso affermativo, il self-hosting probabilmente non è necessario.
3. Se né il costo né la compliance impongono una scelta, non fare self-hosting. L'onere operativo distrae dallo sviluppo del prodotto nei primi 12-18 mesi di vita di un'azienda.
4. Se si sceglie il self-hosting, prevedere nel budget la ridondanza e una rotazione on-call stabile, non solo la voce GPU.

La stessa logica si applica alla scelta tra provider gestiti e bring-your-own-key, come illustrato in BYOK vs. chiavi LLM gestite: l'opzione che sembra più economica sulla carta è raramente la più economica una volta considerato il carico operativo che comporta per il team.

Se si vuole capire dove si colloca il proprio prodotto su questa linea, parliamone.