Encoder, esperti e memoria

C'è un momento ricorrente, nelle call degli ultimi mesi, che arriva sempre più o meno allo stesso punto. Si è finito di parlare del caso d'uso, si è capito che serve un LLM, e qualcuno — di solito non il tecnico, di solito chi firma — dice la frase: «ho letto che questi modelli cinesi vanno come ChatGPT e sono gratis. Non è che ce li mettiamo in casa e ci togliamo il pensiero?»

È una buona domanda. È anche una domanda che non ha una risposta da una riga, e il modo in cui la gestisci nei venti secondi successivi decide se per il resto del progetto sarai il consulente che ragiona o quello che difende il fornitore.

Per rispondere bene non basta sapere che DeepSeek ha rilasciato una versione nuova. Serve sapere cosa ha cambiato, perché è quel cambiamento — non il numero di versione — a dirti se quel modello può girare nel datacenter del cliente o no. Quello che segue è il minimo per stare in quella conversazione da pari: encoder e decoder, mixture of experts, memoria a lookup, e con cosa lo servi davvero.

Cosa è successo davvero, in ordine

Riassumo i fatti, perché è facile perdere il filo.

Il 14 agosto Zhipu ha rilasciato GLM-5.3, presentandolo come il modello open più forte sul coding. La cosa interessante è che condivide il base model con GLM-5.2: tutto il guadagno arriva dal solo post-training. Sul loro benchmark interno di coding dichiarano un salto del 50% in termini relativi, e sui benchmark agentici pubblici si passa da 4,6 a 28,3 su Terminal-Bench 3.0 e da 46,2 a 66,9 su DeepSWE v1.1. I pesi sono usciti due settimane dopo l'annuncio, al termine delle verifiche di sicurezza.

Qwen3.8-Flash-Next ha portato in produzione un'idea che fino a quel momento era stata soprattutto un paper: affiancare alla rete una tabella enorme di embedding n-gram — 51 miliardi di parametri, venti milioni fra bigrammi e trigrammi — che non fa nessun calcolo, si limita a essere letta. Il backbone è un mixture of experts — MoE, l'acronimo che da qui in avanti trovi ovunque — da 125 miliardi di parametri con 6 miliardi attivi per token.

Il 10 settembre è arrivato DeepSeek-V4.1-Flash, ed è quello che mi interessa di più, perché mette insieme tutti e tre i pezzi di cui voglio parlare. Contesto dichiarato da un milione di token, e un prezzo via API che in fascia non di picco sta a 0,15 dollari per milione di token in input e 0,60 in output, con l'input già in cache a 0,003.

L'architettura, però, DeepSeek la mette in tre righe, ed è da lì che conviene partire: memoria Engram da 196 miliardi di parametri, backbone MoE da 552 miliardi, nuova architettura causal encoder-decoder con appena 8 miliardi di parametri attivi per l'input e 16 per l'output.

Tienile da parte. Sono la scheda tecnica di qualunque modello open ti verrà messo davanti nei prossimi mesi, e tutto quello che segue serve a leggerle: tre righe, tre concetti, e da ognuno esce una domanda che sposta il preventivo. V4.1-Flash è anche il caso più comodo su cui ragionare, perché mette insieme le tecniche degli altri due — il MoE che hanno tutti, la memoria a lookup che Qwen ha portato su scala reale — e ci aggiunge la divisione fra encoder e decoder.

Una cosa sui numeri, prima di partire, perché è l'equivoco più frequente: sono tre grandezze che vivono in tre posti diversi, e non si sommano come sembra. I 552 miliardi sono il backbone — attenzione, embedding ed esperti, encoder e decoder insieme. I 196 miliardi della memoria Engram stanno fuori da quel conto, perché sono una tabella e non una rete. E gli 8 e i 16 non sono un terzo gruppo: sono la fetta dei 552 che si accende davvero, rispettivamente quando il modello legge e quando scrive.

La direzione è quella nel diagramma: la capacità cresce, i parametri che devi effettivamente far lavorare per ogni token scendono. Non è un pranzo gratis — ci torno — ma è il motivo per cui la domanda del cliente, che due anni fa era ingenua, oggi merita una risposta seria.

Perché la domanda arriva proprio adesso

Ci sono tre spinte e conviene tenerle separate, perché portano a decisioni diverse.

La prima è normativa, ed è la più fraintesa. Gli obblighi sui modelli di uso generale sono operativi dal 2 agosto 2025. Gli obblighi di trasparenza dell'articolo 50 — dire all'utente che sta parlando con un sistema di AI, marcare i contenuti generati — si applicano dal 2 agosto 2026, con una proroga al 2 dicembre 2026 per la sola marcatura dei contenuti sui sistemi già sul mercato. Le scadenze sui sistemi ad alto rischio sono invece slittate: il regolamento Omnibus è in vigore dal 27 luglio 2026 e porta i sistemi stand-alone dell'Allegato III al 2 dicembre 2027, l'AI incorporata in prodotti già regolati all'agosto 2028.

Vale la pena dirlo in call, perché metà dei clienti crede di avere una scadenza addosso che non ha, e l'altra metà crede di non averne nessuna mentre l'articolo 50 li riguarda eccome. In ogni caso: nessuna di queste norme dice che devi tenere il modello in casa. Il self-hosting è una risposta possibile a un requisito di data residency o di controllo del fornitore, non un adempimento in sé.

La seconda spinta è il costo, e qui va fatto un ragionamento che quasi nessuno fa. Il self-hosting sposta il costo da variabile a fisso. Conviene sopra una certa soglia di volume, e quella soglia si è alzata, non abbassata, perché il prezzo per token dell'inferenza in cloud continua a scendere. Se il cliente fa diecimila chiamate al mese, un server da 200.000 franchi non si ripaga mai, e dirglielo è il servizio che gli stai vendendo.

La terza è il controllo: sapere dove stanno i dati, non dipendere da un deprecation notice, poter congelare una versione. Questa è spesso la ragione vera, anche quando viene presentata come una delle altre due. E su questa il self-hosting è effettivamente la risposta.

Il numero di versione non è un argomento

In una call di pre-sale, o in un confronto tecnico con la controparte, sapere che è uscita la 4.1 e che va meglio della 4 non ti serve a niente: lo sa anche il cliente, l'ha letto sullo stesso post che hai letto tu. Quello che ti serve è saper rispondere a perché va meglio, perché da lì discende tutto il resto — quanta memoria serve, cosa si può quantizzare, cosa si rompe.

Sono le tre righe di prima, lette al contrario: come è fatto un modello dentro — la riga del causal encoder-decoder, quella con l'8 e il 16 — come fa a essere grande senza costare come un modello grande — i 552 miliardi del MoE — e come si risparmia il lavoro che ha già fatto un milione di volte, cioè i 196 miliardi di memoria Engram. Li metto in fila partendo dalle fondamenta: se le fondamenta le hai già, salta ai titoli.

Primo concetto: cos'è un Transformer, e perché esiste

Fino al 2017 i modelli di linguaggio leggevano il testo come lo leggiamo noi: una parola dopo l'altra, tenendo a mente quello che era venuto prima. Funzionava, ma aveva due difetti. Sulle frasi lunghe l'inizio si perdeva per strada. E soprattutto non era parallelizzabile: se per elaborare la sesta parola devi aver finito la quinta, una GPU con migliaia di core la stai usando a un decimo delle sue possibilità.

Nel 2017 un gruppo di Google pubblica un paper il cui titolo è già la tesi: Attention Is All You Need. L'idea è di buttare via la lettura sequenziale. Dai al modello tutta la frase in una volta, e per ogni parola fagli calcolare quanto ogni altra parola le è rilevante. Quel «quanto è rilevante» è l'attention — in ogni riunione e in ogni paper sentirai il termine inglese — ed è il meccanismo su cui gira tutto quanto.

Un esempio per farla atterrare. Prendi la frase: «il bonifico verso il conto estero non è passato perché era bloccato». Quel era si riferisce al bonifico o al conto? Noi lo risolviamo senza accorgercene. Il modello lo risolve assegnando dei pesi: mentre elabora «era», si chiede quanto conta «bonifico» e quanto conta «conto», e fa la media pesata delle loro rappresentazioni. Questo calcolo — il self-attention — viene fatto per ogni parola contro tutte le altre, e per tutte le parole contemporaneamente. Ed è esattamente il punto: sono moltiplicazioni di matrici, e le GPU non fanno altro tutto il giorno.

Quell'architettura si chiama Transformer. È il motivo per cui esistono gli LLM: non perché sia più intelligente di quello che c'era prima, ma perché si può scalare. Puoi buttarci dentro diecimila schede e mesi di addestramento, e continua a migliorare.

Il punto da portarsi in call è questo: tutti i modelli di cui stiamo parlando sono Transformer. GPT, Claude, Llama, Qwen, GLM, DeepSeek. Tutto quello che racconto qui sotto sono variazioni su questo tema, non alternative. Quando un fornitore ti presenta un'architettura come rivoluzionaria, la domanda giusta è quasi sempre «quale pezzo del Transformer avete cambiato?».

Le due metà: chi legge e chi scrive

Siamo sulla terza riga, quella del causal encoder-decoder: in V4.1-Flash sono quaranta layer, venti per metà, ed è da questa divisione che escono l'8 e il 16.

Nel paper del 2017 il Transformer è fatto di due blocchi, e sono due perché quel modello doveva tradurre.

L'encoder riceve la frase in francese — che è già tutta lì, scritta — e ne costruisce una rappresentazione interna, gli hidden state: una specie di «cosa vuol dire questa frase» in forma di numeri. Il decoder prende quella rappresentazione e produce la frase in italiano, una parola alla volta, guardando sia il significato che gli è arrivato sia quello che ha già scritto fin lì.

La differenza fra i due non sta nella dimensione o nella bravura. Sta in cosa gli è concesso guardare, e qui vale la pena essere espliciti, perché è il punto che poi torna su tutto.

L'encoder lavora su un testo che esiste già per intero. Mentre elabora la quinta parola può quindi usare anche la nona e la ventesima: sono lì sul tavolo. È quello che si intende con bidirectional attention — legge in avanti e all'indietro. Pensalo come un revisore: prima si legge il documento tutto, poi decide.

Il decoder no. Il decoder sta scrivendo, e quando è alla quinta parola la nona non esiste ancora: la deve produrre lui. Gli si impedisce per costruzione di guardare oltre la posizione su cui sta lavorando, e questo vincolo si chiama causal mask: causale nel senso che la causa viene prima dell'effetto. Non è un dettaglio implementativo. Senza quella mask, in addestramento il modello barerebbe: tu gli dai la frase intera e gli chiedi di indovinare la sesta parola, e se può vederla non impara a predirla, impara a copiarla.

Perché la bidirezionalità, quando ce l'hai, è preziosa? Perché il significato di una parola dipende spessissimo da quello che viene dopo. «Ho chiuso il conto»: conto bancario o conteggio? Lo capisci solo dal seguito — «...in banca» oppure «...e il totale non torna». Un lettore può aspettare la fine. Uno scrittore non può.

BERT, e perché conviene sapere chi è

BERT — sta per Bidirectional Encoder Representations from Transformers, e il nome dice già tutto — è il modello con cui Google, nel paper del 2018, ha preso solo la metà encoder e l'ha resa famosa. Non ci chatti: non genera testo, non è un assistente, non ha un prompt di sistema. Gli dai un testo e ti restituisce numeri.

Conviene essere concreti, perché è il punto in cui di solito si perde il filo. Dai a un encoder la frase «il bonifico è stato rifiutato» e quello che torna è un vettore: una fila di numeri, 768 in BERT-base, 1024 in BERT-large, 384 nei modelli piccoli che si usano oggi per la ricerca. Presi uno per uno non vogliono dire niente e non sono leggibili. Hanno però una proprietà: testi che vogliono dire cose simili producono vettori vicini.

«Il bonifico è stato rifiutato» e «il pagamento non è andato a buon fine» non hanno quasi nessuna parola in comune, e un LIKE '%...%' non le mette insieme mai. I loro vettori invece finiscono a pochissima distanza, mentre quello di «la riunione è alle tre» va dall'altra parte dello spazio. Questo è l'embedding: il testo trasformato in coordinate, in uno spazio dove la vicinanza è somiglianza di significato.

Ed è esattamente il motivo per cui un RAG funziona. Quando indicizzi i documenti del cliente, nel vector database non finisce il testo: finiscono questi vettori. Poi arriva la domanda dell'utente, la trasformi allo stesso modo e cerchi i vettori più vicini. Trovi il pezzo giusto anche quando l'utente ha usato parole che nel documento non compaiono. Quella trasformazione la fa un encoder.

C'è poi il secondo modo di consumare la stessa uscita. Se sopra all'encoder attacchi una testina di classificazione, invece delle coordinate ottieni un'etichetta: spam o non spam, questa parola è un nome di persona, questo ticket parla di fatturazione. Stesso modello e stesso calcolo, due modi di usarne l'output. Con la testina decide lui e ti dà una parola; con i vettori grezzi decide qualcun altro — la ricerca vettoriale, un reranker, un clustering — e lui ti dà solo le coordinate.

Quei vettori, fra l'altro, sono gli stessi hidden state di cui sopra. In un decoder restano interni e servono a produrre la parola dopo. In un encoder te li porti via: sono il prodotto finale.

Una precisazione che evita una figuraccia: BERT così com'è non è il modello che metti in un RAG. Gli autori di Sentence-BERT lo scrivono nell'abstract — la costruzione di BERT lo rende inadatto alla ricerca per similarità — e nel 2019 hanno riaddestrato quell'architettura apposta, portando il confronto fra diecimila frasi da sessantacinque ore a pochi secondi. I modelli di embedding che usi oggi discendono da quel lavoro, non da BERT preso dallo scaffale.

Conviene sapere chi è per due motivi molto concreti.

Il primo: quella famiglia non è morta affatto, la usi tutti i giorni senza chiamarla per nome. Ogni volta che calcoli un embedding, ogni volta che fai un reranking dei risultati, sotto c'è quasi sempre un discendente di BERT. Se il cliente ha un RAG in produzione, ha un encoder dentro, anche se nessuno in quella stanza lo sa.

Il secondo è che su quei compiti un encoder piccolo batte un modello generativo enorme, costa un centesimo e risponde in millisecondi. Capita regolarmente di trovare aziende che classificano i ticket di supporto con una chiamata a un LLM generativo. È probabilmente il consiglio più facile da dare in una call, e vale tanto quanto tutto il resto del discorso.

Poi è arrivata OpenAI, che ha fatto l'operazione opposta: ha buttato via l'encoder, ha tenuto solo il decoder, gli ha dato in pasto mezza internet e gli ha chiesto di indovinare la parola dopo. Da lì in avanti tutto quello che chiamiamo LLM — GPT, Claude, Llama, i DeepSeek fino alla V4 — è decoder-only.

E qui arriva DeepSeek, con una parola da non sottovalutare

Il technical report di DeepSeek-V4.1-Flash descrive il modello come causal encoder-decoder: quaranta layer, venti di encoder e venti di decoder. E in giro si legge — l'ho sentito raccontare così anche in un video parecchio diffuso in questi giorni — che sarebbe un ritorno all'encoder bidirezionale in stile BERT.

Non è così, e l'aggettivo è lì apposta: l'encoder è causale. Tutto il backbone mantiene la causal mask, nessuno guarda in avanti. Quello che DeepSeek riprende dall'architettura del 2017 non è la bidirezionalità, è la divisione dei ruoli: una metà si occupa di digerire l'input, l'altra di generare.

E il guadagno vero sta in un dettaglio che sembra tecnico e non lo è. In un decoder-only ogni layer si costruisce e si tiene la propria KV cache (Key-Value), la memoria di lavoro dell'attention: quella che cresce con la lunghezza del contesto ed è la voce di costo che ammazza i progetti agentici. Venti layer, venti cache. Qui invece il decoder non la calcola: la proietta dall'ultimo hidden state dell'encoder. Una proiezione al posto di venti cache.

Da lì discendono le due cifre che contano. L'occupazione crolla a circa 890 byte per token, un quarto della generazione precedente — e per darti la scala del percorso, DeepSeek-V1 stava intorno ai 390.000 byte per token. E nasce l'asimmetria che nel titolo delle news suona strana: 8 miliardi di parametri attivi in lettura, 16 in scrittura, in gergo 8B in prefill e 16B in decode. Perché una volta separati i due ruoli, non c'è più nessun motivo di dargli lo stesso budget: capire un input lungo e produrre un output buono sono due lavori diversi.

Già che ci siamo, una precisazione che sento sbagliare di continuo e che in un confronto tecnico ti qualifica: il costo dell'attenzione sul contesto non cresce in modo esponenziale. Cresce quadraticamente nel calcolo e linearmente nella memoria della cache. Non è pedanteria da accademici: «esponenziale» suggerisce che il contesto lungo sia un problema insolubile, «quadratico con cache lineare» ti dice esattamente dove mettere le mani. Ed è infatti dove le hanno messe.

Secondo concetto: mixture of experts, sparso nel calcolo ma non nella memoria

Seconda riga: 552B-parameter MoE. È il concetto più noto dei tre, e quasi sempre raccontato a metà.

Una rete dense fa passare ogni token attraverso tutti i suoi parametri. Un mixture of experts — in sigla MoE, ed è così che lo vedrai scritto nelle schede tecniche e nei nomi dei modelli — sostituisce il blocco feed-forward con molti blocchi più piccoli, gli esperti, e mette davanti un router che per ogni token ne sceglie pochi. In DeepSeek-V4.1-Flash sono 384 routed expert più uno shared expert per ogni layer MoE, e per ogni token se ne accendono 6 più lo shared.

Il risultato è la seconda metà della terza riga: un modello da 552 miliardi di parametri costa, per token, quanto un modello da 8 o 16 miliardi. È questo che rende possibile il prezzo di listino di cui sopra.

E adesso la parte che in call fa la differenza, perché è dove il cliente — o il tuo interlocutore tecnico — si convince di una cosa falsa: il MoE è sparso nel calcolo, non nella memoria. Tutti i 384 esperti devono stare in memoria veloce. Il router decide quali servono solo a runtime, guardando le attivazioni: non puoi saperlo prima, quindi non puoi tenerli altrove e andarli a prendere in tempo.

Attivi 16 miliardi, ma ne devi ospitare 552.

È la ragione per cui il conto della VRAM non torna quasi mai come se lo aspettano.

Terzo concetto: n-gram ed Engram, il secondo asse di sparsità

Resta la prima riga, quella da 196 miliardi. È il concetto più recente e il meno diffuso dei tre, ed è quello che sta effettivamente cambiando il discorso sull'hardware.

L'osservazione di partenza è semplice: dentro i parametri di un modello convivono due cose molto diverse. Da una parte la capacità di ragionare, comporre, seguire istruzioni. Dall'altra i pattern ricorrenti: sequenze di pochi token che il modello ha visto passare milioni di volte e che, a ogni inferenza, ricostruisce facendole attraversare i primi layer. È calcolo speso per riottenere qualcosa di statico, e nel paper DeepSeek lo dice così: la memoria condizionale solleva i primi layer dalla ricostruzione di pattern statici.

L'idea è quindi di tirare fuori quei pattern dalla rete e metterli in una tabella di lookup indicizzata per n-gram. Su ogni posizione si guarda la sequenza corta di token appena vista, si legge la riga corrispondente, e quel vettore viene iniettato nel residual stream. Zero moltiplicazioni matriciali: solo una lettura.

Su cosa ci sia davvero dentro quella tabella si sbaglia in tutte e due le direzioni, e vale la pena essere precisi. Non è un archivio di fatti: non c'è nessuna riga che dice che Roma è la capitale d'Italia, non ci sono soggetti e predicati, e non ci puoi scrivere. Ci sono vettori indirizzati da sequenze di token, e corte — in V4.1-Flash gli ordini sono di due, tre e quattro token, con otto teste di hash per ordine e circa sedici milioni di righe per testa.

Ma non è nemmeno un dettaglio sintattico senza contenuto, e il paper è netto: spegnendo la memoria, i benchmark di conoscenza crollano fra il 29 e il 44% del punteggio originale, mentre la comprensione del testo ne conserva fra l'81 e il 93%. Gli autori la chiamano il deposito principale della conoscenza parametrica del modello. Il meccanismo è un lookup di pattern ricorrenti; l'effetto è che i fatti finiscono per abitare lì.

Da dove viene. Il video che ho visto circolare in questi giorni attribuisce a DeepSeek il primo paper sul tema. Non è esatto, ed è un dettaglio che vale la pena avere in tasca. L'antenato è Scaling Embedding Layers in Language Models di Da Yu, Edith Cohen, Badih Ghazi e colleghi — il metodo noto come SCONE, uscito a febbraio 2025 e presentato a NeurIPS. DeepSeek ci ha costruito sopra Engram — Conditional Memory via Scalable Lookup — aggiungendo roba sua: multi-head hashing per non far collidere entità diverse, e un gating che confronta la riga letta con il contesto corrente e la sopprime se la contraddice. Qwen è arrivato dopo, citando quel lavoro, e ha spinto la tabella su un modello di scala reale.

Perché questa è la parte che tocca l'hardware. Qui sta il vero motivo per cui ne parlo, e la differenza rispetto al MoE.

L'indice della tabella n-gram dipende solo dagli id dei token già visti. Non dalle attivazioni, non dal router, non da niente che si sappia soltanto a runtime. Quindi è noto in anticipo: mentre la GPU sta ancora macinando il token corrente, puoi già andare a prendere la riga che ti servirà dopo. Prefetch asincrono, sovrapposto al calcolo, senza stallo. Ed è per questo — e solo per questo — che quei 196 miliardi di parametri possono stare in RAM di sistema o su NVMe invece che in VRAM, mentre i 384 esperti no.

Vale la pena aggiungere due precisazioni, perché entrambe le sento raccontare male.

La prima: non è un RAG. Non c'è nessuna ricerca per similarità, nessun embedding della domanda, nessun retriever. È un indirizzamento deterministico su una tabella, calcolato per hash. Chiamarlo RAG fa perdere esattamente la proprietà che lo rende utile, cioè la prevedibilità dell'indice.

La seconda: l'idea che si possano aggiornare i fatti scrivendo nella tabella — caricarci documenti aziendali e ottenere un modello che li sa — è affascinante e viene ripetuta spesso, ma oggi è una direzione di ricerca, non una feature disponibile. La tabella si allena insieme al resto del modello e a inferenza è congelata. Se in call qualcuno la presenta come alternativa al fine-tuning o al RAG, vale la pena rimettere le cose a posto.

Sui numeri, DeepSeek riporta che l'ottimo si trova destinando il 20-25% dei parametri alla memoria condizionale, e che a budget di calcolo fisso la qualità cresce in modo log-lineare con la dimensione della tabella. Che è la cosa davvero interessante: una leva di scala che non costa FLOPs.

Quindi gira sul mio hardware?

Adesso la domanda concreta. La risposta che davo un mese fa era no, e oggi è sbagliata: gira, ma non con il motore che ti aspetti.

Sulla strada di produzione il conto resta quello. Il checkpoint completo sta intorno ai 510 GB e la ricetta vLLM chiede circa 614 GB di VRAM: un nodo a otto H200 o un tray GB200.

L'altra strada è un motore scritto apposta per pochi modelli. ds4, o DwarfStar, è quello di Salvatore Sanfilippo: backend Metal, CUDA e ROCm, e V4.1-Flash fra i modelli supportati. Il GGUF a 2 bit pesa 341 GiB, di cui 189 sono le tabelle Engram che restano sul disco e vengono lette riga per riga quando servono, mai caricate tutte. I pesi che devono stare in memoria sono 152 GiB, e su un Mac da 128 GB si lavora in streaming da SSD; due macchine da 128 GB collegate se li dividono, circa 81 GiB per parte; su una da 512 GB ci stanno tutti. Su un DGX Spark funziona allo stesso modo, e i numeri pubblicati a metà settembre danno una prefill fra i 93 e i 96 token al secondo in streaming da SSD.

Guarda cos'è successo, però, perché è il terzo concetto che torna: quel modello entra in una macchina da ufficio solo perché i 189 GiB di memoria a lookup possono stare su un SSD. Se fossero stati 189 GiB di esperti, il router li avrebbe voluti tutti in memoria veloce e non ci sarebbe stata nessuna strada. La sparsità nell'accesso non è un dettaglio da paper: è la ragione per cui questa conversazione col cliente oggi ha una risposta diversa da sei mesi fa.

Il prezzo da mettere nell'offerta, però, va detto: DwarfStar è un motore specializzato, che gira sui GGUF che produce lui, non un runtime generico su cui costruire una piattaforma. Per sperimentare e per un uso interno è la via più concreta che esista; per un servizio con SLA si torna alla strada di sopra.

Con cosa lo servi, oggi

Questa è la parte che nelle discussioni sui modelli open manca sempre, ed è quella che decide se un progetto parte o no. Un modello con i pesi pubblici non è un modello che puoi servire: serve un runtime che ne implementi l'architettura, e fra il rilascio dei pesi e quel momento passano settimane o mesi.

vLLM è l'unica risposta di livello produttivo. Il supporto è arrivato al day zero ed è verificato sia su NVIDIA sia su AMD. Ma non ci arrivi con un pip install, perché nessuna wheel serve questa architettura: si passa da un'immagine Docker, e oggi sono le nightly standard — qualunque nightly dal 10 settembre in poi. La ricetta chiede i 614 GB di cui sopra, ripartiti fra i 259 GiB degli esperti e i 183 delle tabelle Engram. Lo stesso stack ha già un percorso anche su silicio non NVIDIA e non AMD, da Ascend a Cambricon.

DwarfStar è l'altra riga che carica il modello oggi, ed è quella di cui sopra: un motore specializzato, non una piattaforma.

SGLang ha container di preview, non una release: dev-dsv41 per NVIDIA e una variante per MI350X che al momento vive ancora in una pull request aperta. I setup che girano su più DGX Spark messi in rete esistono, ma sono repository di singoli, non un percorso ufficiale.

llama.cpp, a monte, non lo carica: la pull request è in bozza e fa solo la conversione — parole dell'autore, il file convertito non si carica. Il runtime esiste su un branch del suo fork, e anche ik_llama.cpp ha una PR aperta per questa architettura. Nessuna delle due è stata unita.

Ollama, LM Studio e MLX in locale non lo caricano: Ollama lo offre solo con il tag cloud, LM Studio dal suo cloud e senza dichiarare validato il locale, e in MLX la pull request ufficiale è aperta ma non unita, con in giro qualche porting di community. Qui conviene disinnescare una convinzione diffusa, perché vale oltre questo modello: si dice spesso che Ollama sia un wrapper su llama.cpp, e oggi non è più vero — ha un motore suo, e il blocco è che quel motore non implementa questa architettura. Quando qualcuno ti chiede «lo mettiamo su Ollama?», la domanda vera è sempre la stessa: il runtime che vuoi usare ha implementato quell'architettura?

E attenzione a una trappola che costa una giornata: su Hugging Face trovi già una mezza dozzina di repository DeepSeek-V4.1-Flash-GGUF, con dentro pesi veri, da Q2 a Q8. Sembrano un segnale di supporto e non lo sono: un GGUF è un file, e finché il runtime che hai in produzione non implementa l'architettura, quel file non lo carica nessuno. Pesi disponibili e modello servibile sono due date diverse, e in mezzo ci passano settimane.

Cosa ci perdiamo

E qui la parte che nelle presentazioni entusiaste non c'è mai.

I benchmark dicono cose diverse a seconda di cosa misurano. DeepSeek riporta 74,2 su DeepSWE v1.1, davanti a Claude Opus 5 (74,0) e GPT-5.6 Sol (73,0). Sugli stessi materiali, però, Terminal-Bench 3.0 dà 30,0 contro il 43,3 di Opus 5, e sulla 4.0 il divario si allarga: 31,2 contro 51,8. Sulla 2.1, la suite precedente, la 4.1-Flash è invece davanti a tutti: 90,6 contro 89,1. È il numero che ti citeranno, ed è vero — cambia la suite, non il modello. La differenza è fra risolvere un problema circoscritto e reggere una sessione agentica lunga, con strumenti, errori e recupero. La seconda è quella che i nostri progetti fanno davvero.

La verbosità si paga. Le rilevazioni indipendenti di Artificial Analysis contano 250 milioni di token di output contro una mediana di 140 milioni sui modelli di confronto: circa l'80% in più. Su carta il costo per token è ridicolo, e resta comunque vantaggioso; ma se stai dimensionando un'infrastruttura on-premise, i token li paghi in secondi di GPU, non in dollari.

Gli harness funzionano, ma non gratis. Claude Code si può puntare su un modello locale: si imposta ANTHROPIC_BASE_URL su un llama-server avviato con il supporto ai template, e funziona — tool calling incluso, prompt caching incluso, senza proxy. Ma nel resoconto più dettagliato che ho trovato il contesto da un milione di token non si costruisce, con un tetto pratico a 256k, e la prefill a poche decine di token al secondo significa che i ventimila token di system prompt dell'harness si mangiano diversi minuti al primo turno. Funziona. Non è un daily driver.

E c'è un pezzo che non si porta dietro nessuno. Quando compri l'accesso a un modello chiuso non stai comprando solo i pesi: stai comprando il servizio attorno — la garanzia di uptime, il tuning dei formati di tool calling, il moderation layer, il fatto che qualcuno abbia già trovato i bug. Quando porti il modello in casa, tutto quel lavoro diventa tuo. Nell'offerta va messo, perché è la voce che di solito manca.

Ultimo avvertimento, di quelli che costano: il 10 settembre, il giorno del lancio, DeepSeek ha ripuntato l'identificativo deepseek-v4-flash sulla nuova 4.1, e il 14 ha fatto lo stesso con deepseek-v4-pro, che oggi viene servito dalla 4.1 al prezzo della Flash. Se hai una suite di regressione costruita su quegli endpoint, sta misurando un altro modello da qualche giorno. È esattamente il genere di cosa per cui uno mette i pesi in casa.

Torniamo alla domanda della call

Rimettiamo in scena il momento da cui siamo partiti. Il cliente ha letto che i modelli cinesi vanno come ChatGPT e sono gratis, e chiede se non sia il caso di metterseli in casa.

Il punto di tutto questo pezzo non è che adesso sai cosa vuol dire MoE. È che quella domanda, che sembra una domanda sola, in realtà ne contiene quattro — e ognuna delle quattro esce da uno dei concetti di sopra. Riformularla è la cosa che porti in quella stanza e che il cliente da solo non sa fare.

«Quanti parametri attivi, e quanti totali?» Viene dal MoE. Il cliente ti dirà il numero che ha letto sul post; tu hai bisogno dell'altro, perché uno dei due dimensiona il calcolo e l'altro dimensiona la memoria. Se il fornitore — o il collega entusiasta — ti risponde solo «attiviamo 16 miliardi», non ti ha detto niente di utile sul server che devi comprare.

«Quanto contesto useremo davvero, e per quante sessioni in parallelo?» Viene dalla KV cache. È la domanda che nessuno fa e che poi manda fuori budget i progetti, perché quella cache non cresce col numero di parametri: cresce col contesto moltiplicato per il numero di utenti collegati insieme. Un modello che sta comodo in un proof of concept a un utente può non starci a trenta.

«Quanta parte di questo modello può stare su memoria lenta?» Viene dagli n-gram. È la domanda che separa un preventivo da 200.000 franchi di VRAM da uno da 40.000 di RAM e SSD — e oggi, per la prima volta, la risposta non è «niente».

«E questa roba la useremo per fare cosa, esattamente?» Non è una domanda di architettura, ed è la più importante delle quattro. Se la risposta è «rispondere a domande sui nostri documenti», siamo in un territorio dove un modello open di sei mesi fa fa il lavoro su una macchina che l'azienda può comprare. Se la risposta è «un agente che apre ticket, scrive codice e si corregge da solo», siamo nel territorio dove i benchmark che ho citato sopra dicono 74,2 da una parte e 31,2 dall'altra. Sono due progetti diversi, con due budget diversi, e la differenza fra i due non si vede in nessuna classifica.

Nove volte su dieci, dopo queste quattro domande, la risposta onesta al cliente è: non l'ultimo modello, non per tutto, e non adesso. Ma quasi sempre esiste una versione più piccola della stessa idea — un modello di una generazione fa, su un compito solo, su hardware che sta in un rack — che funziona davvero e che gli risolve il problema di controllo da cui era partito. Arrivare a proporgli quella, invece di dire semplicemente «no, meglio il cloud» oppure «sì, compriamo un cluster», è esattamente il lavoro che porto nei progetti.

E qui c'è la ragione di fondo per cui vale la pena spendere tempo su queste cose. Le versioni cambiano ogni sei settimane: qualunque numero in questo post sarà vecchio a gennaio, e va benissimo così. I concetti no. L'attention è del 2017, la separazione fra calcolo e memoria è vecchia quanto l'informatica, e la sparsità — prima nel calcolo con il MoE, adesso anche nell'accesso con gli n-gram — sarà ancora la lente giusta per leggere i modelli del 2028. Inseguire le release è una rincorsa che perdi. Capire le tre o quattro idee che le release ricombinano è un investimento che si ripaga ogni volta che entri in una call.

Perché alla fine la differenza fra te e il cliente non può essere che hai letto il post prima di lui. Deve essere che sai tradurre un'architettura in una voce di budget.

Le domande che restano aperte

Le quattro domande di sopra sono quelle che so già come affrontare. Ce ne sono altre quattro a cui oggi non so rispondere con dei numeri miei.

La prima: cosa vuol dire davvero «supporta il tool calling»? Ogni famiglia di modelli ha il suo formato nativo, ogni runtime lo traduce a modo suo, e il punto in cui la traduzione si rompe non compare in nessun benchmark.

La seconda: un harness agentico è portabile? Claude Code su un modello locale parte, ma quanto lontano arriva prima che la prefill lenta e i loop di recupero rendano il ciclo inutilizzabile? E quanto di quello che attribuiamo al modello è in realtà merito dell'harness?

La terza: oltre la chat completion, cosa ci facciamo? Vision, output strutturato, embedding, reranking, speculative decoding: sono i pezzi che servono davvero in produzione, e il supporto dei runtime locali è a macchia di leopardo.

La quarta, la più scomoda: quando il self-hosting conviene davvero? Non in linea di principio, con i numeri: soglia di volume, costo del server, costo delle persone che lo tengono su, valore effettivo del controllo. È un conto che nella maggior parte dei casi non torna, e dirlo è più utile che vendere un cluster.

Su queste quattro, per ora, quello che ho sono opinioni. Le misuro prima di scriverne.