DeepSeek ouvre DeepInfer, le moteur d'inférence utilisé pour faire fonctionner ses modèles à grande échelle

DeepSeek publie DeepInfer, son moteur d'inférence haute performance, et deepseek-recipe, une bibliothèque pour reproduire ses formats API.

Publier les poids d'un modèle d'intelligence artificielle ne suffit pas à reproduire les performances d'un service comme DeepSeek. Entre le modèle et l'utilisateur intervient une infrastructure chargée de répartir les calculs sur les accélérateurs, gérer les requêtes simultanées et produire les réponses avec une latence maîtrisée. C'est une partie de cette infrastructure que DeepSeek rend désormais publique avec DeepInfer, le moteur d'inférence qu'elle utilise pour ses services à grande échelle. Distribué sous licence Apache 2.0, le framework prend actuellement en charge DeepSeek-V4.1-Flash et réunit plusieurs techniques d'optimisation destinées à réduire le coût du calcul. L'entreprise publie parallèlement deepseek-recipe, une bibliothèque consacrée à l'encodage des requêtes et à la restitution des réponses dans les formats de son API. Du modèle ouvert à son exécution

Les modèles de langage sont généralement évalués sur leurs capacités de raisonnement, de programmation ou de compréhension multimodale. Mais une fois déployés, leurs performances dépendent aussi du logiciel qui les exécute. Le moteur d'inférence doit notamment organiser les opérations sur les GPU, utiliser efficacement la mémoire et traiter plusieurs demandes sans multiplier inutilement les temps d'attente. Cette dimension devient particulièrement importante pour les modèles volumineux utilisant une architecture à experts, dont les calculs sont distribués sur plusieurs accélérateurs.

DeepInfer rassemble les composants logiciels que DeepSeek a développés pour répondre à ces contraintes. Le projet utilise plusieurs bibliothèques déjà publiées par l'entreprise, dont FlashMLA pour les opérations d'attention, DeepGEMM pour les calculs matriciels, DeepEP pour les communications entre experts et DeepSelect pour certaines opérations de sélection. Il intègre également TileKernels et des noyaux spécialisés écrits avec TileLang. Ces différents éléments sont assemblés dans un environnement comprenant le moteur d'exécution du modèle, la gestion de l'échantillonnage et l'ordonnancement des requêtes.

La publication prolonge le travail effectué autour de DeepSeek-V4.1-Flash-1017, version récente du modèle Flash. Pour l'instant, c'est la seule famille explicitement prise en charge par DeepInfer. DeepSeek annonce que les adaptations nécessaires à ses futurs modèles et de nouvelles optimisations pourront être intégrées au même dépôt. Plusieurs GPU, mais une seule réponse à produire

Le fonctionnement d'un grand modèle distribué impose de répartir les calculs entre plusieurs accélérateurs sans que les communications deviennent plus coûteuses que les opérations elles-mêmes. DeepInfer combine différentes formes de parallélisme, notamment la répartition de l'attention, du contexte et des experts d'une architecture Mixture-of-Experts. Un système d'équilibrage de charge, ou EPLB, cherche également à éviter que certains accélérateurs restent surchargés pendant que d'autres attendent.

L'architecture intervient à deux moments distincts de l'inférence. Le prefill correspond au traitement initial des informations transmises dans la requête, tandis que le decode désigne la génération progressive de la réponse. Ces phases n'utilisent pas nécessairement les ressources de la même façon : la première doit absorber un volume potentiellement important de tokens, alors que la seconde doit maintenir un débit élevé sans ralentir les utilisateurs.

DeepSeek publie des courbes de performance séparées pour ces deux opérations. Les mesures présentées dans le dépôt ont été réalisées sur quatre GPU NVIDIA SM100 pour le prefill et 64 pour le décodage, chaque configuration étant contenue dans un même domaine matériel à interconnexion rapide. Le code nécessaire pour reproduire ces évaluations est également disponible, mais la documentation principale ne donne pas de gain global universel par rapport à vLLM ou aux autres moteurs d'inférence. Produire plus vite avec des tokens anticipés

Une autre optimisation concerne le décodage spéculatif. Plutôt que de générer chaque token séparément en mobilisant systématiquement le modèle principal, cette méthode consiste à préparer plusieurs tokens candidats, puis à vérifier leur validité. Lorsqu'une partie de la séquence anticipée est acceptée, le système peut réduire le nombre d'opérations nécessaires à la production du texte final.

DeepInfer intègre à cet effet DSpark, accompagné d'un mécanisme de vérification planifié selon les niveaux de confiance. La longueur des propositions peut être ajustée en fonction des paramètres d'exécution, avec une valeur maximale par défaut de cinq tokens anticipés. L'objectif n'est pas de changer les capacités du modèle, mais de rendre sa génération plus efficace en tirant parti des séquences qui peuvent être validées ensemble.

Le framework propose également une optimisation appelée SWA Bounded Replay, liée à l'attention à fenêtre glissante. Elle permet de limiter certains recalculs en ne conservant que la portion pertinente du contexte lors des opérations de reprise. Pour la configuration V4.1 décrite dans le dépôt, DeepSeek recommande notamment de conserver une suffixe de 140 tokens. Ces réglages illustrent le niveau d'optimisation recherché : réduire des opérations répétitives qui, à l'échelle de millions de requêtes, représentent une quantité importante de calcul. Traiter plusieurs requêtes sans modifier les résultats

DeepInfer utilise un ordonnancement asynchrone qui superpose certaines opérations de préparation des lots sur processeur central à l'exécution des calculs sur accélérateur. Activé par défaut, ce mécanisme vise à limiter les périodes pendant lesquelles le matériel attend que le logiciel organise le travail suivant.

Le framework comprend aussi deux fonctions moins visibles, mais importantes pour la reproductibilité. La première permet une inférence indépendante de la composition des lots : lorsque cette option est activée, le résultat d'une requête reste identique même si les autres demandes