Pourquoi DeepSeek-V4 ne se sert pas comme un Llama
Avec un Llama dense, le contrat est simple : vous chargez les poids, le runtime exécute l’attention de la seule manière dont elle existe, et l’exactitude que vous obtenez est celle du modèle. Le runtime est un exécutant. Si vous vous trompez de version, dans le pire des cas le modèle ne charge pas : l’échec est bruyant.
DeepSeek-V4 déplace le contrat. Son attention n’est pas une opération unique et figée : c’est un pipeline de compression et de sélection, dont une partie tourne en FP4. Servir le modèle correctement suppose que le runtime implémente les bons kernels et active les bons chemins de code. Et c’est là que le mode d’échec change de nature. Quand un chemin manque ou qu’un kernel approxime, le modèle ne s’arrête pas : il continue de produire des tokens plausibles. L’attention sélectionne juste le mauvais contexte, un peu, à chaque pas. Rien dans les logs ne le signale. Seule une mesure d’exactitude le révèle, encore faut-il la faire.
C’est le fil rouge de cet article : sur un modèle aussi compressé que DeepSeek-V4, « ça tourne » a cessé de vouloir dire « c’est correct ».
Ce que DeepSeek-V4 compresse, et pourquoi ça déplace le risque
DeepSeek-V4, sorti en preview le 24 avril 2026, existe en deux variantes MoE (Mixture of Experts) : V4-Pro, 1,6 trillion de paramètres dont environ 49 milliards activés par token, et V4-Flash, 284 milliards dont environ 13 milliards activés. Les deux partagent une architecture d’attention hybride dont le but unique est de rendre le contexte long abordable.
Le mécanisme se déplie en deux étages. Le premier, Compressed Sparse Attention (CSA), compresse le KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire d’un facteur 4 le long de la séquence, puis utilise un Lightning Indexer en FP4 pour sélectionner, pour chaque requête, les quelques blocs compressés les plus pertinents, au lieu de relire tout l’historique. Le second, Heavily Compressed Attention (HCA), applique une compression bien plus violente, de l’ordre de 128×, sur la séquence. L’attention de DeepSeek-V4 n’est donc pas un balayage dense de tout le contexte : c’est un index qui décide quoi regarder, et cet index est lui-même quantifié.
Le gain est ce qui rend le modèle désirable. À un million de tokens de contexte, DeepSeek revendique pour V4-Pro environ 27 % des FLOPs par token et 10 % du KV cache d’un DeepSeek-V3.2 équivalent. Dit autrement : le contexte long, qui faisait exploser la mémoire et le calcul, redevient servable à un coût raisonnable. C’est exactement pour cette raison que la couche d’attention est devenue load-bearing, porteuse. Sur un modèle dense, l’attention est une commodité ; sur DeepSeek-V4, c’est la pièce dont dépend l’exactitude, et c’est la pièce que chaque runtime doit réimplémenter fidèlement.
Piège n°1 : la version (vous épinglez du code en mouvement)
Le support de DeepSeek-V4 est arrivé dans les trois runtimes en quelques semaines, et il bouge encore. Ce n’est pas un détail de release notes : tant que le support se stabilise version après version, la version que vous figez détermine la fidélité de l’attention que vous servez.
Côté vLLM, DeepSeek-V4 tourne dès le jour 0 (avril 2026), mais le chemin se durcit en 0.22.0 (29 mai 2026) : fused MoE en NVFP4 (NVIDIA FP4), capture de graphe CUDA complète et par morceaux, speculative decoding Technique d'accélération du decode qui utilise un petit modèle rapide (draft model) pour proposer plusieurs tokens candidats, ensuite vérifiés en un seul passage par le modèle principal. Les tokens corrects sont acceptés sans coût supplémentaire : on échange du calcul redondant contre une réduction du nombre de passes autorégressives. Approfondir dans le glossaire par MTP (Multi-Token Prediction). La 0.23.0 (408 commits de 200 contributeurs) ajoute un kernel d’attention TRTLLM-gen, l’EPLB (Expert-Parallel Load Balancing) pour le Mega-MoE, et découple les métadonnées d’attention sparse de celles de DeepSeek-V3.2. Deux releases, deux niveaux de maturité.
Côté SGLang, la 0.5.12 fournit le chemin d’inférence complet dès le jour 0 : parallélisme tensoriel, expert et de contexte, offload HiSparse, kernels DeepGEMM et FlashMLA. La 0.5.13 y ajoute le MTP à contexte parallèle et les kernels FlashMLA sparses. Mais la version qui compte n’est ni l’une ni l’autre, comme on le verra à la section suivante.
Côté TensorRT-LLM, la situation demande d’être dite franchement : il n’existe pas de version stable 1.3.0 GA au 15 juin 2026. Le support DeepSeek-V4 vit dans une série de release candidates : la rc15 améliore « le support de DeepSeek V4 et V3.2 avec de nouveaux kernels d’attention, des mises à jour de routage, le chargement du tokenizer », et les rc suivantes (jusqu’à la rc18 du 10 juin) poursuivent. Aucune rc n’est canonique : le support s’affine d’une rc à l’autre. Vous n’épinglez donc pas une version, vous épinglez un instantané d’un travail en cours, et chaque montée de rc demande de retester.
| Runtime | Version minimale | Ce qui a atterri | Statut |
|---|---|---|---|
| vLLM | 0.22.0 (29 mai) | Fused MoE NVFP4, CUDA graph, MTP ; 0.23 ajoute kernel TRTLLM-gen + EPLB | Stable |
| SGLang | 0.5.12.post1 | Chemin complet day-0, HiSparse, FlashMLA + correctif d'exactitude | Stable |
| TensorRT-LLM | 1.3.0rc15+ | Kernels d'attention DSV4, routage, AutoConfig, affinés rc par rc | Release candidate (pas de GA) |
Piège n°2 : l’exactitude silencieuse
C’est ici que tout se joue, et c’est le passage à retenir. SGLang a livré en 0.5.12.post1 un correctif dont l’intitulé est, à lui seul, l’argument de cet article : « DSV4 HiSparse + SGLANG_OPT_USE_COMPRESSOR_V2=1 : exactitude GSM8K restaurée de 0,825 à 0,960 » (PR #25646).
Décortiquons. HiSparse est le mécanisme d’offload du KV inactif spécifique aux modèles à attention sparse comme DeepSeek-V4 : il déplace proactivement vers la mémoire CPU les entrées qui ne participent plus à l’attention. Le « compresseur V2 » est la nouvelle implémentation du chemin de compression que cet offload utilise. Quand le flag SGLANG_OPT_USE_COMPRESSOR_V2=1 n’est pas posé, SGLang sert DeepSeek-V4 par l’ancien chemin, qui fonctionne au sens où il génère des réponses, mais dont la sélection de contexte est suffisamment fausse pour faire chuter l’exactitude de 13 points sur un benchmark de raisonnement arithmétique. Treize points sur GSM8K, c’est la différence entre un modèle qui raisonne et un modèle qui se trompe une fois sur sept de plus, sans qu’aucune trace d’exécution ne le dise.
Le parallèle pour un ingénieur système est celui de la compilation : un kernel numériquement instable, ou un -ffast-math qui réordonne des opérations flottantes, ne lève pas d’exception : il renvoie des résultats plausibles et faux. La différence est qu’ici l’instabilité ne vient pas d’une optimisation que vous avez demandée, mais d’un chemin de code que le runtime active ou non selon un flag que rien ne vous oblige à connaître.
Piège n°3 : la base a bougé sous le runtime
Le troisième piège est plus prosaïque mais non moins coûteux : pour servir DeepSeek-V4, vous montez des runtimes dont la base d’exécution a changé. SGLang est passé par défaut à CUDA 13.0 et PyTorch 2.11 dès sa 0.5.11 ; vLLM a opéré la même bascule dans sa série 0.21 : CUDA porté à 13.0.2 pour s’aligner sur PyTorch 2.11.0, et C++20 désormais requis à la compilation. Ce n’est pas une mise à jour de point, c’est un saut de toolchain, avec ce que cela implique de compatibilité de pilote, de recompilation de kernels et de dépendances Python alignées.
La conséquence pratique : la version de runtime qui sait parler à DeepSeek-V4 est aussi celle qui exige une stack système récente. Vous ne pouvez pas isoler la montée de version du modèle de la montée de la base. Traitez la migration CUDA 13 / PyTorch 2.11 comme un prérequis daté, pas comme un effet de bord, et validez le pilote avant le runtime, pas l’inverse.
Comment servir DeepSeek-V4 correctement
La méthode tient en trois temps, indépendamment du runtime.
Choisissez la version par la fidélité, pas par la fraîcheur. Sur vLLM, la 0.22.0 est le plancher fonctionnel et la 0.23.0 le bon défaut si vous visez le débit (kernel TRTLLM-gen, EPLB). Sur SGLang, le plancher réel est la 0.5.12.post1 : la 0.5.12 « marche » mais embarque la régression d’exactitude. Sur TensorRT-LLM, prenez la release candidate la plus récente de la série 1.3 et acceptez d’en changer : tant qu’il n’y a pas de GA, la stabilité d’API n’est pas garantie.
Activez explicitement les bons chemins. Sur SGLang, SGLANG_OPT_USE_COMPRESSOR_V2=1 n’est pas optionnel pour DeepSeek-V4 : c’est la condition de l’exactitude. Posez le principe : pour un modèle à attention sparse, tout flag qui touche au chemin de compression ou d’indexation est un flag d’exactitude, à documenter dans votre déploiement comme tel.
Mesurez après chaque changement. Une éval courte (GSM8K suffit comme canari, complétée par votre jeu métier) rejouée à chaque bump de version ou de flag est le seul moyen de transformer une dégradation silencieuse en alerte. Sur un Llama dense, on pouvait s’en passer ; sur DeepSeek-V4, c’est de l’infrastructure.
Pour le reste de l’architecture de serving (disaggregation prefill Phase initiale d'une inférence LLM : tous les tokens du prompt sont traités d'un coup. Intensité arithmétique élevée, le GPU sature ses Tensor Cores. C'est l'inverse du decode qui suit. Approfondir dans le glossaire / decode Phase de génération autorégressive d'un LLM : un token est produit à la fois, en relisant tout le KV cache. Intensité arithmétique très basse, le GPU passe l'essentiel du temps à attendre la mémoire. Un service d'inférence réel est presque toujours dominé par le decode. Approfondir dans le glossaire , transport du KV cache, choix du parallélisme), DeepSeek-V4 hérite des mécanismes décrits dans notre état des lieux de la disaggregation, et son indexeur FP4 s’inscrit dans le paysage des dialectes FP4 que chaque runtime interprète à sa façon.
Conclusion
Le cas DeepSeek-V4 n’est pas une anomalie de jeunesse qu’une GA stable effacera. C’est le premier exemple grand public d’une tendance de fond : à mesure que les modèles compressent leur attention et leur KV cache pour rendre le contexte long abordable, la frontière entre « le modèle » et « le runtime » se brouille. Une part de l’exactitude migre du fichier de poids vers le chemin de code qui l’exécute, et cette part-là n’est pas dans le checkpoint, elle est dans la version, dans le kernel, dans le flag.
La quantification Réduction du nombre de bits codant chaque poids d'un modèle (de 16 bits vers 8, 4, voire moins). Elle divise l'empreinte mémoire d'autant, au prix d'une perte de précision contrôlée, sans changer le nombre de paramètres. Approfondir dans le glossaire nous avait habitués à un compromis lisible : moins de bits, un peu moins de précision, mesurable à l’avance. L’attention compressée introduit un compromis moins lisible : l’exactitude dépend de la correction d’implémentation du runtime, qui varie d’une version à l’autre. La prochaine génération de modèles (index encore plus agressifs, KV cache encore plus comprimé) poussera cette logique plus loin. La question de déploiement cessera d’être « est-ce que ça charge » pour devenir « est-ce que ça passe encore l’éval sur cette version, avec ces flags ». Le jour où cette éval tournera automatiquement à chaque déploiement, on aura simplement reconnu que, pour ces modèles, l’exactitude est devenue un paramètre d’exploitation.
Sources et méthode
Recettes + canari. Versions épinglées par runtime, le flag SGLANG_OPT_USE_COMPRESSOR_V2, et un test GSM8K qui casse le CI si l’exactitude régresse : deepseek-v4-serving.
Cet article s’appuie sur un dossier de recherche arrêté au 15 juin 2026. Étiquettes : fait vérifié = source primaire citable ; estimation crédible = cohérent mais non vérifié indépendamment ; hypothèse = raisonnement sans mesure.
DeepSeek-V4 : architecture et modèle
- Carte de modèle DeepSeek-V4-Pro : huggingface.co/deepseek-ai/DeepSeek-V4-Pro et build.nvidia.com/deepseek-ai/deepseek-v4-pro ; preview du 24 avril 2026 (fait vérifié). Variantes Pro (1,6 T / ~49 B actifs) et Flash (284 B / ~13 B actifs), contexte 1 M tokens.
- Attention hybride CSA (compression ×4 + Lightning Indexer FP4, sélection top-k de blocs) et HCA (compression ×128) : description d’architecture détaillée par le blog HuggingFace DeepSeek-V4 (facteurs ×4/×128, indexeur FP4 ReLU-scoré) en complément de la carte de modèle (fait vérifié quant à la description ; les facteurs exacts dépendent de la configuration).
- Coût relatif à 1 M tokens : ~27 % des FLOPs par token et ~10 % du KV cache vs DeepSeek-V3.2 (fait vérifié, chiffre constructeur, carte de modèle ; non mesuré indépendamment ici).
SGLang
- Notes de version : github.com/sgl-project/sglang/releases ; v0.5.12 (chemin DeepSeek-V4 day-0, HiSparse, DeepGEMM/FlashMLA), v0.5.13 (MTP à contexte parallèle, FlashMLA sparse) (fait vérifié).
- Correctif d’exactitude : PR #25646, livré en v0.5.12.post1 ;
SGLANG_OPT_USE_COMPRESSOR_V2=1restaure GSM8K de 0,825 à 0,960 (fait vérifié). - Bascule par défaut CUDA 13.0 + PyTorch 2.11 depuis la v0.5.11 (fait vérifié).
vLLM
- Notes de version : github.com/vllm-project/vllm/releases ; v0.22.0 (29 mai 2026 : fused MoE NVFP4 pour DeepSeek-V4, CUDA graph complet/par morceaux, MTP) ; v0.23.0 (mi-juin 2026 : 408 commits / 200 contributeurs, kernel d’attention TRTLLM-gen, EPLB Mega-MoE, métadonnées sparse découplées de V3.2, frontend Rust expérimental, tier KV secondaire object-store) (fait vérifié).
- Bascule de base par défaut vers CUDA 13.0 (13.0.2 pour s’aligner sur PyTorch 2.11.0) et C++20 requis, sur la série 0.21 ; changement cassant (fait vérifié, notes de version vLLM et docs d’installation GPU).
TensorRT-LLM
- Notes de version : github.com/NVIDIA/TensorRT-LLM/releases ; support DeepSeek-V4 réparti sur la série de release candidates 1.3 (rc15 : « new attention kernels, routing updates, tokenizer loading, AutoConfig registration » ; jusqu’à rc18 du 10 juin 2026). Aucune version stable 1.3.0 GA au 15 juin 2026 (fait vérifié).
Note d’exactitude
Les chiffres GSM8K cités (0,825 / 0,960) proviennent de l’intitulé du correctif SGLang et caractérisent une configuration précise (DeepSeek-V4 + HiSparse) ; ils ne se transposent pas tels quels à un autre runtime ou à une autre charge. La leçon est méthodologique (mesurer après chaque changement), pas la valeur absolue du score.
Image d’en-tête
- Image d’en-tête. Cartes NVIDIA H100 photographiées par 极客湾Geekerwan, Wikimedia Commons, sous licence CC BY 3.0, recadrée pour l’en-tête, image d’illustration du GPU datacenter sur lequel DeepSeek-V4 est servi.
_022.png){kind=link}