Qu’est-ce que DeepInfer ? Le moteur d’inférence de DeepSeek, et les parties qu’il n’a pas livrées

DeepInfer est le framework d'inférence que DeepSeek a publié le 16 octobre 2026 sous Apache-2.0, et il ne sert exactement qu'un seul modèle : DeepSeek-V4.1-Flash, avec DeepSeek-V4.1-Flash-1017 comme checkpoint par défaut. Ce périmètre mono-modèle est la première chose à comprendre, car il explique presque tout le reste du dépôt. Ce n'est pas un framework de service généraliste qui contient accessoirement une configuration DeepSeek. C'est le chemin de code que DeepSeek exécute en production, réduit aux parties généralisables, et il est transparent sur cette réduction : la liste du README lui-même de ce dont a besoin un service d'inférence complet, et de ce que cette version n'inclut pas, cite un système de cache KV, une désagrégation VE/Prefill/Decode et l'équilibrage de charge entre réplicas à parallélisme de données. Ce que vous obtenez, c'est le chemin de calcul — kernels, parallélisme, décodage spéculatif, ordonnancement, sortie structurée. Ce que vous n'obtenez pas, c'est la couche de stockage et de routage qui rend le chemin de calcul peu coûteux à exploiter à l'échelle. DeepSeek en explique la raison : ces composants sont étroitement couplés à l'infrastructure interne, de sorte que la conception est décrite dans un article publié tandis que le code reste en interne.

Qu'y a-t-il réellement dans le dépôt ?

La liste de fonctionnalités publiée se lit comme un tour d’horizon des goulots d’étranglement liés au service d’un grand modèle de mélange d’experts. Il y a les bibliothèques de noyaux que DeepSeek a déjà publiées — FlashMLA pour l’attention, DeepGEMM pour les multiplications matricielles, DeepEP pour la communication en parallélisme d’experts, ainsi que TileKernels et DeepSelect. Il y a le schéma de parallélisme : l’attention fonctionne en parallélisme de données avec un parallélisme de contexte équilibré, la moitié MoE fonctionne en parallélisme d’experts avec un répartiteur de charge en parallélisme d’experts. Il y a DSpark, la pile de décodage spéculatif, avec des longueurs de vérification planifiées plutôt que fixes. Il y a le rejeu borné SWA, le mécanisme qui empêche un cache d’attention à fenêtre glissante d’imposer un recalcul complet à chaque défaut de cache. Il y a l’ordonnancement asynchrone des lots, l’inférence invariante au lot avec échantillonnage déterministe, et la sortie structurée contrainte par regex, schéma JSON ou EBNF.

Le point d'entrée est délibérément minimal. Après avoir défini DEEPINFER_ACCELERATOR sur nvidia ou l'équivalent Ascend et exécuté build.sh, le dépôt fournit examples/offline_inference.py, qui exécute le checkpoint par défaut de bout en bout. DEEPINFER_HF_MODEL_DIR le pointe vers un autre répertoire de poids. Les benchmarks publiés ont été mesurés sur quatre GPU SM100 pour le préremplissage et 64 GPU SM100 pour le décodage, ce qui correspond à la configuration de déploiement pour laquelle le moteur a été conçu, et non à une démo pensée pour un ordinateur portable.

Le README indique également l’origine du code, ce qu’il vaut la peine de savoir avant de le lire. Le moteur a été initialement construit principalement sur vLLM, avec des inspirations de conception tirées de SGLang et TensorRT-LLM. Cette filiation transparaît dans la structure — le scheduler, l’interface d’attention paginée et le chemin d’échantillonnage paraîtront familiers à quiconque a lu ces projets — et elle explique pourquoi la version publiée est un fork d’une pile de serving plutôt qu’une architecture écrite de zéro. Ce que DeepSeek a ajouté, c’est la partie spécifique à son propre modèle : le déploiement dissocié, le parallélisme d’experts étendu avec son équilibreur, le rejeu à fenêtre glissante et DSpark.

Ce qu’il ne contient pas, et pourquoi cela compte davantage

Les trois pièces manquantes ne sont pas de petites omissions. Chacune est un système qui doit exister avant que le moteur ne serve le trafic de production, et chacune est coûteuse d'une manière différente.

• Le système de cache KV. La réutilisation de préfixes est là où se trouvent l’essentiel des gains dans une charge de travail de chat, car un succès de cache remplace un prefill. Sans stockage de cache, chaque requête recalcule son prompt. La propre documentation de DeepSeek décrit le stockage qu’il utilise : un cluster 3FS dédié plutôt que la mémoire locale de l’hôte, précisément pour que n’importe quelle machine de prefill puisse atteindre n’importe quel préfixe et que la capacité de cache puisse être mise à l’échelle indépendamment du calcul.

• Désagrégation VE/Prefill/Decode. Le README indique que l’essentiel des fonctionnalités côté moteur existe déjà dans la version ; ce qui manque, c’est le déploiement. Désagréger l’encodeur visuel, le préremplissage et le décodage permet de dimensionner chaque étape en fonction de son propre goulot d’étranglement et de contrôler séparément le délai avant le premier token et le délai entre les tokens. C’est une décision d’infrastructure, pas une simple option.

• Répartition de charge entre les réplicas de parallélisme de données. DeepSeek exploite quatre équilibreurs — préfill, decode, encodeur vision et parallélisme d’experts — et décrit les quatre dans le document. Aucune logique de routage n’est livrée. Sans elle, une flotte de réplicas ne vaut que ce que vaut le routeur placé devant, et un routeur round-robin naïf détruira le taux de succès du cache que le stockage a été conçu pour protéger.

Lue conjointement, l’omission vous indique de quel type d’artefact il s’agit. DeepInfer est une implémentation de référence du chemin de calcul, publiée afin que le travail sur le noyau et l’ordonnancement puisse être inspecté et réutilisé, et non une distribution que l’on installe et vers laquelle on dirige le trafic.

La barrière matérielle est le véritable filtre

DeepInfer cible les NVIDIA SM100 et Huawei Ascend 950. Il n'existe ni chemin Ampere ni chemin Hopper, ce qui exclut la plupart des GPU présents dans la majorité des clusters aujourd'hui. Le reste de la chaîne d'outils est tout aussi spécifique : Linux uniquement, GCC 13 ou plus récent, Python 3.12, CUDA 13 pour NVIDIA ou CANN 9.2 pour Ascend. Et il n'y a aucune version publiée : au moment de sa consultation le 21 octobre 2026, le dépôt ne comptait aucune release publiée, donc il n'y a rien à télécharger et rien à épingler. Vous le clonez et le compilez avec votre propre chaîne d'outils.

Cette combinaison est inhabituelle pour une publication open source qui suscite autant d’attention, et il vaut mieux y voir un énoncé précis du périmètre plutôt qu’un oubli. Les noyaux du dépôt sont écrits pour un jeu d’instructions spécifique et une interconnexion spécifique ; les chiffres du README proviennent de ce matériel. Porter le chemin de calcul vers une génération antérieure est exactement le type de travail qu’une communauté réalise rapidement et qu’une organisation d’ingénierie ne peut pas promettre. Quelques jours après la publication, un portage tiers ciblant d’anciens composants NVIDIA est apparu sur GitHub, ce qui est un signal utile concernant la demande et pas du tout un signal permettant de savoir si les débits publiés survivent au portage.

La configuration de déploiement que DeepSeek exécute réellement

La description de l’architecture est l’endroit où les hypothèses du dépôt deviennent lisibles. Le système est désagrégé en un encodeur de vision, un préremplissage et un décodage, ainsi que des nœuds de stockage dédiés. Le préremplissage utilise un parallélisme d’experts de 2 à 8 avec un parallélisme de données correspondant, en choisissant la plus petite configuration autorisée par la HBM. Le décodage fait l’inverse : un parallélisme d’experts et un parallélisme de données de 64 à 128, que DeepSeek appelle Wide-EP, en utilisant la plus grande configuration autorisée par les GPU disponibles. Le parallélisme de tenseurs et le parallélisme de contexte ne sont pas utilisés du tout. L’encodeur de vision exécute un GPU par instance, avec des GPU moins chers recommandés, car ce n’est pas sur l’encodeur que l’argent est dépensé.

Le plus petit déploiement qui ait du sens découle de ces chiffres. Un GPU de préremplissage et un GPU de décodage fonctionneront, et en pratique le ratio entre les deux pools est d’environ un pour un. Mais comme le décodage nécessite 64 GPU ou plus pour bénéficier du parallélisme d’experts, la plus petite unité efficace est de 64 GPU de préremplissage plus 64 GPU de décodage. C’est le nombre à garder en tête lorsqu’on lit une quelconque affirmation sur l’efficacité de DeepInfer : les chiffres décrivent un déploiement à 128 GPU, et la moitié correspond à un seul étage.

Répartir le prefill et le decode entre plusieurs centres de données est techniquement possible, car DeepSeek-V4.1-Flash compresse sensiblement son cache KV, et le déploiement de DeepSeek lui-même place bien les nœuds d’inférence dans des centres de données différents mais adjacents. Le budget est d’environ 400 Gbps d’interconnexion pour huit GPU, et le document est franc sur le coût en fiabilité — la fibre entre les bâtiments est facile à couper.

Pourquoi le décodage est-il si répandu ?

Le parallélisme étendu des experts est le choix le plus déterminant de la conception, et il est facile de le prendre à tort pour une astuce de mise à l’échelle. Dans une couche de mélange d’experts, chaque token ne touche qu’un petit nombre d’experts ; le coût d’une étape de décodage est donc dominé par le déplacement des poids et des activations des experts plutôt que par l’intensité arithmétique. Répartir les experts sur 64 ou 128 GPU réduit le trafic mémoire par étape auquel chaque GPU contribue, ce qui augmente le nombre de tokens par seconde si — et c’est là la condition — la charge entre les experts reste équilibrée. C’est précisément le rôle de l’équilibreur de charge du parallélisme d’experts.

Les réglages de DeepSeek sont suffisamment précis pour être reproduits. Pour le prefill, chaque GPU conserve quatre experts redondants en plus de ceux qu’il possède, les statistiques sont collectées sur une fenêtre de 100 pas, et les experts sont réaffectés tous les 1 000 pas, les poids étant mélangés au sein du groupe via la mémoire partagée NVLink. Le déséquilibre mesuré — rang le plus lent divisé par la moyenne — atteint 1,074 pour une configuration EP4/DP4 et 1,045 pour EP2/DP2. Pour le decode, les réglages sont plus relâchés : un expert redondant par GPU, une fenêtre de statistiques de 1 000 pas, une réaffectation tous les 10 000 pas, et un déséquilibre mesuré de 1,090. La différence entre les deux est tout l’intérêt. Le prefill traite un travail en rafales et hétérogène et a besoin d’un rééquilibrage rapide ; le decode traite un flux régulier et peut se permettre une longue fenêtre, il rééquilibre donc rarement et ne paie presque rien pour ce privilège.

Le volet routage présente les mêmes caractéristiques. Les demandes de préremplissage sont réparties en quatre paliers selon la longueur totale du contexte — moins de 16 K, de 16 à 64 K, de 64 à 256 K, et 256 K et plus — et les moteurs sont affectés aux paliers en fonction de la part de chaque palier dans la demande de calcul du tour précédent. Au sein d’un GPU, la taille de bloc de chaque étape de préremplissage n’est pas fixe : un modèle de coût quadratique ajusté prédit la durée d’une étape en fonction du nombre de tokens de séquence et du préfixe déjà calculé, et l’ordonnanceur détermine la plus grande taille de bloc qui tient dans un budget de 32 768 tokens pendant le temps restant. Le répartiteur de décodage équilibre simultanément deux dimensions, le nombre de demandes et la longueur totale du cache KV, en envoyant les demandes courtes vers des GPU à faible concurrence et à grand cache, et les demandes longues vers des GPU à petit cache. Le résumé de DeepSeek sur ce que tout cela apporte : environ 80 % d’un benchmark hors ligne parfaitement équilibré.

Le cache, et la question des trois jours

Le cache KV réside sur un cluster 3FS dédié, et non dans la mémoire locale de l’hôte, et ce choix oriente le reste de la conception du stockage. Les données sont stockées avec un codage à effacement 10+2, de sorte que chaque groupe de codage survit à deux défaillances de nœud simultanées ; une lecture envoie des requêtes aux 11 nœuds du groupe et 10 réponses suffisent pour décoder. Un worker de garbage collection s’exécute sur chaque nœud de stockage et expulse selon LRU au-delà d’un seuil. Le serveur recommandé dispose de 20 disques à semi-conducteurs de 30,73 To chacun et soutient au moins 40 Go/s en lecture et 5 Go/s en écriture, dimensionné pour conserver environ 24 heures de données par serveur. En pratique, le cluster tourne à environ 14,4 To de cache logique par GPU en ligne, avec une capacité physique supérieure à cela.

La résidence est le point où le compromis devient visible. Il n’y a pas de logique d’expiration côté cache ; le TTL est défini côté stockage à trois jours pour le trafic des agents et à sept jours pour le trafic des chatbots, sur un cluster d’environ 100 pétaoctets de stockage à semi-conducteurs. Cette séparation existe parce que le trafic des chatbots présente une longue traîne de hits bien plus lourde — une petite quantité de cache est lue de nombreuses fois, donc la perdre coûte davantage en taux de succès global que son volume ne le suggère. Le coût mesuré par DeepSeek pour réduire la rétention des chatbots à trois jours est de 0,5 à 1 % du taux de succès du cache. C’est un petit nombre qui se trouve représenter une grande quantité de prefill recalculé.

L’attention à fenêtre glissante dispose d’un cache distinct avec des règles différentes. Le cache SWA n’entre pas dans les blocs paginés ; chaque séquence occupe un emplacement de taille fixe en mémoire hôte, et pour DeepSeek-V4.1-Flash, les couches stockées sont les 20 premières. Seule cette région persiste — 20 couches × 134 tokens × 528 octets, soit 1 415 040 octets par séquence dans un format MXFP8. Rien n’est envoyé au cluster de stockage ; cela reste dans la mémoire de la machine qui l’a produit, avec un annuaire en mémoire qui consigne quelle machine détient quoi, et un accès inter-machine le récupère via un VLAN à 400 Gbps.

Les deux mécanismes qui produisent les chiffres phares

Le rejeu borné est la plus intéressante des deux, car il transforme un coût non borné en coût constant. Normalement, un échec de cache de fenêtre glissante implique de recalculer la fenêtre depuis le début, et le coût augmente avec la longueur du contexte et le nombre de couches. DeepSeek ne recalcule plutôt que les 128 tokens les plus récents et tronque la fenêtre d’attention à ce segment, ce qui produit un cache SWA approximatif à coût fixe. Côté encodeur, cela découple entièrement la longueur de succès du cache de préfixes du cache SWA : si le cache SWA est absent, les 128 derniers tokens du préfixe en cache sont rejoués tandis que le cache de blocs est réutilisé tel quel.

C’est du côté du décodeur que les économies sont importantes. Dans cette architecture, le cache de blocs des couches du décodeur est projeté à partir de l’état caché de la dernière couche de l’encodeur, de sorte que seul le cache SWA du décodeur doit être calculé par couche — et le reconstruire exactement impliquerait de faire passer les 2 560 derniers tokens dans 20 couches de décodeur à chaque prefill. En rejouant plutôt 128 tokens, et en n’utilisant le résultat que pour le décodage au lieu de le laisser entrer dans le cache de préfixe, on réduit de près de moitié le calcul total du prefill. Ce seul changement vaut plus que la plupart des optimisations de kernels, et c’est le genre de chose que seule une équipe qui maîtrise l’architecture du modèle peut faire.

La contribution de DSpark est plus modeste et plus classique. Les jetons de brouillon ont des probabilités d’acceptation différentes selon la requête et la position, si bien que vérifier cinq propositions fixes par étape gaspille des calculs sur des jetons qui seront rejetés. Une tête de confiance prédit le taux d’acceptation de chaque jeton de brouillon, et l’ordonnanceur trie les propositions par gain attendu et ne vérifie que le préfixe qui maximise le débit. En production, le modèle de brouillon génère toujours cinq jetons par étape ; le nombre vérifié passe de 5,00 à entre 3,2 et 4,4, soit une réduction d’environ 30 %, tandis que la longueur acceptée ne bouge presque pas — 3,29 contre 3,20. D’après les données de benchmark EP64/DP64, cela représente 4 à 7 % de débit en plus à environ 60 séquences simultanées par rang. À exactement 60, le débit par rang passe de 13 730 à 14 466 jetons par seconde. En dessous d’environ 16 séquences simultanées, la technique entraîne une légère perte nette, ce qu’il vaut la peine de savoir avant de l’adopter pour un déploiement à faible trafic.

Ce que signifie le chiffre de 155 billions

Le chiffre le plus cité associé à cette version est un seul cluster servant 155 billions de tokens par jour, pour un chiffre d’affaires global de 38 dollars US par heure-GPU à la tarification « valley ». Les deux moitiés sont déclarées par le fournisseur et aucune ne constitue un benchmark reproductible, ce qui ne les rend pas inintéressantes — un chiffre d’affaires par heure-GPU est un type d’affirmation véritablement différent d’un chiffre de débit, car il combine taux d’utilisation, tarification et taux de succès du cache en une seule ligne. C’est aussi le chiffre le plus susceptible d’être cité sans ses qualificatifs, aussi ces qualificatifs méritent-ils d’être consignés : un seul cluster, tarification « valley », chiffre d’affaires plutôt que coût, et agrégat sur le préremplissage, le décodage et l’encodeur vision.

Deux divulgations plus modestes sont plus directement utiles. Le noyau de décodage FlashMLA du dépôt public lui manque une optimisation assembleur réglée à la main que possède la version interne, ce qui le rend 5 à 10 pour cent plus lent isolément ; DeepSeek affirme que les performances de bout en bout diffèrent d’au plus 5 pour cent. Et le modèle de brouillon interne pour le décodage spéculatif est plus récent que celui publié, la différence de performance étant décrite comme faible. Ces deux affirmations établissent une attente quant à la part des performances publiées qu’un tiers peut atteindre en copiant le code, et la réponse est : l’essentiel, à condition que le matériel corresponde.

Le dépôt, tel qu'il est

La capture ci-dessus a été réalisée le 21 octobre 2026 et montre la page affichant 16,3 k étoiles. L’API GitHub, interrogée le même jour, renvoyait 16 590 étoiles, 1 649 forks et 176 tickets ouverts, avec les tickets désactivés et les discussions redirigées vers GitHub Discussions à la place. Le nombre d’étoiles n’a cessé d’augmenter depuis, si bien qu’il faut lire chaque chiffre ici comme un horodatage plutôt que comme une propriété du code. Un trafic de cette ampleur en moins d’une semaine en dit plus sur l’intérêt pour la pile de serving de DeepSeek que sur la maturité du code, et le compte de zéro version publiée dit le reste.

Si vous envisagez de le lancer vous-même

Le résumé honnête est que DeepInfer mérite une lecture attentive et est difficile à exploiter. Quatre questions vous indiqueront s’il est adapté.

• Disposez-vous d'un SM100 ou d'un Ascend 950 ? Tout le reste de la chaîne d'outils découle de ce point. Sans le bon accélérateur, les chiffres publiés ne se transposent pas, et les ports communautaires ne sont pas validés à l'échelle de la production.

• Peut-on exécuter 64 GPU de décodage dans un seul domaine de communication ? Le parallélisme d’experts étendu n’est pas une optimisation que l’on peut ignorer ; c’est la configuration autour de laquelle le chemin de décodage a été conçu. En dessous de cette échelle, vous exécutez un système différent portant le même nom.

• Disposez-vous déjà d’un cache de préfixes ? Sinon, vous comparez le chemin de calcul de DeepInfer à une stack concurrente qui en est équipée, et la comparaison paraîtra moins favorable que ne le mérite la conception.

• Avez-vous les moyens d’écrire la couche de routage ? Le regroupement de préremplissage, l’équilibrage du décodage et la réaffectation des experts sont décrits assez précisément pour être réimplémentés, et leur réimplémentation représente des semaines de travail que le dépôt ne fait pas à votre place.

Si vous préférez ne posséder aucun des éléments ci-dessus

Pour la plupart des équipes, la question pratique n’est pas de savoir comment déployer DeepSeek-V4.1-Flash, mais où l’appeler. Le modèle est disponible via une API compatible, sans avoir à construire un cluster de 128 GPU ni à réimplémenter un répartiteur de charge, et il s’agit du même modèle dont cet article décrit l’architecture — même gestion du contexte, même comportement de sortie structurée, sans le travail de désagrégation.

La comparaison à faire n’est pas de savoir quel moteur est plus rapide dans l’absolu, car les chiffres publiés sont des mesures déclarées par les fournisseurs sur du matériel que la plupart des lecteurs ne possèdent pas. Il s’agit de savoir si la charge de travail est de celles où un TTL de cache de 3 jours et un pool de décodage de 64 GPU changent le prix, ou de celles où une requête toutes les quelques secondes via une API est simplement moins chère que n’importe laquelle des opérations décrites ci-dessus. Dans le second cas — qui est la majorité des cas — la bonne quantité de DeepInfer à utiliser est aucune, et la bonne quantité à lire est tout. Commencez par la page du modèle DeepSeek V4.1 Flash si vous voulez le point de terminaison ; commencez par le README du dépôt si vous voulez savoir ce que fait le point de terminaison.