Illustration technique pour Combien de RAM faut-il pour faire tourner un LLM en local ?
IA locale

Combien de RAM faut-il pour faire tourner un LLM en local ?

Pour un petit modèle quantifié, 16 Go peuvent suffire ; 32 Go apportent du confort, 64 Go ouvrent les modèles intermédiaires et 128 Go visent les charges lourdes.

La mémoire se dimensionne en additionnant le modèle quantifié, le cache de contexte, le moteur d’inférence et les autres services. Un fichier de 20 Go ne garantit donc pas qu’un mini-PC de 24 Go le chargera correctement. Garder 20 à 30 % de marge évite le swap et les ralentissements difficiles à diagnostiquer.

Les repères par capacité

MémoireUsage raisonnableVigilance
16 GoPetits modèles quantifiés, contexte courtTrès peu de marge pour le système
32 GoModèles compacts, RAG léger, usage personnelLes variantes lourdes restent hors portée
64 GoModèles intermédiaires, contexte plus long, plusieurs outilsLe backend et la bande passante comptent encore
128 GoGros modèles quantifiés, index volumineux, serveur partagéLe chargement possible ne garantit pas un bon débit

Ces seuils décrivent une enveloppe, pas une liste universelle de modèles. Deux quantifications du même LLM peuvent différer de plusieurs gigaoctets. Vérifiez toujours la taille exacte du fichier que vous comptez utiliser.

Calculer la marge utile

Commencez par la taille du modèle sur disque, puis ajoutez la mémoire du cache de contexte et une réserve pour le système. Le cache augmente avec la fenêtre de contexte et le nombre de conversations simultanées. Un serveur RAG doit aussi conserver son moteur d’indexation, sa base vectorielle et parfois un modèle d’embeddings. Sur une machine partagée, chaque requête concurrente peut modifier l’équilibre.

Un repère prudent consiste à ne pas planifier l’achat à 100 % de la capacité annoncée. Sur 32 Go, garder 6 à 8 Go libres protège Windows ou Linux et les services de fond. Sur 64 Go, une réserve de 12 à 16 Go laisse davantage de souplesse pour le contexte et le RAG. Cette marge vaut mieux qu’un calcul théorique au mégaoctet près.

RAM, VRAM et mémoire unifiée

Une carte NVIDIA utilise d’abord sa VRAM dédiée. Si le modèle la dépasse, un partage avec la RAM peut devenir beaucoup plus lent selon le moteur. Un APU Ryzen AI Max ou une puce Apple accède à une mémoire unifiée, mais le système et le GPU se la partagent. AMD permet par exemple de réserver une part de la mémoire comme mémoire graphique sur certaines configurations 128 Go ; cette réservation ne crée pas de capacité supplémentaire.

Les mini-PC à DDR5 remplaçable sont plus faciles à faire évoluer, tandis que la mémoire LPDDR5X soudée offre souvent davantage de bande passante. Le choix oppose donc évolutivité et débit, pas simplement un nombre de gigaoctets. Notre guide RAM, VRAM et mémoire unifiée détaille ces architectures.

Schéma de calcul de la mémoire nécessaire à un LLM local
Le modèle n’est qu’une partie de l’empreinte : le contexte et la marge système restent indispensables.

Le contexte change le calcul

Une fenêtre de contexte longue permet d’envoyer davantage de documents ou de code, mais elle augmente le cache mémoire. Régler 128 000 tokens parce que le modèle l’accepte sur le papier peut réduire fortement la marge et le débit. Pour un assistant personnel, 8 000 à 16 000 tokens suffisent souvent ; augmentez seulement après avoir mesuré l’usage réel.

Le RAG ne demande pas nécessairement un contexte maximal. Il vaut mieux sélectionner quelques passages pertinents que charger une bibliothèque entière dans chaque requête. Cette discipline réduit la mémoire, le temps avant le premier token et le risque que le modèle se perde dans des informations secondaires.

Éviter le swap trompeur

Quand la mémoire physique est pleine, le système peut déplacer des pages vers le SSD. Le modèle semble alors chargé, mais les réponses deviennent irrégulières et le stockage travaille en continu. Sur macOS, la mémoire compressée et le swap peuvent masquer le dépassement ; sur Windows et Linux, surveillez la mémoire engagée ainsi que l’activité disque.

Un SSD rapide limite la catastrophe sans remplacer la RAM. Si la machine swappe dès le chargement, réduisez le contexte, choisissez une quantification plus compacte ou fermez les services concurrents. Ajouter de la mémoire reste utile uniquement lorsque les modules sont remplaçables.

Choisir la bonne configuration

Pour découvrir Ollama avec de petits modèles, 32 Go constituent un point de départ confortable. Pour coder, utiliser un RAG personnel et conserver plusieurs modèles, 64 Go offrent une meilleure durée de vie. Les 128 Go se justifient pour un gros modèle quantifié, un serveur multi-utilisateur ou un laboratoire qui accepte un prix bien supérieur.

Comparez ensuite le backend et la bande passante. Une machine 128 Go mal accélérée peut répondre moins vite qu’un mini-PC 64 Go mieux pris en charge. Voir la sélection de mini-PC IA par capacité permet de relier ces seuils à des variantes exactes.

Voir la fiche de sélection des mini-PC IA

Sources techniques

Les repères s’appuient sur la documentation de contexte Ollama, les caractéristiques de la plateforme Ryzen AI Max+ 395 et la documentation du projet llama.cpp. Mesurez toujours votre modèle et votre contexte précis.

Questions fréquentes

16 Go suffisent-ils pour Ollama ? +
Oui pour de petits modèles quantifiés et un contexte court, mais la marge devient vite étroite avec Windows, un navigateur et un RAG.
Pourquoi un fichier de 20 Go ne tient-il pas dans 24 Go de RAM ? +
Le moteur, le cache de contexte, le système et les services parallèles consomment aussi de la mémoire.
64 Go sont-ils plus rapides que 32 Go ? +
Pas automatiquement. La capacité évite surtout le dépassement ; le processeur, le GPU, le backend et la bande passante déterminent le débit.
Le swap permet-il de charger un plus gros modèle ? +
Il peut éviter un arrêt immédiat, mais les accès SSD rendent généralement l’inférence lente et irrégulière.
Atelier Mini-PC IA
ÉCRIT PAR

Atelier Mini-PC IA

Je transforme les fiches techniques, documentations et limites logicielles des mini-PC en décisions compréhensibles. Je vérifie la mémoire, les backends, la connectique et les compromis avant toute recommandation — les TOPS seuls ne gagnent jamais le match.