Personne ne parle de RAM. Chaque regret local-LLM vient de la RAM.

Entrez dans n’importe quel fil sur les LLM locaux : les disputes portent sur les GPU. Benchmarks VRAM, cartes à 24 Go, CUDA contre ROCm, la 3060 est-elle encore la carte du peuple. Pendant ce temps, le chiffre qui décide réellement si votre modèle tourne est dans l’autre emplacement, sans benchmark ni marketing : la quantité de RAM de la machine.

La VRAM vend le rêve. La RAM décide si le modèle démarre du tout — et combien de contexte survit quand il tourne.

J’ai testé sur la machine devant moi en écrivant ce billet : un desktop Ryzen avec 32 Go de RAM et une GeForce RTX 3060 de 12 Go de VRAM. J’ai tiré llama3.1:8b — la page de téléchargement annonce 4,9 Go. Regardez ce qu’il a réellement réservé :

Tout le débat tient dans cet écran. Un « modèle de 4,9 Go » a réservé 7,0 Go avant de répondre à un seul prompt — une taxe de contexte de 43 % — et s’est accaparé 7 963 des 12 288 MiB de VRAM. Les poids n’ont jamais été le budget. Le contexte l’était.

D’où viennent les gigaoctets en plus

Les notes mémoire de llama.cpp détaillent l’arithmétique que les pages de téléchargement omettent : mémoire totale = poids du modèle + cache KV + buffer de calcul. Seul le premier terme est constant. Le cache KV grandit linéairement avec la longueur du contexte, le buffer de calcul avec le batch. Ollama emballe llama.cpp, la même loi s’applique — voilà pourquoi ollama ps a affiché 7,0 Go pour un tag de 4,9 Go à 32 000 tokens de contexte, tout en VRAM.

Un modèle quantisé n’est pas un compromis. C’est l’aveu que la mémoire a toujours été le vrai budget.

C’est aussi pourquoi l’échelle de quantification GGUF existe. Le Q4 n’est pas une religion ; c’est ce qui fait atterrir l’arithmétique mémoire dans le matériel que les gens possèdent. Et c’est pourquoi deux configurations « identiques » en 8B ne se ressemblent en rien : même modèle, longueur de contexte différente, machines différentes.

Le tableau que personne ne consulte avant d’acheter

Trois classes de modèles, les deux types de mémoire, une carte de 12 Go et 32 Go de RAM — la configuration que des milliers de développeurs ont réellement :

Classe de modèle (Q4)	Téléchargement	Chargé + ctx 32k	Sur 12 Go de VRAM	Sur 32 Go de RAM
7–8B (llama3.1:8b)	4,9 Go	7,0 Go (mesuré)	100 % GPU, ~8 Go utilisés	à peine remarqué
13–14B (qwen2.5:14b)	9,0 Go	~12 Go	l’offload commence	très bien
27–32B (gemma3:27b)	17 Go	~20 Go et plus	le CPU tire le poids	la seule raison pour laquelle ça tourne

Relisez les deux dernières lignes. En VRAM seule, un 14B avec un vrai contexte est déjà un travail d’offload partagé, et un 27B est impossible. Sur 32 Go de RAM, les deux sont juste lents. Cette différence — entre impossible et lent — est toute la différence pratique entre VRAM et RAM. Si ça tient en VRAM, c’est rapide. Si ça tient en RAM, ça marche. Si ça ne tient nulle part, vous swappez sur NVMe et le temps perd tout sens.

L’offload passe par le PCIe, et la FAQ Ollama est claire sur le coût : les couches qui ne tiennent pas sur le GPU tournent sur le CPU, et le débit chute vite quand la part GPU rétrécit. Personne ne choisit ce compromis consciemment. Il arrive en silence, une couche à la fois, et le symptôme est juste « les modèles locaux, c’est surestimé ».

Le registre honnête

Ce qui a cassé ou surpris en écrivant ce billet, dans l’ordre :

1. Le chiffre de 43 %. J’attendais que le 8B occupe « à peu près sa taille de fichier ». Il a réservé 7,0 Go contre 4,9 Go téléchargés. Si ça m’a surpris, ça surprend tous ceux qui lisent des fiches techniques au lieu de ps.
2. La session de capture. Ma première capture a attrapé la mauvaise fenêtre. La deuxième a marché, c’est celle ci-dessus. Les preuves sont un flux de travail, pas une ambiance — et un cycle pull → capture → ollama rm garde le disque honnête.
3. Ce qui n’a pas cassé : le GPU n’a jamais débordé. 8B à 32k de contexte sur 12 Go, c’est réellement confortable. La carte va bien. C’est le discours autour de la carte qui est mal calibré.

Rien de tout ça ne dit que les GPU ne comptent pas — la ligne 100 % GPU dans la capture, c’est pourquoi la génération a paru instantanée. Ça veut dire que le GPU est la deuxième question. Le choix Ollama ou llama.cpp vient après savoir ce qui tient, pas avant.

La règle à retenir

RAM nécessaire = fichier du modèle + cache KV pour votre vrai contexte + 4 Go pour rester un ordinateur. Pour du 7–8B en Q4, 16 Go sont confortables. Pour du 14B–32B, 32 Go cessent d’être un luxe et deviennent l’essentiel. Achetez la VRAM pour la vitesse voulue au contexte utilisé ; achetez la RAM pour tout ce que vous chargerez un jour.

Un coup d’œil à ollama ps, et la religion des fiches techniques s’éteint tranquillement.

Alors, deux questions. Quand vous spécifiez votre prochaine machine, vous achetez de la VRAM pour les benchmarks que vous afficherez — ou de la RAM pour les modèles que vous faites réellement tourner ? Et honnêtement : combien de modèles tirés à 2 h du matin avez-vous supprimés avant le petit-déjeuner ? C’est mon cas ce soir, en plein billet. Dites-moi que je ne suis pas le seul dans les commentaires — et de quel côté de la ligne VRAM/RAM se trouve votre machine.