Ma première machine avec Ollama, c’était un Mac mini M2 16 Go. Les tutos promettaient « une commande pour pull un modèle, chatter en local » — j’ai lancé ollama run llama3.1:8b. Les cinq premières minutes, nickel. À la dixième, les ventilateurs hurlent, la pression mémoire dans le Moniteur d’activité passe au rouge, et changer d’onglet dans le navigateur, c’est comme traîner du béton.
Ce que j’ai appris : choisir 16, 24 ou 32 Go pour Ollama, ce n’est pas « plus gros = toujours mieux ». C’est savoir si modèle + fenêtre de contexte + apps en arrière-plan tiennent encore dans la mémoire unifiée. Cet article reprend les pièges que j’ai pris et le cadre que j’utilise quand des amis demandent quoi acheter — pour gaspiller moins d’argent et moins de nuits blanches.
Pourquoi la RAM mord avant « j’ai une GPU ? »
Sur les portables gaming Windows, on obsède sur la VRAM. Sur Mac Apple Silicon, CPU et GPU partagent un même pool de mémoire unifiée. Les poids Ollama, le cache KV à l’inférence et les caches macOS puisent tous dedans. Docs et benchmarks communautaires convergent : plus le modèle est gros et plus le contexte est long, plus la RAM part — la même ligne « Mémoire » du Moniteur d’activité.
Piège n°1 : compter les paramètres, ignorer la quantification. Un 7B en Q4_K_M peut demander ~4–5 Go ; Q8 ou FP16, ça double. Piège n°2 : oublier l’OS — macOS, navigateur, messagerie, IDE prennent facilement 4–6 Go ; sur 16 Go, il reste ~10 Go pour le modèle. Piège n°3, sournois : on attend une erreur OOM claire, on obtient souvent « ça tourne, mais c’est insupportablement lent ». RAM insuffisante → macOS swap sur le SSD ; tokens/s de 30 à 3 — vous accusez le modèle alors que le disque fait semblant d’être de la RAM.
16 Go : jouable, pas un tier production
16 Go peut faire tourner Ollama — petits modèles, chats courts, moins d’apps en fond — et ça passe. Cas concrets :
- Essais : modèles 3B–7B Q4 comme
llama3.2:3b,qwen2.5:7b-instruct-q4_K_M - Q&R ponctuelles, brouillons mail, traduction courte
- Pas d’agents, pas plusieurs modèles chargés, contexte sous ~16K
Ma scène douloureuse classique : Chrome (20+ onglets), VS Code, Docker Desktop, plus un 8B sur 16 Go — pas de crash, juste une « mort en douceur », une demi-seconde par token. Tuer Docker et la moitié des onglets : la vitesse revient aussitôt.
Verdict 16 Go : traiter Ollama comme un assistant léger. Ne pas viser du 14B+ stable, ne pas empiler OpenClaw, base vectorielle et automation navigateur en local. Gateway sur un VPS, Ollama maison en amont — 16 Go suffit comme hôte petits modèles. Voir notre guide dépannage OpenClaw + passerelle Ollama.
24 Go : le sweet spot 2026 pour dev solo
Si un seul tier pour Ollama à long terme, 24 Go est ce que je recommande le plus aux devs individuels. Raisons pratiques :
- 7B–8B peuvent rester résidents pendant que l’OS et l’IDE respirent — pas besoin de fermer des apps chaque jour
- 14B Q4 viable dans beaucoup de workflows ; nettement mieux que 7B pour le code et longs résumés
- Contexte 8K–16K : croissance du cache KV maîtrisable
- Ollama plus une légère base vectorielle ou un service Docker — pas de choix forcé
24 Go ne fait pas voler un 70B. Sa valeur : équilibre qualité / coût — Mac mini M4 24 Go coûte moins que 32 Go et gère confortablement dev quotidien + inférence locale 8B/14B.
Facile à manquer : la RAM Apple est soudée — pas d’upgrade plus tard. « J’achète 16 Go et on verra » est une erreur permanente sur Mac. 24 Go, c’est la marge pour l’inflation des modèles — en 2024 le défaut était 7B ; en 2026 beaucoup commencent à 14B. Les 8 Go en plus, c’est l’assurance.
32 Go : agents, multi-modèles, « arrêter de compter la RAM »
Pour qui 32 Go ? Vous traitez les LLM locaux comme de l’infra, pas un jouet du week-end.
- OpenClaw, LangGraph ou stacks similaires always-on, Ollama en amont
- Plusieurs modèles
ollama pull(7B code, 14B rédaction, petit modèle embed) - Contexte souvent 32K+, ou RAG avec longs documents dans le prompt
- Stack AI Docker Compose complète — souvent liée au déploiement d’apps IA avec Docker
32 Go ne rend pas un 70B rapide, mais ça réduit la taxe « ferme ça, ouvre ça ». Le debug le plus lent n’est pas une mauvaise config de modèle — c’est vivre au bord du précipice mémoire : ça marche aujourd’hui, demain Notion et Slack rejoignent la fête.
Budget serré ? Inférence légère sur 24 Go local, gros travail sur Mac cloud ou VPS. Même logique que louer un Mac cloud avant de s’engager — voir Mac ou Windows pour apprendre à coder.
Tableau de décision : ignorez le marketing
| Usage principal | Tier RAM | Pourquoi |
|---|---|---|
| Chat local occasionnel, apprendre la CLI Ollama | 16 Go (OK) | 3B–7B Q4 ; accepter de fermer apps et contexte court |
| Dev quotidien + assist code local 7B/8B | 24 Go (recommandé) | OS + IDE + modèle en ligne ensemble, stable |
| Modèles 14B, docs longs, RAG léger | 24 Go (min) / 32 Go (confort) | 14B Q4 ~8–9 Go ; avec cache, 16 Go est serré |
| Stack agent + Docker + plusieurs modèles | 32 Go | Beaucoup de composants ; pics et fragmentation s’additionnent |
| Inférence 70B locale complète | Passer les tiers grand public | GPU cloud ou API ; ne pas forcer la RAM |
Cinq réglages (moins cher qu’upgrader la RAM)
Avant d’acheter plus de mémoire — ils m’ont gagné six mois sur 16 Go :
- Quantification avisée : Q4_K_M ou Q5 d’abord, pas FP16 ;
ollama show <model> --modelfilepour la taille. - Plafonner le contexte :
num_ctxdans Modelfile ou appels API — 4K suffit souvent pour chatbots, pas 32K par défaut. - Un modèle chargé à la fois :
ollama pspuisollama stopsur l’inutile. - Alléger l’arrière-plan : Docker Desktop, apps IM Electron, Chrome à onglets — Safari ou un profil pendant l’inférence.
- Surveiller la pression mémoire, pas seulement « Go utilisés » : jaune/rouge prédit mieux les saccades qu’un chiffre brut.
Plus de leviers : docs Modelfile Ollama.
Trois histoires « sang et larmes » que je revois sans cesse
Histoire 1 : « 16 Go suffisent, je ne fais que du 7B. » — Modèle embed + Open WebUI ; trois processus affamés ; 25 tokens/s → 4 ; le Wi‑Fi accusé.
Histoire 2 : « J’ai payé 32 Go, je suis invincible. » — Toujours quant proche FP16, contexte 32K, Chrome grand ouvert ; le 70B swap quand même. La capacité ne rétrécit pas le modèle.
Histoire 3 : « Mon PC Windows 32 Go bat n’importe quel Mac 16 Go. » — Peut-être avec VRAM NVIDIA — mais sur Mac pour Ollama, bande passante et partage de la mémoire unifiée font soutenant qu’un Mac 16 Go tient 7B plus stablement que beaucoup de portables 16 Go iGPU. Comparez les plateformes, pas les Go sur l’étiquette. Le chemin mémoire unifiée Apple Silicon (MLX, etc.) compte aussi.
Bilan : choisir sans regret
Trois questions rapides :
- Quelle taille de modèle tournez-vous vraiment ? 7B/8B régulier → 24 Go ; 3B jouet → 16 Go tolérable ; 14B+ ou stacks → 32 Go.
- Fermerez-vous des apps pendant l’inférence ? Si non → n’achetez pas 16 Go.
- La RAM est-elle upgradable plus tard ? Pas sur Mac — sous-dimensionner est permanent ; Windows bureau peut ajouter des barrettes, mais Ollama + CUDA, c’est une autre voie.
Mon avis 2026 : Ollama sérieux comme copilote dev commence à 24 Go pour le rapport qualité-prix ; 32 Go pour les gens agents qui refusent de micromanager la mémoire ; 16 Go seulement pour de légers essais — les yeux ouverts. Ne vénérez pas « plus de RAM gagne toujours », mais ne sous-estimez pas cache KV et long contexte — les monstres mémoire silencieux.
En une ligne : la barrière logicielle Ollama est basse ; le hardware heurte d’abord la mémoire unifiée. Connaissez votre tier modèle et workflow avant de commander 16 / 24 / 32 Go — vous économiserez de l’argent et bien des nuits de ventilateurs hurlants.
Un Ollama local stable exige le bon tier — Mac cloud aussi
Bien faire tourner Ollama, c’est assez de mémoire unifiée et de bande passante. Mac mini M4 en 24 / 32 Go gère l’inférence locale 7B–14B plus sereinement que des bricolages — silencieux, faible conso, laissable allumé.
Pas envie d’un gros pari matériel, ou besoin d’une seconde machine propre pour modèles et Xcode ? Les abonnements Mac cloud VPSSpark permettent de séparer les tiers : essais légers en local, agents et files de build dans le cloud.