Self-Hosting Mistral Large 4: lezioni apprese a caro prezzo

Quando Mistral ha rilasciato i pesi di Mistral Large 4 — un modello da circa 1 trilione di parametri con circa 52 miliardi attivi — la mia casella di posta si è riempita della stessa domanda: possiamo eseguirlo noi stessi? Il self-hosting di pesi aperti non è più una fantasia da hobbista, ma un'opzione architetturale concreta, e questo significa che molti team stanno per fare errori costosi. Ne ho già visti diversi accadere. Questo articolo è la versione delle lezioni apprese: i modi specifici in cui chi lavora sul campo sbaglia il self-hosting e come si risolve ogni volta.

Errore 1: leggere «Open Weights» come «gratis da usare come vuoi»

Il primo errore arriva prima ancora che qualcuno tocchi una GPU. Mistral Large 4 è distribuito con una licenza in stile MIT modificata, con una limitazione importante: se tu o le tue affiliate gestite un business di model-as-a-service, serve una licenza commerciale separata da Mistral prima di usare il modello a fini commerciali. Per un'azienda che esegue l'inferenza internamente — per esempio per riassumere documenti o alimentare un assistente per il codice dei dipendenti — probabilmente va bene. Per una startup che vuole rivendere l'inferenza, è un vero stop finché non scrivi a loro.

I team sbagliano in entrambe le direzioni. Alcuni vedono la parola «open» in un comunicato stampa e costruiscono un prodotto commerciale sui pesi, scoprendo la restrizione durante una due diligence per un round di finanziamento — il momento peggiore possibile. Altri esagerano nella prudenza e presumono che la licenza vieti ogni uso commerciale, quando in realtà si rivolge ai fornitori di inferenza concorrenti. La soluzione è noiosa ma essenziale: fai leggere il testo effettivo della licenza al tuo ufficio legale, non il post di annuncio. Che tu lo chiami «open weights» o «weight-available» — una distinzione su cui la community discute animatamente, e non senza ragione — la decisione ingegneristica dovrebbe basarsi su ciò che i termini consentono davvero al tuo business.

Un'ulteriore sottigliezza: questo schema di licenza è ormai la norma per i grandi rilasci di pesi, non l'eccezione. Se la tua architettura prevede di alternare tra Mistral, Qwen e altri modelli a pesi aperti di frontiera, ti serve una matrice delle licenze, non una revisione una tantum. Crea quel foglio di calcolo prima di costruire il cluster.

Errore 2: dimensionare l'hardware dalla pagina marketing invece che dai conti

Ecco l'errore che brucia più soldi. Un ingegnere legge «1T parametri», dà un'occhiata alle quattro H200 nella sala server aziendale e pensa che 540 GB di VRAM siano abbastanza. Non lo sono, e il motivo è un calcolo che richiede novanta secondi e ti risparmia un trimestre di imbarazzo.

In precisione BF16, un trilione di parametri richiede circa 2 TB di memoria solo per i pesi. Con quantizzazione a 8 bit si arriva vicino a 1 TB. A 4 bit, intorno a 500–560 GB — prima di aggiungere KV cache, attivazioni e overhead di serving. Quel server da 540 GB ospita un modello a 4 bit solo se ti va bene una finestra di contesto corta e una manciata di utenti concorrenti. L'architettura mixture-of-experts (52B parametri attivi per token) aiuta il calcolo per token, ma non fa nulla per la memoria: tutti i trilione di parametri devono comunque stare da qualche parte indirizzabile, e in un MoE i pesi degli esperti vengono richiamati in modo imprevedibile, quindi spostarli nella RAM della CPU distrugge la latenza in un modo che non accade con i modelli densi.

La soluzione è partire dai requisiti di serving e lavorare a ritroso, non partire dall'hardware. Decidi prima la lunghezza di contesto, la concorrenza e i token al secondo che ti servono, poi ricava il livello di quantizzazione che puoi permetterti, poi ricava l'hardware. Se il risultato sono otto H200 o una coppia di nodi di classe NVL72, e quel numero ti fa trasalire, bene — quel sussulto significa che il modello sta funzionando come previsto. Abbiamo già trattato il problema collegato in cosa fare quando la tua GPU esaurisce la VRAM, e le opzioni lì (offloading, quant più piccole, modelli più piccoli) valgono anche qui, solo su scala da datacenter.

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

Nota che la versione onesta di quella tabella include KV cache e overhead. La versione disonesta — solo pesi — è il modo in cui i team finiscono con un modello che si carica ma non riesce a servire più di tre utenti.

Errore 3: considerare la quantizzazione un pasto gratis

Una volta che i team accettano di dover quantizzare, il passo successivo è presumere che il 4 bit sia «sostanzialmente lo stesso modello». A volte lo è. Spesso no, e le modalità di guasto sono proprio quelle che ti interessano di più.

Lo schema che ho visto più volte: un team misura il proprio deployment a 4 bit su test a scelta multipla in stile MMLU, vede un calo dell'1% e rilascia. Poi gli utenti in produzione segnalano che i refactoring di codice lunghi su più file vanno fuori controllo, o che il JSON per il tool calling si rompe in modo sottile con bassa probabilità ma alta frequenza. Una quantizzazione aggressiva danneggia in modo sproporzionato i compiti a orizzonte lungo, strutturati e a bassa temperatura — esattamente i carichi agentici e di coding che giustificano un modello di frontiera. La media si muove appena; la coda crolla.

La soluzione è quantizzare fino a dove il tuo eval del task lo tollera, non fino a dove ti obbliga la VRAM. Esegui i prompt del tuo carico di lavoro su build FP8, 4 bit e 3 bit e confrontali. Se il 3 bit supera i tuoi eval, complimenti, la bolletta hardware si è appena dimezzata. Se fallisce, nessuna media dei benchmark ti salverà. E preferisci le release quantizzate native quando il laboratorio le pubblica: Mistral ha rilasciato una variante NVFP4 insieme ai pesi BF16, e una quant di prima parte con delta di qualità misurati batte una conversione GPTQ della comunità che hai validato per un pomeriggio.

Un livello di quantizzazione è un budget di qualità, non un'impostazione di compressione. Spendilo dove il tuo carico di lavoro può permettersi la perdita.

Errore 4: confrontare il prezzo dell'API con il prezzo della GPU e chiamarlo analisi TCO

Il classico foglio di calcolo: «l'API costa 2,10 $ per milione di token in output, un nodo GPU riservato costa X $ all'ora, quindi il self-hosting si ripaga sopra Y token al mese». Questo foglio è quasi sempre sbagliato, e sbaglia nella direzione più costosa.

Ciò che trascura è l'utilizzo. Un'API ti dà il 100% di utilizzo della capacità di qualcun altro, fatturata a token. Il tuo cluster self-hosted ti dà l'utilizzo che il tuo traffico produce, e la maggior parte dei carichi interni è a raffiche — intenso in orario d'ufficio, inattivo di notte, con picchi attorno ai rilasci. Un cluster dimensionato per il picco resta mezzo vuoto per gran parte della giornata. Poi aggiungi i costi che non finiscono mai nel foglio: una rotazione di reperibilità per uno stack di serving che ora include aggiornamenti di vLLM, incompatibilità di driver CUDA e la chiamata alle 2 di notte quando la KV cache si frammenta; il continuo rincorrere i nuovi rilasci di pesi (devi rivalidare ogni release? La tua suite di eval dice di sì); e il costo opportunità dell'ingegnere ML che ora fa da babysitter della GPU invece di costruire prodotto.

C'è anche un problema di bersaglio mobile che nessuno quantifica. Mistral ha ridotto il prezzo dell'API per questo modello di quasi la metà tra la preview e la release completa — i token di input sono passati da 1,36 $ a 0,70 $ per milione. Ogni calcolo di ROI del self-hosting basato sul vecchio prezzo è ormai fantasia. L'inferenza di frontiera diventa più economica con cadenza trimestrale, mentre l'hardware si ammortizza su più anni. Questa asimmetria è il killer silenzioso dei business case del self-hosting.

La soluzione: fai self-hosting solo per motivi che l'API non può strutturalmente offrire. Questi motivi esistono e sono reali — ma «più economico su larga scala» raramente è tra questi, alle scale in cui opera la maggior parte delle aziende.

Quando il self-hosting conviene davvero

Quindi quando conviene far girare pesi di classe Mistral in locale invece dell'API? Dopo aver visto team farlo bene e male, i casi vincenti si raggruppano in quattro categorie:

• Residenza dei dati e sovranità. Settori regolamentati, lavoro vicino alla difesa e organizzazioni europee con vincoli giurisdizionali stringenti. Un vincolo pratico che ho visto sul campo: un'azienda a cui era vietato usare modelli di origine cinese per motivi di conformità — pesi aperti di un laboratorio europeo con provenienza verificabile hanno risolto un problema che nessun contratto API poteva risolvere.
• Ambienti air-gapped o connessi a intermittenza. Se la rete non può essere considerata affidabile, i pesi locali sono l'intera architettura. Abbiamo approfondito questo schema in come costruire un LLM che funziona offline.
• Carichi di lavoro sostenuti, prevedibili e ad alto volume. L'elaborazione batch di documenti 24/7 a throughput costante può davvero battere il prezzo a token — perché risolve il problema dell'utilizzo per costruzione.
• Fine-tuning e modifica. Non puoi fare fine-tuning del modello di qualcun altro oltre ciò che consente il suo endpoint dedicato. Possedere i pesi significa possedere il loop di addestramento: pretraining continuo su corpus di dominio, allineamento personalizzato, distillazione in deployment più piccoli.

Nota cosa non compare nell'elenco: la latenza. Self-hostare un MoE da un trilione di parametri non ti dà una latenza più bassa di un'API ben provisionata, a meno che tu non sia disposto a investire molto in speculative decoding e serving ottimizzato per batch-1. E nota anche cos'altro manca: «evitare la dipendenza da un fornitore». I pesi che scarichi oggi saranno due generazioni indietro entro un anno, e ti ritroverai davanti alla stessa decisione — che, non a caso, è un buon argomento a favore dell'istinto di archiviazione di alcuni professionisti, che conservano copie locali delle release di pesi significative. Lo storage costa poco; le opzioni hanno valore.

La cornice onesta è che pesi aperti e API sono complementari, non concorrenti. Diversi team che conosco usano un approccio ibrido: l'API per il traffico interattivo a raffiche, i pesi locali per la fetta regolamentata o ad alto volume batch. Le competenze si trasferiscono — la tua configurazione vLLM, il tuo eval harness e i tuoi template di prompt funzionano in entrambi i mondi. Se vuoi le basi operative prima di impegnarti sulla scala di frontiera, la nostra guida a far girare large language model sul proprio hardware copre lo stack di serving dall'inizio alla fine.

Errore 5: valutare con i benchmark invece che con il proprio carico di lavoro

L'ultimo errore è quello che annulla tutti gli altri. Un team fa tutto nel modo giusto — licenza verificata, hardware dimensionato, quantizzazione testata sui benchmark pubblici — e poi rilascia un modello che gli utenti detestano, perché gli eval non hanno mai misurato nulla di ciò che gli utenti fanno davvero.

I benchmark pubblici rispondono alla domanda «questo modello è generalmente capace?». Non rispondono a «questo modello classifica i nostri ticket di supporto con il tono e il formato che ci servono, a 4 bit, sotto il nostro carico di concorrenza?». Abbiamo già scritto del perché i benchmark AI non colgono il 90% del lavoro reale, e il self-hosting rende il divario più netto, non più sfumato: ora sei responsabile di ogni variabile che il fornitore di API gestiva per te. Lo stack di deployment, le impostazioni del sampler, le convenzioni dei system prompt con cui il modello è stato addestrato — tutto è di tua competenza, e tutto può essere sbagliato.

La soluzione è un eval a tre livelli da costruire prima di impegnarti sull'hardware:

1. Un golden set dalla produzione. Qualche centinaio di prompt reali con output ideali verificati, che coprano la distribuzione reale dei tuoi compiti — inclusi i casi lunghi, disordinati e multi-turno.
2. Un harness di regressione. Ogni candidato (API vs locale, FP8 vs 4 bit, vecchi pesi vs nuova release) esegue automaticamente il golden set. Valuta con un modello giudice solido più una revisione umana a campione; non fidarti ciecamente del giudice sugli output strutturati.
3. Un periodo di shadow. Fai girare il deployment locale affiancato all'API sul traffico reale per due settimane, confrontando gli output e misurando la latenza reale sotto carico reale. È qui che emergono davvero gli errori di dimensionamento della KV cache e i fallimenti nella coda della quantizzazione.

Questo harness si ripaga la prima volta che esce una nuova release di pesi e puoi rispondere alla domanda «dobbiamo aggiornare?» con i dati in un pomeriggio invece che con sensazioni in riunione.

La vera lezione: i pesi aperti hanno cambiato la domanda, non la risposta

Un anno fa, «dovremmo fare self-hosting di un modello di frontiera?» era un'ipotesi — la frontiera non era scaricabile. Mistral Large 4, insieme all'ondata di altri rilasci da un trilione di parametri, l'ha trasformata in una decisione reale con soldi reali in gioco. Ma il framework decisionale non è cambiato; è solo diventato obbligatorio.

Fai self-hosting quando sovranità, connettività, volume sostenuto o la necessità di modificare il modello lo richiedono. Paga l'API quando il traffico è a raffiche, il team è piccolo e il tuo elemento distintivo è il prodotto, non lo stack di inferenza. E qualunque scelta tu faccia, fai il calcolo della memoria in novanta secondi, leggi la licenza e costruisci l'eval harness prima di firmare qualsiasi cosa. I pesi ora sono aperti. Purtroppo lo sono anche gli errori.