LLM Calculateur VRAM pour l'auto-hébergement
Auto-héberger un LLM signifie exécuter l'inférence sur du matériel que l'opérateur contrôle, 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 fonctionner ou non 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 est adaptée, la répartition de la mémoire entre les poids, le cache KV et la surcharge, ainsi que les modèles qu'un GPU ou un Mac donnés peuvent exécuter. Les formats de quantification et les largeurs de précision suivent la documentation des Transformers Hugging Face. 1
Voir notre méthodologie de calcul de la VRAM pour LLM auto-hébergé pour les mathématiques complètes derrière ces estimations.
Matériel pour l'auto-hébergement : GPUs et Apple Silicon
Deux chiffres décident du matériel. La capacité est la condition d'adéquation, et le décodage est limité par la bande passante mémoire, de sorte que les tokens par seconde évoluent à peu près avec le Go/s de la carte.
Les lignes ci-dessus échantillonnent chaque tier. Le calculateur référence 34 cartes au total, ajoutant la A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX, et la gamme AMD Instinct. Sur 24 à 32 Go, un modèle 70B nécessite une quantification lourde plus un contexte court, ou deux cartes. Un modèle 671B nécessite 640 Go (8×80 Go) comme minimum standard. La RTX PRO 6000 est la meilleure carte mono de classe station de travail, et son prix de vente a grimpé à environ 13 000 $ à la mi-2026, contre un prix conseillé de 8 565 $.2
Apple Silicon et mémoire unifiée : Sur Apple Silicon, le CPU et le GPU partagent un même pool mémoire, et le GPU adresse environ 75% de la RAM totale par défaut via Metal_recommendedMaxWorkingSetSize, un peu moins sur les Mac plus petits. La limite peut être relevée avec _sudo sysctl iogpu.wired_limit_mb=, en laissant de 8 à 16 Go pour macOS. 3 4 Un Mac de 128 Go expose environ 96 Go au GPU. Le M3 Ultra, jusqu'à 512 Go, expose environ 384 Go, suffisant pour un modèle de classe 400B en 4-bit avec marge KV sur un seul appareil, sans pénalité de réplication multi-GPU. 5 Cette voie mono-appareil pour les grands modèles est l'atout d'Apple, bien qu'AMD Strix Halo (128 Go) et NVIDIA DGX Spark (128 Go) proposent désormais également une grande mémoire unifiée à bas coût. 6
Moteurs de déploiement de LLM
Le choix du moteur de déploiement se fait selon la charge de travail plutôt que selon un meilleur outil universel. Les moteurs de production utilisent l'attention paginée et le traitement par lots continu pour de nombreux utilisateurs simultanés sur des GPUs de datacenter, tandis que les exécutables locaux ciblent un utilisateur unique sur un poste de travail, un portable ou un seul GPU. L'écart apparaît en charge. À 64 requêtes simultanées, vLLM a délivré environ 44 fois plus de tokens par seconde que llama.cpp, dont le temps jusqu'au premier token dépassait 3 minutes. Pour un seul utilisateur, les deux sont comparables. 7
Le calculateur modélise huit moteurs répartis entre les deux camps :
Au sein du tier 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 efficacement en coût pour InternLM, Qwen et DeepSeek. 8 Côté local, ExLlamaV2 avec TabbyAPI ajuste une largeur de bits fractionnaire moyenne pour remplir exactement une carte, et MLX utilise la mémoire unifiée d'Apple de sorte que la RAM totale constitue le budget. Hugging Face TGI est le seul sortant. 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 rencontrent ces moteurs à travers des applications utilisateur qui les encapsulent. Ollama, LM Studio et AnythingLLM fonctionnent tous sur llama.cpp (LM Studio également sur MLX), ajoutant des modèles en une commande, une API localhost compatible OpenAI et, pour AnythingLLM, du RAG documentaire sur PDF et bases de code. En étoiles GitHub comme indicateur approximatif d'adoption au 2026-07-11, Ollama en a 175 925, vLLM 85 979, tous deux open source, et AnythingLLM 63 120. Les 5 053 de LM Studio viennent de son dépôt CLI open source (_lmstudio-ai/lms) plutôt que de l'application propriétaire, ce qui sous-estime l'adoption réelle sur les postes de travail. 11 12 13 14
Un composant interactif de paysage mappe ces outils aux cas d'usage. Les intégrations et la large compatibilité reviennent à Ollama, les développeurs et hautes performances à vLLM, les applications de RAG locales à AnythingLLM, et l'expérimentation accessible 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 n'importe qui peut les télécharger, les modifier et les exécuter, généralement depuis Hugging Face. La frontière des modèles auto-hébergeables à la mi-2026 a largement dépassé l'ère Qwen2.5 et Llama-3 :
Les colonnes total et actif constituent la distinction déterminante. Les paramètres totaux déterminent la mémoire et le nombre de GPUs, 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 relicencié la famille sous Apache 2.0, et GPT-OSS embarque des experts MoE en MXFP4 natif. 15 16 17 18 19
Les modèles phares propriétaires (GPT-5.6 d'OpenAI, Gemini 3.1 Pro de Google, Claude Opus 4.8 d'Anthropic, Grok 4.5 de xAI) ne peuvent être téléchargés ni auto-hébergés ; ils sont uniquement accessibles via API, généralement derrière un point de terminaison compatible OpenAI. Un déploiement purement local renonce à ce que ces modèles font de mieux sur une tâche donnée. 20 21 22
Quantification et dimensionnement MoE
La quantification en 2026 consiste moins à arrondir les poids après l'entraînement qu'à distribuer des points de contrôle conçus directement en basse précision, ainsi que des choix architecturaux qui réduisent le cache avant même la quantification.
Points de contrôle natifs à basse précision : Les modèles ouverts de pointe sont de plus en plus livrés avec une quantification adaptée. GPT-OSS distribue ses experts MoE en MXFP4 (E2M1 avec une échelle partagée sur 8 bits, 4,25 bits par paramètre), de sorte que le 120B tient dans environ 63 Go, soit un GPU de 80 Go, là où une estimation naïve en BF16 exigerait environ 234 Go répartis sur trois GPUs. DeepSeek-V3 et R1 sont livrés en FP8 natif à environ 1 octet par paramètre. Les poids doivent être dimensionnés sur le dtype réel du point de contrôle, pas sur 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 indique 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 est de 8,5 bits (1,06 octet par paramètre), et non 8,0. Un calculateur basé sur le nombre de bits sous-dimensionne les poids d'environ 20% en Q4 et de 6% en Q8. Les quantifications IQ comme IQ4_XS (environ 4,25 bits) égalent désormais la qualité de Q4_K_M avec une taille plus réduite. 25
Quantification du cache KV : Réduire le dtype KV réduit linéairement l'ensemble du cache 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é globalement gratuite. L'INT4 le divise par quatre mais nécessite une évaluation. Dans vLLM, c'est un simple flag (_--kv-cache-dtype fp8). 26
L'attention comme économiseur de mémoire : L'attention latente multi-tête (MLA, utilisée par DeepSeek) met en cache un seul latent partagé de faible rang (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 le besoin nominal de 128 têtes. C'est ce qui permet à un modèle de 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 d'un facteur 10 à 40 par rapport à une estimation naïve tout-global. Ces caractéristiques sont fixes par famille d'architecture, pas des paramètres ajustables. 27
Déchargement et partitionnement : 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, en échangeant des tokens par seconde contre la possibilité même de fonctionner. 28 Le partitionnement divise un modèle sur plusieurs périphériques ou niveaux de mémoire, ce qui permet à un modèle de 671B de s'étendre sur un nœud de 8 GPUs. 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 avec les modèles propriétaires.
Résidence des données et conformité : Le transfert transfrontalier de données est le moteur de la conformité. Sous le 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 ajoute une deuxième couche, mais il est en cours de mise en œuvre progressive plutôt que pleinement en vigueur. À la mi-2026, les interdictions (applicables depuis le 2 février 2025) et les obligations pour les 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 à haut risque autonomes 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 Exécuter 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 le cas d'usage de l'IA souveraine pour la finance, la santé et le secteur public.
Coût et contrôle : L'auto-hébergement démarre cher, avec des GPUs grand public ou un petit serveur, mais l'inférence locale peut réduire les frais récurrents d'API pour les équipes générant 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 contrainte principale, et certaines charges de travail nécessitent encore de 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 CUDA et noyau, la surveillance et les mises à jour qu'un fournisseur cloud prendrait autrement en charge. La performance est de la responsabilité de l'opérateur, du batching et du partitionnement à 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é sur les tâches où ils excellent.
Ajouter comme source préféréeMéthodologie de calcul de la VRAM pour LLM auto-hébergé
L'empreinte mémoire d'un modèle est la somme de quatre termes calculés indépendamment et additionnés, pas un chiffre unique proportionnel au 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 correct pour une taille de modèle donnée mais faux pour les autres, car les trois termes évoluent différemment. 32
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 environ 1,0. Le piège est le 4-bit, qui ne fait pas 0,5 octet par paramètre. Le véritable INT4 groupé (GPTQ, AWQ) se situe entre 0,52 et 0,55, et GGUF Q4_K_M à environ 0,61 octet par paramètre (4,9 bits effectifs, pas 4,0). GGUF Q8_0 fait 8,5 bits (1,06 octet par paramètre), pas 8,0. Supposer 0,5 sous-estime un modèle 70B d'environ 8 Go, ce qui inverse un diagnostic d'adéquation. 33
Les mélanges d'experts dimensionnent chaque expert, pas les actifs : Tous les poids des experts restent résidents en VRAM même si seulement quelques-uns s'activent par token. Mixtral-8x7B nécessite environ 28 Go en Q4 pour l'ensemble des 46,7B paramètres, pas les 13B actifs. Les paramètres totaux déterminent la mémoire et le nombre de GPUs, et les paramètres actifs déterminent le calcul. Un calculateur qui dimensionne sur les paramètres actifs fait croire à tort que de grands modèles MoE sont adaptés.
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 par requête groupée (GQA), où de nombreuses têtes de requête partagent quelques têtes KV, donc n_kv_heads paires sont mises en cache, ce qui réduit le cache d'un facteur 4 (Llama-3-8B) à 8 (Llama-3-70B) par rapport à l'attention multi-tête complète. head_dim et n_kv_heads sont lus dans le config.json de chaque modèle plutôt que déduits de la taille cachée et du nombre de têtes, car des familles comme Gemma (head_dim 256) et Qwen3 (128) seraient autrement mal dimensionnées d'un facteur d'environ 2. Le cache croît linéairement avec la longueur du contexte et la taille du batch, et à contexte long, il rivalise ou dépasse les poids. Llama-3-8B met en cache 128 Kio par token, donc à 128k de contexte et 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. 34
La surcharge est un plancher, pas un pourcentage : La surcharge du framework est un plancher fixe par GPU (contexte CUDA et noyaux, environ 1 à 2 Go par GPU) plus une petite fraction limitée, pas une part des poids. Un forfait de 20% 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 exact, et le forfait de 20% constitue une estimation rapide. 35
Activations et le moteur de déploiement : Le terme d'activation est transitoire. Pendant le décodage, un token à la fois, il est petit et se fond dans le plancher de surcharge, mais le 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 mémoire, environ 10% avec la valeur par défaut de 0,90, et placent les poids et le KV dans le reste. Les exécutables non paginés (llama.cpp, Ollama) maintiennent un tampon de calcul fixe d'environ 1 à 2 Go à la place. Dimensionner les deux de la même manière induit un écart de quelques Go.
Plusieurs GPUs ne se divisent pas proprement : Deux cartes de 24 Go ne donnent pas 48 Go d'espace utilisable. En parallélisme de tenseur, 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 plus grande qu'une estimation mono-périphérique du même total. Cette pénalité 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 GPUs.
Les quatre termes interagissent à la frontière d'adéquation. Une configuration est considérée comme « Adaptée » lorsque la mémoire requise est inférieure ou égale à 90% de l'utilisable, « Serré » dans les 10% supérieurs de la capacité, et « Ne convient pas » au-dessus de l'utilisable. Les serveurs paginés retiennent 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 la longueur du contexte, pas le nombre de paramètres, décide de l'adéquation. La dernière ligne convient parce que les poids Q4 (~405 Go) restent sous les 640 Go à 8k de contexte. L'avantage de MLA se manifeste à contexte long, où il maintient le KV d'un modèle 671B suffisamment petit pour servir 128k.
Pour approfondir
- Quantification de 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 cloud de GPU
- LLM cloud vs LLM locaux
- Tarification des LLM : Top 15+ fournisseurs comparés
- Guide de fine-tuning de LLM pour les entreprises
_0__
FAQ
Un LLM auto-hébergé est un LLM utilisé pour des applications LLM qui s'exécute entièrement sur du matériel que vous contrôlez (comme votre ordinateur personnel ou un serveur privé), plutôt que de dépendre d'un service cloud tiers.
Les techniques incluent l'utilisation de frameworks comme llama.cpp, de bibliothèques comme les transformers d'Hugging Face, d'applications conviviales (Ollama, LM Studio), de la quantification des modèles (par exemple, GGUF, GPTQ) pour réduire les besoins en ressources, du parallélisme de modèle pour répartir de grands modèles sur plusieurs périphériques, et de moteurs d'inférence optimisés (comme vLLM).
Oui, des outils comme vLLM, Ollama et LM Studio peuvent exécuter des serveurs locaux capables de gérer plusieurs requêtes (souvent simultanées). Cela fonctionne de manière similaire aux APIs cloud, en utilisant souvent le batching pour l'efficacité.
Non, vous n'avez pas besoin d'autorisation d'accès externe ni de clés d'API d'un fournisseur pour un llm auto-hébergé. Puisque vous l'hébergez vous-même, vous avez un accès direct ; vous pouvez éventuellement configurer votre propre authentification pour votre serveur local si nécessaire.
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 VRAM pour l'auto-hébergement}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/self-hosted-llm}},
note = {AIMultiple. Consulté le 12 Juillet 2026}
}Liens de référence
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.