DeepSeek V4.1 auto-hébergé : VRAM, GPU et vLLM en 2026

TL;DR

DeepSeek V4.1 auto-hébergé demande environ 510 Go de mémoire GPU pour le checkpoint officiel FP8/FP4 : prévoyez un serveur 8x H200 ou quatre B200. Servez-le avec une image nightly de vLLM ou l’image preview de SGLang, car aucune version stable ne le prend en charge. La licence MIT autorise l’usage commercial et aucune donnée ne part chez DeepSeek.

Qu’est-ce que DeepSeek V4.1 Flash ?

DeepSeek V4.1 Flash est un modèle Mixture-of-Experts multimodal à poids ouverts, publié sur Hugging Face le 10 septembre 2026. Il compte 552B paramètres de backbone, en active 8B par token en prefill et 16B en décodage, lit images et texte, produit du texte et gère jusqu’à un million de tokens de contexte. Les poids sont sous licence MIT.

La fiche du modèle décrit un Causal Encoder-Decoder : 40 couches Transformer réparties en 20 couches d’encodeur et 20 couches de décodeur. Le cache KV global du décodeur est projeté depuis la sortie de l’encodeur, d’où les 8B paramètres seulement en prefill. S’y ajoute Engram, une mémoire conditionnelle de 196B paramètres interrogée par n-grammes de tokens. Vous devez la charger entièrement, même si chaque token n’en lit que quelques lignes.

Caractéristique	Valeur	Source
Paramètres du backbone	552B	Fiche du modèle
Paramètres actifs	8B prefill, 16B décodage	Fiche du modèle
Mémoire Engram	196B paramètres	Fiche du modèle
Experts	1 partagé + 384 routés, 6 actifs	Fiche, config.json
Contexte	1 048 576 tokens (YaRN facteur 16 sur 65 536)	config.json
Modalités	Image et texte en entrée, texte en sortie	Fiche du modèle
Format des poids	FP8 dense (blocs 32x32, échelles UE8M0), experts FP4	config.json
Cache KV global	890 octets par token	Fiche du modèle
Licence	MIT (dépôt et poids)	Fiche du modèle

Les benchmarks de la fiche, mesurés à effort de raisonnement maximal, donnent 74,2 sur DeepSWE v1.1 et 90,6 sur Terminal-Bench 2.1. Ce sont des chiffres éditeur. Deux détails comptent avant le déploiement : la publication ne fournit pas de template de chat Jinja, seulement un encodeur Python de référence, et la fiche recommande temperature=1.0, top_p à 0,95 et un budget max_tokens d’au moins 256K pour le raisonnement.

Combien de VRAM faut-il pour DeepSeek V4.1 Flash ?

Le checkpoint officiel compte 48 fichiers safetensors pour 510,3 Go au total (475,3 Gio). C’est le plancher pour les poids en mémoire GPU. Il faut y ajouter le cache KV, les activations, les CUDA graphs et le tampon de l’indexeur d’attention sparse. La recette vLLM retient un minimum de 614 Go, soit la taille du checkpoint multipliée par 1,2.

Nous avons obtenu les 510,3 Go en additionnant la taille des fichiers du dépôt Hugging Face (révision dba1be0a). La recette vLLM détaille : experts MXFP4, experts de draft compris, 259,5 Gio ; tables Engram en FP8 183,1 Gio ; échelles de bloc UE8M0 21,9 Gio ; attention et projections denses 6,9 Gio ; embedding et tête LM 3,9 Gio. Engram est la surprise : plus d’un tiers du checkpoint.

Variante de précision	Éditeur	Poids	Statut
FP8 dense natif + experts MXFP4	DeepSeek	510,3 Go (mesuré)	Officiel, base des recettes
Experts NVFP4	NVIDIA	environ 492 Gio selon la fiche NVIDIA	Quantification NVIDIA officielle, Blackwell uniquement
BF16 intégral	personne	environ 1 526 Go (estimation)	Non publié, sans intérêt
GGUF 2 à 4 bits	communauté seulement	variable	Pas de support llama.cpp en amont

La ligne BF16 est notre estimation : 557,2B entrées d’experts, 196,6B pour Engram, 7,4B paramètres denses et 2,0B d’embedding font environ 763B valeurs, soit à 2 octets près de 1,53 To. Personne ne le publie, et convertir en BF16 un modèle livré avec des experts FP4 n’apporte rien. Le checkpoint NVFP4 de NVIDIA n’économise pas de mémoire non plus : NVIDIA indique qu’il passe d’environ 476 Gio à 492 Gio à cause d’échelles plus fines. Son intérêt est le calcul W4A4 sur Blackwell.

Estimation du cache KV. La fiche donne 890 octets de cache KV global par token. Notre calcul, hors fenêtre glissante fixe de 128 tokens par couche et hors surcoût d’exécution :

Un contexte complet de 1 048 576 tokens : 1 048 576 x 890 o = 0,93 Go (estimation)
32 requêtes simultanées de 128K tokens : 32 x 131 072 x 890 o = 3,7 Go (estimation)
256 requêtes simultanées de 32K tokens : 256 x 32 768 x 890 o = 7,5 Go (estimation)

Le cache KV n’est donc pas la contrainte, les tampons d’exécution si. La recette vLLM précise que l’indexeur alloue un tampon de logits égal au nombre maximal de tokens par batch multiplié par la longueur maximale : 8 192 x 1M x 2 octets, soit exactement 16 Gio. Prévoyez au moins 100 Go au-delà des poids pour un serveur de production. Ce chiffre est notre estimation et rejoint le minimum de 614 Go de la recette.

Quelle configuration GPU choisir ?

Le choix sûr est un serveur 8x H200 : 1 128 Go de HBM, validé par vLLM et SGLang. Quatre B200 (720 Go) sont également validés. Un serveur 8x H100 (640 Go) ne fonctionne qu’avec vLLM, et seulement si Engram est déchargé en mémoire hôte. Quatre H200 restent sous le minimum de la recette.

Les capacités mémoire viennent des fiches NVIDIA : H100 80 Go, H200 141 Go, DGX B200 1 440 Go pour 8 GPU (180 Go chacun), RTX PRO 6000 Blackwell 96 Go.

Configuration	Mémoire GPU totale	Reste après 510,3 Go de poids	Statut des moteurs (19/09/2026)
8x H200 141 Go	1 128 Go	617,7 Go	Validé dans vLLM et SGLang (TP8)
4x B200 180 Go	720 Go	209,7 Go	Validé dans vLLM et SGLang (TP4)
8x RTX PRO 6000 96 Go	768 Go	257,7 Go	Absent des recettes officielles, retours communautaires seulement
8x H100 80 Go	640 Go	129,7 Go	vLLM seulement, avec déchargement CPU d’Engram
4x H200 141 Go	564 Go	53,7 Go	Sous le minimum de 614 Go, déconseillé
4x RTX PRO 6000 96 Go	384 Go	ne tient pas	Non

Le cas H100 mérite une explication. La recette vLLM qualifie 8x 80 Go de plus petit nœud NVIDIA capable de servir ce checkpoint, et uniquement avec --engram-config '{"cpu_offload":true}', qui place les 183 Gio de tables Engram en mémoire hôte épinglée. Votre serveur doit donc disposer d’autant de RAM libre en plus. SGLang ne mentionne pas du tout le H100.

Pour la RTX PRO 6000, le calcul passe avec huit cartes, mais aucune recette officielle ne la marque comme validée. Le suivi des issues de vLLM contient un retour d’expérience communautaire sur 8x RTX PRO 6000 et un bug distinct de débit de décodage très faible sur cette configuration. Considérez-la comme un montage de laboratoire, pas comme une cible de production.

Notre recommandation : 8x H200 si vous restez sur Hopper, 4x B200 si vous obtenez du Blackwell. Les deux laissent de la marge pour les longs contextes et le batching sans astuce de déchargement, que l’hébergement des données se fasse dans votre salle serveur ou chez un hébergeur en colocation en France.

Comment servir le modèle avec vLLM ou SGLang ?

Aucune version stable des deux moteurs ne prend encore en charge DeepSeek V4.1 Flash. La recette vLLM exige la version 0.30.0, pas encore publiée, et renvoie vers l’image vllm/vllm-openai:nightly. Le cookbook SGLang indique que le support “has not shipped in an SGLang release yet” et utilise l’image preview lmsysorg/sglang:dev-dsv41.

La dernière version de vLLM, v0.29.0, est sortie le 9 septembre 2026, la veille du modèle. L’architecture est arrivée dans main le 10 septembre avec la PR 56228. En production, épinglez un digest nightly précis, car ces images changent chaque jour.

vLLM sur 8x H200. Les arguments viennent de la recette vLLM (arguments de base, parsers, option texte seul). À lancer dans le conteneur vllm/vllm-openai:nightly :

export VLLM_ENGINE_READY_TIMEOUT_S=3600
vllm serve deepseek-ai/DeepSeek-V4.1-Flash \
  --tensor-parallel-size 8 \
  --tokenizer-mode deepseek_v41 \
  --reasoning-parser deepseek_v41 \
  --tool-call-parser deepseek_v41 --enable-auto-tool-choice \
  --language-model-only

Retirez --language-model-only si vous avez besoin d’entrées image. Sur 8x H100, la recette ajoute --engram-config '{"cpu_offload":true}' --max-num-batched-tokens 4096 --gpu-memory-utilization 0.92 ainsi que les variables VLLM_USE_V2_MODEL_RUNNER=1 et PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. Un piège signalé par la recette : dans vLLM, le mode thinking est actif à l’effort 50 si la requête n’envoie aucun réglage de raisonnement. Un petit max_tokens renvoie alors un contenu vide.

SGLang sur 8x H200. Voici la cellule haut débit validée des configurations de lancement SGLang :

docker run --gpus all --shm-size 32g -p 30000:30000 --ipc=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  lmsysorg/sglang:dev-dsv41 \
  sglang serve --trust-remote-code \
  --model-path deepseek-ai/DeepSeek-V4.1-Flash \
  --tp 8 --ep-size 8 --mem-fraction-static 0.8 \
  --attention-backend dsv4 --moe-runner-backend flashinfer_mxfp4 \
  --max-running-requests 256 --cuda-graph-max-bs-decode 64 \
  --reasoning-parser auto --tool-call-parser auto \
  --host 0.0.0.0 --port 30000

Sur B200, B300 et GB300, le cookbook utilise --tp 4 --ep-size 4 et déconseille de forcer les backends. Dans SGLang, le mode thinking est désactivé par défaut tant qu’une requête n’envoie pas reasoning_effort. Comme --trust-remote-code exécute du code du dépôt, épinglez la révision du modèle que vous avez vérifiée.

Test de fumée (tiré de la recette vLLM, port 8000 ; 30000 pour SGLang). La bonne réponse est 323 :

curl http://localhost:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"deepseek-ai/DeepSeek-V4.1-Flash","messages":[{"role":"user","content":"What is 17*19? Return only the integer."}]}'

Ollama et llama.cpp. Pas une option en local aujourd’hui. La bibliothèque Ollama ne propose que deepseek-v4.1-flash:cloud, exécuté sur les serveurs d’Ollama : vos prompts quittent donc votre infrastructure. La conversion dans llama.cpp est une pull request ouverte et non fusionnée. Des GGUF communautaires existent sur Hugging Face, mais aucun ne vient de DeepSeek ni des mainteneurs de llama.cpp.

DeepSeek V4.1 Flash est-il disponible sur Bedrock ou Google Cloud en Europe ?

Non. Au 19 septembre 2026, Amazon Bedrock documente DeepSeek-R1, V3.1 et V3.2, mais aucun modèle V4 ou V4.1. L’offre DeepSeek managée de Google Cloud liste V3.2, V3.1, R1-0528 et OCR. Pour utiliser V4.1 Flash avec un hébergement des données dans l’UE, il faut l’héberger vous-même.

La liste des modèles Bedrock contient des fiches pour trois modèles DeepSeek. Le plus récent, DeepSeek-V3.2 (deepseek.v3.2), cite notamment eu-north-1 (Stockholm) et eu-west-2 (Londres) dans son tableau de régions, sans Paris ni Francfort, et sans profil géographique ou global. Côté Google Cloud, la page DeepSeek MaaS montre le même retard de génération. Les modèles que Bedrock garde réellement dans des régions UE sont recensés dans notre guide Amazon Bedrock. Kimi K3, autre modèle open-weight, n’est proposé sur Bedrock qu’avec un profil global, comme l’explique notre analyse de Kimi K3 sur Bedrock.

Option	V4.1 Flash disponible	Hébergement des données dans l’UE
GPU en propre ou colocation dans l’UE	Oui	Oui, sous votre contrôle
VM GPU dans une région cloud européenne, exploitées par vous	Oui, si la capacité H200 ou B200 est disponible	Oui, région au choix
Amazon Bedrock	Non disponible	sans objet
Google Cloud MaaS	Non disponible	sans objet
Tag cloud Ollama	Oui	Non documenté sur la page du modèle

Si vous cherchez plutôt une alternative managée avec Claude et un hébergement dans l’UE, notre guide Claude AWS Bedrock en Europe détaille les profils d’inférence européens.

Que changent le RGPD, la licence MIT et l’AI Act ?

Avec des poids ouverts auto-hébergés, aucun prompt ni aucune sortie n’atteint DeepSeek. Les poids sont un fichier, l’inférence tourne sur du matériel que vous contrôlez. Le traitement au sens du RGPD reste dans votre installation et chez vos sous-traitants existants. La licence MIT autorise l’usage commercial, la modification et la redistribution, à condition de conserver la mention de copyright.

RGPD. En auto-hébergement, les questions habituelles disparaissent pour la couche modèle : éditeur du modèle comme sous-traitant, transfert hors UE, entraînement sur les données clients. Reste votre propre infrastructure : contrat d’hébergement ou de colocation, contrôle d’accès, journalisation et conservation. Deux fuites à éviter : le tag Ollama :cloud ainsi que le chat et l’API de DeepSeek sont d’autres flux, qui envoient les prompts à un tiers. Notre comparatif Claude RGPD des hébergements applique la même logique aux offres Claude managées.

Licence. La fiche indique : “This repository and the model weights are licensed under the MIT License”. Le dépôt n’ajoute ni restriction d’usage, ni seuil d’utilisateurs, ni politique d’usage acceptable. Seule condition : joindre la mention de copyright et de licence si vous redistribuez les poids ou le code. La variante NVFP4 de NVIDIA est aussi sous MIT et déclarée “ready for commercial or non-commercial use”.

AI Act. Les obligations GPAI s’appliquent aux fournisseurs de modèles depuis le 2 août 2025, et l’application générale du règlement a commencé le 2 août 2026, selon la Commission européenne. DeepSeek est le fournisseur du modèle. Si vous construisez un assistant interne dessus, vous êtes fournisseur et déployeur de ce système d’IA, avec des obligations comme la maîtrise de l’IA et la transparence. Si vous affinez ou modifiez le modèle lui-même, vérifiez si des obligations de fournisseur du modèle vous reviennent. Notre article sur l’AI Act pour les entreprises utilisant des LLM explique les rôles.

FAQ

Combien coûte l’auto-hébergement de DeepSeek V4.1 Flash ?

Le poste principal est un serveur 8x H200 ou quatre B200, achetés ou loués. Nous n’avons pas vérifié de prix de location en Europe, nous n’en citons donc pas. À titre de comparaison, le tag cloud hébergé d’Ollama affiche au tarif de base 0,15 USD en entrée et 0,60 USD en sortie par million de tokens, mais vos données partent chez Ollama.

DeepSeek V4.1 Flash vs DeepSeek V4 Flash : qu’est-ce qui change pour l’hébergement ?

V4.1 Flash est bien plus lourd à charger : 552B de backbone plus 196B d’Engram, contre 284B de backbone pour V4 Flash selon la fiche. En échange, son cache KV global fait environ un quart de celui de V4 Flash, 890 octets par token. Il faut plus de mémoire GPU pour les poids, beaucoup moins pour les longs contextes.

Peut-on faire tourner DeepSeek V4.1 Flash sur un seul GPU ou une station de travail ?

Pas le checkpoint officiel. Avec 510,3 Go de poids, même le B200 à 180 Go exige trois cartes pour les seuls poids, et les recettes en utilisent quatre. Des quantifications communautaires en 2 bits existent, mais elles demandent des moteurs hors amont et perdent en précision. En production, comptez au minimum 4x B200 ou 8x H200.

L’auto-hébergement envoie-t-il des données en Chine ?

Non. L’inférence avec des poids téléchargés s’exécute entièrement sur vos serveurs et n’appelle pas DeepSeek. Les données ne sortent que si vous utilisez l’API ou le chat hébergés de DeepSeek, ou le tag cloud d’Ollama. Vérifiez tout de même que l’image de service et la supervision n’envoient pas de télémétrie vers l’extérieur.

Quel moteur choisir, vLLM ou SGLang ?

Les deux disposent de configurations H200 et B200 validées, et les deux sont en préversion pour ce modèle. Choisissez vLLM si vous devez utiliser 8x H100, seule sa recette couvre ce cas. Choisissez SGLang si vous voulez ses cellules basse latence validées avec le décodage spéculatif DSpark sur Blackwell. Dans les deux cas, épinglez les digests d’image.

DeepSeek V4.1 Flash est-il sur Amazon Bedrock à Paris ou Francfort ?

Non. Bedrock ne documente que DeepSeek-R1, V3.1 et V3.2, et le tableau de régions de V3.2 ne contient ni Paris ni Francfort. Aucune fiche V4.1 n’existe sur Bedrock au 19 septembre 2026.

Sources

Hugging Face : fiche du modèle deepseek-ai/DeepSeek-V4.1-Flash (19 septembre 2026)
Hugging Face : config.json de DeepSeek-V4.1-Flash (19 septembre 2026)
vLLM recipes : DeepSeek-V4.1-Flash (19 septembre 2026)
SGLang cookbook : DeepSeek-V4.1 (19 septembre 2026)
SGLang : configurations de lancement DeepSeek-V4.1 (19 septembre 2026)
Hugging Face : nvidia/DeepSeek-V4.1-Flash-NVFP4 (19 septembre 2026)
llama.cpp PR 28696 : conversion DeepSeek V4.1 (19 septembre 2026)
Ollama library : deepseek-v4.1-flash (19 septembre 2026)
NVIDIA H100, fiche technique (19 septembre 2026)
NVIDIA H200, fiche technique (19 septembre 2026)
NVIDIA DGX B200, spécifications (19 septembre 2026)
NVIDIA RTX PRO 6000 Blackwell Server Edition (19 septembre 2026)
Amazon Bedrock : modèles de fondation pris en charge (19 septembre 2026)
Google Cloud : modèles DeepSeek (MaaS) (19 septembre 2026)
Commission européenne : cadre réglementaire de l'AI Act (18 septembre 2026)