Nel 2026, il self-hosting di un grande modello di linguaggio non è più una curiosità da laboratorio. È diventato un'opzione matura, performante ed economicamente difendibile per una parte crescente dei progetti che inquadriamo. I modelli aperti come Mistral Large 2, Llama 3.3 70B, Qwen 2.5 72B o DeepSeek V3 raggiungono ormai il 90-95% delle performance di GPT-4 Turbo o Claude 3.7 Sonnet sulla maggioranza dei casi standard: estrazione, classificazione, sintesi, generazione assistita, RAG. Questo divario di qualità, che era proibitivo nel 2023, si è ridotto al punto che la domanda non è più « è abbastanza buono? » ma « qual è il giusto arbitrato per il nostro business? ».

Questo articolo è rivolto a CTO, CIO e lead engineer che valutano seriamente l'opzione dell'LLM self-hosted. Dettagliamo le sei decisioni strutturanti: criteri di sovranità, scelta del modello, dimensionamento GPU, stack di serving, sicurezza e osservabilità, FinOps. Ci basiamo su ciò che vediamo concretamente nei nostri progetti, senza cedere al discorso marketing dominante. Sovranità non significa « tutto self-host a ogni costo »: la questione è capire dove collocare la frontiera e con quale rigore ingegneristico.

Perché questa questione torna in forza nel 2026

Convergono tre forze. Anzitutto, la regolamentazione si fa più stringente: GDPR per qualsiasi dato personale, HDS per il settore sanitario, NIS2 per gli operatori essenziali, AI Act per i sistemi a rischio, senza contare le esigenze contrattuali specifiche che le grandi imprese impongono ora ai propri fornitori. Molte di queste clausole vietano esplicitamente il trasferimento verso un'API IA non europea, o esigono una tracciabilità completa impossibile da garantire su un'API terza.

Poi, l'ecosistema open-weight ha colmato il ritardo. Mistral Large 2 (123B parametri), Llama 3.3 70B, Qwen 2.5 72B e DeepSeek V3 (671B in MoE, ~37B attivi) sono oggi modelli industriali. Abbinati a server come vLLM o TensorRT-LLM e a hardware NVIDIA H100, A100 o L40S, o anche AMD MI300X, erogano throughput reali di 30-80 token al secondo per richiesta, con un batching dinamico che permette di assorbire diverse centinaia di utenti simultanei su un singolo server correttamente dimensionato.

1. Definire i criteri di sovranità prima di tutto il resto

L'errore più frequente consiste nello scegliere un modello e poi vestire il progetto con un discorso di sovranità. L'approccio rigoroso è inverso: qualificare prima la sensibilità dei dati, gli obblighi normativi e gli impegni contrattuali, poi declinare le implicazioni tecniche. Un dato sanitario identificante impone un hosting HDS e blocca ogni API extra-UE. Un documento classificato da un cliente della difesa impone un isolamento di rete totale. Un segreto aziendale di R&D impone almeno la cifratura in transito e a riposo, e idealmente un'infrastruttura sulla quale l'operatore dell'LLM non abbia accesso.

Nei nostri audit, separiamo sistematicamente tre livelli: dati pubblici o banalizzati (API proprietaria accettabile), dati riservati interni (API europea con DPA rigoroso o self-host cloud sovrano), dati sensibili o regolamentati (self-host obbligatorio, idealmente on-prem o cloud SecNumCloud / HDS). Questa griglia permette di oggettivare il bisogno e di evitare il « tutto o niente » che affossa la maggior parte dei comitati IA.

2. Scegliere il modello open-weight adatto

La scelta del modello dipende da quattro criteri: qualità sui vostri casi, qualità specifica in italiano, dimensione (quindi costo infrastrutturale) e licenza. Mistral Large 2 resta il nostro riferimento per i casi multilingue esigenti: qualità di ragionamento, instruction-following, generazione naturale. Llama 3.3 70B offre un eccellente rapporto qualità/dimensione ma la sua licenza (Acceptable Use Policy) resta vincolante per certi usi ed esclude le piattaforme molto grandi. Qwen 2.5 72B è sorprendentemente forte in codice e matematica. DeepSeek V3, in MoE, offre una qualità prossima a GPT-4 con un costo di serving paradossalmente moderato grazie ai 37B parametri attivi.

Il nostro metodo: non crediamo mai alle classifiche generiche tipo MMLU o Chatbot Arena. Costruiamo un benchmark interno di 50-200 prompt rappresentativi del business del cliente, e misuriamo faithfulness, formato, tono, latenza e costo su ogni modello candidato. È l'unico modo per decidere onestamente.

  • Mistral Large 2 (123B): ottimo multilingue, licenza MRL chiara, deploy 2-4×H100
  • Llama 3.3 70B: miglior rapporto qualità/dimensione, attenzione all'AUP
  • Qwen 2.5 72B: forte in codice e ragionamento, licenza Apache 2.0 parziale
  • DeepSeek V3 (671B MoE): qualità top-tier, costo serving ragionevole nonostante la dimensione

3. Dimensionare l'infrastruttura GPU

Il dimensionamento non ha nulla di intuitivo. Contano tre variabili: la VRAM disponibile, la latenza target (time to first token e token/secondo per utente) e la concorrenza (utenti simultanei). Per un Llama 3.3 70B quantizzato in INT4, una singola H100 80GB basta in POC ma satura rapidamente oltre i 5-10 utenti simultanei. In FP8 servono due H100. Per Mistral Large 2 in produzione, partiamo tipicamente da 2-4×H100 o un nodo 8×L40S secondo il profilo di carico.

Sul lato infrastruttura, dominano due opzioni: acquisto diretto (1×H100 80GB intorno ai 30-40 k€ IVA esclusa, ammortizzabile su 24-36 mesi) o locazione cloud GPU presso Scaleway, OVHcloud, Lambda Labs o RunPod, tra 2,5 e 4 € all'ora secondo il fornitore e l'impegno. Il cloud GPU europeo resta pertinente quando si cerca di conciliare sovranità e flessibilità, a condizione di verificare la giurisdizione reale del fornitore e il suo status SecNumCloud se applicabile.

4. Scegliere lo stack di serving

Quattro opzioni strutturano il mercato. vLLM è diventato il riferimento open-source: PagedAttention, continuous batching, supporto OpenAI-compatible, community massiccia. È la nostra scelta di default. TGI (text-generation-inference di Hugging Face) resta molto solido, particolarmente integrato nell'ecosistema HF, leggermente meno performante di vLLM in throughput ma molto maturo in produzione. TensorRT-LLM di NVIDIA fornisce le migliori performance grezze su hardware NVIDIA, al prezzo di una complessità di compilazione e manutenzione molto più elevata — pertinente solo a grande scala. NVIDIA NIM propone un approccio managed on-prem, con microservizi containerizzati pronti all'uso: interessante quando il team interno non ha un profilo MLOps senior, meno flessibile e più costoso nel tempo.

Per progetti fino a qualche centinaio di utenti concorrenti, vLLM dietro un reverse proxy (Traefik, NGINX) con un client OpenAI-compatible lato applicazione è la combinazione più semplice, performante e manutenibile. È quella che implementiamo nella maggior parte dei nostri progetti di self-hosting.

5. Mettere in sicurezza e osservare l'LLM in produzione

Un LLM self-hosted non è mai una semplice API da esporre. È un componente critico che manipola potenzialmente dati sensibili e che costituisce una nuova superficie di attacco. Imponiamo sistematicamente quattro linee di difesa: isolamento di rete rigoroso (VPC privato, niente accesso diretto a internet), autenticazione applicativa forte (JWT firmati, rotazione), logging completo di prompt e risposte con retention controllata, e guardrail di business (filtri di input, validazione di output, rilevamento di prompt injection).

L'osservabilità tecnica conta altrettanto: monitoring GPU (utilizzo, memoria, temperatura), metriche di serving (TTFT, token/sec, dimensione della coda), tracciabilità applicativa (Langfuse, OpenLLMetry o soluzione in-house). Senza questa telemetria, non saprete né quando la vostra infrastruttura satura, né quando un modello deriva, né da dove proviene una regressione di qualità.

6. FinOps: modellare il TCO onestamente

La questione finanziaria non si riduce al prezzo della GPU. Il TCO reale di un LLM self-hosted integra l'ammortamento hardware o la locazione, l'elettricità e il raffreddamento se on-prem, le competenze MLOps interne o esterne, la manutenzione dei modelli (aggiornamenti ogni 3-6 mesi sull'open-weight), l'osservabilità, la sicurezza e le fasi di upgrade. Sui nostri progetti, costruiamo sempre un comparativo su 24 mesi tra tre scenari: API proprietaria pura, ibrida (API per il picco, self-host per il ricorrente), full self-host.

A titolo indicativo: Mistral Large 2 su 1×H100 80GB in serving vLLM ottimizzato eroga circa 50 token/secondo per richiesta e 1500-2500 token/secondo in throughput aggregato a seconda del batching. Su 30 giorni pieni, ciò rappresenta un volume teorico di diversi miliardi di token, da confrontare con una fattura API equivalente che si conta in decine di migliaia di euro al mese sugli stessi volumi.

Le trappole che fanno fallire i progetti di self-hosting

Quattro trappole tornano nei nostri audit di recupero. Primo, sottostimare l'osservabilità: senza telemetria, il team pilota alla cieca e qualunque guasto diventa un sinistro. Secondo, trascurare la sicurezza di rete: troppi POC vanno in produzione con un endpoint vLLM esposto in chiaro. Terzo, dimenticare il costo ricorrente di aggiornamento dei modelli: un LLM open-weight del 2026 sarà obsoleto nel 2027, va pianificata la cadenza di upgrade fin dall'inquadramento. Quarto, non formare il team: un LLM self-host non si gestisce come un microservizio classico, le competenze MLOps e ML engineering sono indispensabili.

A queste trappole tecniche si aggiunge una trappola strategica: confondere sovranità e performance. Il self-host non rende buono un cattivo caso d'uso. Se il bisogno di business è mal inquadrato, se il RAG è trascurato, se la valutazione è assente, il progetto fallirà con o senza sovranità. Il self-hosting è un mezzo, non un fine.

E adesso?

Se state valutando seriamente il self-hosting di un LLM, il primo passo è qualificare onestamente il vostro bisogno di sovranità, il volume target e la criticità del caso d'uso. È precisamente ciò che facciamo nei nostri inquadramenti in DevHighWay: scegliere tra API, ibrido e self-host con numeri, non con slogan.

  • Contattateci per un inquadramento di progetto sovranità (workshop di 2 giorni, deliverable decisionale)
  • Il nostro audit copre anche la dimensione visibilità della vostra piattaforma IA
  • Consultate le nostre tariffe per i pacchetti che includono la gestione operativa dell'LLM

Il self-hosting di un LLM è oggi un'opzione credibile, talvolta l'unica, per le organizzazioni che devono mantenere il controllo sui propri dati. Ma è un progetto di ingegneria serio che si tratta come tale: obiettivi chiari, modello sottoposto a benchmark, infrastruttura dimensionata, sicurezza e osservabilità impeccabili, FinOps documentato. È esattamente l'approccio che adottiamo sui nostri progetti, e quello che separa durevolmente i deploy duraturi dai POC che muoiono al primo incidente di produzione.