Mein erster Rechner mit Ollama war ein Mac mini M2 mit 16 GB. Tutorials versprachen „ein Befehl, Modell ziehen, lokal chatten“ – also ollama run llama3.1:8b. Die ersten fünf Minuten fühlten sich großartig an. Nach zehn Minuten heulten die Lüfter, der Speicherdruck in der Aktivitätsanzeige wurde rot, und Browser-Tabs wechseln fühlte sich an wie Beton schleppen.
Was ich gelernt habe: 16 GB, 24 GB oder 32 GB für Ollama ist nicht „größer ist immer besser“. Es geht darum, ob Modell + Kontextfenster + Hintergrund-Apps noch in den Unified Memory passen. Dieser Artikel sammelt die Fallen, in die ich getappt bin, und das Framework, mit dem ich Freunde berate – damit du weniger Geld und weniger durchwachte Nächte verlierst.
Warum RAM zuerst beißt – noch vor „hab ich eine GPU?“
Auf Windows-Gaming-Laptops fixiert man sich auf VRAM. Auf Apple-Silicon-Macs teilen sich CPU und GPU einen gemeinsamen Unified-Memory-Pool. Ollamas Gewichte, der KV-Cache zur Inferenzzeit und macOS-Caches ziehen alle daraus. Docs und Community-Benchmarks stimmen überein: größere Modelle und längerer Kontext fressen mehr RAM – dieselbe „Speicher“-Zeile in der Aktivitätsanzeige.
Falle Nr. 1: Parameter zählen, Quantisierung ignorieren. Ein 7B-Modell in Q4_K_M braucht vielleicht ~4–5 GB; Q8 oder FP16 verdoppelt das leicht. Falle Nr. 2: das OS vergessen – macOS, Browser, Chat, IDE nehmen schnell 4–6 GB; auf 16 GB bleiben ~10 GB fürs Modell. Falle Nr. 3 ist heimtückisch: Man erwartet einen klaren OOM-Fehler, bekommt aber oft „läuft, aber qualvoll langsam“. Wenn RAM fehlt, swapt macOS auf die SSD; tokens/s fallen von 30 auf 3 – du gibst dem Modell die Schuld, während die Platte als RAM verkleidet ist.
16 GB: spielbar, kein Produktions-Tier
16 GB kann Ollama laufen lassen – kleine Modelle, kurze Chats, weniger Hintergrund – und sich okay anfühlen. Konkrete Fits:
- Ausprobieren: 3B–7B Q4 wie
llama3.2:3b,qwen2.5:7b-instruct-q4_K_M - Einmal-Q&A, E-Mail-Entwürfe, kurze Übersetzung
- Keine Agenten, kein Multi-Modell-Load, Kontext unter ~16K
Meine klassische Schmerzszene: Chrome (20+ Tabs), VS Code, Docker Desktop plus 8B auf 16 GB – kein Crash, nur „sanfter Tod“, halbe Sekunde pro Token. Docker und die Hälfte der Tabs killen – Geschwindigkeit sofort zurück.
16-GB-Fazit: Ollama als leichter Assistent. Keine stabilen 14B+ erwarten, kein OpenClaw + Vektor-DB + Browser-Automation lokal stapeln. Gateway auf dem VPS, Ollama zu Hause als Upstream – 16 GB reicht als Kleinmodell-Host. Siehe unseren OpenClaw- + Ollama-Gateway-Troubleshooting-Guide.
24 GB: 2026 Sweet Spot für Solo-Entwickler
Wenn du ein Tier langfristig wählen musst, empfehle ich Einzelentwicklern am häufigsten 24 GB. Praktische Gründe:
- 7B–8B können resident bleiben, während OS und IDE atmen – du schließt nicht täglich Apps
- 14B Q4 ist in vielen Workflows machbar; spürbar besser als 7B für Code und lange Zusammenfassungen
- 8K–16K Kontext hält KV-Cache-Wachstum im Griff
- Ollama plus leichte Vektor-DB oder ein Docker-Service – kein Zwang entweder/oder
24 GB lassen 70B nicht magisch fliegen. Der Wert ist Balance zwischen Qualität und Kosten: Mac mini M4 24 GB kostet weniger als 32 GB und meistert tägliche Dev + lokale 8B/14B-Inferenz komfortabel.
Leicht übersehen: Apple-Speicher ist verlötet – kein Upgrade später. „Ich kauf 16 GB und schau mal“ ist auf dem Mac permanent. 24 GB sind Puffer gegen Modell-Inflation – 2024 war 7B Standard; 2026 starten viele bei 14B. Die extra 8 GB sind Versicherung.
32 GB: Agenten, mehrere Modelle, „RAM nicht mehr zählen“
Für wen ist 32 GB? Du behandelst lokale LLMs als Infrastruktur, nicht als Wochenend-Spielzeug.
- Always-on OpenClaw, LangGraph o. Ä. mit Ollama als Upstream
- Mehrere
ollama pull-Modelle (7B Code, 14B Schreiben, kleines Embed-Modell) - Kontext oft 32K+, oder RAG mit langen Dokumenten im Prompt
- Voller Docker-Compose-AI-Stack – oft gebunden an AI-Apps mit Docker deployen
32 GB machen 70B nicht schnell, aber sie senken die „schließ das, öffne das“-Steuer. Das langsamste Debugging ist selten falsche Modell-Config – es ist Leben am Speicher-Abgrund: heute ok, morgen tot, weil Notion und Slack mitfeiern.
Knappes Budget? Leichte Inferenz auf 24 GB, Schweres in der Cloud Mac oder VPS. Gleiche Logik wie Cloud-Mac mieten vor dem Hardware-Commit – siehe Mac oder Windows beim Programmieren lernen.
Entscheidungstabelle: Marketing ignorieren
| Hauptnutzung | RAM-Tier | Warum |
|---|---|---|
| Gelegentlicher lokaler Chat, Ollama CLI lernen | 16 GB (OK) | 3B–7B Q4; Apps schließen, kurzer Kontext akzeptieren |
| Tägliche Dev + lokale 7B/8B Coding-Hilfe | 24 GB (empfohlen) | OS + IDE + Modell gleichzeitig online, stabil |
| 14B, längere Docs, leichtes RAG | 24 GB (min) / 32 GB (komfortabel) | 14B Q4 ~8–9 GB; mit Cache ist 16 GB eng |
| Agent-Stack + Docker + mehrere Modelle | 32 GB | Viele Komponenten; Peaks und Fragmentierung addieren sich |
| Volle lokale 70B-Inferenz | Consumer-Tiers überspringen | Cloud-GPU oder API; RAM nicht brutal forcieren |
Fünf Tuning-Moves (günstiger als RAM-Upgrade)
Bevor du mehr Speicher kaufst – die haben mir sechs Monate auf 16 GB beschert:
- Quantisierung klug wählen: Q4_K_M oder Q5 zuerst, nicht FP16;
ollama show <model> --modelfilefür Größe. - Kontext begrenzen:
num_ctxin Modelfile oder API – 4K reicht oft für Chatbots, nicht Default 32K. - Ein geladenes Modell zur Zeit:
ollama ps, dannollama stopfür Unnötiges. - Schwere Hintergrund-Apps trimmen: Docker Desktop, Electron-IM, Chrome-Tab-Hort – Safari oder ein Profil beim Inferieren.
- Speicherdruck beobachten, nicht nur „belegte GB“: Gelb/Rot sagt Ruckler besser voraus als eine Zahl.
Mehr Knöpfe: Ollama Modelfile Docs.
Drei „Blut und Tränen“-Geschichten, die ich ständig sehe
Story 1: „16 GB reichen, ich laufe nur 7B.“ — Embed-Modell + Open WebUI dazu; drei hungrige Prozesse; 25 tokens/s → 4; WLAN beschuldigt.
Story 2: „Ich hab 32 GB bezahlt, bin unbesiegbar.“ — Trotzdem FP16-artige Quant, 32K Kontext, Chrome weit offen; 70B swapt weiter. Kapazität schrumpft das Modell nicht.
Story 3: „Mein Windows-Box mit 32 GB schlägt jeden 16-GB-Mac.“ — Vielleicht mit NVIDIA-VRAM – aber für Ollama auf dem Mac machen Unified-Memory-Bandbreite und Sharing oft, dass 16 GB Mac 7B stabiler laufen als viele 16-GB-iGPU-Laptops. Plattformen vergleichen, nicht GB-Aufkleber. Apples Apple Silicon Unified Memory (z. B. MLX) zählt auch.
Fazit: ohne Reue wählen
Drei schnelle Fragen:
- Welche Modellgröße läufst du wirklich? Stetig 7B/8B → 24 GB; Spielzeug 3B → 16 GB tolerierbar; 14B+ oder Stacks → 32 GB.
- Schließt du Apps beim Inferieren? Wenn nein → kauf nicht 16 GB.
- Kann RAM später upgraded werden? Nicht auf dem Mac – Unterdimensionierung ist permanent; Desktop-Windows kann Sticks nachlegen, aber Ollama + CUDA ist eine andere Spur.
Mein Take für 2026: Ernsthaftes Ollama als Dev-Copilot startet bei 24 GB fürs Preis-Leistungs-Verhältnis; 32 GB für Agenten-Leute, die Speicher nicht micromanagen wollen; 16 GB nur für leichte Experimente – mit offenen Augen. „Mehr RAM gewinnt immer“ nicht anbeten, aber KV-Cache und langer Kontext – die stillen Speicher-Monster – nicht unterschätzen.
In einem Satz: Ollamas Software-Hürde ist niedrig; Hardware trifft zuerst Unified Memory. Kenn dein Modell-Tier und deinen Workflow, bevor du 16 / 24 / 32 GB bestellst – du sparst Geld und viele Nächte mit heulenden Lüftern.
Stabiles lokales Ollama braucht das richtige Tier – Cloud Mac auch
Ollama gut laufen lassen heißt genug Unified Memory und Bandbreite. Mac mini M4 in 24-GB-/32-GB-Konfigurationen handhaben lokale 7B–14B-Inferenz ruhiger als zusammengestoppelte Kisten – leise, sparsam, dauerhaft anlassbar.
Keine große Hardware-Wette, oder eine saubere Zweitmaschine für Modelle und Xcode? VPSSpark Cloud Mac-Abos erlauben Tier-Split: leichte Experimente lokal, Agenten und Build-Queues in der Cloud.