DeepSeek V3.2 en local : MoE 671B accessible aux mortels

#Pourquoi installer DeepSeek V3.2 en local

DeepSeek V3.2 est la mise à jour intermédiaire publiée par DeepSeek AI fin 2025, sous licence MIT, qui introduit deux changements significatifs par rapport à V3 : DeepSeek Sparse Attention (DSA), un mécanisme d'attention parcimonieuse qui rend le coût mémoire du long contexte sub-quadratique, et un raffinement de l'entraînement multi-token prediction. Sur le papier, on garde la qualité de V3 et on gagne en efficacité sur 128k+ tokens.

L'installer en local répond à trois besoins concrets : confidentialité totale (aucun document n'est envoyé chez DeepSeek), reproductibilité (les poids ne disparaissent pas du jour au lendemain), et expérimentation libre (pas de rate limits, pas de filtre de modération imposé).

Soyons honnêtes sur la cible

Un déploiement DeepSeek V3.2 local n'est pas un remplacement temps réel de ChatGPT. On vise plutôt un débit utile (5–15 tok/s) sur une workstation home musclée, pour du batch raisonnement, de la synthèse de documents longs, ou du code complexe où la qualité prime sur la latence.

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

DeepSeek V3.2 garde l'architecture MoE de V3 : un routeur sélectionne 8 experts sur 256 par couche, ce qui ne fait travailler que ~37 milliards de paramètres pour chaque token généré. Les 634 milliards restants dorment, mais doivent rester adressables, sinon le routeur perd l'accès aux experts qu'il n'a pas chargés.

Paramètres totaux: ≈ 671 milliards (peu importe le bit-rate, c'est cette masse qui doit être logée quelque part : RAM, VRAM, ou SSD via mmap).
Paramètres actifs par token: ≈ 37 milliards. Ce chiffre dicte la vitesse théorique : un MoE 671B s'inflige le coût compute d'un dense 37B.
Experts par couche: 256 experts MoE + 1 expert partagé, top-8 routing. Plus on a de RAM, plus de couches d'experts restent résidentes et plus la génération est stable.
Attention: Multi-Head Latent Attention (MLA) héritée de V3, désormais combinée à DeepSeek Sparse Attention (DSA) sur les contextes > 32k tokens.
Contexte: 128k tokens annoncés, exploitables en pratique grâce à DSA — le cache KV n'explose plus linéairement comme sur Llama 3 ou Qwen 3.

→

Ce que DSA change vraiment

DeepSeek Sparse Attention sélectionne pour chaque token un sous-ensemble de positions à attendre, au lieu de balayer tout le contexte. À 128k, ça divise la consommation mémoire du cache KV par 3 à 5 selon le réglage, et accélère le prefill d'autant. C'est le seul argument technique qui justifie de viser V3.2 plutôt que V3 si vous voulez exploiter les long contextes.

#Prérequis matériels honnêtes

Aucune config grand public n'avale DeepSeek V3.2 sans contorsions. Voici les trois profils réalistes en 2026, classés par compromis vitesse/budget.

Profil A — DDR5 musclée (192–384 Go): Workstation Threadripper 7960X / Xeon W ou EPYC 9354P, 256 Go DDR5 ECC (8 canaux), pas de GPU obligatoire. Q2_K_XL tient intégralement en RAM. Vitesse : 5–9 tok/s en CPU pur.
Profil B — RTX 5090 + 192 Go DDR5 (recommandé): Le sweet spot 2026 : RTX 5090 (32 Go GDDR7, bande passante 1792 Go/s) + 192 Go DDR5 sur une plateforme grand public récente. On garde les couches d'attention et l'expert partagé sur GPU, le reste en RAM. Vitesse : 10–15 tok/s en génération.
Profil C — RAM modeste + SSD NVMe Gen 4/5: 96–128 Go DDR5 + SSD NVMe 7 Go/s minimum, ≥ 1 To libre. On mmap les experts depuis le SSD. Vitesse : 1,5–3 tok/s — utilisable en batch nocturne, pas en interactif.

192 Go DDR5, le minimum vital

En dessous de 192 Go de RAM, la quantization Q2_K_XL (~220 Go pour V3.2) ne tient pas en mémoire physique et vous paginez en permanence depuis le SSD. Même avec un NVMe Gen 5 rapide, vous tomberez sous 2 tok/s. Si le budget RAM est contraint, descendez en IQ1_S plutôt que de saturer le SSD.

#1. Choisir la quantization pour V3.2

L'écosystème GGUF pour DeepSeek V3.2 est porté par deux acteurs principaux : Unsloth (qui publie les variantes UD = « Unsloth Dynamic » dont la fameuse Q2_K_XL) et bartowski. Les UD utilisent une matrice d'importance pour préserver les couches sensibles (attention, expert partagé) à une précision plus haute que le reste — vraie différence pratique sur la qualité finale.

IQ1_S (~150 Go): Quantification 1-bit dynamique. Tient sur 192 Go RAM avec marge. Qualité dégradée mais utilisable pour du chat généraliste. À éviter pour le code.
Q2_K_XL (~220 Go): La référence ik_llama / Unsloth Dynamic. Conserve les couches critiques en Q4-Q5 et écrase les experts en Q2. ~95 % de la qualité Q4 sur les benchmarks de raisonnement. Tient sur 256 Go RAM ou 192 Go + un peu d'offload SSD.
Q3_K_S (~290 Go): Pour les workstations 384 Go. Qualité quasi-Q4 sur les long contextes. Recommandé si vous comptez exploiter les 128k tokens sérieusement.
Q4_K_M (~400 Go): Plein pot. Réservé aux serveurs EPYC bi-socket avec 512 Go+ DDR5. Au-delà, le retour sur qualité devient marginal pour un usage local.

→

Pourquoi Q2_K_XL et pas Q2_K_S

Sur un MoE 671B, la sensibilité à la quantization est très hétérogène : les couches d'attention et les routeurs supportent mal Q2, les experts FFN encaissent bien. Q2_K_XL respecte cette répartition (mixed precision) là où Q2_K_S applique le même bit-rate partout. Pour ~5 % de mémoire en plus, on gagne ~10 % de qualité sur les tâches de code.

#2. Compiler ik_llama.cpp (le fork qui gère V3.2)

Au moment d'écrire ces lignes, la branche principale de ggerganov/llama.cpp gère DeepSeek V3.2 mais sans optimisations spécifiques au routing MoE de DeepSeek. Le fork ik_llama.cpp (Iwan Kawrakow) embarque des kernels CUDA accélérés pour les expert tensors et la prise en charge dynamique de DSA — gain de 30 à 50 % de débit sur V3.2 selon la config.

Cloner et compiler 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)

Sur Mac Apple Silicon, remplacer GGML_CUDA par GGML_METAL. Sur AMD, GGML_HIP avec ROCm 6.3+. Comptez 10 à 15 minutes de build sur une machine récente — c'est du C++ avec génération CUDA, ne lancez pas ça sur un laptop sans alim secteur.

Pourquoi ik_llama plutôt qu'un binaire pré-built

Les releases Linux/Windows d'ik_llama.cpp existent, mais les kernels CUDA générés à la compilation sont sensibles au compute capability de votre GPU (sm_120 pour RTX 5090, sm_89 pour RTX 4090, etc.). Un binaire générique tombe en fallback générique et perd 20–30 % de débit. Sur ce volume, ça vaut le quart d'heure de compilation.

#3. Télécharger les GGUF V3.2

Les poids GGUF de DeepSeek V3.2 sont publiés sur Hugging Face. Pour Q2_K_XL Unsloth (l'option recommandée pour la plupart des configs), un seul download de ~220 Go split en plusieurs fichiers.

Téléchargement Q2_K_XL depuis 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

Le download prend plusieurs heures sur une connexion grand public — prévoyez une fibre stable et un disque cible avec ≥ 250 Go libres. Les GGUF de cette taille sont split en 5 à 7 fichiers (split-00001-of-N.gguf), et ik_llama.cpp détecte automatiquement les splits si vous pointez vers le premier.

Vérifier les checksums

Un GGUF tronqué de 1 octet sort des réponses cohérentes pendant 20 tokens puis dérape en boucle infinie. C'est le bug le plus pénible à diagnostiquer. Vérifiez systématiquement les SHA fournis dans le repo Hugging Face avant la première inférence — ça prend 30 secondes par fichier avec sha256sum.

#4. Lancement avec --override-tensor (la clé de la perf hybride)

Le secret d'une bonne deepseek v3.2 local installation tient en une option : --override-tensor (alias -ot). Elle permet de cibler par regex quelles couches restent sur CPU/RAM et lesquelles partent sur GPU. Sur un MoE, on ne veut surtout pas tout charger sur GPU (la VRAM ne suffira jamais), mais on veut absolument que l'attention et les couches partagées soient accélérées.

Lancement RTX 5090 + 192 Go DDR5 (profil 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

Le regex \.ffn_(up|down|gate)_exps\. cible les trois tenseurs FFN par expert — c'est-à-dire l'écrasante majorité des 671B paramètres — et les force à rester sur CPU. Ce qui part sur GPU : attention (MLA), expert partagé, embeddings, head. Sur RTX 5090 32 Go, on consomme ~22 Go de VRAM, le reste sert au cache KV.

Lancement CPU pur (profil A, 256 Go 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

→

Quantizer le cache KV même à 32k

Sur V3.2, --cache-type-k q8_0 --cache-type-v q8_0 divisent par 2 la consommation du cache KV avec une perte de qualité imperceptible. C'est ce qui vous permet de tenir 64k de contexte sur un GPU 32 Go au lieu de cracher en OOM à 24k.

#5. Tokens/sec mesurés sur workstation home

Repères mesurés avec ik_llama.cpp build de mai 2026, Q2_K_XL, contexte 32k, prompt FR/code mixte. Les chiffres sont stables à ±15 % selon le prompt et le warm-up des pages mémoire.

RTX 5090 + Ryzen 9 7950X3D + 192 Go DDR5-6000: Prefill ~110 tok/s, génération 12–15 tok/s. La config home recommandée 2026.
RTX 4090 + Threadripper 7960X + 256 Go DDR5 ECC: Prefill ~90 tok/s, génération 9–12 tok/s. La 4090 fait jeu égal avec la 5090 sur ce profil hybride parce que le goulot est en RAM, pas en GPU.
EPYC 9354P + 384 Go DDR5 ECC (12 canaux), pas de GPU: Prefill ~70 tok/s, génération 7–9 tok/s. La bande passante mémoire totale (~460 Go/s) compense l'absence de GPU.
Mac Studio M3 Ultra 192 Go: Prefill ~55 tok/s, génération 6–8 tok/s en Q2_K_XL. La mémoire unifiée (~820 Go/s) sauve la mise.
Ryzen 9 7950X + 128 Go DDR5 + SSD Samsung 990 Pro: Prefill ~25 tok/s, génération 1,5–2,5 tok/s. Honnêtement utilisable seulement en batch.

Pourquoi le prefill est rapide et la génération lente

Le prefill traite le prompt en batch et profite du parallélisme matriciel — c'est là que la bande passante mémoire et le GPU brillent. La génération produit un token à la fois, chaque token doit relire les ~37B paramètres routés. C'est intrinsèque au MoE, aucun fork de llama.cpp ne fera de miracle.

#DeepSeek V3.2 vs DeepSeek R1 : lequel installer ?

Question récurrente, parce que les deux modèles partagent la même architecture MoE 671B / 37B actifs et la même licence MIT. La différence est dans la post-formation, pas dans le squelette.

DeepSeek V3.2: Modèle généraliste (chat), réponses directes. Excellent en FR, très solide en code. Ajoute DSA pour le long contexte. À privilégier pour de l'assistant quotidien, de la synthèse, de la rédaction.
DeepSeek R1: Modèle de raisonnement (chaîne de pensée explicite façon o1). Émet beaucoup de tokens internes (<think>...</think>) avant la réponse finale. À privilégier pour math, logique, debug algorithmique complexe.
Coût d'inférence: R1 génère 3 à 10 fois plus de tokens (à cause du thinking) pour produire la même réponse finale. À débit identique, R1 met 5 minutes là où V3.2 met 30 secondes. Critique en local où chaque tok/s compte.
Long contexte: V3.2 grâce à DSA encaisse 128k tokens avec un cache KV raisonnable. R1 manque de DSA et explose en mémoire au-delà de 64k.
VRAM/RAM requise: Identique. Les deux modèles partagent l'architecture 671B/37B et se logent dans la même quantization Q2_K_XL ~220 Go.

→

Verdict pratique

Installez V3.2 par défaut, et basculez sur R1 ponctuellement pour les tâches qui justifient la chaîne de pensée explicite (preuves math, debugging complexe). Beaucoup d'utilisateurs locaux gardent les deux GGUF sur leur NVMe et utilisent un wrapper de routage simple.

#Dépannage

« unknown model architecture: deepseek2 »: Votre llama.cpp est trop ancien ou compilé sans le support deepseek2. Mettez à jour ik_llama.cpp (branche main post-avril 2026) et recompilez. Le binaire pré-built standard ne suffit pas toujours.
OOM CUDA dès le chargement: Votre regex -ot ne pousse pas assez d'experts sur CPU. Vérifiez ollama-style avec ik_llama-bench la répartition réelle des tenseurs. Le bon regex pour V3.2 cible bien ffn_(up|down|gate)_exps, pas seulement ffn_exps.
Génération à 1 tok/s sur 192 Go RAM: Le kernel paginera depuis le GGUF tant qu'il n'a pas chargé toutes les pages chaudes. Un premier prompt de chauffe sur 200 tokens précharge les experts. Sinon, augmentez --threads jusqu'au nombre de coeurs physiques (pas logiques).
Réponses qui basculent en chinois sans raison: Template de chat incorrect. Vérifiez que --chat-template est en mode auto et que le GGUF embarque bien le jinja DeepSeek. Sinon, passez --chat-template deepseek3 explicitement.
DSA semble inactif (cache KV linéaire): DSA n'est activé qu'à partir d'une longueur de contexte minimale (configurable). Pour les contextes < 16k, le modèle utilise l'attention dense classique — c'est attendu, et ça ne change rien à la qualité.
Crash sur prompt long après warmup: Vous avez probablement saturé la swap. DeepSeek V3.2 n'aime pas la swap : si la RAM physique ne suffit pas, désactivez la swap (sudo swapoff -a) et laissez llama.cpp gérer la pagination via mmap, c'est plus rapide et plus stable.

#Pour aller plus loin

DeepSeek V3.2 en local est un point de départ pour explorer la classe « modèles frontière auto-hébergeables ». Trois pistes complémentaires :

Pousser le build llama.cpp: Le guide "Compiler llama.cpp avec CUDA" détaille les flags avancés (Flash Attention, MMQ, offload tensors) qui changent réellement la perf sur MoE.
Comprendre les quantizations modernes: Le guide "Choisir sa quantification (Q4, Q5, Q8, FP16)" éclaire pourquoi Q2_K_XL fonctionne là où Q2 classique échoue, et quand monter en Q3/Q4.
Pousser un cran plus loin en taille: Le guide "Kimi K2 en local" applique la même méthode à un MoE 1T paramètres — utile pour anticiper où ira l'écosystème en 2026-2027.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Installation · 15 min