DeepSeek ouvre DeepInfer : le moteur d'inférence de sa production, en Apache 2.0

DeepSeek ouvre DeepInfer : le moteur d'inférence de sa production, en Apache 2.0

🔎 Trois jours après les poids de V4.1-Flash, DeepSeek publie la machine qui les sert

Le calendrier est trop serré pour être un hasard. Le 17 octobre 2026, DeepSeek publie les poids de DeepSeek-V4.1-Flash. Le 20 octobre, le labo dépose sur GitHub DeepInfer : le framework d'inférence qui fait tourner ce modèle sur ses propres serveurs, en production. Licence Apache 2.0, usage commercial autorisé sans condition.

Le geste mérite qu'on s'y arrête. Ouvrir un modèle, c'est donner un produit fini. Ouvrir le moteur qui sert ce modèle à l'échelle d'un service mondial, c'est donner la manufacture : les kernels d'attention FlashMLA, les multiplications matricielles DeepGEMM, la couche de communication inter-GPU DeepEP, le décodage spéculatif DSpark. Tout ce qui, d'habitude, reste soigneusement fermé.

L'accueil est à la hauteur : première place du trending GitHub, tête de Hacker News avec plus de 2 100 points, 3 300 étoiles et 235 forks en quelques jours. Restent trois questions. Que contient exactement ce code ? Que valent les chiffres annoncés ? Et que DeepSeek a-t-il choisi de ne pas donner ?

L'essentiel

• DeepInfer est le framework d'inférence de production de DeepSeek, open sourcé le 20 octobre 2026 sous Apache 2.0 (repo GitHub).
• Un seul modèle cible : DeepSeek-V4.1-Flash, dont les poids ont été publiés le 17 octobre 2026.
• ~26 000 tokens/s par GPU en décodage (EP64, contexte de 131 072 tokens, taux d'acceptation de 75 %) et un préfill de 60 000 à 1,5 million de tokens/s/GPU grâce à un taux de prefix cache de 96 %.
• DSpark, le décodage spéculatif maison, réduit les drafts rejetés de 30 % et ajoute 4 à 7 % de débit.
• Le cluster de DeepSeek servirait 155 000 milliards de tokens par jour pour 38 $ de revenu par GPU et par heure (octobre 2026, chiffres DeepSeek).
• Double cible matérielle de première classe : NVIDIA SM100 et Huawei Ascend 950.
• Limites assumées : inférence hors-ligne uniquement, pas de gestion de KV cache, pas de load balancing.

Outils recommandés : les briques de DeepInfer

DeepInfer n'est pas un repo monolithique : c'est un assemblage de briques, pour la plupart déjà connues des suiveurs de DeepSeek, désormais réunies dans un cadre unique.

DeepSeek publie aussi un second repo, deepseek-recipe, sous licence MIT cette fois, qui rassemble recettes et configurations. Séparer le cœur du moteur (Apache 2.0) des recettes d'usage (MIT) est un choix peu banal — et plutôt malin : les recettes pourront évoluer vite sans toucher au cœur du moteur.

Un moteur de production, pas un projet de recherche

La réponse tient en une phrase : DeepInfer n'est pas un moteur de labo adapté à la production, c'est le moteur de production publié tel quel.

C'est ce que souligne SiliconANGLE : le framework derrière les services de production de DeepSeek. Le code qui tourne sert le trafic réel du service, pas une démonstration optimisée pour un benchmark.

Deuxième singularité : un seul modèle. DeepInfer est conçu pour servir DeepSeek-V4.1-Flash, point. Ce n'est pas une limitation accidentelle, c'est un choix d'architecture : le moteur et le modèle sont co-conçus, du parallélisme d'experts aux kernels d'attention. Cette logique découle directement de la stratégie V4 du labo, où le duo Pro/Flash a redessiné toute la gamme (DeepSeek V4 : deux nouveaux modèles — Pro et Flash — changent la donne).

Troisième singularité : la séquence de publication. Poids le 17 octobre, moteur le 20 octobre. Trois jours d'écart, pour que quiconque le souhaite puisse rapprocher les poids du code qui les sert. C'est du storytelling technique, mais c'est aussi une invitation à l'audit — et peu de labos osent ce niveau d'exposition.

À mon sens, c'est la fin d'un cycle. Depuis deux ans, les labos ouvrent des poids et ferment des usines. DeepSeek vient de montrer qu'on peut ouvrir les deux.

Les chiffres : 26 000 tokens/s par GPU, 155 000 milliards de tokens par jour

Réponse directe : DeepSeek mesure environ 26 000 tokens/s par GPU en décodage et affirme que son cluster sert 155 000 milliards de tokens par jour, pour 38 $ de revenu par GPU et par heure.

Commençons par le décodage. La configuration de référence : EP64 (les experts du modèle répartis sur 64 GPU), un contexte de 131 072 tokens et un taux d'acceptation de 75 % pour le décodage spéculatif. Le préfill, lui, a été mesuré sur 4 GPU, le décodage sur 64 — deux régimes très différents, ne les confondez pas (MarktechPost). Sur cette configuration, DeepSeek annonce environ 26 000 tokens/s/GPU.

Le prefix cache, la vraie star des chiffres

Côté préfill, les chiffres sont encore plus spectaculaires : de 60 000 à 1,5 million de tokens/s par GPU. Comment ? Parce que 96 % des entrées de DeepSeek sont déjà en prefix cache.

Concrètement : une énorme partie du trafic de production répète des contextes — prompts système, instructions, historiques de conversation. Le préfill de ces tokens est déjà fait, il ne reste que le delta à traiter. Ce chiffre de 96 % en dit moins sur le moteur que sur le trafic de DeepSeek : c'est le profil d'un service avec des millions d'utilisateurs qui reviennent.

Côté expérience utilisateur, la lecture du repo par dev.to aboutit à un premier token vers 400 ms et une génération à 230 tokens/s. Des chiffres d'usage final, pas de banc d'essai.

38 $ par GPU/heure : le chiffre le plus subversif

Le plus intéressant n'est pas un chiffre de vitesse, c'est un chiffre d'argent : 38 $ de revenu par GPU et par heure (octobre 2026, chiffres DeepSeek), pour un cluster qui sert 155 000 milliards de tokens par jour. DeepSeek ne publie pas seulement un moteur, il publie une grille économique de référence. Tout opérateur de cluster dispose désormais d'un point de comparaison brutal pour juger sa propre rentabilité.

Un bémol s'impose pourtant. Ces mesures viennent de DeepSeek, sur son trafic, avec sa configuration. explainx.ai consacre d'ailleurs son analyse à l'écart entre l'affirmé et le vérifiable — et rappelle que la version interne de FlashMLA serait 5 à 10 % plus rapide que la version publiée. Autrement dit : même le code ouvert n'est pas exactement la build de production. À prendre comme un majorant, pas comme une promesse contractuelle.

DSpark : 30 % de drafts rejetés en moins, 4 à 7 % de débit en plus

Réponse directe : DSpark est la couche de décodage spéculatif de DeepInfer. Son travail : réduire de 30 % les drafts rejetés, pour un gain de 4 à 7 % de débit, avec un taux d'acceptation de 75 %.

Rappel utile pour ceux qui suivent moins l'infra. Le décodage spéculatif fait deviner par un petit modèle les prochains tokens — les « drafts » — que le grand modèle vérifie ensuite en parallèle. Chaque token accepté, c'est du débit gratuit. Chaque token rejeté, c'est du calcul brûlé pour rien. Tout le jeu consiste à maximiser le taux d'acceptation, d'où l'importance du 75 % annoncé.

Un gain de 4 à 7 % peut sembler modeste sur le papier. À l'échelle d'un service qui sert 155 000 milliards de tokens par jour, c'est une capacité énorme récupérée sans acheter un seul GPU de plus. C'est toute la différence entre optimiser un benchmark et optimiser une ligne de coûts.

Notre lecture : DSpark est la brique la plus immédiatement copiable du lot. La technique est connue, mais une implémentation éprouvée à cette échelle, avec des taux d'acceptation documentés publiquement, cela manquait à l'écosystème open source.

SM100 et Ascend 950 : la double cible qui en dit long

Réponse directe : DeepInfer traite le NVIDIA SM100 et le Huawei Ascend 950 comme des cibles de première classe, au même niveau. C'est peut-être la ligne la plus stratégique de tout le repo.

Dans l'écosystème de l'inférence, le matériel non-NVIDIA est généralement traité en parent pauvre : un port tardif, moins optimisé, moins testé. Ici, le repo souligne qu'Ascend 950 est une cible de première classe du framework, et les kernels DeepGEMM sont optimisés pour les deux plates-formes.

La lecture géopolitique est évidente. Un labo capable de servir 155 000 milliards de tokens par jour sur du matériel Huawei est un labo qu'aucun contrôle à l'export de GPU ne peut asphyxier. DeepInfer n'est pas seulement du code : c'est une assurance-vie technologique, publiée en pleine vue.

C'est aussi un signal pour l'industrie : la preuve publique, chiffrée, qu'une infrastructure d'inférence de premier plan tourne nativement sur du matériel chinois. Pour les opérateurs, enfin, c'est du pouvoir de négociation. Quand votre moteur tourne sur deux écosystèmes matériels, les vendeurs se retrouvent en concurrence — et les prix, enfin, aussi.

Ce que DeepInfer ne fait pas : hors-ligne, sans KV cache, sans load balancing

Réponse directe : DeepInfer ne couvre que l'inférence hors-ligne. Pas de gestion de KV cache, pas de load balancing, un seul modèle supporté. Le plus délicat du serving en ligne reste en interne.

Trois limites, clairement documentées dans le repo :

• Hors-ligne uniquement : le framework est pensé pour des charges de type batch et débit, pas pour servir une API interactive telle quelle.
• Pas de KV cache : l'état qui rend les conversations multi-tours économiquement viables n'est pas géré par le code publié.
• Pas de load balancing : la répartition de charge entre GPU et nœuds, pilier de tout service en ligne, est hors périmètre.

Comment lire ces absences ? Deux hypothèses non exclusives. Première lecture : DeepSeek ouvre le cœur de calcul — là où se trouve la vraie valeur technique, les kernels et l'ordonnancement — et garde la plomberie du serving. Seconde lecture : cette plomberie arrive, brique par brique. DeepEP, la couche de communication, avait déjà été publiée séparément l'an dernier.

Il faut saluer la clarté : les limites sont énoncées noir sur blanc, pas noyées dans un README marketing. Mais il faut aussi appeler les choses par leur nom. DeepInfer n'est pas une plateforme de serving prête à l'emploi, c'est un noyau d'excellence à intégrer dans une pile existante.

La stratégie : ouvrir l'inférence pour mieux vendre l'intelligence

Réponse directe : en publiant DeepInfer, DeepSeek transforme l'inférence en commodité et déplace son avantage concurrentiel là où il est difficile à copier — les modèles et les services.

Le raisonnement est implacable. Si le moteur est Apache 2.0, n'importe quel opérateur peut servir des modèles avec une efficacité comparable. DeepSeek parie donc que son fossé n'est pas dans des kernels secrets, mais dans la qualité de ses modèles et dans sa structure de coûts. Les chiffres publiés appuient ce pari : à 38 $ de revenu par GPU/heure, l'argent se fait à l'échelle, pas dans l'obscurité.

La monétisation, elle, se joue ailleurs. Le labo a déjà ouvert aux agents ses API Search et Fetch, facturées 0,75 $ le millier d'appels (DeepSeek ouvre Search et Fetch API aux agents : son moteur interne à 0,75 $ le millier d'appels). La logique est cohérente : l'infrastructure est un coût à optimiser et à partager, le service est le produit.

Quartz y voit la continuation d'une stratégie open source assumée comme arme concurrentielle. Difficile de contredire ce diagnostic : à chaque publication — poids, kernels, moteur — DeepSeek pose la même question embarrassante à ses concurrents fermés. Que vendez-vous, exactement, que nous ne donnons pas gratuitement ?

Ajoutez la visibilité — tête de Hacker News, 3 300 étoiles en quelques jours — et vous obtenez aussi le meilleur argument de recrutement possible pour une équipe d'ingénierie systèmes. L'ouverture offensive est aussi une machine à talent.

Qui peut vraiment faire tourner DeepInfer ?

Réponse directe : sans un cluster de GPU de datacenter, personne. Et c'est un choix, pas un oubli.

Les prérequis matériels sont sans ambiguïté : NVIDIA SM100 ou Huawei Ascend 950. La configuration de référence du décodage mobilise 64 GPU en parallélisme d'experts ; les tests de préfill, 4. Nous sommes très loin de la station de travail, et volontairement. DeepInfer s'adresse aux opérateurs de clusters, aux clouds et aux entreprises qui font de l'inférence leur métier.

Pour ces publics, le parcours est balisé : poids de DeepSeek-V4.1-Flash (17 octobre), framework (20 octobre), et un repo deepseek-recipe sous licence MIT qui documente recettes et configurations. De quoi reproduire, sur son propre matériel, des conditions proches de celles annoncées par DeepSeek.

Pour un particulier, en revanche, la porte d'entrée reste ailleurs. Si l'objectif est de faire tourner DeepSeek V4 Flash en local, la voie réaliste passe par ds4, le moteur d'inférence lancé par antirez qui rend ce modèle utilisable sur un Mac (antirez lance ds4 : le moteur d'inférence local qui rend DeepSeek V4 Flash utilisable sur un Mac). Sinon, l'API du labo reste le chemin le plus court.

Notre avis : DeepInfer n'est pas un cadeau aux hobbyistes, c'est un cadeau aux opérateurs — et un message aux concurrents. Ne vous trompez pas de destinataire.

❌ Erreurs courantes

Erreur 1 : comparer les 26 000 tokens/s/GPU à votre propre charge de travail

Le chiffre vient d'une configuration précise : EP64, contexte de 131 072 tokens, taux d'acceptation de 75 % — et surtout un trafic où 96 % des entrées sont en prefix cache. Votre trafic ne ressemble pas à celui de DeepSeek. La solution : lisez les configurations de deepseek-recipe, puis mesurez sur votre propre charge avant de conclure quoi que ce soit.

Erreur 2 : croire que DeepInfer remplace une plateforme de serving

Hors-ligne uniquement, pas de KV cache, pas de load balancing : le code publié ne sert pas une API interactive telle quelle. La solution : traitez DeepInfer comme un noyau de calcul dont vous extrayez les briques — FlashMLA, DeepEP, DSpark — pour les intégrer dans votre pile existante.

Erreur 3 : prendre le repo pour la build de production exacte

La version interne de FlashMLA serait 5 à 10 % plus rapide que la version publiée, et des pans entiers du serving restent internes. La solution : considérez les chiffres annoncés comme des majorants et attendez des benchmarks indépendants avant d'investir sur la base de ces seules mesures.

❓ Questions fréquentes

Qu'est-ce que DeepInfer, en une phrase ?

Le framework d'inférence utilisé en production par DeepSeek, open sourcé le 20 octobre 2026 sous Apache 2.0. Il regroupe les kernels FlashMLA, DeepGEMM et DeepEP, le décodage spéculatif DSpark et un préfill SWA bounded replay, pour servir un unique modèle : DeepSeek-V4.1-Flash.

DeepInfer est-il utilisable commercialement ?

Oui. La licence Apache 2.0 autorise l'usage commercial, la modification et la redistribution sans redevance, et le repo deepseek-recipe est sous licence MIT. La vraie barrière n'est pas légale mais matérielle : il faut des GPU NVIDIA SM100 ou Huawei Ascend 950 pour l'exécuter.

Quelle est la différence entre DeepSeek V4 Flash et V4.1-Flash ?

V4.1-Flash est la déclinaison de la gamme Flash que sert DeepInfer, dont les poids ont été publiés le 17 octobre 2026. Elle s'inscrit dans la stratégie V4 du labo, qui distingue des variantes Pro et Flash aux positionnements et aux profils de coût différents.

Les performances annoncées sont-elles vérifiées par des tiers ?

Non : ce sont les mesures de DeepSeek — environ 26 000 tokens/s/GPU en décodage (EP64, contexte 131 072, 75 % d'acceptation) — relayées par MarktechPost. explainx.ai souligne l'écart entre l'affirmé et le vérifiable, et la version interne de FlashMLA serait plus rapide que la version publiée.

Pourquoi DeepSeek open-source son infrastructure de production ?

Trois raisons se cumulent : commoditiser l'inférence pour déplacer l'avantage vers les modèles et les services, afficher une indépendance matérielle avec le duo SM100/Ascend 950, et capter la communauté technique. La première place de Hacker News et les 3 300 étoiles en quelques jours en sont l'illustration immédiate.

✅ Conclusion

En ouvrant le moteur qui sert 155 000 milliards de tokens par jour, DeepSeek ne publie pas seulement du code : il publie une grille économique, une double cible matérielle et un aveu — dans l'IA, l'avantage se déplace du secret vers l'exécution. La prochaine étape sera celle des benchmarks indépendants. Pour ne rien manquer de ce type d'annonces, direction notre veille des nouveaux outils IA.