La publication open source de DeepSeek DeepInfer expose le moteur, tandis que les composants de service restent internes

DeepSeek a publié DeepInfer, son framework d’inférence interne, tout en laissant hors du package public plusieurs composants nécessaires à un service de production complet. La publication open source de DeepSeek DeepInfer prend en charge DeepSeek-V4.1-Flash et expose les logiciels utilisés pour exécuter les modèles de l’entreprise. Elle met également en évidence une distinction importante : l’accès à un moteur d’inférence ne permet pas automatiquement de reproduire le service qui l’entoure.

La documentation associée de DeepSeek décrit une infrastructure reposant sur du matériel spécialisé, une planification coordonnée et des calculs réutilisables. La version publique fournit l’inférence hors ligne, ce qui signifie que les développeurs peuvent générer des sorties sans déployer un service en ligne complet. L’infrastructure de cache, les étapes de service séparées et une partie de l’équilibrage de charge restent des travaux d’intégration supplémentaires.

Cette frontière compte davantage qu’une simple étiquette opposant l’ouvert au fermé. DeepInfer s’appuie sur vLLM, SGLang et TensorRT-LLM, des projets d’inférence établis qui répondent déjà à des défis de déploiement. DeepSeek apporte sa propre implémentation à ce domaine commun. Pour les équipes d’infrastructure, la question immédiate est de savoir quelles décisions d’ingénierie sont transférables dans leurs environnements, et lesquelles dépendent de systèmes que DeepSeek s’est seulement contenté de décrire.

Ce que la publication open source de DeepSeek DeepInfer inclut réellement

DeepSeek a publié un moteur d’exécution de modèles intégrant d’importants travaux d’optimisation, plutôt qu’une copie complète de son service hébergé.

La documentation du moteur d’inférence identifie DeepSeek-V4.1-Flash comme le modèle pris en charge. Son checkpoint par défaut, une version sauvegardée du modèle, est DeepSeek-V4.1-Flash-1017. La publication mentionne les processeurs graphiques NVIDIA SM100 et les processeurs neuronaux Huawei Ascend 950 comme matériel compatible.

Ces précisions définissent le public initial. Il s’agit d’un logiciel d’infrastructure destiné aux équipes travaillant avec le modèle et les plateformes d’accélérateurs indiqués. La documentation n’établit pas une prise en charge équivalente pour tous les modèles DeepSeek, les cartes graphiques plus anciennes ou les environnements informatiques généralistes.

DeepInfer inclut des kernels optimisés, de petits programmes qui exécutent des opérations numériques sur les accélérateurs. Il comprend également le runtime qui coordonne l’exécution du modèle et la sélection des sorties. Ces couches déterminent avec quelle efficacité les instructions du modèle deviennent un travail utile sur le matériel.

La liste des fonctionnalités publiées va au-delà des routines numériques. Elle comprend l’exécution distribuée, qui répartit le travail d’inférence entre les processeurs, ainsi qu’une planification qui coordonne les tâches entrantes avec l’exécution sur les appareils. Elle inclut aussi les sorties structurées, qui contraignent le texte généré à respecter un format défini.

Ces capacités comptent, car servir un modèle implique davantage que charger ses poids, les valeurs numériques apprises durant l’entraînement. Les requêtes se disputent la mémoire et la capacité de calcul. Leurs longueurs d’entrée diffèrent, et leurs sorties se terminent à des moments différents. Un moteur doit gérer ces différences sans laisser du matériel coûteux inactif.

DeepSeek a publié DeepInfer sous licence Apache 2.0. Cette licence définit les conditions applicables au code du framework ; elle ne dispense pas de vérifier séparément les conditions des modèles et des dépendances. Les organisations doivent toujours évaluer le package logiciel complet qu’elles envisagent de déployer.

Les exclusions sont tout aussi concrètes. Le README mentionne un système de cache KV, des services distincts d’encodage visuel, de traitement des prompts et de génération, ainsi que l’équilibrage de charge entre répliques. Un cache KV stocke les calculs d’attention intermédiaires afin que les traitements ultérieurs puissent réutiliser des travaux précédents.

Selon DeepSeek, certaines fonctionnalités du moteur nécessaires à ces services existent déjà. Néanmoins, le package public ne comprend pas leur déploiement complet. Cette distinction évite que l’expression « entièrement open source » ne devienne une description inexacte de l’ensemble de la plateforme d’exploitation.

La publication modifie donc ce que les observateurs extérieurs peuvent examiner et exécuter. Elle expose une implémentation fonctionnelle des choix d’inférence de DeepSeek, avec des exemples et des scripts de benchmark. Elle n’établit pas qu’une équipe externe puisse reproduire le service de production de DeepSeek simplement en compilant le dépôt.

Pour les lecteurs qui cherchent à comprendre DeepSeek DeepInfer, voilà le point de départ essentiel. La publication du code est réelle, sa portée est importante, et sa limite documentée fait toujours partie de l’histoire.

Les équipes d’infrastructure gagnent du code et héritent de décisions d’intégration

La pression immédiate pèse sur les équipes qui évaluent un DeepSeek auto-hébergé, car elles disposent désormais d’une implémentation supplémentaire à comparer à leurs exigences opérationnelles.

Le moteur interne d’un fournisseur de modèles offre un point de référence différent d’un framework de service généraliste. DeepSeek peut exposer des optimisations conçues autour de l’architecture de ses modèles et des charges de travail observées. Les opérateurs externes peuvent examiner ces choix au lieu de les déduire du comportement du service hébergé.

Cela transforme l’évaluation technique. Une équipe qui analyse des réponses lentes peut examiner la planification, les communications et le traitement des sorties dans une implémentation publique. Elle peut distinguer les problèmes d’exécution du modèle de ceux introduits par son application environnante.

Cette possibilité crée toutefois du travail. Les équipes doivent déterminer si les exigences matérielles publiées correspondent à leurs capacités disponibles. Elles doivent également décider comment relier le moteur à la gestion des requêtes, au stockage, à la supervision et aux systèmes de reprise.

Prenons l’exemple illustratif d’un assistant documentaire d’entreprise qui reçoit de façon répétée un ensemble partagé de manuels techniques. Ses prompts contiennent des éléments qui se recoupent, tandis que les questions individuelles et la longueur des réponses varient. Il s’agit d’un scénario de déploiement, et non d’un exemple de client DeepInfer documenté.

Le moteur influence l’efficacité d’exécution de chaque requête. Le système de cache environnant détermine si le contenu documentaire répété nécessite de nouveaux calculs. Le routage des requêtes détermine si les calculs utiles stockés restent accessibles lorsque le trafic se déplace d’une machine à l’autre.

Un benchmark du moteur ne saisit qu’une partie de cette expérience. Les employés remarquent aussi le temps d’attente avant le début d’une réponse, les interruptions pendant la génération et les défaillances lorsque la demande augmente. Ces résultats dépendent de composants de service allant au-delà de l’exécution numérique.

La même distinction s’applique aux achats. Un acheteur qui envisage l’auto-hébergement a besoin d’éléments sur la responsabilité opérationnelle, la disponibilité matérielle et la compatibilité applicative. L’existence de code public élargit les options d’évaluation sans trancher ces questions.

L’explication de DeepSeek sur le déploiement montre également pourquoi la maîtrise de l’infrastructure importe. Sa conception interne coordonne le stockage et le calcul au lieu de les traiter comme des cibles d’optimisation indépendantes. Reproduire cette organisation exige des décisions sur les réseaux, la capacité de stockage et la gestion des défaillances.

Pour les petites équipes, adopter certaines idées ou certains composants peut être plus pratique que reconstruire l’architecture entière. Il s’agit d’une implication analytique liée au périmètre de la publication, et non d’une recommandation de déploiement établie par des tests indépendants.

La comparaison concurrentielle pertinente dépasse donc la vitesse brute de génération. Un framework qui s’intègre aux opérations existantes peut rester préférable, même lorsqu’une autre implémentation révèle une optimisation attrayante. L’effort d’ingénierie, la fiabilité et les charges de travail prises en charge influencent tous la décision.

C’est aussi là que la gestion des connaissances techniques devient utile. Les équipes peuvent conserver les configurations de benchmark, les constats liés aux incidents et les hypothèses de déploiement dans une base de connaissances consultable. Cet historique aide à éviter que des comparaisons ultérieures ne mélangent des conditions de test incompatibles.

La publication open source de DeepSeek DeepInfer rend une plus grande part de l’implémentation disponible à l’examen. Les équipes d’infrastructure restent responsables de décider quoi adopter, quoi intégrer et quelles preuves exigent leurs applications.

L’architecture dépend de la manière dont le travail circule dans le système

L’importance de DeepInfer réside dans des choix d’exécution coordonnés, dont la valeur dépend de l’organisation matérielle et de la forme des charges de travail.

L’architecture de déploiement de DeepSeek sépare le traitement des prompts de la génération des réponses. Le prefill traite le prompt d’entrée ; le decode génère les tokens de sortie suivants, les unités qu’un modèle lit et produit. Ces étapes imposent des exigences différentes au matériel.

L’architecture interne sépare également l’encodage visuel, qui convertit les images en représentations que le modèle de langage peut traiter. Un stockage dédié permet de réutiliser des calculs antérieurs. Le schéma d’architecture décrit ce système de production plus large, y compris des composants exclus du package de service public initial.

La séparation des étapes permet aux opérateurs d’allouer les ressources selon leurs charges de travail distinctes. Les entrées longues peuvent créer une demande importante de prefill, même lorsque les réponses restent courtes. Les réponses longues peuvent maintenir une demande de decode après la fin du traitement des entrées.

DeepSeek décrit également le parallélisme d’experts, qui répartit les composants neuronaux spécialisés d’un modèle mixture-of-experts entre les processeurs. Ses configurations de production privilégiées diffèrent entre le prefill et le decode. Cela reflète l’équilibre différent entre calcul, accès mémoire et communications à chaque étape.

La discussion de l’entreprise sur Wide-EP compare le parallélisme d’experts sur 8 et 64 processeurs. Un groupe plus large modifie la manière dont les calculs des experts et le trafic mémoire sont répartis. Il fait également de l’efficacité des communications et de l’équilibrage de la charge des éléments centraux du résultat.

Ces considérations expliquent pourquoi le seul nombre d’appareils ne suffit pas. Un groupe relié par des liens locaux rapides se comporte différemment de machines communiquant à travers un réseau plus lent. La topologie matérielle, c’est-à-dire l’organisation des appareils et de leurs connexions, doit figurer dans toute comparaison significative.

DeepInfer implémente également le décodage spéculatif, qui propose des tokens provisoires et les vérifie avec le modèle principal. Le mécanisme DSpark de DeepSeek utilise des estimations de confiance pour décider quelle quantité de travail provisoire mérite vérification. L’objectif est d’éviter de consacrer des calculs de vérification à des candidats peu probables.

Il s’agit d’une décision de planification assortie d’un compromis mesurable. Vérifier davantage de tokens provisoires ne produit pas automatiquement davantage de sorties acceptées. Le résultat utile dépend du comportement d’acceptation et de la capacité du matériel à traiter la charge de vérification.

Une autre optimisation fait se chevaucher la planification du processeur et l’exécution sur l’accélérateur. Le processeur central prépare le travail à venir pendant que l’accélérateur traite les calculs en cours. DeepSeek attribue explicitement cette approche à des implémentations existantes de SGLang et NanoFlow.

Cette attribution est importante. DeepInfer s’ajoute à un corpus existant d’ingénierie de l’inférence, avec des influences reconnues et des techniques partagées. La publication n’établit pas que chaque optimisation citée est née chez DeepSeek.

Le moteur propose également des contrôles destinés à rendre les résultats reproductibles entre différents lots de requêtes. Sa documentation limite les fonctionnalités d’inférence indépendante des lots et d’échantillonnage déterministe à NVIDIA. L’échantillonnage déterministe exige des paramètres définis, dont une graine de séquence fixe.

Ces conditions comptent pour les équipes d’évaluation qui comparent les résultats après des modifications logicielles. La présence d’une fonctionnalité dans le README ne signifie pas qu’elle est disponible de manière identique sur les deux familles de matériel prises en charge. DeepSeek DeepInfer, expliqué par son architecture, relève donc de contraintes coordonnées, et non d’un raccourci universel vers de meilleures performances.

deepseek-recipe traite de la frontière entre applications et modèles

deepseek-recipe s’occupe de la conversion des protocoles et des jetons, un problème distinct de l’exécution rapide du modèle.

DeepSeek accompagne l’annonce de son moteur de bibliothèques de conversion de protocoles écrites en Rust, avec des liaisons Python. Ces bibliothèques traduisent les requêtes vers une représentation commune des conversations. Elles génèrent ensuite les prompts du modèle et convertissent les sorties produites vers les formats de réponse pris en charge.

Le README du projet compagnon avait déjà été modifié le 19 octobre, avant la modification du README de DeepInfer le 20 octobre. Ce rapprochement ne doit donc pas laisser entendre que les deux dépôts sont devenus disponibles exactement au même moment. Le point vérifié est que DeepSeek les présente ensemble dans son explication du déploiement d’inférence.

deepseek-recipe prend en charge la conversion des formats de requête Messages, Chat Completions et Responses. Il s’agit de formats d’interface de programmation d’applications, c’est-à-dire de conventions utilisées par les applications pour échanger des requêtes et des sorties avec des services de modèles. La prise en charge de leurs structures aide à connecter les applications existantes à un backend d’inférence.

La frontière reste explicite. L’appelant fournit l’inférence du modèle, l’exécution des outils et le transport HTTP, le mécanisme réseau qui véhicule les requêtes et les réponses. deepseek-recipe gère la conversion et l’analyse ; il ne fournit pas l’intégralité du service.

Cette séparation importe pour les applications qui demandent aux modèles d’utiliser des outils. Un appel d’outil est une requête structurée visant une action ou une fonction externe. La conversion de sa représentation n’exécute pas l’action, ne l’autorise pas et ne garantit pas l’exactitude de ses arguments.

De même, la compatibilité de format ne garantit pas un comportement équivalent du modèle. Une application peut recevoir une structure de réponse familière tout en observant une qualité de réponse ou un comportement de raisonnement différent. L’affirmation de DeepSeek selon laquelle le système s’aligne sur son service officiel exige des tests portant sur les fonctionnalités particulières utilisées par une application.

Le projet gère également le streaming, qui renvoie progressivement la sortie au fil de la génération. Un fragment de sortie peut se terminer au milieu d’un caractère, d’un délimiteur ou d’un argument d’outil. Une analyse correcte doit conserver suffisamment d’état pour interpréter les fragments ultérieurs sans corrompre le contenu précédent.

L’explication de DeepSeek décrit des mécanismes destinés à gérer ces frontières. Ce travail est moins visible que les performances des accélérateurs, mais les développeurs d’applications en rencontrent directement les conséquences. Un flux malformé peut briser une intégration même lorsque le moteur d’inférence génère correctement les jetons.

La conception de conversion des jetons distingue également les marqueurs de contrôle du texte ordinaire. Les marqueurs de contrôle indiquent au modèle où commencent ou se terminent certaines parties d’une conversation. DeepSeek affirme qu’un texte fourni par l’utilisateur et ressemblant à ces marqueurs demeure un contenu ordinaire lors de l’encodage.

Cela traite une frontière de sérialisation spécifique. Il ne faut pas le présenter comme une solution générale à l’injection de prompts, c’est-à-dire aux tentatives de rediriger un modèle par du contenu non fiable. Un modèle peut toujours rencontrer des instructions trompeuses formulées en langage ordinaire.

La documentation de deepseek-recipe établit une autre distinction utile concernant la sortie structurée. Transmettre une contrainte de format lors de la conversion de la requête ne l’applique pas, à lui seul, durant la génération. Le backend d’inférence doit appliquer les contrôles de décodage pertinents.

Le projet utilise la licence MIT, tandis que DeepInfer utilise Apache 2.0. Ensemble, ils exposent des couches complémentaires du parcours de déploiement. L’un exécute le modèle ; l’autre aide les applications à communiquer correctement avec lui.

Les affirmations de production et les graphiques de benchmark répondent à des questions différentes

Les chiffres d’exploitation internes de DeepSeek décrivent son propre système, tandis que les benchmarks publiés décrivent des configurations de test spécifiques.

L’entreprise indique qu’un seul cluster de production sert 155 mille milliards de jetons par jour. Il s’agit d’un chiffre d’exploitation communiqué par le fournisseur, et non d’un résultat reproduit indépendamment à partir de la version publique. Il ne doit pas devenir un chiffre de capacité promis pour des déploiements tiers.

L’explication du déploiement décrit l’infrastructure entourant ce cluster, notamment le stockage de cache, le routage des requêtes et des étapes de traitement séparées. Plusieurs de ces systèmes sont absents du package public. Traiter le total de production comme un benchmark du moteur seul effacerait ces dépendances.

Le graphique de prefill publié utilise 4 processeurs NVIDIA SM100. Le graphique de décodage en utilise 64, et chaque test reste dans un unique domaine scale-up, un groupe connecté par des interconnexions locales rapides. Ces configurations doivent accompagner les graphiques chaque fois que leurs résultats sont évoqués.

Les graphiques mesurent aussi des relations différentes. Le prefill compare le débit des entrées non mises en cache à la latence, le temps nécessaire pour traiter une tâche. Le décodage compare le débit de sortie à la vitesse de génération par utilisateur. Un déploiement peut favoriser la capacité globale tout en offrant une expérience différente à chaque utilisateur.

Cela empêche une conclusion simpliste selon laquelle un système est « plus rapide » d’avoir beaucoup de sens. Une comparaison valide exige le même checkpoint de modèle, la même charge de travail, les mêmes paramètres numériques, la même disposition matérielle et les mêmes contraintes de service pertinentes. Sinon, le résultat peut refléter des choix opérationnels différents plutôt qu’un meilleur moteur.

La même prudence s’applique au graphique Wide-EP. Il examine une comparaison particulière de parallélisme dans la configuration fournie. Il n’établit pas que chaque déploiement plus vaste en bénéficie dans la même mesure, ni que la communication entre des machines arbitraires entraîne les mêmes surcoûts.

Le README de DeepInfer fournit un moyen de reproduire ses benchmarks via un script de balayage fourni, qui exécute des tests sur plusieurs configurations. Cela améliore la possibilité d’inspection. Ce rapport n’a pas exécuté indépendamment ces tests ; les performances tracées restent donc attribuables à DeepSeek.

Un cadre concurrentiel neutre doit aussi tenir compte des projets d’inférence existants. DeepSeek indique que DeepInfer a été conçu à l’origine principalement sur vLLM, avec l’inspiration de SGLang et TensorRT-LLM. Cette reconnaissance plaide contre la description de cette version comme un remplacement isolé de l’écosystème environnant.

Le framework de service SGLang traite du service de modèles sur une gamme plus large de configurations de modèles et de matériel. Son périmètre donne aux opérateurs des raisons de l’évaluer au-delà du graphique de performances d’un seul modèle. Le choix pertinent dépend des exigences de chaque déploiement.

Une comparaison entre DeepInfer et SGLang exige donc davantage que l’alignement d’un chiffre de débit mis en avant. Elle nécessite d’examiner le comportement des applications, l’effort d’intégration, le matériel pris en charge et la récupération après défaillance dans des conditions comparables. Les éléments vérifiés n’établissent pas de vainqueur indépendant.

Il existe aussi une distinction entre l’équilibrage de charge des experts au sein d’un moteur et l’équilibrage des requêtes entre réplicas de service. La version inclut une fonctionnalité d’équilibrage expert-parallèle tout en excluant les systèmes complets de service au niveau des réplicas listés dans son README. Dire simplement que « l’équilibrage de charge est absent » serait trop général.

La version open source de DeepSeek DeepInfer permet un examen plus approfondi de ces frontières. Elle ne justifie pas d’importer chaque affirmation interne concernant la production dans les attentes envers le package public. L’évaluation la plus solide reste précise sur ce qui a été mesuré, ce qui a été publié et ce qui demeure non vérifié.

Trois évolutions montreront jusqu’où ira cette version

Les prochaines preuves utiles concerneront la reproductibilité, l’intégration des services et le comportement des applications, dans cet ordre.

Premièrement, il faut surveiller les reproductions indépendantes de benchmarks accompagnées de configurations complètes. Un rapport utile identifierait la révision exacte du code, le checkpoint du modèle, les connexions matérielles, la charge de travail et les paramètres de génération. Il distinguerait aussi les mesures du moteur d’un déploiement en ligne complet.

De tels rapports renforceraient la confiance dans la capacité d’équipes externes à obtenir des résultats comparables avec l’implémentation publiée. Des différences significatives exigeraient une investigation plutôt qu’un verdict immédiat. Les paramètres de compilation, les longueurs d’entrée et la concurrence, c’est-à-dire le nombre de requêtes simultanément actives, peuvent tous modifier les performances observées.

Les reproductions les plus informatives publieraient à la fois le débit global et le temps de réponse individuel. Un service peut traiter davantage de travail total tout en faisant attendre plus longtemps certaines requêtes. La publication des deux mesures aide les lecteurs à voir si une optimisation convient aux applications interactives ou bénéficie principalement au traitement par lots.

Deuxièmement, il faut surveiller le périmètre public des composants de service environnants. Le README de DeepSeek identifie l’infrastructure de cache, les étapes de service séparées et l’équilibrage de charge des réplicas comme des exigences en dehors de cette version. De futurs composants de code ou des intégrations documentées traitant ces lacunes réduiraient le travail attendu des adoptants.

Cela renforcerait l’argument en faveur de DeepInfer comme fondation de déploiement plus complète. Si ces composants restent internes, le moteur conserve néanmoins une valeur pour l’inspection et l’expérimentation. Son adoption continuerait à dépendre davantage de l’infrastructure existante de chaque opérateur.

Les éléments de maintenance comptent dans ce signal. Une documentation qui reflète le comportement réel, des exigences de compatibilité claires et des correctifs pour les problèmes signalés aident à établir si des utilisateurs externes peuvent exploiter le logiciel. La disponibilité publique marque le début de cette relation, plutôt qu’une preuve de sa profondeur future.

Troisièmement, il faut surveiller les tests de compatibilité au niveau des applications autour de deepseek-recipe. Des résultats utiles examineraient les frontières du streaming, les arguments d’outils, le contenu de raisonnement et les formats de sortie imposés. Ces tests montreraient si la couche de conversion partagée réduit les différences pratiques entre les environnements de déploiement.

Des tests réussis renforceraient l’affirmation de DeepSeek selon laquelle des services tiers peuvent s’aligner sur son comportement de traitement officiel. Des échecs indiqueraient les points où la prise en charge de la conversion et l’implémentation du backend divergent. Aucun de ces résultats ne doit être confondu avec un jugement général sur l’intelligence du modèle.

Pour une évaluation de DeepInfer face à SGLang, ces évolutions offrent une base plus utile que l’attention portée au dépôt. Les mesures indépendantes traitent les affirmations de performance. Les intégrations de services concernent l’effort opérationnel, tandis que les tests d’application évaluent si les logiciels existants se comportent comme prévu.

Au cours des prochains mois, la question centrale sera de savoir quelle part de l’approche de production documentée par DeepSeek deviendra reproductible en dehors de l’entreprise. Cette question respecte les deux aspects de la version : une ingénierie publique substantielle et une frontière d’infrastructure clairement énoncée.

Avant d’adopter la version open source de DeepSeek DeepInfer, comparez son périmètre documenté au service dont vos utilisateurs ont réellement besoin. Lisez les exigences du moteur en parallèle de l’explication du déploiement, puis identifiez les composants manquants que votre plateforme existante fournit déjà. Conservez les affirmations de performance associées à leurs conditions matérielles et de charge de travail. Pour les équipes d’application, examinez le comportement des protocoles aussi attentivement que la vitesse de génération, en particulier lorsque le streaming et les appels d’outils prennent en charge des flux de travail essentiels. Consignez les conclusions qui proviennent du code publié, des mesures de l’entreprise ou de vos propres tests. Réévaluez ensuite ces conclusions à mesure que paraissent des reproductions et intégrations indépendantes. La décision utile consiste à déterminer si cette version élimine suffisamment d’incertitude et de travail d’ingénierie pour votre déploiement particulier afin de justifier une évaluation plus approfondie.