Analyse technique 034 | Le framework de raisonnement open source DeepInfer de DeepSeek

Tech Teardown : Analyse les frameworks technologiques de l’IA, avec explications, analyses et jugements. Auteur : Yongliang Date : 2026-10-21 | Version v1 (les données du repository sont de la période 10-20)

---

Couverture en attente

Couverture : En attente

Motif

Le 16 octobre, DeepSeek a ouvert le code deepseek-ai/DeepInfer sur GitHub. Le README du repository indique que son objectif est : « Le framework de raisonnement utilisé par DeepSeek pour les services à grande échelle » (Apache License 2.0).

Selon les données de suivi de popularité de tierces parties, au 20 octobre, ce repository comptait environ 10 863 points, 959 forks ; les données de Upstar montrent qu’il a reçu environ 7.6k points cette semaine, atteignant même la première place du classement des langages entiers. Sur Hacker News, la discussion correspondante 50163277 comptait environ 2075 likes et 812 commentaires (données du 10-21). Cependant, au niveau du code, il n’y a actuellement que 3 commits visibles, et PithWire a commenté : « 3 commits, des milliers de points : c’est un dump, pas une histoire de développement. »

Les discussions sur Hacker News se concentrent principalement sur trois points : cet open source ressemble-il à un dump de code ponctuel ou est-ce le début d’une maintenance continue ; la description de production dans le README peut-elle être directement appliquée aux utilisateurs externes ; et ce que cela signifie pour l’écosystème propre de DeepSeek. Ce débat montre également que le marché a des attentes élevées pour chaque open source de DeepSeek ; si la forme de livraison ne correspond pas aux attentes, le contraste sera amplifié.

Quel est le but

DeepInfer est un framework haute performance pour le raisonnement de grands modèles, conçu par défaut autour de la série DeepSeek-V4.1-Flash, avec comme checkpoint par défaut deepseek-ai/DeepSeek-V4.1-Flash-1017. Il ne s’agit pas de poids de modèle ni de code d’entraînement, mais plutôt d’un système de génie qui transforme les modèles entièrement entraînés en services de raisonnement servicesables et évolutifs.

Selon le descriptif du repository, DeepInfer soutient les services de production en ligne de DeepSeek. Il combine des opérateurs, des stratégies de parallélisation, un scheduler et des contraintes d’output, dans le but de garantir une faible latence et un haut débit lors du déploiement à grande échelle. Mais le repository public ressemble plus à une version organisée du code de production : l’histoire complète du git n’a pas été publiée, et les externes ne peuvent voir que 3 commits. Cette approche de « dump ponctuel » est inhabituelle dans les open sources de grandes entreprises ; l’avantage est que le code est complet et lisible, mais l’inconvénient est que les extérieurs ont du mal à juger la différence entre ce code et la version en ligne actuelle, ainsi qu’à suivre le parcours d’évolution.

En termes de chaîne de dépendance, le README remercie vLLM comme base principale, et se réfère à SGLang et TensorRT-LLM. Cela signifie que DeepInfer s’appuie sur l’écosystème open source existant, plutôt que de créer un système à partir de zéro. Pour les développeurs déjà familiers avec vLLM, la manière de comprendre DeepInfer est de « voir quelles optimisations DeepSeek ont elles-mêmes testées sur vLLM ». Pour les observateurs externes, il est plus précis de le considérer comme la « proposition de génie côté raisonnement » de DeepSeek plutôt que comme un service open source directement reproductible.

Quelles problèmes résoudre

La réflexion de grands modèles à niveau de production doit satisfaire simultanément les critères de faible latence, haute consommation de ressources, stabilité des résultats et compatibilité avec le matériel. DeepInfer tente d’offrir une solution complète dans ces domaines.

Le premier problème est la latence d’une seule requête. Dans la réflexion de grands modèles, le calcul de l’attention et les opérations de multiplication matricielle représentent la majeure partie du temps consacré. Si le noyau n’est pas adapté au matériel, il est facile de surcharger le GPU. Le deuxième problème est la consommation de ressources. Les services en ligne effectuent généralement les requêtes par lots. La manière de former ces lots, de les programmer et d’éviter que les résultats ne soient incohérents après leur formation sont des questions clés. Le troisième problème est la stabilité des résultats. En environnement de production, il est souhaitable que les mêmes entrées produisent des résultats cohérents dans différents lots, ainsi que que le processus de sampling puisse être reproduit. Le quatrième problème est la contrainte sur l’output. Dans les applications réelles, il est souvent nécessaire que le modèle affiche des données selon un schéma JSON, une régularité ou un format EBNF, plutôt que du texte libre. Le cinquième problème est la compatibilité avec différents types de matériel. DeepSeek a listé dans son README les plateformes NVIDIA SM100 GPU et Huawei Ascend 950 NPU, afin de fournir une entrée de réflexion interplateformes.

Ces problèmes ne sont pas propres à DeepInfer, mais il regroupe les solutions dans un seul répertoire et affirme clairement que ces solutions proviennent de ses services de production. Pour les équipes qui souhaitent s’inspirer de la décision technique de DeepSeek, cela est plus orienté que de devoir développer le code source du vLLM depuis zéro. En d’autres termes, la valeur de DeepInfer ne réside pas seulement dans le code lui-même, mais aussi dans le fait qu’il montre quelles optimisations sont considérées par DeepSeek comme les plus importantes pour la réflexion en production. Pour de nombreuses entreprises, ces problèmes sont dispersés dans plusieurs outils différents, tandis que DeepInfer tente de les regrouper dans un cadre unifié.

Comment le réaliser

La mise en œuvre de DeepInfer se concentre sur cinq aspects : le noyau, la parallélisation, l’programmation, le sampling et le format d’output.

Le niveau du noyau est le point fort de DeepInfer. Le répertoire liste les noyaux FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect et TileLang. FlashMLA est chargé de réduire la consommation de ressources liée au calcul de l’attention jusqu’à près des limites du matériel. Le nom MLA suggère que le concept de Multi-head Latent Attention est utilisé pour compresser les données, diminuant ainsi la consommation de mémoire. DeepGEMM correspond à une personnalisation approfondie des opérations de multiplication matricielle. DeepEP s’adresse aux coûts de communication dans les algorithmes parallèles. TileKernels et TileLang abstraissent les calculs de niveau tile courants en modules réutilisables. Les noms de ces noyaux indiquent que DeepInfer ne constitue pas simplement une encapsulation de frameworks existants, mais plutôt que les opérateurs testés par DeepSeek dans ses services en ligne sont directement intégrés.

Sur le plan de la parallélisation, DeepInfer prend en charge Attention DP et balanced CP, ainsi que EP et EPLB dans les scénarios MoE. DP distribue différentes requêtes sur différents appareils, CP divise des séquences longues en fonction du contexte, tandis que EP et EPLB gèrent l’équilibrage de charge des modules experts dans les modèles MoE. Pour un cadre de raisonnement de grand modèle, le choix de la stratégie de parallélisation affecte directement la capacité à utiliser pleinement les plusieurs cartes graphiques. Si l’équilibrage de charge n’est pas bien réalisé, certains experts seront fréquemment consultés, ce qui entraînera une partie des cartes graphiques à pleine charge et une autre inutilisée.

Sur le plan de la mise en place, il y a deux caractéristiques principales. Premièrement, un scheduler de batch asynchrone sans surcoût, dont l’objectif est de maintenir un haut débit de sortie selon les tailles et temps d’arrivée des requêtes. Deuxièmement, l’inférence invariant par rapport au batch, c’est-à-dire que les résultats de sortie restent constants quel que soit le mode de combinaison des requêtes en batch. Ce dernier point est particulièrement important pour un environnement de production, car il élimine le risque que «le même problème puisse avoir différentes solutions avec des résultats différents». Pour les équipes de développement nécessitant des résultats reproductibles, l’invariance par rapport au batch est une caractéristique clé pour réduire les coûts de débogage.

En termes d’accélération de la décodage, DeepInfer introduit DSpark et la vérification planifiée par confiance. En termes simples, on utilise un token de draft pour générer rapidement des candidats, puis on utilise la vérification planifiée par confiance pour éviter de calculer à chaque étape avec une précision complète. De plus, la réécriture limitée par SWA ne reproduit que des parties limitées du contexte, plutôt que tout le contexte, ce qui réduit la quantité de calcul préalable. Ces deux améliorations visent à diminuer les coûts de décodage pour de longs contextes.

En termes de contrôle de l’output, le framework prend en charge la sampling déterministe et l’output structuré. La sampling déterministe garantit que les résultats sont reproductibles avec les mêmes entrées et paramètres ; l’output structuré prend en charge les regex, les schémas JSON et EBNF, ce qui facilite la consommation des résultats du modèle par le niveau de service. L’output structuré permet au niveau de service de ne pas vérifier la formatage après la génération du modèle, ce qui réduit également la complexité du niveau d’interface.

En ce qui concerne les exigences hardware et de construction, le README indique que pour la partie NVIDIA, il faut des GPU SM100 et CUDA 13, tandis que pour Huawei, il faut des NPU Ascend 950 et CANN 9.2 ; l’environnement de construction nécessite Linux, GCC non inférieur à 13.0, Python 3.12. En ce qui concerne les dépendances, le README remercie vLLM comme base principale, et prend en compte SGLang et TensorRT-LLM.

Vérification/Résultats

Actuellement, les vérifications de DeepInfer proviennent principalement des descriptions du repository et des données de popularité, sans encore de tests indépendants de tiers.

D’après la popularité, environ 10.900 likes le 20 octobre et deux mille éloges sur HN indiquent que la communauté est très sensible à l’idée de «DeepSeek open-source framework de raisonnement de production». Les discussions se concentrent sur trois points : s’agit-il d’un dump de code ou d’une véritable open-source continue ; la description de production dans le README peut-elle être directement appliquée aux utilisateurs externes ; et son importance pour l’écosystème DeepSeek. Les commentaires de PithWire sont les critiques les plus représentatifs, soulignant que le nombre de likes et de commits ne correspond pas correctement.

En termes de niveau de fonctionnalité, les scénarios d’utilisation mentionnés dans le README sont plutôt destinés à l’inférence hors ligne à grande échelle. Pour un service en ligne complet, il manque des composants clés tels que la gestion de la cache KV, la dissection VE/Prefill/Decode, et la répartition des charges de travail. En d’autres termes, DeepInfer ressemble davantage à un « moteur d’inférence » qu’à une « plateforme de service d’inférence ». Actuellement, il n’existe pas de tableau de comparaison de performances publié par des tiers ; pour évaluer quantitativement ses avantages en termes de délai et de capacité de traitement, il faudra attendre que la communauté ou DeepSeek publie davantage de données de test.

Problèmes et limites

Premièrement, la forme du code est un dump plutôt qu’une histoire complète de développement. Les 3 commits ne permettent pas de voir le processus d’amélioration de la conception, et il est difficile de déterminer quels modules sont encore en cours de modification. Pour les développeurs externes souhaitant suivre à long terme et contribuer au code, ce n’est pas une entrée idéale.

Deuxièmement, le standard de production ne peut pas être simplement transféré. Le résumé du repository indique que DeepInfer soutient le service de production de DeepSeek, mais l’environnement en ligne de DeepSeek inclut certainement des composants de scheduling, de surveillance, de tolérance aux pannes et de répartition des charges de travail non open-sourced. Si les utilisateurs externes considèrent DeepInfer comme un solution de production prête à l’emploi, ils sous-estonneront le coût d’intégration.

Troisièmement, le seuil matériel n’est pas bas. Les GPU SM100 et CUDA 13 appartiennent à une plateforme NVIDIA plus récente, tandis que les Ascend 950 et CANN 9.2 nécessitent également des plateformes matérielles spécifiques. Les développeurs ordinaires n’ont pas forcément ces équipements à leur disposition, ce qui augmente le coût de validation.

Quatrièmement, les composants manquants sont explicitement listés. Des modules tels que la cache KV, la dissection VE/Prefill/Decode et la répartition des charges de travail n’apparaissent pas dans le repository public, et le README admet cela. Cela signifie que DeepInfer est actuellement plus adapté pour servir de point de départ à la recherche ou au traitement en batch hors ligne, plutôt que de finir une plateforme de service en ligne.

Cinquièmement, le nombre d’étoiles et de forks mesure la popularité, mais pas l’adoption dans la production. 10.9k étoiles indique simplement que la communauté s’intéresse au projet, mais ne montre pas combien de services réels fonctionnent avec DeepInfer. Lors de l’évaluation de son intégration, il est nécessaire de distinguer entre popularité et maturité.

Sixièmement, le fait que vLLM soit la base principale signifie que le rythme d’amélioration est limité par le système upstream. Si des changements majeurs surviennent dans les interfaces de vLLM, DeepInfer doit suivre en temps réel. Le support des Huawei Ascend 950 et CANN 9.2 dépend de la maturité de la plateforme logicielle Huawei ; par rapport à la voie NVIDIA, il y a moins de données de validation dans la communauté, et l’utilisabilité réelle nécessite des tests séparés.

Conclusion

DeepInfer est une tentative de DeepSeek de partager son expérience de production d’inférence. Elle intègre l’optimisation du kernel, les stratégies parallèles, la logique de scheduling et les contraintes d’output dans un même cadre, ce qui constitue une référence très informée pour ceux qui s’intéressent à l’ingénierie d’inférence des LLM. Cependant, la version publique ressemble davantage à une version de code, manquant de certains composants clés nécessaires pour un service complet, et son format open-source est un « dump unique », ce qui rend difficile pour les externes de suivre son évolution.

Pour les chercheurs et les équipes techniques, la valeur de DeepInfer réside dans le fait qu’elle montre quelles questions il convient de prendre en compte pour un framework de raisonnement à grande échelle et comment l’optimiser. Pour ceux qui souhaitent l’appliquer directement, une approche plus pragmatique consiste à le considérer comme un point de départ pour la raisonnement hors ligne ou des prototypes internes, plutôt que comme une alternative aux plateformes de services existantes et mature. Il ne peut pas être immédiatement intégré dans un environnement de production, mais il expose bien l’expertise de DeepSeek en matière de raisonnement au sein de la communauté. Ce qui sera utile de suivre par la suite, c’est quand les composants nécessaires seront complétés et quand des exemples concrets de déploiement extérieur apparaîtront.

Si DeepSeek peut continuer à mettre à jour l’histoire des commits, compléter les composants de service manquants et publier des données comparatives avec des frameworks tels que vLLM et SGLang, DeepInfer pourrait passer d’une version très populaire à une référence technique sur laquelle on peut compter à long terme. Avant cela, il est sûr de rester attentif sans exagérer.