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

DeepSeek a publié le 31 juillet 2026 la version officielle de son modèle Flash : 284 milliards de paramètres totaux, 13 milliards actifs par token, un million de tokens de contexte, poids mixtes FP4 + FP8 et module DSpark fusionné. Cet article recense ce qu'il faut pour le faire tourner en local sur un DGX Spark, un cluster de deux DGX Spark et la DGX Station GB300, avec vLLM 0.25 ou plus.

Par QDNA · Publié le 2 août 2026 · Mis à jour le 7 septembre 2026 · 11 min de lecture

Mis à jour le 2 septembre 2026 : Relecture du même jour : les poids publiés de V4 Flash 0731 pèsent 167 Go (48 fichiers, API Hugging Face), non 83,4 Go, et ceux de V4 Pro 865 Go, non 470 ; le tag NGC et les débits MiaAI-Lab sont repris du playbook et du dépôt du jour ; les prix Mac Studio passent au M5 Ultra (apple.com/fr) et le prix MI300X, non publié, est retiré ; deux affirmations prêtées à NVIDIA sans source (avertissement Llama 405B, relevé RoCE 189,85 Gb/s) sont retirées.

Vérification du nom : V4 Flash 0731 existe bien

Le nom a circulé dans plusieurs fils professionnels avant d'être confirmé. Le dépôt officiel deepseek-ai/DeepSeek-V4-Flash-0731 existe sur Hugging Face depuis le 31 juillet 2026 à 07:30 UTC, et l'alias API deepseek-v4-flash pointe dessus depuis l'annonce du 1er août 2026 sur le site DeepSeek.

Il s'agit bien de la version officielle de Flash, qui remplace la preview d'avril 2026 et qui embarque le module DSpark, un décodeur spéculatif fusionné dans le même checkpoint. Les annonces de « R2 » qui circulent dans la presse spécialisée ne correspondent, à ce jour, à aucun dépôt officiel de DeepSeek.

Le paysage généraliste actuel tient en une chronologie serrée : V3.2 stable le 1er décembre 2025, V4 Preview (Flash + Pro) le 24 avril 2026, V4 Flash 0731 le 31 juillet 2026. Le V4 Pro reste en preview et n'a pas reçu de révision 0731. L'angle de cet article est matériel : V4 Flash 0731 est intéressant parce qu'il est compact pour sa catégorie (13 milliards actifs sur 284 milliards), ce qui ouvre la porte à des déploiements sur du matériel de bureau raisonnable, à condition d'accepter le poids total à charger et de surveiller le cache clé-valeur en contexte long.

Quelles sont les spécifications vérifiées du modèle ?

Le config.json officiel du dépôt 0731 décrit un mélange d'experts de 256 experts routés plus un expert partagé, six experts sélectionnés par token, quarante-trois couches et une couche de prédiction next-token alimentée par DSpark.

Le contexte maximal annoncé atteint 1 048 576 tokens via une mise à l'échelle YaRN ×16 appliquée à une fenêtre native de 64 K. Pour les modes de raisonnement high et max, DeepSeek recommande une fenêtre de sortie pouvant aller jusqu'à 384 K tokens, et la recette vLLM officielle demande au moins 393 216 tokens de contexte pour Think Max.

Les poids sont publiés dans un format mixte FP4 + FP8. Les experts MoE sont stockés en FP4, la majorité des autres paramètres en FP8 par blocs 128×128, avec activations dynamiques et calcul BF16. Le dépôt 0731 contient 48 shards safetensors pour un total de 166,9 Go relevés via l'API Hugging Face le 2 septembre 2026, soit 4,7 bits par paramètre en moyenne (166,9 × 8 / 284). La version du 2 août donnait 83,4 Go et 2,35 bits, soit la moitié : un compte d'éléments de tenseurs avait été pris pour un compte d'octets. C'est la base d'estimation à retenir pour dimensionner la mémoire : 167 Go rien que pour les poids, avant le cache clé-valeur, les buffers d'exécution et la marge de débit.

Aucune quantification communautaire (GGUF, AWQ, GPTQ) n'est officielle pour 0731 ; il faut charger le safetensors mixte tel quel. DeepSeek ne publie pas non plus de checkpoint BF16 intégral pour cette révision. Le rapport technique associé, DeepSeek V4: Towards Highly Efficient Million-Token Context Intelligence, est référencé arXiv 2606.19348. Les innovations principales sont l'attention hybride CSA + HCA (Compressed Sparse Attention puis Heavily Compressed Attention), les connexions mHC (Manifold-Constrained Hyper-Connections) et l'optimiseur Muon pour l'entraînement ; l'efficacité déclarée à 1 M de contexte est de 27 % des FLOPs d'inférence mono-token et 10 % du cache KV de V3.2.

Quelles sont les performances officielles déclarées par DeepSeek ?

DeepSeek publie surtout des benchmarks agentiques pour la révision 0731. Les valeurs ci-dessous sont officielles mais déclaratives ; le modèle est évalué en effort max, température 1, top_p 0,95 avec un harness annoncé mais pas encore publié au moment de la model card. Deux jeux DSBench restent internes.

Le ton reste donc prudent : d'après les benchmarks publiés par DeepSeek, et non « prouvé meilleur ».

Lecture sobre : 0731 dépasse Flash Preview et même Pro Preview sur tous les tests de cette table, dépasse GLM 5.2, mais reste généralement derrière Opus 4.8. Pour les benchmarks académiques (MMLU-Pro, GPQA, LiveCodeBench, SWE-bench), les valeurs publiées par DeepSeek concernent la famille V4 Preview et ne sont pas systématiquement republiées pour 0731 : il faut écrire « non publié pour 0731 » plutôt que fabriquer un chiffre.

Le trio matériel : DGX Spark, cluster 2× Spark, DGX Station

Le DGX Spark est un mini-système Arm64 de 1,2 kg bâti sur le superchip Grace Blackwell GB10, et il combine un CPU Arm à 20 cœurs (10× Cortex-X925 plus 10× Cortex-A725) et un GPU Blackwell, le tout dans 128 Go de mémoire LPDDR5X cohérente à 273 Go/s.

NVIDIA annonce jusqu'à 1 PFLOP FP4 avec sparsité 2:1, et StorageReview mesure en matrice réelle 99,8 TFLOPS BF16 et 207,7 TFLOPS FP8 par matmul MAMF. Le réseau rapide ConnectX-7 à 200 Gb/s est intégré, plus un RJ-45 10 GbE. Le TDP du SoC est de 140 W pour une alimentation de 240 W, le SSD NVMe M.2 auto-chiffrant de 4 To est livré en standard, et DGX OS, une distribution Ubuntu arm64, est le système officiel.

Pour relier deux DGX Spark, un seul câble QSFP suffit : pas de commutateur. NVIDIA documente cette liaison directe avec une pleine bande passante ConnectX-7, en RoCE/RDMA. vLLM répartit alors les poids en tensor parallel 2 (TP=2), Ray lançant un worker par Spark, et NCCL transportant les collectives sur le lien ConnectX-7. Ce n'est pas du NVLink entre boîtiers : le lien réseau théorique de 25 Go/s est près de onze fois moins large que les 273 Go/s de mémoire locale et ajoute une latence à chaque collective. NVIDIA donne jusqu'à quatre DGX Spark reliés pour des modèles jusqu'à 700 milliards de paramètres (page produit relue le 2 septembre 2026) ; la version du 2 août lui prêtait un avertissement sur Llama 405B que le playbook ne contient pas.

La DGX Station GB300 est d'un autre ordre de grandeur, et la fiche NVIDIA finale fait foi : 252 Go de HBM3e à 7,1 To/s côté GPU, plus 496 Go de LPDDR5X à 396 Go/s côté CPU, le tout relié par NVLink-C2C à 900 Go/s pour un pool cohérent de 748 Go. Les performances annoncées sont 20 PFLOPS FP4 avec sparsité, 10 PFLOPS FP8/FP6 avec sparsité, 5 PFLOPS FP16/BF16 avec sparsité, et 80 TFLOPS FP32. Le réseau ConnectX-8 SuperNIC monte à 800 Gb/s sur deux ports QSFP112 400 Gb/s. La machine supporte 7 instances MIG et consomme 1 600 W en charge système. Attention toutefois, le communiqué de mars 2025 annonçait 784 Go, alors que la fiche finale actuelle fait foi à 748 Go.

Tableau comparatif matériel et budget

Avant d'écrire le ticket, le bon réflexe est de comparer le trio DGX aux alternatives CUDA x86 (RTX 5090), Apple Silicon (Mac Studio M5 Ultra) et accélérateurs serveur (AMD MI300X).

Les chiffres ci-dessous sont en euros hors taxes pour le DGX Spark (meilleur prix relevé sur idealo.fr le 2 septembre 2026), en euros TTC et HT pour le Mac Studio (apple.com/fr, 2 septembre 2026), en dollars ou en livres hors taxes pour le reste, prix publics ou observés en 2026 ; la bande passante mémoire est le critère décisif en décodage, comme détaillé dans notre article prefill/decode.

Lecture achat. Pour plus de 32 Go et la simplicité CUDA, un Spark suffit tant que le modèle tient dans 128 Go en quantification agressive ; il sacrifie la bande passante à la capacité et à la sobriété. Le cluster 2× Spark fonctionne pour les modèles qui dépassent la taille d'un Spark (Llama 3 70B BF16, V4 Flash 0731 via TP=2), mais la latence augmente à chaque collective réseau. La RTX 5090 écrase le décodage en bande passante (1 792 Go/s) mais plafonne à 32 Go : elle sert un excellent ticket pour modèles compacts. Le Mac Studio M5 Ultra monte à 512 Go (option annoncée pour fin octobre 2026, prix non publié), mais MLX/llama.cpp remplace vLLM CUDA et le débit de décodage reste memory-bound. La DGX Station vise la production entreprise avec BF16/HBM, MIG et modèles géants.

À noter : NVIDIA ne publie pas de MSRP mondial ferme pour la Station ; les devis passant par les OEM que sont ASUS, Dell, Exxact, Gigabyte, HP, MSI et Supermicro. Le revendeur pi3g affiche, sur une page mise à jour le 27 août 2026, de 93 000 à 110 500 € HT selon l'OEM, dont la configuration Exxact Valence à 95 000 € HT retenue dans tous les calculs du site ; au Royaume-Uni, l'ASUS ExpertCenter Pro ET900N G3 est affiché 98 000 £ HT / 117 600 £ TTC chez Scan, et 99 999 $ HT chez SHI aux États-Unis. Les commandes ont ouvert en 2026 avec des livraisons dans les mois suivants, et pour la France il faut demander un devis OEM et confirmer la disponibilité, la TVA et la date de livraison.

Recette vLLM pas-à-pas

La voie recommandée par NVIDIA est le conteneur NGC arm64 (variante aarch64 SBSA), pas un pip install vllm arbitraire sur l'hôte : le GB10 est un GPU sm_121/121a et les wheels CUDA x86_64 standards ne ciblent pas cette architecture. DeepSeek V4 Flash 0731 exige vLLM 0.25.0 minimum, à cause du module DSpark fusionné dans le checkpoint.

Le tag NGC du mois (catalogue NGC vLLM) varie ; vérifier la dernière révision stable avant déploiement.

1× DGX Spark : API locale compatible OpenAI

Le Spark 1 expose l'API vLLM, et le cache Hugging Face doit être monté pour éviter de retélécharger les 167 Go à chaque redémarrage.

docker run --rm -it \
  --gpus all --network host \
  -v $HOME/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  nvcr.io/nvidia/vllm:26.05-py3 \
  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"}'

Points pratiques. Le flag --kv-cache-dtype fp8 divise par deux l'empreinte du cache KV, critique à contexte long. --attention-config use_fp4_indexer_cache active le cache d'indexeur FP4 propre à l'attention hybride CSA + HCA. --speculative-config active DSpark sans draft model séparé, les poids sont fusionnés. Aucun --rope-scaling manuel : YaRN ×16 est déjà inscrit dans config.json. Pour le sampling, DeepSeek recommande température 1 et top_p 0,95 en mode agentique, top_p 1 hors scénario agentique.

Cluster 2× DGX Spark : tensor parallel via Ray

Le Spark 1 démarre le Ray head et expose l'API, quand le Spark 2 rejoint le cluster comme Ray worker, le même conteneur NGC tournant sur les deux nœuds. Le cache Hugging Face doit être présent (ou monté via NFS) sur les deux machines pour éviter un retéléchargement et garantir que les shards safetensors sont identiques.

# Spark 1 (head)
ray start --head --port=6379
docker run --rm -it --gpus all --network host \
  --add-host=spark2:<IP_SPARK_2> \
  -v $HOME/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  nvcr.io/nvidia/vllm:26.05-py3 \
  vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
    --trust-remote-code \
    --tensor-parallel-size 2 \
    --distributed-executor-backend ray \
    --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"}'

# Spark 2 (worker)
ray start --address='spark1:6379'

Avant de lancer vLLM, vérifier le tissu RoCE sur les deux nœuds avec ib_write_bw et nccl-tests. Si NCCL retombe sur le RJ-45/TCP au lieu du QSFP/RDMA, les performances s'effondrent, avec une pénalité de 10 à 20× observée, et le test de fumée devient indispensable : un LinkX Berkeley à 200 Gb/s doit monter autour de 190 Gb/s réels.

DGX Station GB300 : variante mono-GPU simple

La Station se comporte comme un serveur Blackwell classique, si bien que la même commande fonctionne en supprimant le tensor parallel et en ajustant la fenêtre de contexte si besoin :

docker run --rm -it --gpus all --network host \
  -v $HOME/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  nvcr.io/nvidia/vllm:26.05-py3 \
  vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
    --trust-remote-code \
    --tensor-parallel-size 1 \
    --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"}'

Sur la Station, 252 Go de HBM3e à 7,1 To/s accueillent les 167 Go de poids en HBM, ce qui laisse toute la bande passante GPU disponible pour le décodage. C'est la cible privilégiée pour servir V4 Flash 0731 sans compromis de quantification.

Comment comparer les benchmarks réels en tokens/s ?

Un tok/s n'est comparable que si le modèle, la quantification, les longueurs d'entrée/sortie, la concurrence et le moteur sont identiques. Les chiffres ci-dessous sont des tokens de sortie agrégés sauf mention ; ne pas confondre C128 avec 924 tok/s par utilisateur.

La documentation officielle DeepSeek ne publie pas de chiffre tok/s unique pour V4 Flash 0731, le débit dépend fortement du matériel, du batching, de la longueur de préfill et de DSpark.

Lecture. Sur un seul Spark, le décodage est bridé par les 273 Go/s de bande passante LPDDR5X. C'est cohérent : le décodage autoregressif relit les poids à chaque token et devient memory-bound. Le passage à deux Sparks en TP=2 dégrade la latence par utilisateur (chaque token traverse le QSFP) mais débloque des modèles qui ne tiennent pas sur une seule machine et permet de paralléliser plusieurs flux. La recette MiaAI-Lab montre qu'un setup 2× Spark fortement patché atteint 95,9 tok/s médian en C1 et 340,5 tok/s agrégés en C6 sur V4 Flash 0731, avec MTP_NUM_TOKENS=6 et le cache KV nvfp4_ds_mla. La DGX Station, avec ses 7,1 To/s de HBM3e, prend le relais quand la latence prime et que le budget le permet.

Pièges ARM64 et unified memory

Les DGX Spark et DGX Station partagent la mémoire entre CPU et GPU. Ce n'est pas un déport vers le processeur comme avec une RTX, puisque CUDA adresse le pool unifié, mais les 128 Go d'un Spark ne sont jamais 128 Go entièrement disponibles aux poids : DGX OS, page cache, Ray, Python, CUDA graphs, activations et KV cache utilisent le même pool.

Pièges observés et parades. Premièrement, nvidia-smi --query-gpu=memory.* peut retourner N/A sur l'unified memory ; NVIDIA conseille d'utiliser le nvidia-smi brut. Deuxièmement, vLLM raisonne encore en budget « GPU memory utilization », et l'allocation dynamique UMA peut provoquer un OOM malgré une taille de poids apparemment inférieure à 128 Go. Troisièmement, le loader fastsafetensors peut doubler temporairement la pression mémoire ; une recette communautaire déconseille ce loader quand les poids approchent la mémoire disponible. Quatrièmement, Ray a disparu de certaines images NGC en tant que dépendance par défaut et doit être installé dans le conteneur ; le playbook NVIDIA documente le patch.

Le tissu réseau entre deux Sparks est l'autre point sensible. Mauvaise interface, mauvais HCA ou conflit de libnccl.so peuvent faire pendre le chargement ou forcer TCP au lieu de RoCE/RDMA. Le test ib_write_bw doit approcher les 200 Gb/s nominaux ; la version du 2 août citait « 92,57 + 97,28 = 189,85 Gb/s » comme relevé officiel, chiffres que le playbook NVIDIA ne contient pas. Si ce n'est pas le cas, ne pas lancer vLLM : corriger le HCA, l'IP ou la MTU d'abord. Côté quantification, AWQ, Marlin, NVFP4, MXFP4, FlashInfer et DeepGEMM n'ont pas tous eu le support sm_121 au même moment ; préférer les modèles explicitement listés par le playbook et l'image NGC correspondante. Côté mémoire, NVIDIA recommande en dépannage de vider le buffer cache (sync; echo 3 | sudo tee /proc/sys/vm/drop_caches) et de réduire le contexte ou le nombre de séquences.

Conclusion : souveraineté, coût et point de bascule

DeepSeek V4 Flash 0731 ferme la parenthèse sur la disponibilité locale d'un modèle MoE 284 milliards à la pointe agentique.

Son format mixte FP4 + FP8 de 167 Go rend la cible matérielle crédible, qu'il s'agisse d'un cluster de deux DGX Spark à 9 750 € HT ou d'une DGX Station GB300 à 95 000 € HT (pi3g, 27 août 2026), et vLLM 0.25+ avec DSpark et l'attention hybride CSA + HCA rend l'exécution réellement supportée. Les conteneurs NVIDIA NGC arm64 et le playbook officiel lèvent les principaux pièges techniques.

Le bon arbitrage suit la question métier. Pour un prototype ou un usage monoposte sur un modèle compact, le DGX Spark seul suffit et reste le ticket le moins cher. Pour servir V4 Flash 0731 à plusieurs utilisateurs avec un budget contenu, le cluster 2× Spark fonctionne mais le lien 200 Gb/s devient vite le goulot ; à ce stade, la Station prend la main avec sa HBM3e à 7,1 To/s. Pour les charges agentiques, le cache clé-valeur local rend les préfixes répétés quasi gratuits, ce que ne permet pas le paiement au token. La souveraineté impose le local dès que la donnée est sensible, indépendamment du coût ; c'est l'argument qui fait pencher la décision même quand l'API cloud paraît moins chère à l'instant t. Notre analyse sur site vs API détaille le calcul de point de bascule.

Références

• DeepSeek V4 Flash 0731 : dépôt officiel Hugging Face
• Documentation DeepSeek : l'alias API deepseek-v4-flash sert la version DeepSeek-V4-Flash-0731
• Rapport technique DeepSeek V4 : Towards Highly Efficient Million-Token Context Intelligence (arXiv 2606.19348)
• Recette vLLM officielle : DeepSeek V4 Flash
• NVIDIA DGX Spark : page produit et spécifications
• NVIDIA DGX Station : spécifications finales
• NVIDIA DGX Spark Playbooks : vLLM officiel
• NVIDIA DGX Spark Playbooks : connexion de deux Sparks
• StorageReview : revue DGX Spark et benchmarks vLLM réels
• MiaAI-Lab : recette DeepSeek V4 Flash sur 2× DGX Spark (scripts et artefacts)
• tonyd2wild : recette 2× Spark plus simple pour V4 Flash
• VideoCardz : prix ASUS ExpertCenter Pro ET900N G3 (DGX Station, UK)