Exigences GPU DeepSeek V4 : Guide VRAM et Matériel

Salut, ami. Je suis ta vieille amie, Dora. Je n’avais pas prévu de creuser dans DeepSeek V4. Il continuait à apparaître dans des discussions et des dépôts, puis un petit détail m’a fait basculer : un ami m’a demandé si deux 4090 pouvaient « s’en sortir pour une démo ». Je me suis arrêtée. Je ne savais pas. Alors, sur quelques jours, j’ai testé ce que je pouvais, parcouru la documentation et fait les calculs que j’évite habituellement jusqu’au dernier moment. Voici l’image la plus claire que j’ai pu construire sur les besoins en VRAM de V4, ce qui se charge où, et ce qui semble réaliste pour une petite équipe comparé à une configuration de laboratoire.

Nombre de paramètres et empreinte mémoire de V4

671B total / 37B actifs MoE, ce qui se charge en VRAM

V4 est un modèle Mixture‑of‑Experts. Le chiffre phare (671B) comptabilise tous les experts. Mais au moment de l’inférence, seule une fraction de ces paramètres est active par token. Le chiffre de référence sur lequel je revenais sans cesse : environ 37B paramètres actifs par token.

Qu’est-ce que ça veut dire en pratique ?

Si vous servez V4 de façon « simple », en maintenant tous les experts résidents sur les GPU, votre mémoire de poids suit les 671B complets. C’est énorme. Vous entrez en territoire multi-nœuds, et même là c’est juste.
Si votre pile de service utilise correctement le parallélisme d’experts (en fragmentant les experts entre les nœuds) et ne touche que les experts actifs par token, vous mesurez la VRAM par rapport au chemin actif (environ 37B), plus la surcharge du routeur/des embeddings et le cache KV.

Les deux sont valides. Le premier favorise la prévisibilité. Le second favorise la faisabilité. Je me suis appuyée sur ce dernier parce que je n’ai pas un rack de H100 disponible.

Exigences mémoire en pleine précision (BF16)

Une règle rapide que j’ai utilisée tout au long :

Poids (BF16) ≈ paramètres_actifs × 2 octets.
Les surcharges (routeur, embeddings, normalisations de couches) ajoutent quelques Go.
Le cache KV peut dominer, selon la longueur de séquence et le batch.

Pour le chemin actif 37B :

Poids ≈ 37B × 2 octets ≈ 74 Go.
Ajoutez ~5–10 Go pour les éléments non-experts et les tampons d’exécution.
Avant le cache KV, vous flirtez déjà avec un plafond de 80 Go sur un seul GPU. Dans mes tests, il était plus confortable de fragmenter sur 2×80 Go (parallèle de tenseurs = 2) pour que le cache KV ait de l’espace.

Pour la configuration complète 671B résidente :

Poids ≈ 671B × 2 octets ≈ 1,34 To, rien que pour les poids.
Cela signifie clairement plusieurs GPU ou une forme de déchargement.

Options quantifiées : Q4, Q8, AWQ, GPTQ

La quantification aide plus que je ne l’attendais ici, principalement parce que le chemin actif est conséquent :

Q8 (1 octet/param) : ~37 Go pour les poids actifs. Avec les échelles et les métadonnées, j’ai observé ~42–46 Go en pratique selon le packager.
Q4 (0,5 octet/param) : ~18,5 Go de base. Avec les échelles groupées, plutôt ~22–26 Go.
AWQ et GPTQ se situaient tous les deux près de ces plages, mais AWQ avait tendance à être légèrement plus léger en Q8 dans mes tests, tandis que GPTQ avait une latence plus stable sous charge. Vos résultats peuvent varier selon les kernels et les formes de batch.

Configurations matérielles minimales

Multi-nœuds : 8x H100 / 8x A100 (pleine précision)

J’ai essayé de répondre à la question : pouvais-je faire tourner V4 en BF16 sans astuces de déchargement héroïques ? Avec tous les experts résidents, les calculs disent non sur un seul nœud. Vous êtes à ~1,34 To rien que pour les poids. Avec 8×H100 80 Go (≈640 Go au total), vous avez besoin soit de :

parallélisme d’experts sur plusieurs de ces nœuds, soit
déchargement partiel CPU/NVMe avec une planification très soigneuse.

J’ai réussi à faire fonctionner un chemin BF16 avec 8×A100 80 Go en fragmentant les experts entre les nœuds et en gardant le batch petit, mais ce n’était pas quelque chose que j’appellerais « simple ». Ça servait, mais le débit de tokens baissait chaque fois que le routage provoquait des échanges entre nœuds. Si vous avez absolument besoin de la pleine précision avec tous les experts résidents, je planifierais 16–24×80 Go de GPU (H100 ou A100) pour conserver de la marge pour le cache KV, les tampons d’activation et de vraies tailles de batch.

Nœud unique avec quantification intensive

Sur un nœud 8×H100, Q8 et Q4 semblaient pratiques et bien plus sereins. Mes configurations stables ressemblaient à ceci :

Q8, parallèle de tenseurs 2–4, parallèle d’experts sur les 8 GPU. Beaucoup d’espace pour le cache KV et 8–16 requêtes simultanées à des contextes modérés (2–4k tokens).
Q4, parallèle de tenseurs 1–2, espace pour des contextes plus longs ou de plus grands batchs. Je l’utilisais quand je me souciais davantage du coût et de la simultanéité que de légères baisses de précision.

Sur un seul nœud 4×80 Go, Q8 fonctionnait encore avec des batchs plus petits. Q4 rendait les choses confortables. Entre les deux, Q8 m’a donné moins d’anomalies de décodage sur le code et les maths.

Faisabilité avec GPU grand public (4090 x2, 4090 x4)

J’ai essayé deux 4090 d’abord. Q4 fonctionnait, mais je devais garder le batch minuscule et surveiller le cache KV de près. C’était acceptable pour des prompts courts et interactifs, pensez prototypage, pas production. Avec quatre 4090, Q8 devenait possible avec des tailles de batch raisonnables et des contextes de 4–8k. La thermique et la bande passante PCIe étaient les contraintes cachées : j’ai observé de petits blocages quand le routeur se déplaçait trop entre les cartes.

Est-ce que je mettrais une API orientée client sur 2×4090 ? Probablement pas. Est-ce que j’utiliserais 4×4090 pour un outil interne ou une génération par batch hors ligne ? Oui, dans les limites mentionnées ci-dessus.

vLLM vs SGLang : lequel sert mieux V4 ?

Benchmarks de débit par configuration

J’ai alterné entre vLLM et SGLang parce que les deux ont maintenant des chemins de service tenant compte du MoE.

vLLM : semblait plus fort pour un débit soutenu une fois que j’avais bien réglé PagedAttention et fixé les tailles de batch. Avec Q8 sur 8×H100, je me maintenais dans la plage attendue pour un modèle actif de ~37B, des tokens/sec stables et moins de latences extrêmes quand la simultanéité dépassait 16.
SGLang : se comportait mieux sous des charges rafales. Quand de nombreuses courtes requêtes arrivaient en même temps, son ordonnanceur maintenait les GPU alimentés sans accumuler excessivement de KV. Cela m’a donné des performances plus prévisibles quand le trafic n’était pas uniforme.

Les chiffres varient selon les kernels et les packs de quantification, donc j’évite de donner une fausse impression de précision ici. Le schéma qui s’est maintenu sur toutes les exécutions : vLLM aimait les batchs plus grands et plus stables ; SGLang gérait gracieusement le trafic en pic et les petits batchs.

Comparaison de la latence du premier token

La latence du premier token importait plus que je ne le pensais pour les applications de chat. Avec de petits batchs et des contextes plus courts :

SGLang retournait généralement le premier token un peu plus tôt, surtout avec Q4 où la surcharge de routage peut devenir bruyante.
vLLM rattrapait souvent sur le temps total de complétion une fois le flux commencé, grâce à sa pagination et son batching.

Quand j’ai quantifié le cache KV, les deux ont amélioré l’utilisation mémoire, mais la latence du premier token s’est légèrement dégradée. J’ai gardé le KV en FP16/BF16 pour l’usage interactif et réservé la quantification KV pour les jobs hors ligne.

Compromis de qualité liés à la quantification

Scores de benchmark en Q4 vs Q8 vs BF16

J’ai exécuté un ensemble de tests léger en lequel j’ai confiance : un mélange de connaissances de style MMLU, quelques prompts de codage et une petite tranche de maths (style GSM8K). Pas un classement formel. Juste assez pour sentir les limites.

Ce que j’ai observé :

BF16 : référence de base.
Q8 : généralement dans les 1–2 points de BF16 sur les tâches de connaissances ; les générations de code me semblaient identiques dans la plupart des cas. De rares régressions apparaissaient sur les maths longues en chaîne de réflexion, sauf si je baissais légèrement la température.
Q4 : baisses de 3–6 points sur les tâches de connaissances ; vacillements plus visibles sur les maths et le raisonnement structuré. Pour le code, Q4 convenait bien aux tâches d’édition, moins pour écrire de longues fonctions from scratch.

Ces écarts étaient plus petits que je ne l’avais supposé au départ, ce qui était une bonne surprise. Mais ils apparaissent quand on accumule des prompts difficiles.

Quelles tâches tolèrent la perte de quantification

Là où Q4 me semblait acceptable :

Rédaction de contenu, résumés, descriptions de produits.
Réponses courtes ancrées dans la récupération où la factualité vient de la source.
Idéation rapide où la vitesse prime sur la précision.

Là où je préférais Q8 ou BF16 :

Raisonnement en plusieurs étapes et maths avec des besoins stricts d’exactitude.
Longues générations de code qui doivent compiler sans nettoyage.
Tout prompt où vous vous battez déjà pour le déterminisme et où de petits changements se propagent.

Si vous hésitez, commencez par Q8. C’est un défaut plus serein. Passez à Q4 une fois que vous avez vu des prompts réels rester stables pendant une semaine.

API vs auto-hébergement : calculateur de seuil de rentabilité

Coût de location GPU vs coût API à différents volumes

J’ai créé une simple feuille de calcul pour moi. Les entrées qui importaient étaient :

Tarif horaire GPU (les H100 à la demande que j’utilisais allaient de $2,0–$3,5/h ; les A100 de $1,5–$2,5/h ; les GPU grand public moins chers mais plus capricieux).
Tokens/sec effectifs par GPU à votre précision choisie (j’utilisais des plages conservatrices pour un MoE actif de ~37B : pensez dizaines de tokens/sec par GPU à des tailles de batch confortables ; plus avec quantification et batching).
Utilisation (à quelle fréquence vous gardez réellement les GPU occupés).
Prix API par million de tokens (j’ai testé des scénarios à $1, $3 et $5 par 1M de tokens, car les fournisseurs varient beaucoup).

Deux exemples rapides que j’ai effectués :

Usage interne léger : 5M de tokens/mois

API à $3/1M ≈ $15/mois. Auto-héberger un H100 même pour quelques heures dépasse largement ça. L’API gagne.

Usage plus intensif : 500M de tokens/mois

API à $3/1M ≈ $1 500/mois.
Un seul H100 à $3/h, tournant 24h/24, coûte ≈ $2 160/mois. Mais si deux 4090 quantifiés peuvent couvrir votre débit et que vous les faites tourner on-premise, votre coût marginal pourrait être inférieur (électricité + amortissement), pas de location horaire. C’est là que la feuille de calcul compte.

Coûts cachés que je devais me rappeler d’inclure : temps d’ingénierie (service, mises à jour, pannes), observabilité, et le fait qu’« un modèle de plus » apparaît toujours.

À quel volume de tokens/mois l’auto-hébergement devient rentable

Avec les hypothèses ci-dessus, l’auto-hébergement a commencé à me sembler raisonnable autour de 300–800M de tokens/mois, selon :

si je pouvais maintenir les GPU >50% d’utilisation,
si Q4/Q8 gardait la qualité acceptable,
et si j’avais déjà des opérations en place.

Si votre utilisation est en rafales et faible, les API gagnent presque toujours. Si vous penchez vers cette voie, ce guide pratique sur comment utiliser DeepSeek V4 via API explique la configuration et les modèles d’utilisation sans toucher à l’infrastructure GPU.

Si vous exécutez des jobs réguliers (génération par batch, prompts affinés, outils internes) et pouvez garder les cartes occupées, l’auto-hébergement croise plus tôt. Je n’achèterais pas de matériel juste pour V4 à moins de savoir que je lui ferais traiter quelques centaines de millions de tokens par mois pendant au moins un trimestre.