Quando metti su Ollama e scarichi qwen3:14b, stai scaricando un file di circa 9 gigabyte. Quel file contiene miliardi di numeri in virgola mobile — i pesi del modello. Non c'è codice, non c'è logica esplicita, non ci sono if-else. Solo numeri. Capire cosa sono quei numeri, come si comprimono e come nascono i modelli derivati è la chiave per smettere di scegliere modelli per sentito dire.
Un Large Language Model è una rete neurale con centinaia di layer impilati. Ogni layer trasforma il vettore di input applicando matrici di moltiplicazione — e i valori di quelle matrici sono i pesi. Durante il training, il modello vede miliardi di testi e aggiusta iterativamente quei pesi per minimizzare l'errore di previsione del token successivo. Alla fine del training i pesi sono frozen: il modello non impara più, esegue solo.
Un modello da 70 miliardi di parametri ha 70 miliardi di numeri. In float32 (4 byte ciascuno) occuperebbe 280 GB. In float16 (2 byte) scende a 140 GB. Questo spiega immediatamente perché una RTX 3090 da 24 GB non ci entra neanche lontanamente, e perché si è sviluppata tutta una scienza della compressione.
La quantizzazione è il processo di ridurre la precisione numerica dei pesi. Invece di usare 16 bit per ogni numero, usi 8, 4, o anche 2 bit. Un modello Q4 da 70B pesa circa 40 GB: entra in due RTX 3090, o in una singola A100 da 40 GB.
La perdita di qualità dipende da quanta precisione sacrifichi. Q8 è quasi indistinguibile dall'originale. Q4 è ottimo per uso pratico. Q2 inizia a degradare in modo percettibile, soprattutto su ragionamento complesso. La scelta giusta per un agente brain è Q4 o Q5: massimo risparmio di VRAM con impatto minimo sulla coerenza delle risposte.
Il formato più diffuso per la quantizzazione è GGUF, sviluppato da llama.cpp. Un file .gguf è un modello quantizzato che Ollama, LM Studio e llama.cpp sanno leggere direttamente. Quando scarichi da Hugging Face un file con Q4_K_M nel nome, stai scaricando una quantizzazione Q4 con un particolare algoritmo di ottimizzazione (K-Quants) che bilancia meglio la qualità rispetto al Q4 piatto.
I modelli base — quelli su cui poi si costruisce tutto il resto — vengono da pochi grandi laboratori. Meta ha rilasciato la famiglia Llama, Alibaba ha rilasciato Qwen, Mistral AI ha rilasciato Mistral e Mixtral. Questi sono modelli foundation open-weight: i pesi sono scaricabili liberamente, le architetture sono documentate.
Llama 3.3 70B è il modello di riferimento per l'open source in questo momento. Qwen 2.5 è la risposta cinese di Alibaba — con varianti da 0.5B a 72B — e risulta particolarmente forte su coding e ragionamento matematico. Mistral è un laboratorio francese che ha contribuito idee architetturali importanti come l'attention a finestra scorrevole e l'architettura Mixture of Experts.
Quando vedi un modello chiamato deepseek-r1-distill-llama-70b, stai leggendo una genealogia: è una Llama 3.3 70B (l'architettura e i pesi base sono di Meta) che DeepSeek ha poi riaddestrato con i propri dati. Non è una compressione, è un modello diverso con la stessa struttura ossea.
La distillazione è una tecnica di training in cui un modello piccolo impara da un modello grande. Il modello grande — chiamato teacher — produce output su migliaia di task. Il modello piccolo — lo student — viene addestrato a replicare quegli output, assorbendo in forma compressa i ragionamenti del teacher.
DeepSeek ha usato questa tecnica in modo sistematico. Il loro modello R1 (671B, puramente originale) genera soluzioni elaborate a problemi di reasoning: dimostrazioni matematiche, catene di pensiero passo-passo, ragionamenti su più livelli. Quei dati vengono poi usati per fare fine-tuning su Llama 70B o Qwen 32B. Il risultato sono i modelli "Distill": mantengono l'architettura leggera e la licenza aperta del modello base, ma hanno assorbito il ragionamento strutturato di R1.
È come affiancare un junior a un senior per sei mesi: il junior non diventa il senior, ma impara un modo di approcciare i problemi che prima non aveva. Il limite è che il junior resta un junior — capace di ragionare bene su problemi simili a quelli che ha visto, meno robusto su situazioni completamente nuove.
DeepSeek V3 ha 671 miliardi di parametri, ma non li usa tutti contemporaneamente. Usa un'architettura Mixture of Experts (MoE): invece di un unico percorso di computazione, il modello ha molti sotto-modelli specializzati (experts), e per ogni token attiva solo un sottoinsieme di essi.
In pratica, su 671B parametri totali, solo circa 37B sono attivi durante l'inferenza di un singolo token. La computazione è quindi comparabile a un modello da 37B, mentre la capacità totale — la conoscenza memorizzata nei pesi — è quella di un modello da 671B. Velocità di un modello piccolo, memoria di un modello grande.
Il rovescio della medaglia è che tutti i 671B devono comunque stare in VRAM per essere accessibili al router MoE. Non puoi fare streaming parziale dei pesi: servono ~320 GB di VRAM al Q4. Questo è il motivo per cui un singolo Hetzner GEX131 da 96 GB non basta — non per il compute, ma per la memoria.
Quando devi scegliere un modello da montare, le domande sono nell'ordine seguente. Prima: quanta VRAM hai? Questo determina il range di parametri che puoi usare. Poi: dense o MoE? I modelli MoE come Mixtral e DeepSeek V3 danno più capacità per VRAM ma richiedono che tutti i pesi siano caricati. Poi: vuoi un modello base o un modello fine-tuned? Base se vuoi addestrarlo tu, fine-tuned (Instruct, Chat) se lo usi direttamente. Infine: quale quantizzazione? Q4_K_M è quasi sempre la scelta giusta per produzione.
Per un agente brain che deve fare tool calling, ragionamento multi-step e scrittura strutturata, il punto dolce oggi è intorno ai 32-70B parametri Q4. Sotto i 14B iniziano a vacillare su task complessi. Sopra i 70B entri in territorio dove servono multi-GPU o soluzioni cloud. DeepSeek V3 via API è l'eccezione: 671B a costo irrisorio perché i pesi li gestisce qualcun altro.
Il modello non è il prodotto. Il prodotto è l'infrastruttura intorno al modello: i prompt, i tool, la memoria, il contesto. Cambiare modello è come cambiare motore — importante, ma la macchina è il resto.
DeepSeek ha rilasciato due grandi modelli che si chiamano in modo simile ma fanno cose completamente diverse. Confonderli è il modo più rapido per scegliere quello sbagliato.
DeepSeek V3 è un modello conversazionale general-purpose. Riceve un messaggio, ragiona brevemente, risponde. Tool calling eccellente, velocità alta, comportamento prevedibile. È il modello giusto per un agente che deve agire: creare file, chiamare API, orchestrare step multipli. Nei benchmark che abbiamo fatto su task brain reali — crea persona, scrivi diary, aggiorna progetto, cerca prima di creare — V3 ha fatto 10/10 con tempi medi di 7 secondi, identici a Claude Sonnet a un decimo del costo.
DeepSeek R1 è un modello di ragionamento. Prima di rispondere produce un lungo chain-of-thought interno — pensa per decine di secondi, a volte minuti, su problemi complessi. È il corrispettivo di o1 di OpenAI. Eccelle su dimostrazioni matematiche, ragionamento logico formale, analisi multi-livello. Non è progettato per tool calling: la maggior parte dei provider che lo distribuiscono non espongono la funzione di function calling perché il modello in fase di thinking tende a romperla. Se chiedi a R1 di creare un diary entry, ci pensa su 20 secondi e poi ti scrive una bella risposta in prosa senza fare niente — tecnicamente risponde, praticamente inutile come agente.
La regola pratica: V3 per tutto ciò che è agentico e operativo. R1 per analisi one-shot dove serve ragionamento profondo e non ti importa dell'azione diretta. Sono strumenti diversi, non versioni diverse dello stesso strumento.
DeepSeek V3 su API diretta costa $0.27 per milione di token in input e $1.10 in output. Claude Sonnet costa $3.00 e $15.00. Il rapporto è circa 1:10. Non è un errore di pricing — è il risultato di tre scelte tecniche precise e di un contesto economico diverso.
La prima scelta è l'architettura MoE che abbiamo già visto: attivare solo 37B parametri su 671B per ogni token significa che il compute effettivo per richiesta è quello di un modello piccolo, anche se la capacità complessiva è enorme. Meno FLOP per token = meno costo di inferenza.
La seconda è una loro innovazione chiamata Multi-head Latent Attention: una variante dell'attention mechanism standard che comprime la KV cache — la memoria temporanea che il modello mantiene durante la generazione — di circa il 90%. Meno memoria occupata significa più richieste in parallelo sullo stesso hardware.
La terza è l'uso di FP8 durante il training, invece del classico BF16 o FP32. Dimezza la memoria e la banda necessaria durante l'addestramento, riducendo drasticamente i costi del cluster. DeepSeek ha dichiarato di aver addestrato V3 con circa 6 milioni di dollari in compute — un ordine di grandezza meno rispetto ai modelli equivalenti di OpenAI o Anthropic.
Il contesto geografico completa il quadro: DeepSeek è un laboratorio cinese fondato da Liang Wenfeng, ex gestore di un hedge fund quantitativo. Opera con H800 — la versione export-limited degli H100 che l'embargo americano ha reso disponibile in Cina — e con costi operativi strutturalmente diversi da una startup di San Francisco che deve pagare affitti a SoMa e ingegneri con equity. Il risultato è che trasferiscono sul prezzo un vantaggio di costo reale, non una sovvenzione temporanea per acquisire mercato.
Per un utente che usa il brain come Giobi — sessioni intense, molti tool call, contesti lunghi — il costo mensile su DeepSeek direct API è circa 5-6 dollari. Su Claude Sonnet API sarebbe intorno ai 70. Claude Max a 100 dollari flat è ancora competitivo per uso personale intenso, ma non scalabile come backend per un prodotto con utenti multipli. DeepSeek V3 lo è.