Avanzato 20 minllama.cpp

DeepSeek V3.2 localmente: MoE 671B accessibile ai mortels

Installare DeepSeek V3.2 in locale significa fare i conti con una realtà: 671 miliardi di parametri totali, 37 miliardi attivi per token e un nuovo meccanismo di attenzione sparsa che cambia le carte in tavola sui contesti lunghi. Questa guida fornisce i requisiti hardware reali (non quelli del marketing), spiega la quantizzazione Q2_K_XL di ik_llama, mostra l'impresa tecnica dell'offload selettivo tramite --override-tensor e si conclude con i token/sec misurati su una workstation domestica nel 2026.

Di Mohamed Meguedmi·Agg. 2026-08-27·Testato su Windows, macOS e Linux

#Perché installare DeepSeek V3.2 localmente

DeepSeek V3.2 è l'aggiornamento intermedio pubblicato da DeepSeek AI alla fine del 2025, con licenza MIT, che introduce due cambiamenti significativi rispetto a V3: DeepSeek Sparse Attention (DSA), un meccanismo di attenzione sparsa che rende subquadratico il costo in memoria dei contesti lunghi, e un perfezionamento dell'addestramento con predizione di più token. Sulla carta, si mantiene la qualità di V3 e si guadagna in efficienza su 128k+ token.

Installarlo in locale risponde a tre esigenze concrete: riservatezza totale (nessun documento viene inviato a DeepSeek), riproducibilità (i pesi non scompaiono da un giorno all'altro) e libertà di sperimentazione (nessun limite alla frequenza delle richieste, nessun filtro di moderazione imposto).

i
Siamo onesti sull'obiettivo
Un deploy locale DeepSeek V3.2 non sostituisce in tempo reale ChatGPT. Si mira piuttosto a un throughput utile (5–15 tok/s) su una workstation domestica potente, per ragionamenti in batch, sintesi di documenti lunghi o codice complesso, dove la qualità è più importante della latenza.

#MoE 671B / 37B attivi + DeepSeek Sparse Attention

Il kit IA Locale

Il tuo ChatGPT privato e gratuito sulla tua macchina in 1 ora — LM Studio, Ollama, Open WebUI, i tuoi documenti, senza cloud.

  • Spazio online a vita
  • PDF + file
  • Aggiornamenti a vita
Il kit IA Locale →o tutti i kit a vita — 49 € →

DeepSeek V3.2 mantiene l'architettura MoE di V3: un router seleziona 8 esperti su 256 per strato, il che fa lavorare solo circa 37 miliardi di parametri per ogni token generato. I restanti 634 miliardi dormono, ma devono rimanere indirizzabili, altrimenti il router perde l'accesso agli esperti che non ha caricato.

Parametri totali
≈ 671 miliardi (indipendentemente dal numero di bit, questa massa deve trovare posto da qualche parte: nella RAM, nella VRAM o su un SSD tramite mmap).
Parametri attivi per token
≈ 37 miliardi. Questo numero determina la velocità teorica: un MoE da 671B sostiene il costo computazionale di un modello denso da 37B.
Esperti per layer
256 esperti MoE + 1 esperto condiviso, routing top-8. Più RAM hai, più strati di esperti rimangono residenti e più la generazione è stabile.
Attenzione
Multi-Head Latent Attention (MLA) ereditata da V3, ora combinata con DeepSeek Sparse Attention (DSA) per i contesti > 32k token.
Contesto
128k token annunciati, utilizzabili in pratica grazie a DSA — la cache KV non esplode più in maniera lineare come su un modello denso classico tipo Qwen 3.5 o Gemma 4.
→
Cosa cambia davvero DSA
DeepSeek Sparse Attention seleziona per ogni token un sottoinsieme di posizioni a cui prestare attenzione, invece di scansionare l'intero contesto. A 128k, riduce il consumo di memoria della cache KV di un fattore da 3 a 5, a seconda dell'impostazione, e accelera il prefill dello stesso fattore. È l'unico argomento tecnico che giustifica la scelta di V3.2 anziché V3 se vuoi sfruttare i contesti lunghi.

#Requisiti hardware realistici

Nessuna configurazione consumer riesce a far girare DeepSeek V3.2 senza complicati accorgimenti. Ecco i tre profili realistici nel 2026, ordinati in base al compromesso tra velocità e budget.

Profilo A — DDR5 potente (192–384 GB)
Workstation con Threadripper 7960X / Xeon W o EPYC 9354P, 256 GB di DDR5 ECC (8 canali), GPU non obbligatoria. Q2_K_XL entra interamente in RAM. Velocità: 5–9 tok/s usando solo la CPU.
Profilo B — RTX 5090 + 192 GB DDR5 (raccomandato)
Il punto ottimale nel 2026: RTX 5090 (32 GB GDDR7, banda passante 1792 GB/s) + 192 GB DDR5 su una piattaforma consumer recente. Si mantengono i livelli di attenzione e l'esperto condiviso sulla GPU, il resto in RAM. Velocità: 10–15 tok/s in generazione.
Profilo C — RAM modesta + SSD NVMe Gen 4/5
96–128 GB di DDR5 + SSD NVMe da almeno 7 GB/s, ≥ 1 TB libero. Gli esperti vengono mappati in memoria dal SSD tramite mmap. Velocità: 1,5–3 tok/s — utilizzabile per batch notturni, non per un uso interattivo.
!
192 GB DDR5, il minimo indispensabile
Con meno di 192 GB di RAM, la quantizzazione Q2_K_XL (~220 GB per V3.2) non entra nella memoria fisica e il sistema ricorre continuamente alla paginazione dall'SSD. Anche con un NVMe Gen 5 veloce, scenderai sotto i 2 tok/s. Se il budget per la RAM è limitato, passa a IQ1_S invece di saturare l'SSD.

#1. Scegliere la quantizzazione per V3.2

L'ecosistema GGUF per DeepSeek V3.2 è sostenuto da due attori principali: Unsloth (che pubblica le varianti UD = «Unsloth Dynamic», tra cui la famosa Q2_K_XL) e bartowski. Le UD utilizzano una matrice di importanza per mantenere gli strati sensibili (attenzione, esperto condiviso) a una precisione superiore rispetto al resto: una differenza concreta nella qualità finale.

IQ1_S (~150 GB)
Quantizzazione dinamica a 1 bit. Rientra in 192 GB di RAM con margine. Qualità degradata, ma utilizzabile per conversazioni generiche. Da evitare per il codice.
Q2_K_XL (~220 GB)
Il riferimento ik_llama / Unsloth Dynamic. Mantiene gli strati critici in Q4-Q5 e comprime gli esperti in Q2. Circa il 95% della qualità di Q4 sui benchmark di ragionamento. Entra in 256 GB di RAM oppure in 192 GB con un po' di offload su SSD.
Q3_K_S (~290 GB)
Per le workstation da 384 GB. Qualità quasi-Q4 sui contesti lunghi. Consigliato se intendi utilizzare seriamente i 128k token.
Q4_K_M (~400 GB)
A pieno regime. Riservato ai server EPYC a doppio socket con almeno 512 GB di DDR5. Oltre questo livello, il guadagno in qualità diventa marginale per un uso locale.
→
Perché Q2_K_XL e non Q2_K_S
Su un MoE 671B, la sensibilità alla quantizzazione è molto eterogenea: i layer di attenzione e i router tollerano male Q2, mentre gli esperti FFN lo tollerano bene. Q2_K_XL rispetta questa distribuzione (precisione mista), mentre Q2_K_S applica lo stesso numero di bit ovunque. Con circa il 5 % di memoria in più, si ottiene un miglioramento della qualità di circa il 10 % nelle attività di programmazione.

#2. Compilare ik_llama.cpp (il fork che gestisce V3.2)

Al momento della stesura di queste righe, il ramo principale di ggerganov/llama.cpp supporta DeepSeek V3.2, ma senza ottimizzazioni specifiche per il routing MoE di DeepSeek. Il fork ik_llama.cpp (Iwan Kawrakow) include kernel CUDA accelerati per i tensori degli esperti e il supporto dinamico a DSA — un aumento del throughput dal 30 al 50% su V3.2, a seconda della configurazione.

Clonare e compilare ik_llama.cpp (CUDA + Flash Attention)
git clone https://github.com/ikawrakow/ik_llama.cpp
cd ik_llama.cpp
cmake -B build \
  -DGGML_CUDA=ON \
  -DGGML_CUDA_FA_ALL_QUANTS=ON \
  -DGGML_CUDA_F16=ON
cmake --build build --config Release -j $(nproc)

Su Mac Apple Silicon, sostituire GGML_CUDA con GGML_METAL. Su AMD, GGML_HIP con ROCm 6.3+. Calcola da 10 a 15 minuti di compilazione su una macchina recente: è C++ con generazione CUDA, quindi non avviare la compilazione su un portatile non collegato alla rete elettrica.

i
Perché ik_llama anziché un binario precompilato
Esistono versioni Linux/Windows di ik_llama.cpp, ma i kernel CUDA generati durante la compilazione dipendono dalla compute capability della tua GPU (sm_120 per RTX 5090, sm_89 per RTX 4090, ecc.). Un binario generico ricorre a un fallback generico e perde il 20–30 % della velocità di elaborazione. Con un volume di queste dimensioni, vale la pena dedicare un quarto d'ora alla compilazione.

#3. Scaricare i GGUF V3.2

I pesi GGUF di DeepSeek V3.2 sono pubblicati su Hugging Face. Per Q2_K_XL Unsloth (l'opzione consigliata per la maggior parte delle configurazioni), un solo download di circa 220 GB suddiviso in diversi file.

Download Q2_K_XL da Hugging Face
pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/DeepSeek-V3.2-GGUF \
  --include "*UD-Q2_K_XL*" \
  --local-dir ./models/deepseek-v32-q2kxl

Il download richiede diverse ore con una connessione domestica — prevedi una connessione in fibra stabile e un disco di destinazione con almeno 250 GB liberi. I GGUF di queste dimensioni sono suddivisi in un numero di file compreso tra 5 e 7 (split-00001-of-N.gguf), e ik_llama.cpp rileva automaticamente le parti se indichi la prima.

!
Verificare i checksum
Un GGUF troncato di 1 byte produce risposte coerenti per 20 token, poi degenera in un ciclo infinito. È il bug più fastidioso da diagnosticare. Verifica sistematicamente gli hash SHA forniti nel repository Hugging Face prima della prima inferenza — bastano 30 secondi per file con sha256sum.

#4. Avvio con --override-tensor (la chiave della performance ibrida)

Il segreto di una buona installazione locale di deepseek v3.2 sta in un'opzione: --override-tensor (alias -ot). Consente di selezionare tramite regex quali layer rimangono su CPU/RAM e quali vengono spostati sulla GPU. Su un MoE, non vogliamo assolutamente caricare tutto sulla GPU (la VRAM non basterà mai), ma vogliamo assolutamente che l'attenzione e i layer condivisi siano accelerati.

Avvio RTX 5090 + 192 GB DDR5 (profilo B)
./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_(up|down|gate)_exps\.=CPU" \
  --threads 16 \
  --flash-attn \
  --host 0.0.0.0 --port 8080

L'espressione regolare \.ffn_(up|down|gate)_exps\. seleziona i tre tensori FFN per esperto — cioè la stragrande maggioranza dei 671B parametri — e li forza a rimanere sulla CPU. Sulla GPU vengono caricati: attenzione (MLA), esperto condiviso, embedding, head. Su una RTX 5090 da 32 GB si utilizzano circa 22 GB di VRAM; il resto serve per la cache KV.

Avvio sulla sola CPU (profilo A, 256 GB DDR5)
./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 32 \
  --flash-attn \
  --host 0.0.0.0 --port 8080
→
Quantizzare la cache KV anche a 32k
Su V3.2, --cache-type-k q8_0 --cache-type-v q8_0 dimezzano il consumo della cache KV con una perdita di qualità impercettibile. È ciò che ti permette di gestire 64k di contesto su una GPU da 32 GB invece di andare in OOM a 24k.

#5. Token/sec misurati su workstation domestica

Valori di riferimento misurati con la build di maggio 2026 di ik_llama.cpp, Q2_K_XL, contesto 32k, prompt misto in francese e codice. I valori restano stabili entro ±15 % a seconda del prompt e del warm-up delle pagine di memoria.

RTX 5090 + Ryzen 9 7950X3D + 192 GB DDR5-6000
Prefill ~110 tok/s, generazione 12–15 tok/s. La configurazione domestica consigliata per il 2026.
RTX 4090 + Threadripper 7960X + 256 GB DDR5 ECC
Prefill ~90 tok/s, generazione 9–12 tok/s. La 4090 è alla pari con la 5090 in questa configurazione ibrida perché il collo di bottiglia è nella RAM, non nella GPU.
EPYC 9354P + 384 GB DDR5 ECC (12 canali), senza GPU
Prefill ~70 tok/s, generazione 7–9 tok/s. La banda di memoria totale (~460 GB/s) compensa l'assenza di GPU.
Mac Studio M3 Ultra 192 GB
Prefill ~55 tok/s, generazione 6–8 tok/s in Q2_K_XL. La memoria unificata (~820 GB/s) salva la situazione.
Ryzen 9 7950X + 128 GB DDR5 + SSD Samsung 990 Pro
Prefill ~25 tok/s, generazione 1,5–2,5 tok/s. Onestamente, utilizzabile solo in batch.
i
Perché il prefill è veloce e la generazione lenta
Il prefill elabora il prompt in batch e sfrutta il parallelismo matriciale — è qui che la larghezza di banda della memoria e la GPU brillano. La generazione produce un token alla volta: per ogni token occorre rileggere i ~37B parametri selezionati dal routing. È una caratteristica intrinseca del MoE, nessun fork di llama.cpp farà miracoli.

#DeepSeek V3.2 vs DeepSeek R1: quale installare?

È una domanda ricorrente, perché i due modelli condividono la stessa architettura MoE 671B / 37B attivi e la stessa licenza MIT. La differenza sta nel post-addestramento, non nella struttura di base.

DeepSeek V3.2
Modello generalista (chat), risposte dirette. Eccellente in francese, molto valido nella programmazione. Aggiunge DSA per il contesto lungo. Da preferire come assistente quotidiano, per la sintesi e la scrittura.
DeepSeek R1
Modello di ragionamento (catena di pensiero esplicita in stile o1). Emette molti token interni (<think>...</think>) prima della risposta finale. Da preferire per matematica, logica e debug di algoritmi complessi.
Costo dell'inferenza
R1 genera da 3 a 10 volte più token (a causa del thinking) per produrre la stessa risposta finale. A parità di velocità di generazione, R1 impiega 5 minuti mentre V3.2 impiega 30 secondi. È un aspetto critico in locale, dove ogni tok/s conta.
Contesto lungo
Grazie a DSA, V3.2 gestisce 128k token con una cache KV di dimensioni ragionevoli. R1 non dispone di DSA e il suo consumo di memoria esplode oltre i 64k token.
VRAM/RAM richiesta
Identica. I due modelli condividono l'architettura 671B/37B e occupano entrambi circa 220 GB nella stessa quantizzazione Q2_K_XL.
→
Verdetto pratico
Installa V3.2 come scelta predefinita e passa occasionalmente a R1 per i compiti che giustificano una catena di pensiero esplicita (dimostrazioni matematiche, debugging complesso). Molti utenti che eseguono i modelli in locale conservano entrambi i GGUF sul proprio NVMe e usano un semplice wrapper di routing.

#Risoluzione dei problemi

« unknown model architecture: deepseek2 »
Il tuo llama.cpp è troppo vecchio o è stato compilato senza il supporto per deepseek2. Aggiorna ik_llama.cpp (ramo main successivo ad aprile 2026) e ricompila. Il binario precompilato standard non sempre basta.
OOM CUDA già durante il caricamento
Il tuo regex -ot non genera abbastanza esperti su CPU. Verifica con ik_llama-bench lo schema reale delle tensori. Il regex giusto per V3.2 mira bene a ffn_(up|down|gate)_exps, non solo a ffn_exps.
Generazione a 1 tok/s con 192 GB di RAM
Il kernel caricherà le pagine dal GGUF finché non avrà caricato tutte quelle utilizzate più spesso. Un primo prompt di riscaldamento da 200 token precarica gli esperti. Altrimenti, aumenta --threads fino al numero di core fisici (non logici).
Risposte che passano al cinese senza motivo
Template di chat errato. Verifica che --chat-template sia in modalità auto e che il GGUF includa effettivamente il template Jinja di DeepSeek. Altrimenti, specifica esplicitamente --chat-template deepseek3.
DSA sembra inattivo (cache KV lineare)
DSA si attiva solo a partire da una lunghezza minima del contesto (configurabile). Per contesti < 16k, il modello utilizza l'attenzione densa classica: è il comportamento previsto e non cambia nulla in termini di qualità.
Crash su prompt lungo dopo il warmup
Probabilmente hai saturato la swap. DeepSeek V3.2 non ama la swap: se la RAM fisica non è sufficiente, disattiva la swap (sudo swapoff -a) e lascia che llama.cpp gestisca la paginazione tramite mmap: è più veloce e più stabile.

#Per approfondire

DeepSeek V3.2 in locale è un punto di partenza per esplorare la categoria dei «modelli di frontiera ospitabili su infrastruttura propria». Tre percorsi complementari:

Ottimizzare la compilazione di llama.cpp
La guida "Compilare llama.cpp con CUDA" descrive in dettaglio i flag avanzati (Flash Attention, MMQ, offload tensors) che incidono realmente sulle prestazioni dei modelli MoE.
Capire le quantizzazioni moderne
Il manuale "Scegliere la quantizzazione (Q4, Q5, Q8, FP16)" spiega perché Q2_K_XL funziona dove Q2 classico fallisce e in quali casi passare a Q3/Q4.
Spingersi un passo oltre nelle dimensioni
La guida "Kimi K2 in locale" applica lo stesso metodo a un MoE con 1T di parametri — utile per anticipare dove andrà l'ecosistema nel 2026-2027.
Questa guida ti è stata utile?

Un feedback, un errore, una precisazione? Facci sapere, così la guida migliora per tutti.