Faire tourner un modèle de langage (LLM) sur sa propre machine séduit de plus en plus d’utilisateurs : confidentialité des données, absence d’abonnement, fonctionnement hors-ligne. Mais avant d’installer Ollama, LM Studio ou llama.cpp, une question revient sans cesse : de combien de mémoire et de stockage ai-je réellement besoin ? La réponse dépend surtout de deux paramètres : la taille du modèle et son niveau de quantification. Ce guide vous aide à dimensionner votre configuration sans surpayer ni rester bloqué.
La règle de base : taille des poids et quantification
Un LLM est défini par son nombre de paramètres, exprimé en milliards (7B, 13B, 70B…). Chaque paramètre occupe de la place en mémoire, et c’est la quantification qui détermine combien. En pleine précision (FP16), chaque paramètre pèse environ 2 octets ; un modèle 7B réclame alors près de 14 Go rien que pour ses poids. Heureusement, la quantification réduit cette précision : en 4 bits (formats Q4 courants), on tombe à environ un demi-octet par paramètre, soit grossièrement 4 Go pour un 7B.
La règle empirique la plus utile : en quantification 4 bits, comptez à peu près 0,5 à 0,7 Go de RAM par milliard de paramètres, puis ajoutez une marge pour le contexte (la fenêtre de tokens) et le système. Concrètement, un modèle 7B en Q4 tient confortablement dans 8 Go, un 13B demande plutôt 16 Go, et un 70B exige 48 à 64 Go. Plus la quantification est agressive, plus l’empreinte mémoire baisse, au prix d’une légère perte de qualité, souvent imperceptible sur les tâches courantes.
RAM, VRAM ou unified memory : où vivent les poids ?
Tout dépend de votre matériel. Sur un PC classique sans carte graphique dédiée, le modèle est chargé en RAM système et calculé par le processeur : l’inférence fonctionne, mais reste lente. Avec une carte graphique, ce sont les poids logés dans la VRAM qui comptent : si le modèle dépasse la mémoire du GPU, une partie déborde sur la RAM, ce qui ralentit fortement. Sur les Mac Apple Silicon, la mémoire unifiée partagée entre CPU et GPU change la donne et permet de charger de gros modèles dans une seule réserve mémoire.
Le bon réflexe consiste à viser une machine où le modèle visé tient entièrement dans la mémoire la plus rapide disponible. Un 7B ou 13B doit idéalement loger dans la VRAM ou la mémoire unifiée ; dès qu’on déborde, les performances s’effondrent. Si vous hésitez, partez sur 16 Go pour démarrer sereinement avec les petits modèles, et 32 Go si vous voulez de la marge pour des modèles intermédiaires et un contexte étendu.
Le swap : filet de sécurité, pas solution
Quand la mémoire physique manque, le système bascule sur le swap, une zone du disque utilisée comme rallonge de mémoire. En théorie, cela permet de charger un modèle trop gros ; en pratique, l’inférence devient si lente qu’elle en perd presque tout intérêt, car un SSD reste des dizaines de fois plus lent que la RAM. Le swap dépanne pour tester ponctuellement un modèle, mais ne doit jamais constituer votre stratégie principale. Mieux vaut choisir un modèle plus petit ou plus quantifié qui tient en mémoire.
Quel stockage prévoir pour vos modèles
Côté disque, l’enjeu n’est pas la vitesse pure mais le volume. Les fichiers de modèles sont lourds : quelques gigaoctets pour un petit modèle quantifié, plusieurs dizaines pour les gros. En accumulant variantes et niveaux de quantification, on remplit vite un SSD. Prévoyez un SSD NVMe d’au moins 1 To si vous comptez collectionner plusieurs modèles ; le format NVMe accélère surtout le chargement initial en mémoire, pas l’inférence elle-même.
En résumé, dimensionnez d’abord la mémoire selon le plus gros modèle que vous voulez vraiment utiliser, en appliquant la règle des 4 bits, puis assurez-vous d’un stockage généreux pour héberger votre collection. Une machine équilibrée pour l’usage local courant tourne autour de 16 à 32 Go de mémoire et d’un SSD NVMe d’1 To : de quoi explorer la plupart des modèles ouverts sans frustration.
Notre sélection
PLAN
PLAN
