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.
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.
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.
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 ».
Le réseau dispose d’un très grand ensemble d’experts, mais seulement quelques experts sont sélectionnés pour un token donné.
La capacité stockée est immense, tandis que l’activité effective reste beaucoup plus contenue.
Les poids sont distribués avec des formats à faible précision, particulièrement importants pour réduire le volume réel du checkpoint.
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.
Une masse paramétrique de mémoire conditionnelle qui complète le backbone.
Le mécanisme exploite des représentations de séquences courtes afin de retrouver rapidement de l’information pertinente.
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.
| Mécanisme | Rôle |
|---|---|
| Full | Attention complète lorsque nécessaire. |
| Reindex | Reconstruction ou mise à jour d’indices sparse pour cibler l’information utile. |
| Reuse | Réutilisation de structures déjà calculées afin d’éviter un coût quadratique généralisé. |
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é.
Un mécanisme spéculatif propose plusieurs tokens à l’avance avant validation, afin d’augmenter le débit de génération.
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.
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.
Chemin local :
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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é.
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.