LLM Calculateur de VRAM pour l'auto-hébergement

Auto-héberger un LLM signifie exécuter l'inférence sur du matériel contrôlé par l'opérateur plutôt que via une API tierce, ce qui modifie le coût, le contrôle des données et le profil de confidentialité. Qu'un modèle puisse s'exécuter dépend de la mémoire.

Calculateur de compatibilité LLM

Le calculateur estime la VRAM ou la mémoire unifiée dont un modèle a besoin pour s'exécuter localement, en fonction du modèle, de sa précision, de la longueur du contexte et du matériel cible. Il indique si une configuration tient, la répartition de la mémoire entre les poids, le cache KV et l'overhead, ainsi que les modèles qu'un GPU ou Mac donné peut exécuter. Les formats de quantification et les largeurs de précision suivent la documentation Transformers de Hugging Face. ¹

Consultez notre méthodologie de calcul de la VRAM pour un LLM auto-hébergé pour toutes les mathématiques derrière ces estimations.

Matériel pour l'auto-hébergement : GPUs et Apple Silicon

Deux chiffres déterminent le matériel. La capacité est le critère d'ajustement, et le décodage est limité par la bande passante mémoire, de sorte que les tokens par seconde évoluent approximativement avec le GB/s de la carte.

Les lignes ci-dessus donnent un aperçu de chaque niveau. Le calculateur intègre 34 cartes au total, en ajoutant l'A100, la L40S, la RTX A6000, la AMD Radeon RX 7900 XTX et la gamme AMD Instinct. Avec 24 à 32 Go, un modèle 70B nécessite une forte quantification et un contexte court, ou bien deux cartes. Un modèle 671B nécessite 640 Go (8×80 Go) comme minimum standard. La RTX PRO 6000 est la meilleure carte unique de classe station de travail, et son prix de vente est monté à environ $13 000 d'ici mi-2026, contre un PDSF de $8 565.²

Apple Silicon et mémoire unifiée : Sur les puces Apple Silicon, le CPU et le GPU partagent un même pool de mémoire, et le GPU adresse environ 75 % de la RAM totale par défaut via le recommendedMaxWorkingSetSize de Metal, un peu moins sur les Mac plus petits. Le plafond peut être relevé avec sudo sysctl iogpu.wired_limit_mb=, laissant 8 à 16 Go pour macOS. ^{3 4} Un Mac de 128 Go expose environ 96 Go au GPU. Le M3 Ultra, jusqu'à 512 Go, en expose environ 384 Go, assez pour un modèle de classe 400B en 4 bits avec de la marge KV sur un seul appareil, sans la taxe de réplication multi-GPU. ⁵ Cette voie à appareil unique pour les grands modèles est l'avantage d'Apple, même si AMD Strix Halo (128 Go) et NVIDIA DGX Spark (128 Go) offrent désormais aussi une grande mémoire unifiée bon marché. ⁶

Moteurs d'inférence LLM

Le choix du moteur de service se divise selon la charge de travail plutôt que selon un seul meilleur outil. Les moteurs de service en production utilisent l'attention paginée et le batching continu pour de nombreux utilisateurs simultanés sur des GPU de centre de données, tandis que les runtimes locaux ciblent un seul utilisateur sur un ordinateur de bureau, un portable ou un GPU unique. L'écart apparaît sous charge. À 64 requêtes simultanées, vLLM a servi environ 44 fois plus de tokens par seconde que llama.cpp, dont le temps jusqu'au premier token a dépassé 3 minutes. Pour un seul utilisateur, les deux sont comparables. ⁷

Le calculateur modélise huit moteurs dans les deux camps :

Au sein du niveau production, RadixAttention de SGLang réutilise les préfixes entre requêtes, TensorRT-LLM fige son budget d'activation lorsque le moteur est construit, et LMDeploy sert W4A16 et MXFP4 de manière rentable pour InternLM, Qwen et DeepSeek. ⁸ Côté local, ExLlamaV2 avec TabbyAPI ajuste une largeur de bits moyenne fractionnaire pour remplir une carte exactement, et MLX utilise la mémoire unifiée d'Apple, si bien que la RAM totale constitue le budget. Hugging Face TGI est la seule sortie. Il est passé en mode maintenance en décembre 2025 et son dépôt GitHub a été archivé (lecture seule) le 21 mars 2026, les utilisateurs étant orientés vers vLLM, SGLang et llama.cpp. ^{9 10}

La plupart des gens découvrent ces moteurs via des applications grand public qui les enveloppent. Ollama, LM Studio et AnythingLLM s'appuient tous sur llama.cpp (LM Studio aussi sur MLX), ajoutant des modèles à une seule commande, une OpenAI-compatible localhost API et, pour AnythingLLM, du RAG documentaire sur PDF et bases de code. En prenant les étoiles GitHub comme indicateur approximatif d'adoption au 2026-07-11, Ollama compte 175 925 étoiles, vLLM 85 979, tous deux open source, et AnythingLLM 63 120. Les 5 053 de LM Studio proviennent de son dépôt CLI open source (lmstudio-ai/lms) plutôt que de l'application à code fermé, ce qui sous-estime l'adoption réelle sur ordinateur de bureau. ^{11 12 13 14}

Un composant de paysage interactif associe ces outils à des cas d'usage. Les intégrations et une large compatibilité reviennent à Ollama, les développeurs et les hautes performances à vLLM, les applications RAG locales à AnythingLLM, et l'expérimentation adaptée aux débutants à LM Studio.

Grands modèles de langage open source

Les modèles à poids ouverts publient leur architecture et leurs fichiers de poids, de sorte que tout le monde peut les télécharger, les modifier et les exécuter, généralement depuis Hugging Face. La frontière auto-hébergeable de mi-2026 a largement dépassé l'ère Qwen2.5 et Llama-3 :

Les colonnes total et actifs constituent la distinction essentielle. Les paramètres totaux déterminent la mémoire et le nombre de GPU, et les paramètres actifs déterminent le calcul. DeepSeek-V4-Flash et GLM-5.2 sont arrivés en poids ouverts en 2026, Gemma 4 a placé la famille sous licence Apache 2.0, et GPT-OSS livre des experts MoE en MXFP4 natif. ^{15 16 17 18 19}

Les modèles propriétaires phares (GPT-5.6 d'OpenAI, Gemini 3.1 Pro de Google, Claude Opus 4.8 d'Anthropic, Grok 4.5 de xAI) ne peuvent pas être téléchargés ni auto-hébergés ; ils sont uniquement accessibles via API, généralement derrière un endpoint compatible OpenAI. Un déploiement exclusivement local renonce à ce que ces modèles font mieux sur une tâche donnée. ^{20 21 22}

Quantification et dimensionnement des MoE

La quantification en 2026 consiste moins à arrondir les poids après l'entraînement qu'à utiliser des checkpoints conçus dès le départ en faible nombre de bits, parallèlement à des choix d'architecture qui réduisent le cache avant même la quantification.

Checkpoints natifs à faible nombre de bits : Les modèles open source de pointe sont de plus en plus conçus pour la quantification. GPT-OSS livre ses experts MoE en MXFP4 (E2M1 avec une échelle 8 bits partagée, 4.25 bits par paramètre), de sorte que le 120B tient dans environ 63 Go, soit un 80 Go GPU, là où une estimation naïve en BF16 exigerait environ 234 Go répartis sur trois GPU. DeepSeek-V3 et R1 sont livrés en FP8 natif à environ 1 octet par paramètre. Les poids doivent être dimensionnés selon le dtype réel du checkpoint, et non selon le nombre de paramètres. ^{23 24}

Le piège des bits effectifs GGUF : Les fichiers GGUF mélangent les précisions, avec des échelles FP16 par bloc et des tenseurs d'embedding et de sortie non quantifiés, de sorte que le nom est un plancher plutôt que la taille réelle. Q4_K_M représente environ 4.9 bits effectifs (0.61 octet par paramètre), et non 4.0. Q8_0 représente 8.5 bits (1.06 octet par paramètre), et non 8.0. Un calculateur basé sur le nombre de bits sous-estime les poids d'environ 20 % en Q4 et 6 % en Q8. Les IQ-quants comme IQ4_XS (environ 4.25 bits) égalent désormais la qualité de Q4_K_M avec une taille plus petite. ²⁵

Quantification du cache KV : Réduire le dtype KV réduit l'ensemble du cache de manière linéaire et est indépendant de la précision des poids. Le KV en FP8 (e4m3) le divise par deux (Llama-3-8B à 128k, batch 1, de 16.0 Gio BF16 à 8.0 Gio FP8) avec une qualité pour ainsi dire gratuite. INT4 le divise par quatre mais nécessite une évaluation. Dans vLLM, c'est un seul flag (--kv-cache-dtype fp8). ²⁶

L'attention comme économiseur de mémoire: L'attention latente multi-têtes (MLA, utilisée par DeepSeek) met en cache un unique latent partagé de rang faible (environ 576 éléments par token et par couche) au lieu des clés et valeurs par tête, soit environ 30 fois plus petit que la lecture nominale à 128 têtes. C'est ce qui permet à un modèle 671B de servir un contexte de 128k avec environ 8.6 Gio de KV. L'attention à fenêtre glissante et locale-globale (Gemma 2 et 3, GPT-OSS, Llama 4) plafonne la plupart des couches à une fenêtre fixe au lieu du contexte complet, réduisant le KV à long contexte de 10 à 40 fois par rapport à une estimation naïve tout-globale. Ces caractéristiques sont fixes par famille d'architecture, et non des paramètres ajustables. ²⁷

Déchargement et sharding: Lorsque les poids dépassent la mémoire du GPU, le déchargement déplace les parties inactives, comme les experts MoE non utilisés, entre la mémoire du GPU et la RAM système plus lente, sacrifiant des tokens par seconde pour pouvoir s'exécuter. ²⁸ Le sharding répartit un modèle sur plusieurs appareils ou niveaux de mémoire, ce qui permet à un modèle 671B de s'étendre sur un nœud de 8 GPU. Les deux étendent la portée d'un matériel fixe au prix de la bande passante.

Avantages et compromis de l'auto-hébergement

Les arguments en faveur de l'auto-hébergement sont le contrôle des données, le coût à volume et la liberté de configuration. Les arguments contre sont le coût du matériel, la charge opérationnelle et l'écart face aux modèles propriétaires.

Résidence des données et conformité: Le transfert transfrontalier de données est le moteur de la conformité. Dans le cadre du RGPD, l'envoi de données personnelles hors de l'UE peut déclencher des garanties juridiques, des obligations contractuelles ou des restrictions. Le règlement européen sur l'IA (IA Act) ajoute une deuxième couche, mais il est en cours de mise en application plutôt que pleinement en vigueur. À la mi-2026, les interdictions (applicables depuis le 2 février 2025) et les obligations relatives aux modèles d'IA à usage général (GPAI) (depuis le 2 août 2025) s'appliquent déjà, tandis que les exigences à haut risque concernant la gestion des risques, l'auditabilité et la gouvernance sont différées au 2 décembre 2027 pour les systèmes autonomes à haut risque de l'annexe III et au 2 août 2028 pour les systèmes embarqués de l'annexe I, dans le cadre du paquet « Digital Omnibus » 2025-26. ^{29 30 31} L'exécution de l'inférence dans la juridiction, sur un réseau contrôlé, garde les données sensibles hors des mains d'un tiers, ce qui constitue l'argument de l'IA souveraine pour la finance, la santé et le secteur public.

Coût et contrôle: L'auto-hébergement commence cher, avec des GPU grand public ou un petit serveur, mais l'inférence locale peut réduire les API frais récurrents pour les équipes qui génèrent de gros volumes de requêtes. Il élimine également la dépendance vis-à-vis d'un fournisseur et les limites imposées sur la fenêtre de contexte, les paramètres d'inférence et l'intégration, et donne un accès direct aux poids pour le fine-tuning sur des données privées.

Les compromis: La mémoire du GPU est la limite contraignante, et certaines charges de travail nécessitent encore 16 à 48 Go de VRAM, hors de portée pour les petites équipes. Le déploiement ajoute la gestion des dépendances, le dépannage de CUDA et des noyaux, la supervision et des mises à jour qu'un fournisseur cloud gérerait autrement. La performance relève de la responsabilité de l'opérateur, du batching et du sharding jusqu'à l'utilisation du matériel. Et les modèles propriétaires les plus puissants restent uniquement accessibles via API, de sorte qu'un déploiement local accepte un écart de capacités sur les tâches où ils excellent.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Méthodologie de calcul de la VRAM pour un LLM auto-hébergé

L'empreinte mémoire d'un modèle est la somme de quatre termes calculés indépendamment puis additionnés, et non un chiffre unique mis à l'échelle du nombre de paramètres :

VRAM_total = Weights + KV cache + Activations + Overhead

L'erreur d'estimation la plus courante consiste à regrouper les trois derniers termes en une marge forfaitaire de 20 % sur les poids. C'est proche pour une taille de modèle et faux pour les autres, car les trois termes évoluent différemment. ³²

Poids: La mémoire des poids correspond aux paramètres multipliés par les octets par paramètre. BF16 et FP16 stockent 2.0 octets par paramètre, et FP8 et INT8 stockent environ 1.0. Le piège est le 4 bits, qui ne fait pas 0.5 octet par paramètre. Le vrai INT4 groupé (GPTQ, AWQ) se situe entre 0.52 et 0.55, et GGUF Q4_K_M est d'environ 0.61 octet par paramètre (4.9 bits effectifs, et non 4.0). GGUF Q8_0 est de 8.5 bits (1.06 octet par paramètre), et non 8.0. En supposant 0.5, on sous-estime un modèle 70B d'environ 8 Go, ce qui inverse un verdict d'ajustement. ²⁵

Le mélange d'experts dimensionne chaque expert, pas seulement les actifs: Tous les poids des experts restent résidents en VRAM même si seuls quelques-uns s'activent par token. Mixtral-8x7B nécessite environ 28 Go en Q4 pour la totalité des 46.7B paramètres, et non les 13B actifs. Les paramètres totaux déterminent la mémoire et le nombre de GPU, et les paramètres actifs déterminent le calcul. Un calculateur qui se base sur les paramètres actifs fait faussement tenir de grands modèles MoE.

Cache KV: Le cache clé-valeur est 2 x n_layers x n_kv_heads x head_dim x seq_len x batch x bytes_per_element. La plupart des modèles actuels utilisent l'attention à requêtes groupées (GQA), où plusieurs têtes de requête partagent quelques têtes KV, de sorte que les paires n_kv_heads sont mises en cache, ce qui réduit le cache de 4 fois (Llama-3-8B) à 8 fois (Llama-3-70B) par rapport à l'attention multi-têtes complète. head_dim et n_kv_heads sont lus dans le config.json de chaque modèle plutôt que dérivés de la taille cachée et du nombre de têtes, car des familles comme Gemma (head_dim 256) et Qwen3 (128) seraient sinon mal dimensionnées d'environ 2 fois. Le cache croît linéairement avec la longueur du contexte et la taille du batch, et en contexte long, il rivalise avec les poids ou les dépasse. Llama-3-8B met en cache 128 Kio par token, de sorte qu'à un contexte de 128k et en batch 1, un cache KV FP16 fait 16.0 Gio, soit l'équivalent des 16 Go de poids en BF16. Un cache KV en FP8 divise cela par deux. ³³

L'overhead est un plancher, pas un pourcentage: L'overhead du framework est un plancher fixe par GPU (contexte CUDA et noyaux, environ 1 à 2 Go par GPU) plus une petite fraction bornée, et non une part des poids. Un 20 % forfaitaire sous-estime les petits modèles, où le seul contexte CUDA peut dépasser 20 % d'un modèle de 6 Go, et surestime les grands, où un modèle de 140 Go n'a pas besoin de 28 Go de contexte. Le plancher par morceaux est le modèle précis, et le 20 % forfaitaire fonctionne comme estimation rapide. ³⁴

Activations et moteur de service: Le terme d'activation est transitoire. Pendant le décodage, un token à la fois, il est petit et se fond dans le plancher d'overhead, mais la phase de préremplissage traite tout le prompt d'un coup, de sorte que son pic d'activation évolue avec la taille du batch et la longueur du prompt. Le plancher lui-même dépend du moteur. Les serveurs paginés (vLLM, SGLang) réservent une part fixe de chaque carte via un paramètre d'utilisation de la mémoire, environ 10 % à la valeur par défaut de 0.90, et placent les poids et le KV dans le reste. Les runtimes non paginés (llama.cpp, Ollama) conservent plutôt un tampon de calcul fixe d'environ 1 à 2 Go. Dimensionner les deux de la même manière entraîne une erreur de quelques Go.

Plusieurs GPU ne se répartissent pas proprement: Deux cartes de 24 Go ne représentent pas 48 Go d'espace utilisable. En parallélisme tensoriel, les poids et le cache KV se répartissent sur les N cartes (W/N et KV/N), mais les activations, le contexte CUDA et les tampons de communication NCCL sont répliqués sur chaque carte, de sorte que l'empreinte totale est supérieure à l'estimation sur un seul appareil du même total. Cette taxe de réplication explique pourquoi un 70B nécessitant 43 Go de poids tient sur deux cartes de 24 Go avec un contexte court, et pourquoi le contrôle sûr est le total par GPU plutôt que le total divisé par le nombre de GPU.

Les quatre termes interagissent à la limite d'ajustement. Une configuration est considérée comme « Tient » lorsque la mémoire requise est inférieure ou égale à 90 % de la mémoire utilisable, « Juste » dans les 10 % supérieurs de capacité, et « Ne tient pas » au-dessus de la mémoire utilisable. Les serveurs paginés réservent déjà ces 10 % via le paramètre d'utilisation. Les exemples ci-dessous utilisent Llama-3 sur du matériel courant, avec llama.cpp sur les cartes grand public :

À 128k de contexte, le cache KV égale les poids, de sorte que c'est la longueur du contexte, et non le nombre de paramètres, qui décide de l'ajustement. La dernière ligne tient parce que les poids Q4 (~405 Go) restent sous 640 Go à 8k de contexte. L'avantage du MLA se manifeste en contexte long, où il garde le KV d'un modèle 671B assez petit pour servir 128k.

Pour aller plus loin

• Quantification LLM : BF16 vs FP8 vs INT4
• Moteurs d'inférence LLM : vLLM vs LMDeploy vs SGLang
• Benchmark de concurrence GPU : H100 vs H200 vs B200 vs MI300X
• Benchmark multi-GPU : B200 vs H200 vs H100 vs MI300X
• Top 60+ fournisseurs de GPU cloud
• LLM cloud vs LLM locaux
• Tarification LLM : Top 15+ fournisseurs comparés
• Guide de fine-tuning LLM pour les entreprises

FAQ

Citer cette recherche

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{LLM Calculateur de VRAM pour l'auto-hébergement}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/self-hosted-llm}},
  note   = {AIMultiple. Consulté le 31 Août 2026}
}

Journal des modifications

2 mises à jour

1. 202626 Jan

   Ajout d'une section, Confidentialité et conformité, à Avantages des LLM auto-hébergés.

2. 20254 Déc

   Ajout d'une liste des 4 meilleurs outils auto-hébergés à l'introduction.

Liens de référence

1.

Overview · Hugging Face

2.

RTX 5090 vs RTX PRO 6000 Blackwell: Consumer vs Pro GPU for AI (2026) | Spheron Blog

Spheron

3.

recommendedMaxWorkingSetSize | Apple Developer Documentation

4.

Adjust VRAM/RAM split on Apple Silicon · ggml-org/llama.cpp · Discussion #2182 · GitHub

5.

Apple reveals M3 Ultra, taking Apple silicon to a new extreme - Apple

Apple

6.

Personal AI Supercomputer Powered by Blackwell | NVIDIA DGX Spark

7.

llama.cpp vs. vLLM: Choosing the right local LLM inference engine | Red Hat Developer

Red Hat

8.

vLLM, Ollama, LM Studio, llama.cpp: Choosing the best LLM inference engine in 2026 [ Updated ] | BIZON

BIZON

9.

GitHub - huggingface/text-generation-inference: Large Language Model Text Generation Inference · GitHub

10.

Migrate from Hugging Face TGI to vLLM or SGLang on GPU Cloud: A 2026 Move-Off Guide | Spheron Blog

Spheron

11.

GitHub - lmstudio-ai/lms: LM Studio CLI · GitHub

12.

GitHub - ollama/ollama: Get up and running with Kimi-K2.6, GLM-5.2, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models. · GitHub

13.

GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs · GitHub

14.

GitHub - Mintplex-Labs/anything-llm: Stop renting your intelligence. Own it with AnythingLLM. Everything you need for a powerful local-first agent experience · GitHub

15.

DeepSeek V4 Ships 1M Context, Open-Weights

WinBuzzer

16.

Gemma 4: Our most capable open models to date

Google

17.

New Released - Overview - Z.AI DEVELOPER DOCUMENT

Mintlify

18.

Qwen 3.5 to 3.8: Alibaba Open-Weights Guide (2026)

Codersera Blogs

19.

Welcome GPT OSS, the new open-source model family from OpenAI!

Hugging Face

20.

GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI

21.

Introducing Claude Opus 4.8 \ Anthropic

22.

Introducing Grok 4.5 | SpaceXAI

xAI

23.

MXFP4 · Hugging Face

24.

OpenAI gpt-oss LLMs use MXFP4: smaller, faster, cheaper

theregister

25.

Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct

26.

Quantized KV Cache - vLLM

27.

Decoding Multi-Head Latent Attention (Part 1): The KV Cache Memory Bottleneck, Solved.

Vizuara’s Substack

28.

https://arxiv.org/pdf/2312.17238

29.

EU Artificial Intelligence Act | Up-to-date developments and analyses of the EU AI Act

30.

EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes - Gibson Dunn

Gibson Dunn & Crutcher, LLP

31.

EU AI Act Update: Timeline Relief, Targeted Simplification, and New Prohibitions | Inside Privacy

32.

A Practical Guide to LLM Inference at Scale

The Neural Maze

33.

The State of FP8 KV-Cache and Attention Quantization in vLLM | vLLM Blog

vLLM

34.

How LLM Inference Works (Prefill, Decode & the GPU Memory Wall)

Into AI

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et scientifique des données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire