DeepSeek ouvre DeepInfer : 155 billions de tokens par jour et 80 % de marge

DeepSeek a publié en accès libre DeepInfer, le moteur sur lequel tourne V4.1 Flash. Le code s'accompagne d'un rapport d'ingénierie avec des chiffres de production : 155 billions de tokens par jour sur un seul cluster, 96 % de cache hits en entrée, un time to first token moyen de 400 ms et une génération à 230 tokens/s (jusqu'à 300 pour le code). D'après les calculs de Latent Space, aux tarifs exceptionnels de $0,15 par million de tokens en entrée et de $0,60 par million de tokens en sortie, cela représente environ $22 millions de revenus par jour et de l'ordre de $38 par accélérateur et par heure.

D'où vient la marge de 80 %

Le calcul est le suivant. 155 millions de millions de tokens à un prix mixte d'environ $0,14 donnent à peu près $1 million par heure. Selon l'estimation de l'auteur de l'analyse, le coût complet d'une carte est de $5 à 8 par heure. On en déduit une marge d'inférence supérieure à 80 % et un retour sur investissement du cluster d'environ 81 jours. Il s'agit d'une estimation de Latent Space : DeepSeek elle-même table sur un amortissement en 10 mois.

Une réserve importante : 155 billions de tokens servis ne sont pas 155 billions de tokens générés. Avec 96 % de cache hits, la quasi-totalité de l'entrée est lue depuis le stockage, et seule une faible part est recalculée. Les chiffres sont de première main, sans audit indépendant, et le résultat dépend fortement de la composition de la charge, de la comptabilisation du cache et du périmètre des coûts inclus.

Comment la pile est conçue

DeepInfer sépare le vision encoding, le prefill et le decode, et chaque étape est dimensionnée selon son propre goulot d'étranglement. Il est recommandé d'exécuter le prefill sur des machines classiques à huit accélérateurs, et le decode sur des supernœuds de 64 à 128 accélérateurs avec du wide expert parallelism pour les MoE.

• Le planificateur de prefill estime le coût de l'attention et découpe les chunks selon un budget de temps, et non selon une taille fixe.
• Le routage du prefill n'est pas lié au cache : les préfixes résident dans un stockage partagé, et la requête part vers n'importe quel worker libre.
• Le routage du decode tient compte du nombre de requêtes actives et de la longueur du KV-cache.
• Les experts les plus sollicités sont répliqués et redistribués périodiquement, au prix de la mémoire HBM.
• Le planificateur CPU fonctionne de façon asynchrone et supprime les pauses entre les étapes de decode.
• D'après l'analyse, la configuration dévoilée pour Blackwell n'utilise pas de tensor parallelism.

Le cache repose sur un cluster 3FS d'environ 100 PiB de SSD. La durée de conservation est de 3 jours pour les agents et de 7 jours pour les chats. L'état de la sliding-window attention reste dans la mémoire de l'hôte. La méthode SWA Bounded Replay reconstruit l'état éphémère manquant à partir des 128 derniers tokens et, selon DeepSeek, réduit presque de moitié les calculs de prefill. La vérification spéculative adaptative DSpark apporte +6 % de débit en production par rapport à une vérification fixe de cinq tokens de brouillon.

Le composant deepseek-recipe couvre la couche d'interface : les API Chat Completions, Responses et Messages, la tokenisation parallèle, ainsi que la distinction entre les véritables tokens de contrôle et les chaînes identiques présentes dans le texte utilisateur. Ce n'est pas une protection complète contre la prompt injection.

Ce qui est ouvert, et ce qui ne l'est pas

L'équipe qualifie la publication de totalement ouverte, mais la description technique indique que la gestion du KV-cache et le répartiteur de charge ne sont pas encore intégralement publiés. Ils dépendent de l'infrastructure interne. 3FS, publié auparavant, en fait aussi partie. L'orchestration au niveau du service reste à la charge de celui qui déploie la pile.

Les estimations de la communauté sont secondaires : 196B de paramètres pour Engram, 552B de paramètres d'experts, DP64/EP64, des poids majoritairement en 4 bits, une compression du KV de 400 fois par rapport à GQA. La source primaire ne confirme pas ces détails.

vLLM a répondu par des benchmarks. DeepInfer a été conçu à l'origine sur vLLM, et l'équipe du projet a mesuré un decode-throughput à moins de 6 % de celui publié par DeepSeek sur GB200, dans une configuration comparable, puis a publié les recettes et les résultats AgentX. C'est la parité d'une seule étape, pas la reproduction du service entier : le cache de 100 PiB, le routage et la disponibilité n'entrent pas dans ce résultat.

De son côté, OpenAI a annoncé un cache de prompts de 12 heures dans l'API, contre 30 minutes par défaut. Les produits diffèrent, mais l'objectif est le même : des agents qui reviennent à un long contexte après plusieurs heures.

Une équipe qui construit un service d'agents peut retenir trois choses de cette publication. Première : calculer l'économie à partir de la part de cache hits et de la durée de conservation des préfixes, et non du prix par token. Deuxième : séparer le prefill et le decode dans des pools distincts et équilibrer le prefill d'après l'estimation du calcul. Troisième : tester vLLM sur sa propre charge, car le décodage y est déjà proche des résultats de DeepSeek, et l'essentiel de l'écart se situe dans la couche de cache et d'orchestration.