DeepSeek V4 Flash 0731 sur DGX Station et un cluster de 2 DGX Spark (vLLM)

Le dernier modèle généraliste de DeepSeek (284 B / 13 B actifs, 1 M de contexte, FP4+FP8, DSpark) tourne en local sur DGX Spark, un cluster de 2 DGX Spark et DGX Station GB300 avec vLLM 0.25+. Ce guide couvre uniquement ce qu'il faut pour installer, servir et budgéter le modèle sur ces trois cibles matérielles.

Par QDNA · Publié le 2 août 2026 · 9 min de lecture

Intelligence du modèle : ce qu'il sait faire

DeepSeek a publié V4 Flash 0731 le 31 juillet 2026 (Hugging Face deepseek-ai/DeepSeek-V4-Flash-0731, alias API deepseek-v4-flash). C'est un MoE de 284 milliards de paramètres avec 13 milliards actifs par token, fenêtre de contexte d'1 million de jetons, et un module DSpark (décodeur spéculatif fusionné dans le checkpoint).

Matériel : trois configurations qui marchent

Machines GB10 et GB300 : liste complète des marques OEM

NVIDIA ne vend pas toujours les machines finales directement. Les DGX Spark (GB10) et DGX Station (GB300) sont distribués via un programme OEM strict qui impose le cahier des charges. Voici la liste complète des marques confirmées à GTC 2026 (source : ServeTheHome et NVIDIA).

Toutes ces machines partagent la même architecture Grace Blackwell et le même DGX OS (Ubuntu 24.04 optimisé Blackwell). Les différences portent sur le châssis, le refroidissement, la garantie et le support. Pour les DGX Spark (GB10), toutes les machines délivrent 128 Go unifiée à 273 Go/s. Pour les DGX Station (GB300), toutes délivrent 252 Go HBM3e + 496 Go LPDDR5X via NVLink-C2C à 900 Go/s. Les prix ne sont pas publiés pour les DGX Station : il faut passer par un contact commercial (Dell, MSI, Supermicro).

Voir les fiches détaillées DGX Spark, DGX Station et RTX PRO 6000 (alternative quand le modèle tient en mémoire unifiée).

Quantization : combien de qualité on perd par Go économisé

Avant de choisir, l'enjeu est de savoir combien de points de performance on perd par Go économisé. Sources croisées : Unsloth Dynamic 2.0, Aider Polyglot et arXiv "Accuracy is Not All You Need".

Recommandation : sur DGX Spark (128 Go), UD-IQ3_XXS est le choix pragmatique d'Unsloth — la dégradation reste dans le bruit des benchmarks publiés. Sur un cluster de 2 DGX Spark ou DGX Station, monter à UD-Q4_K_XL ou UD-Q8_K_XL lossless si la qualité prime. Téléchargement : huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUF.

Quantization requise par modèle et par machine : perte réelle de qualité

Le tableau précédent décrit la perte de qualité par quantization. Celui-ci répond à la question pratique : pour chaque modèle et chaque machine, quelle quantization faut-il appliquer pour tenir, et combien de qualité perd-on réellement ? Les modèles ci-dessous sont triés par taille, de ceux qui tiennent partout à ceux qui exigent la compression la plus agressive.

Deux familles de perte à distinguer : (1) QAT-aware comme DeepSeek V4 Flash 0731, entraîné quantization-aware — les experts MXFP4 natifs sont repackés bit-for-bit, la perte est ~0 sur UD-IQ3_XXS malgré une réduction de 37 % (167 → 104 Go). (2) Post-training quantization comme AWQ Q4 sur Llama 3 ou Mistral, qui descend à 4 bits sans avoir été entraînée pour — perte typique de 0,5 à 1 pt MMLU et dégradation visible sur le code. La différence est l'origine : DeepSeek a intégré la quantization dans le training, pas les autres.

Référence croisée : Aider Polyglot sur DeepSeek V3.1 (modèle comparable MoE) montre que UD 5-bit ≈ full-precision (70,7 % Aider Pass-2 ≈ BF16), tandis que la conversion classique AWQ 4-bit sur un modèle non-QAT descend sous les 60 %.

Quels modèles tiennent sur la machine

KV cache : formule et dimensionnement

Le calcul du cache clé-valeur est la donnée structurante du dimensionnement : V4 Flash 0731 utilise un Grouped Query Attention (GQA) extrêmement agressif — 1 tête KV pour 64 têtes de requête. Cette compression (la plus agressive du marché pour un MoE 284 B) divise le footprint KV par 64 par rapport à un MHA classique.

Formule : KV par token = 2 × head_dim × n_kv_heads × bytes_par_valeur × n_couches

Avec la config officielle deepseek-ai/DeepSeek-V4-Flash-0731/config.json (head_dim=512, num_key_value_heads=1, num_hidden_layers=43) :

• KV cache BF16 : 2 × 512 × 1 × 2 × 43 = 88 064 bytes/token = 86,0 KB/token
• KV cache FP8 : 2 × 512 × 1 × 1 × 43 = 44 032 bytes/token = 43,0 KB/token

À titre de comparaison, Llama 3 70B en GQA 8/64 atteint 320 KB/token, soit 7,4× plus lourd que V4 Flash 0731.

Calculette KV cache et contexte

Sélectionnez votre machine, le modèle à servir et le format KV cache. La calculette affiche instantanément la mémoire disponible pour le KV cache, le contexte maximum et le nombre d'utilisateurs concurrents par taille de contexte.

Le calcul du cache clé-valeur est la donnée structurante du dimensionnement : V4 Flash 0731 utilise un Grouped Query Attention (GQA) extrêmement agressif — 1 tête KV pour 64 têtes de requête. Cette compression (la plus agressive du marché pour un MoE 284 B) divise le footprint KV par 64 par rapport à un MHA classique.

Formule : KV par token = 2 × head_dim × n_kv_heads × bytes_par_valeur × n_couches

Avec la config officielle deepseek-ai/DeepSeek-V4-Flash-0731/config.json (head_dim=512, num_key_value_heads=1, num_hidden_layers=43) :

• KV cache BF16 : 2 × 512 × 1 × 2 × 43 = 88 064 bytes/token = 86,0 KB/token
• KV cache FP8 : 2 × 512 × 1 × 1 × 43 = 44 032 bytes/token = 43,0 KB/token

À titre de comparaison, Llama 3 70B en GQA 8/64 atteint 320 KB/token, soit 7,4× plus lourd que V4 Flash 0731.

Vitesses réelles (decode + préremplissage)

Référence NVIDIA officielle sur DGX Spark pour d'autres modèles : Qwen3 14B atteint 22,71 tok/s en NVFP4, GPT-OSS-120B atteint 55,37 tok/s en MXFP4. Avec deux DGX Sparks en tensor-parallel, Qwen3 235B (qui ne tient pas sur un seul nœud) tourne à 11,73 tok/s agrégé.

Recette pas-à-pas pour un DGX Spark

Voir la fiche complète DGX Spark pour les alternatives OEM et les détails hardware.

1. Mettre à jour DGX OS et le driver NVIDIA (CUDA 12.8+, sm_120).
2. Tirer l'image NGC officielle :

   docker pull nvcr.io/nvidia/vllm:25.04-py3-aarch64

3. Lancer le container en montant le cache Hugging Face :

   docker run --gpus all \
     -v $HOME/.cache/huggingface:/root/.cache/huggingface \
     -p 8000:8000 \
     nvcr.io/nvidia/vllm:25.04-py3-aarch64

4. Servir V4 Flash 0731 avec vLLM 0.25+ :

   vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
     --trust-remote-code \
     --kv-cache-dtype fp8 \
     --block-size 256 \
     --enable-expert-parallel \
     --moe-backend deep_gemm_mega_moe \
     --attention-config '{"use_fp4_indexer_cache": true}' \
     --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

5. Tester l'API compatible OpenAI :

   curl http://127.0.0.1:8000/v1/chat/completions \
     -H 'Content-Type: application/json' \
     -d '{
       "model": "deepseek-ai/DeepSeek-V4-Flash-0731",
       "messages": [{"role":"user","content":"Bonjour"}],
       "max_tokens": 256
     }'

Pour utiliser un GGUF Unsloth à la place du safetensors natif : ollama run unsloth/DeepSeek-V4-Flash-0731-GGUF:UD-IQ3_XXS ou via llama.cpp récent avec support sm_120/sm_103.

Recette pas-à-pas pour un cluster de 2 DGX Spark

Voir aussi : Dynamo pour la distribution d'inférence sur grandes flottes GPU, et le routeur sémantique QDNA pour orchestrer plusieurs clusters.

1. Relier les deux DGX Spark par un câble DAC QSFP-DD 200 Gb/s (≈ 100 €) sur les ports ConnectX-7.
2. Configurer l'IP statique RoCE sur les deux nœuds :

   # Spark maître
   sudo ip addr add 10.10.10.1/24 dev 
   
   # Spark worker
   sudo ip addr add 10.10.10.2/24 dev 

3. Démarrer Ray head sur le Spark maître :

   ray start --head --port=6379 --num-gpus=1

4. Joindre le second Spark :

   ray start --address='10.10.10.1:6379' --num-gpus=1 --block

5. Vérifier le cluster puis servir en tensor-parallel sur 2 nœuds :

   ray status
   vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
     --trust-remote-code \
     --tensor-parallel-size 2 \
     --enable-expert-parallel \
     --kv-cache-dtype fp8 \
     --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

Pièges ARM64 et unified memory

• ARM64 SBSA + CUDA. Les containers NGC publient des variantes aarch64 avec CUDA 12.8+. V4 Flash 0731 exige vLLM 0.25 minimum pour le support DSpark. Vérifier la présence de PyTorch ≥ 2.5 nightly dans l'image NGC.
• Unified memory et --max-model-len. Sur GB10, le modèle, le KV cache et le runtime partagent les 128 Go. Ne pas régler --gpu-memory-utilization trop haut. Le calcul taille modèle + 10-30 % de marge + cache clé-valeur attendu reste la bonne approche.
• Câble et interface ConnectX-7. Pour un cluster de 2 DGX Spark, le port 200 Gb/s doit être configuré en mode RoCE v2 et l'IP statique doit être routée. NCCL utilise NCCL_NET_PLUGIN « IB » ou « socket » selon les versions.
• Pas de NVLink-C2C entre Sparks. Les deux pools de 128 Go restent disjoints. vLLM s'en accommode via le tensor-parallel, mais cela coûte une communication all-reduce à chaque couche (overhead mesurable dès que le batch dépasse quelques dizaines de séquences).
• DeepSeek V4 Pro reste en preview et pèse 1,6 T de paramètres (49 B actifs). Aucun checkpoint BF16 complet n'est distribué. La cible raisonnable pour le duo Spark est donc V4 Flash 0731, pas Pro.

Conclusion : quelle machine pour quel usage

Pour un usage d'entreprise sur V4 Flash 0731, l'écosystème QDNA propose plusieurs briques complémentaires à déployer selon le besoin : la passerelle vLLM pour servir le modèle, Unsloth pour le fine-tuning QLoRA, la fiche DGX Spark et la fiche DGX Station pour le dimensionnement matériel, et la pile dwarfstar pour assembler le tout sur un serveur RTX PRO 6000 quand la taille du modèle le permet.

Le DGX Spark seul fait tourner DeepSeek V4 Flash 0731 dans son format natif FP4+FP8, à un débit limité par les 273 Go/s de bande passante unifiée. C'est la bonne cible pour un usage individuel ou une équipe qui accepte un débit modeste sur des contextes courts.

Un cluster de 2 DGX Spark n'apporte un gain que dans deux cas : faire tenir un modèle qui dépasse 128 Go en shardant (par exemple Llama 3 70B BF16, ou une version quantifiée agressive d'un plus gros modèle), ou servir plus d'utilisateurs concurrents en agrégeant deux pools disjoints.

La DGX Station GB300 est la cible privilégiée pour DeepSeek V4 Flash 0731 en production. Son pool cohérent de 748 Go (252 Go HBM3e GPU à 7,1 To/s + 496 Go LPDDR5X CPU à 396 Go/s, reliés en NVLink-C2C à 900 Go/s) traitent le modèle sans compression agressive, et le 1M de contexte devient tenable grâce au cache clé-valeur FP8 et à use_fp4_indexer_cache. C'est la machine qui justifie le passage à l'échelle d'une PME ou d'une grande entreprise, à condition d'accepter le budget et les 1 600 W de consommation.

Références

• DeepSeek V4 Flash 0731, dépôt officiel Hugging Face
• Annonce DeepSeek du 1er août 2026, alias API V4 Flash
• Rapport technique DeepSeek V4 (arXiv 2606.19348)
• Recette vLLM officielle pour V4 Flash
• NVIDIA DGX Spark, page officielle
• NVIDIA DGX Station, page officielle
• vLLM, documentation officielle
• Fiche QDNA : DGX Spark
• Fiche QDNA : DGX Station
• Fiche QDNA : DeepSeek V4