Aller au contenu

Matériel et coûts

Le malentendu à dissiper d'abord

890 octets par jeton ne veut pas dire « petit modèle »

Tous les gains de DeepSeek-V4.1-Flash portent sur le cache et sur le calcul par jeton. Aucun ne porte sur la mémoire nécessaire pour héberger les poids.

Un modèle à 16 G de paramètres activés n'est pas un modèle de 16 G. Il faut les 552 G en mémoire, plus les 196 G d'Engram, avant de pouvoir activer quoi que ce soit.

La taille réelle du dépôt

Mesurée via l'API Hugging Face, la somme des 48 fichiers safetensors vaut :

510,30 Go, soit 475,25 Gio.

C'est le chiffre à retenir : c'est ce qu'il faut télécharger, et à peu près ce qu'il faut loger.

D'où viennent ces 510 Go

La reconstruction depuis les dimensions et les formats déclarés :

Composant Format Taille
Experts MoE, DSpark compris FP4, blocs 32×32, échelles E8M0 279,8 Go
Reste du squelette (attention, plongements, vision) FP8 majoritaire 6,9 Go
Tables Engram FP8 196,6 Go
Total reconstruit 483,4 Go
Mesuré 510,30 Go

L'écart de 26,9 Go n'est pas expliqué par les documents publiés. Une hypothèse plausible : les facteurs d'échelle des tables Engram. Une échelle FP32 par bloc de 32 canaux sur les 768 millions de lignes en représenterait 24,6 Go — presque exactement l'écart. Ce rapport le mentionne comme hypothèse, sans la certifier.

Ce que la reconstruction établit malgré tout

Elle rend compte de 95 % de la taille du dépôt, ce qui confirme au passage deux choses non documentées explicitement : les experts sont bien livrés en FP4 (et non quantifiés a posteriori par l'utilisateur), et les 196 G de paramètres Engram sont bien inclus dans les poids publiés.

Ce qu'il faut comme matériel

Pour héberger les poids

Configuration Mémoire totale Verdict
8 × H100 80 Go 640 Go possible, sans marge confortable
8 × H200 141 Go 1 128 Go confortable
8 × B200 192 Go 1 536 Go large
1 × RTX 4090 24 Go 24 Go hors de question

L'implémentation de référence vise 8 rangs de parallélisme de tenseur par défaut, ce qui est cohérent avec un nœud à 8 GPU. Deux configurations sont par ailleurs données comme vérifiées avec SGLang — 4 × GB300 et 4 × MI350X — avec la possibilité de déporter les tables Engram en mémoire hôte.

La nuance Engram

Les 196,6 Go de tables Engram n'ont pas besoin d'être en mémoire vive graphique au service. L'adressage étant déterministe, DeepSeek les garde en mémoire hôte et les préextrait par RDMA en arrière-plan, la préextraction du premier module recouvrant le calcul du premier bloc Transformer.

En excluant Engram de la HBM, le budget graphique tombe à environ 287 Go, soit 4 × H100 en théorie — mais avec une contrainte forte sur la bande passante hôte-GPU et une latence supplémentaire à absorber.

Une exception importante

Pendant les trajectoires d'apprentissage par renforcement, DeepSeek précise garder les tables Engram résidentes en mémoire GPU, pour réduire la pression sur la mémoire hôte et éviter les échecs par manque de mémoire causés par la fragmentation. Le compromis n'est donc pas le même à l'entraînement et au service.

Pour le cache

C'est là que le modèle brille.

Contexte Cache global Cache de fenêtre glissante
128 K jetons 109 Mio 2,7 Mio
512 K jetons 435 Mio 2,7 Mio
1 M jetons 0,87 Gio 2,7 Mio

Sur un nœud de 640 Go dont 300 servent aux poids, il reste de quoi tenir plusieurs centaines de requêtes concurrentes à contexte plein. C'est précisément l'objectif du modèle : le cache cesse d'être le facteur limitant du nombre de requêtes simultanées.

Pour comparaison, sur une architecture GQA classique de type DeepSeek-V1 67B, le même nœud ne tiendrait pas même une seule requête à un million de jetons — il faudrait 372 Gio de cache pour une requête.

Pour le stockage persistant

Le cache persistant sur SSD est dimensionné pour garder le cache global au moins 72 heures. À 890 octets par jeton, un million de jetons persistés coûte 0,87 Gio de SSD — contre environ 3,4 Gio pour DeepSeek-V4-Flash au même contexte, et sans compter le cache de fenêtre glissante que V4 devait également persister.

Le coût par jeton en calcul

Une propriété structurelle, plus intéressante que les chiffres absolus : le coût de calcul du décodage ne dépend presque pas de la longueur du contexte.

Le rapport technique mesure qu'étendre le contexte d'un facteur 256 — de 4 K à 1 M — n'augmente les FLOPs de décodage par jeton que d'un quart, en pondérant les opérations BF16, FP8 et FP4 par 1, 0,5 et 0,25 respectivement.

Trois mécanismes se conjuguent pour cela :

  • l'attention ne porte que sur \(128 + 512 = 640\) positions, quel que soit le contexte ;
  • l'indexeur hiérarchique borne le coût des indexeurs profonds ;
  • le MoE n'active que 7 experts sur 385.

Ce qui n'est pas publié

Aucune mesure de latence ni de débit

DeepSeek ne publie ni jetons par seconde, ni latence au premier jeton, ni coût mesuré par tâche, ni consommation énergétique.

Les gains d'efficacité sont calculés — paramètres activés, octets de cache, nombre de noyaux GPU — et non mesurés de bout en bout. Pour un modèle dont l'argument principal est le coût de service, c'est l'absence la plus notable de la publication.

Le prix, lui, est public — mais pas dans le rapport technique

Le rapport technique ne mentionne aucun tarif. La documentation d'API, si : 0,003 $ par million de jetons d'entrée en cache en heures creuses, contre 0,022 $ pour V4-Pro.

C'est la seule traduction chiffrée du gain de cache disponible, et elle est éloquente. Voir L'API et ses tarifs.

En résumé

Question Réponse
Puis-je le faire tourner chez moi ? Non.
Sur un nœud à 8 GPU ? Oui, à partir de 8 × H100.
Combien de contexte ? 1 M de jetons pour moins de 1 Gio de cache.
Combien de requêtes concurrentes ? Plusieurs centaines à contexte plein — c'est le point.
Est-ce moins cher que V4-Flash ? Sur le cache, oui, ÷ 4 à ÷ 8. Sur les poids, non : le modèle est deux fois plus gros.
Et par API ? 0,003 $ le million de jetons en cache hit — tarifs détaillés.

Chapitre suivant : L'API et ses tarifs