Qui dimensionne une machine pour DeepSeek-V4-Flash raisonne sur le mauvais chiffre. Le modèle active 13 milliards de paramètres par token et en conserve 284 milliards (rapport technique). Le premier chiffre fixe la vitesse, le second fixe la facture mémoire. Nous dimensionnons les hôtes Mixture-of-Experts sur le second, et s'il reste supportable, c'est grâce à une seule ligne du fichier de configuration : les experts sont stockés sur 4 bits.
DeepSeek a publié DeepSeek-V4-Flash-0731 le 31 juillet 2026, version officielle qui remplace la préversion, à architecture et taille inchangées (MarkTechPost). Les poids sont sous licence MIT et librement téléchargeables (fiche du modèle). Voici le calcul derrière le chiffre de la mémoire, l'endroit précis où l'affirmation « ça tourne sur un portable » se désagrège, et ce que cela change au dimensionnement.
Le chiffre le plus cité est le mauvais
Tout le reste en découle. Un routeur qui sélectionne 6 experts sur 256 par token n'autorise pas à n'en garder que 6 en mémoire : au token suivant, il en choisit six autres. Chaque expert doit être résident, faute de quoi le token attend une lecture disque. ModemGuides en tire la conséquence sans détour : un modèle dense de 13 milliards de paramètres demande environ 8 Go en 4 bits, là où V4-Flash, à précision comparable, en réclame près de vingt fois plus (analyse matérielle). Un fil du forum Hugging Face le résume en quatre mots : « Not a 13B memory problem » (discussion).
Nous dimensionnons désormais tout hôte Mixture-of-Experts sur le nombre total de paramètres et traitons le nombre actif comme une simple mesure de débit, car sur ce modèle les deux valeurs diffèrent d'un facteur 22. L'habitude ne coûte rien quand les deux chiffres sont proches et épargne un cycle d'achat quand ils ne le sont pas.
❌ Dimensionner sur le titre : « 13 milliards actifs, une carte de 24 Go suffira. » ✅ Dimensionner sur le checkpoint : 284 milliards de poids résidents, un plancher qui se compte en centaines de gigaoctets, et la carte de 24 Go n'entre pas dans la discussion.
Ce que dit réellement le fichier de configuration
Il ne s'agit pas d'une quantification appliquée après coup par la communauté, mais d'une caractéristique des poids livrés, lisible directement dans le fichier config.json (configuration) :
"expert_dtype": "fp4",
"n_routed_experts": 256,
"num_experts_per_tok": 6,
"n_shared_experts": 1,
"num_hidden_layers": 43,
"hidden_size": 4096,
"moe_intermediate_size": 2048,
"quantization_config": {
"quant_method": "fp8",
"fmt": "e4m3",
"weight_block_size": [128, 128]
}
La recette vLLM consacrée au modèle décrit la même répartition en toutes lettres : poids des experts en FP4, paramètres restants d'attention, de normalisation et de routage en FP8 (recettes vLLM). Deux types de données, un seul checkpoint. Savoir laquelle des deux moitiés l'emporte décide de tout le reste, et c'est à cette question que la configuration répond.
Où résident les 284 milliards de paramètres
La configuration suffit à le vérifier, sans rien télécharger. Chaque expert est un bloc SwiGLU qui fait passer une dimension cachée de 4096 par une dimension intermédiaire de 2048, répartie sur trois matrices : gate, up et down. Soit 3 × 4096 × 2048, environ 25,2 millions de paramètres par expert. Avec 256 experts routés et un expert partagé, une seule couche porte ainsi près de 6,5 milliards de paramètres rien qu'en experts. Sur 43 couches, le total avoisine 278 milliards.
Rapportés aux 284 milliards publiés, les experts pèsent donc environ 98 % du modèle. Tout le reste — attention, embeddings, normalisation, le routeur lui-même — se partage les quelques milliards restants.
Le même calcul appliqué au chemin actif redonne le chiffre publié. Six experts routés plus l'expert partagé font 7 experts actifs par couche, soit environ 176 millions de paramètres, et près de 7,6 milliards sur 43 couches. En ajoutant la pile d'attention et les embeddings, denses et toujours actifs, on retombe sur les 13 milliards de paramètres activés annoncés par le rapport technique. La configuration est cohérente avec elle-même, ce qu'il vaut mieux vérifier avant d'accorder du crédit à un chiffre qui en découle.
La forme retenue relève d'un choix, non du hasard. La famille V4 associe une pile d'attention hybride — Compressed Sparse Attention et Heavily Compressed Attention — à des Manifold-Constrained Hyper-Connections. Le rapport technique chiffre le résultat à 27 % des FLOPs d'inférence par token et 10 % du cache KV de DeepSeek-V3.2 sur un contexte d'un million de tokens (rapport technique). Le routage parcimonieux et l'attention compressée règlent deux problèmes distincts : le routage contient le calcul par token, l'attention compressée rend le contexte abordable. Ni l'un ni l'autre ne réduit les poids résidents, et c'est précisément pour cela que le format de stockage doit s'en charger séparément.
Reste à appliquer les types de données. À un demi-octet par paramètre, 278 milliards de paramètres d'experts occupent environ 139 Go. Les quelques milliards de paramètres restants, à un octet chacun, ajoutent un montant à un chiffre. Si ces mêmes experts avaient été livrés en FP8, ils occuperaient près de 278 Go ; en BF16, bien plus d'un demi-téraoctet. Le choix du FP4 n'est donc pas un détail d'arrondi : il sépare une machine unique à forte mémoire d'un déploiement réparti sur plusieurs nœuds.
La facture mémoire en octets, pas en paramètres
Le nombre de paramètres n'est qu'un indicateur ; les octets sont la contrainte réelle, et ils sont publiés. Les checkpoints fusionnés 0731 occupent environ 167 Go contre près de 160 Go pour la préversion, la différence tenant au module de décodage spéculatif qui leur est adjoint (recettes vLLM).
En deçà de la précision complète, Unsloth publie une échelle calibrée. La version recommandée UD-IQ3_XXS pèse 103 Go, avec la consigne de disposer d'au moins 110 Go de RAM, la taille du fichier n'incluant ni le cache KV ni l'allocation de contexte. La version UD-Q8_K_XL correspond à V4-Flash en précision d'origine complète, à 162 Go (documentation Unsloth).
Trois chiffres méritent de figurer dans toute décision matérielle :
| Version | Taille du fichier | Plancher mémoire de travail |
|---|---|---|
| Checkpoint 0731 livré | ~167 Go | au-dessus de la taille du fichier |
Précision complète (UD-Q8_K_XL) | 162 Go | au-dessus de la taille du fichier |
Recommandée, 3 bits (UD-IQ3_XXS) | 103 Go | 110 Go |
Il existe par ailleurs plusieurs checkpoints. La recette vLLM en recense quatre : la version 0731 par défaut avec son module de brouillon, les poids FP8 de la préversion, une variante DSpark de préversion, et une variante NVFP4 publiée par NVIDIA dont les experts MoE sont requantifiés en NVFP4 standard tandis que l'attention, les experts partagés, la tête de routage et le module de brouillon restent en FP8. Cette variante vise les GPU Blackwell et s'accompagne d'une réserve qu'il vaut mieux lire avant de la choisir : ses experts ne prennent pas en charge le noyau MoE fusionné réservé au FP8 et retombent sur le backend par défaut (recettes vLLM). Choisir un checkpoint relève donc autant du débit que de la mémoire.
L'écart entre la taille du fichier et le plancher de travail est ce que les équipes oublient. Une fenêtre de contexte d'un million de tokens (rapport technique) ne s'obtient pas sans coût mémoire, et les tailles de fichiers publiées ne la comprennent pas.
Une leçon plus discrète se cache dans ces chiffres, et c'est la même que pour le nombre de paramètres. Les totaux publiés divergent : des articles avançant 304 milliards de paramètres ont circulé à côté du chiffre de 284 milliards. Le rapport technique tranche à 284 milliards pour 13 milliards activés, et la recette vLLM comme les fiches techniques des fournisseurs le confirment. Quand un chiffre de titre est contesté, c'est la taille sur disque qui bloquera réellement un déploiement, et personne ne conteste les 167 Go.
Pourquoi « ça tourne sur un portable » revient sans cesse
L'affirmation circule partout, et l'attrait se comprend : 13 milliards de paramètres actifs évoquent un modèle taillé pour un poste de développement. Nous n'avons pas testé de configuration à 32 Go, et les chiffres publiés par les éditeurs y sont contraires : 110 Go constituent le plancher de la plus petite version recommandée par Unsloth (documentation Unsloth). ModemGuides parvient à la même conclusion par le matériel et désigne les machines de 128 Go comme la cible réaliste, en relevant qu'Apple propose le Mac Studio M3 Ultra à 96 Go, ce qui place le candidat le plus évident juste sous la barre (analyse matérielle).
Quantifier davantage reste un levier réel, mais il cesse d'être gratuit. La même analyse mesure pour les versions de classe 2 bits une concordance d'environ 78 % sur le token le plus probable face aux poids de référence. C'est une décision de qualité, non de conditionnement, et elle relève de l'évaluation plutôt que de l'achat. Si vous échangez de la précision contre de la mémoire, mesurez l'échange sur vos propres tâches : la discipline vaut chaque fois qu'un harnais d'évaluation s'intercale entre un modèle et son score.
Ce que cela change au dimensionnement
Trois habitudes découlent de ce calcul.
Lire le format de stockage avant le nombre de paramètres. expert_dtype en dit plus long sur la facture mémoire que les 284 milliards affichés, puisqu'il s'applique à 98 % des paramètres. Un modèle comptant moins de paramètres au total, mais stocké en BF16, peut sans difficulté réclamer davantage de mémoire que celui-ci.
Traiter les paramètres actifs comme une mesure de débit. Ils expliquent pourquoi DeepSeek peut proposer V4-Flash à 0,14 dollar le million de tokens en entrée et 0,28 dollar le million en sortie (tarifs de l'API). Ils n'expliquent rien du poids des poids.
Séparer la question de la licence de celle du matériel. La licence MIT attachée à ces poids est un acquis réel, et une licence open-weight règle ce que vous avez le droit de faire. Elle ne règle pas ce que vous avez les moyens de faire. Ce sont deux verrous indépendants, et le second se décide sur les chiffres de cet article.
Les capacités qui suscitent l'intérêt sont bien réelles. DeepSeek-V4-Flash-0731 obtient 82,7 sur Terminal Bench 2.1 contre 72,1 pour DeepSeek-V4-Pro (Preview), et 54,4 sur DeepSWE contre 7,3 pour sa propre préversion (fiche du modèle). Simon Willison y voit possiblement le meilleur rapport intelligence-prix disponible et signale qu'Artificial Analysis le classe devant MiniMax M3, un modèle de 428 milliards de paramètres (carnet). Rien de tout cela ne modifie le nombre d'octets, et c'est ce nombre que le bon de commande doit satisfaire.
On retrouve le schéma décrit dans notre article expliquant qu'ARC-AGI-3 a mesuré le harnais, pas seulement le modèle : un chiffre se colle à un modèle alors qu'il provient de la configuration qui l'entoure. Ici le chiffre vaut 13 milliards, la configuration est un routeur 6 parmi 256, et ce qui est mesuré tient de la vitesse, pas de la taille. Si vous évaluez cette catégorie de modèles face à une solution hébergée haut de gamme, notre comparatif DeepSeek V4 détaille l'arbitrage, et la fiche configuration d'inférence traite des réglages qui pèsent sur le débit une fois les poids résidents.
Si vous cherchez à savoir si un modèle de cette catégorie a sa place dans votre stack, et si vous préférez régler le dimensionnement avant l'achat du matériel plutôt qu'après, notre équipe réalise exactement ce type d'évaluation.
Questions fréquentes
De combien de mémoire DeepSeek-V4-Flash a-t-il réellement besoin ? Prévoyez au moins 110 Go. La version 3 bits recommandée par Unsloth pèse 103 Go et s'accompagne d'un plancher de 110 Go, les tailles de fichiers excluant le cache KV et l'allocation de contexte. La précision d'origine complète atteint 162 Go (documentation Unsloth).
Pourquoi 13 milliards de paramètres actifs ne font-ils pas 13 milliards en mémoire ? Parce que le routeur peut retenir n'importe quels 6 experts sur 256 à chaque token : tous doivent rester résidents. Les paramètres actifs régissent le calcul par token, le total régit la facture mémoire (analyse matérielle).
Qu'est-ce que le FP4 change concrètement ? Les experts concentrent près de 98 % des paramètres : les stocker sur un demi-octet plutôt qu'un octet réduit de moitié, ou presque, l'empreinte résidente. Cette répartition appartient au checkpoint et n'est pas une requantification ultérieure (recettes vLLM).
DeepSeek-V4-Flash compte-t-il 284 ou 304 milliards de paramètres ? Le rapport technique indique 284 milliards de paramètres pour 13 milliards activés, ce que confirme la recette vLLM. Des valeurs supérieures ont circulé dans des articles secondaires. Le checkpoint pèse de toute façon environ 167 Go sur disque (rapport technique).
Peut-on l'exécuter sans carte graphique ? Nous n'avons pas testé cette configuration, et les tailles publiées plaident contre une machine de 32 Go. La plus petite version recommandée exige 110 Go de mémoire de travail, ce qui oriente vers des systèmes de 128 Go plutôt que vers des portables (analyse matérielle).
Sources
- https://arxiv.org/abs/2606.19348
- https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731
- https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731/blob/main/config.json
- https://recipes.vllm.ai/deepseek-ai/DeepSeek-V4-Flash
- https://api-docs.deepseek.com/quick_start/pricing
- https://unsloth.ai/docs/models/deepseek-v4
- https://www.modemguides.com/blogs/ai-infrastructure/run-deepseek-v4-flash-locally-hardware-reality-check
- https://simonwillison.net/2026/Jul/31/deepseek-v4-flash-0731/
- https://www.marktechpost.com/2026/07/31/deepseek-upgrades-deepseek-v4-flash-0731-with-major-agentic-and-coding-gains/
- https://discuss.huggingface.co/t/deepseek-qwen/176657
- https://www.spheron.network/blog/deploy-deepseek-v4-flash-gpu-cloud
- https://willitrunai.com/blog/deepseek-v4-vram-requirements