DeepSeek · open weights · architecture sparse · septembre 2026

DeepSeek
V4.1‑Flash

Un modèle massif par sa capacité stockée, mais radicalement sparse dans son exécution : environ 763 milliards de paramètres dans le checkpoint complet, 552B de backbone annoncés, près de 196B de mémoire Engram, et seulement une fraction des paramètres mobilisée à chaque token.

MoEMIT1 048 576 tokensVision nativeFP8 + FP448 shards safetensors
Vidéo de référence

Le modèle présenté en vidéo.

Vidéo à l’origine de cette recherche sur DeepSeek‑V4.1‑Flash. Elle est intégrée ici comme point d’entrée audiovisuel, à côté de la documentation technique et des sources officielles.

Le modèle

763B présents ne veut pas dire 763B calculés.

La particularité de V4.1‑Flash est précisément d’accumuler une énorme capacité paramétrique tout en n’activant qu’une petite partie du réseau pour chaque token. C’est ce qui change totalement la lecture du chiffre « 763B ».

552Bbackbone annoncé
~196Bmémoire Engram sparse
8Bactifs au prefill
16Bactifs au decode
Formulation rigoureuse : DeepSeek‑V4.1‑Flash peut être décrit comme un modèle à environ 552B de backbone, augmenté d’une importante mémoire Engram et d’autres composants, pour un checkpoint complet de l’ordre de 763B paramètres.
Architecture

Un système de calcul sparse plutôt qu’un monolithe dense.

EntréeTexte, image et très long contexte.
Causal Encoder20 couches pour encoder efficacement le contexte.
MoE + EngramExperts routés et mémoire conditionnelle sparse.
Decoder20 couches pour la génération.
DSparkDécodage spéculatif pour accélérer la production.
MoE

384 experts routés

Le réseau dispose d’un très grand ensemble d’experts, mais seulement quelques experts sont sélectionnés pour un token donné.

Activation

6 experts routés / token

La capacité stockée est immense, tandis que l’activité effective reste beaucoup plus contenue.

Quantification native

FP8 + FP4

Les poids sont distribués avec des formats à faible précision, particulièrement importants pour réduire le volume réel du checkpoint.

Engram

Une mémoire conditionnelle intégrée au réseau.

Engram constitue l’un des éléments les plus inhabituels de cette architecture. Une très grande quantité de paramètres est mobilisable comme mémoire sparse, sans être traversée comme un bloc dense classique à chaque token.

~196B

Une masse paramétrique de mémoire conditionnelle qui complète le backbone.

n‑grams

Le mécanisme exploite des représentations de séquences courtes afin de retrouver rapidement de l’information pertinente.

Idée centrale.
Le modèle ressemble moins à un Transformer dense géant qu’à un système hybride : backbone + experts + mémoire conditionnelle + mécanismes de décodage et de vision.
Long contexte

1 048 576 tokens.

V4.1‑Flash vise directement les usages où le contexte devient lui‑même une infrastructure : dépôts de code entiers, dossiers documentaires, mémoire agentique, historiques très longs ou grands corpus.

1Mtokens de contexte natif
CSA2Compressed Sparse Attention 2
~890 Bordre de grandeur annoncé du global KV / token
FP4KV cache optimisé
MécanismeRôle
FullAttention complète lorsque nécessaire.
ReindexReconstruction ou mise à jour d’indices sparse pour cibler l’information utile.
ReuseRéutilisation de structures déjà calculées afin d’éviter un coût quadratique généralisé.
Multimodalité & génération

Vision native, raisonnement réglable, décodage spéculatif.

DeepSeek‑ViT

Le modèle intègre une voie visuelle native. Il peut traiter des captures d’écran, documents, graphiques, schémas et images sans dépendre d’un modèle vision entièrement séparé.

DSpark

Un mécanisme spéculatif propose plusieurs tokens à l’avance avant validation, afin d’augmenter le débit de génération.

Reasoning effort

Le modèle est conçu pour faire varier l’effort de raisonnement, ce qui permet d’arbitrer plus finement entre vitesse, coût et profondeur de calcul.

Entraînement & usages

Un modèle pensé pour les agents, le code et les corpus massifs.

Les informations publiées par DeepSeek décrivent un entraînement à très grande échelle et un post‑entraînement combinant supervision, reinforcement learning et distillation on‑policy.

  • corpus multimodal massif ;
  • extension progressive du contexte jusqu’à 1M tokens ;
  • forte orientation code et agents ;
  • tool use et longues trajectoires ;
  • analyse multimodale et documentaire.
Le profil qui se dégage :
V4.1‑Flash est particulièrement intéressant non pas comme simple chatbot, mais comme moteur pour l’analyse de dépôts, le RAG très long, l’orchestration agentique, le code, les outils et la mémoire contextuelle massive.
T‑LINUX · Orion3

Le checkpoint est en cours de téléchargement local.

510,3 Gotaille totale du jeu de poids téléchargé
48fichiers .safetensors
MITlicence
Orion3nœud de stockage / expérimentation

Chemin local :

D:\T-LINUX\models\DeepSeek-V4.1-Flash
Important : télécharger et stocker environ 510 Go de poids est une chose ; exécuter nativement le checkpoint complet en est une autre. Les recettes serveur de référence demandent une quantité de VRAM de classe datacenter. Orion3 peut néanmoins servir de dépôt maître local, de plateforme d’expérimentation, d’offload, de quantification ou de travail sur des variantes adaptées.
Fil complet

Tout ce que nous avons établi dans cette recherche.

1. Identité du modèle

Le modèle étudié est DeepSeek‑V4.1‑Flash, publié dans le dépôt officiel deepseek-ai/DeepSeek-V4.1-Flash. Il s’agit d’un modèle open‑weight sous licence MIT, distribué en dizaines de shards safetensors.

2. Le chiffre « 763B »

Le chiffre d’environ 763 milliards décrit le checkpoint complet. Il ne doit pas être confondu avec le seul backbone, annoncé autour de 552B. Une large quantité supplémentaire de paramètres provient notamment de la mémoire Engram et de composants auxiliaires.

3. Le paradoxe de l’activation sparse

Bien que le checkpoint soit gigantesque, une petite fraction est activée à chaque token. Les indications publiées donnent environ 8B actifs pendant le prefill et 16B pendant le décodage. Le coût réel par token n’est donc pas celui d’un modèle dense 763B.

4. Le MoE

Le modèle repose sur une architecture Mixture‑of‑Experts à très grand nombre d’experts. Les experts disponibles sont nombreux, mais le routeur n’en sélectionne que quelques‑uns à chaque étape. C’est ce découplage entre capacité totale et capacité active qui rend l’architecture possible.

5. Engram

Engram ajoute une mémoire conditionnelle sparse de très grande taille. Cette mémoire est accessible de façon ciblée au lieu d’être traitée comme une succession de couches denses ordinaires. Elle augmente fortement la capacité stockée tout en limitant le calcul effectué à chaque token.

6. Causal Encoder–Decoder

L’architecture publiée décrit un Causal Encoder–Decoder de 40 couches, réparties entre une partie encoder et une partie decoder. Le but est notamment de rendre le traitement de très longs contextes beaucoup plus efficace.

7. Le contexte d’un million de tokens

La fenêtre native atteint 1 048 576 tokens. Pour maîtriser le coût, le modèle associe attention sparse compressée, réutilisation d’indices, KV cache à basse précision et autres optimisations structurelles.

8. CSA2 et le KV cache

Compressed Sparse Attention 2 permet d’éviter une attention complète partout et tout le temps. Les modes Full, Reindex et Reuse participent à la réduction du coût mémoire et de calcul. Les chiffres annoncés pour le global KV sont extrêmement faibles au regard d’une fenêtre de 1M tokens.

9. DSpark

DSpark constitue le mécanisme de décodage spéculatif de cette génération. Il permet de proposer plusieurs tokens puis de les valider, afin d’améliorer le débit sans transformer le modèle en version dense plus petite.

10. Vision native

Le modèle n’est pas limité au texte. Il comprend une voie vision dédiée et peut recevoir des images, des captures, des documents ou des graphiques en entrée, puis produire une sortie textuelle.

11. Quantification et volume réel

Le fait qu’un checkpoint de cet ordre de grandeur tienne autour de 510 Go s’explique par l’usage de formats réduits, notamment FP8 et FP4 sur certaines composantes. Un checkpoint logique de ~763B ne signifie donc pas 763B × 2 octets comme dans une distribution BF16 naïve.

12. Entraînement

DeepSeek décrit un entraînement massif, suivi d’étapes de post‑entraînement destinées au raisonnement, au code, aux agents et à l’utilisation d’outils. Le long contexte a été étendu progressivement jusqu’au million de tokens.

13. Benchmarking

Les scores publiés par le fournisseur indiquent des performances élevées sur plusieurs tâches de code, d’agents, de sciences et d’automatisation. Ils doivent être lus comme résultats annoncés par DeepSeek tant qu’ils ne sont pas tous reproduits indépendamment avec des protocoles identiques.

14. Orion3

Sur T‑LINUX, le jeu de poids complet est destiné au stockage local sur Orion3 dans D:\T-LINUX\models\DeepSeek-V4.1-Flash. Le téléchargement porte sur environ 510,3 Go répartis en 48 fichiers safetensors.

15. Stockage ≠ exécution native

Le stockage complet sur Orion3 est réaliste. L’exécution native du checkpoint dans sa configuration serveur de référence nécessite en revanche une quantité de VRAM bien supérieure à celle d’une seule carte graphique grand public. Les pistes réalistes sont l’offload, la quantification supplémentaire, le pruning, les variantes dérivées ou une exécution distribuée.

16. Pourquoi ce modèle est intéressant pour T‑LINUX

La valeur de V4.1‑Flash pour T‑LINUX ne se limite pas au chat. Il représente surtout un laboratoire pour la mémoire longue, les agents, le RAG à très grand contexte, le code, l’analyse documentaire, la vision et les architectures sparse à forte capacité.

Sources principales

Documentation officielle et implémentation.

Dossier T-1-T · synthèse technique au 24 septembre 2026. Les chiffres annoncés par l’éditeur sont distingués des observations d’infrastructure locale et des évaluations indépendantes.