512-GB-MacBook für Ollama: Reicht der Speicher für lokale LLMs?

Direkte Antwort

Ein MacBook mit 512 GB SSD reicht für Ollama und lokale LLMs in den allermeisten Fällen problemlos aus. Der SSD-Speicher ist fast nie der erste Engpass — ein typisches Arbeitsset aus vier bis sechs quantisierten Modellen belegt rund 20 bis 25 GB, also etwa fünf Prozent der Platte.

Der eigentliche Engpass ist RAM. Auf Apple Silicon teilen sich CPU und GPU denselben unified memory, und dieser Speicher entscheidet, welche Modelle überhaupt laufen und wie schnell sie antworten. Die praktische Reihenfolge der Prioritäten lautet deshalb: RAM zuerst, Speicherbandbreite zweitens, SSD-Kapazität zuletzt.

Wer vor einer Kaufentscheidung steht und zwischen mehr SSD und mehr RAM wählen muss, sollte im Zweifel immer den RAM nehmen. Ein M-Chip-MacBook mit 512 GB SSD und 32 GB RAM ist für lokale Sprachmodelle klar besser aufgestellt als eines mit 2 TB SSD und 16 GB RAM — und meist sogar günstiger.

Was Modelle wirklich auf der SSD belegen

Die Zahlen, mit denen im Netz hantiert wird, meinen fast immer unquantisierte Modelle. Was Ollama tatsächlich herunterlädt, sind quantisierte Varianten, standardmäßig in 4-bit (Q4_K_M). Die Größenordnungen sehen damit so aus:

Modell	Quantisierung	Größe auf der SSD (ca.)
Llama 3.2 3B	Q4_K_M	~2,0 GB
Mistral 7B Instruct	Q4_K_M	~4,1 GB
Llama 3.1 8B	Q4_K_M	~4,7 GB
Qwen 2.5 14B	Q4_K_M	~9 GB
Mixtral 8x7B	Q4_K_M	~26 GB
Llama 3.3 70B	Q4_K_M	~43 GB
nomic-embed-text	—	~275 MB

Ein realistisches Alltagsset — ein schnelles 3B-Modell, ein 7B- oder 8B-Allrounder, ein 14B-Modell für anspruchsvollere Aufgaben und ein Embedding-Modell für RAG — landet zusammen bei etwa 16 GB. Selbst mit großzügigem Experimentierpuffer bleibt man unter 50 GB.

Erst bei 70B-Modellen ändert sich die Rechnung spürbar: Ein einziges Llama 3.3 70B in Q4 belegt mehr Platz als das komplette Alltagsset. Aber genau diese Modelle sind auf einem MacBook ohnehin selten die richtige Wahl, weil der RAM vorher limitiert.

Den tatsächlichen Verbrauch prüfst du direkt:

# Alle installierten Modelle mit Größe
ollama list

# Gesamtverbrauch des Modellverzeichnisses
du -sh ~/.ollama/models

# Ein nicht mehr genutztes Modell entfernen
ollama rm mixtral:8x7b

Wer den Platz auf der internen SSD trotzdem knapp hält, kann das Modellverzeichnis auf eine externe SSD umlenken:

# In ~/.zshrc eintragen, danach Ollama neu starten
export OLLAMA_MODELS="/Volumes/ExterneSSD/ollama-models"

Das funktioniert, hat aber einen Haken: Beim ersten Laden eines Modells wird es komplett von der externen SSD gelesen. Über Thunderbolt ist das unauffällig, über USB-C mit langsamem Gehäuse merkt man die Ladezeit deutlich. Für Modelle, die du täglich nutzt, gehört das Verzeichnis auf die interne SSD.

Warum RAM der härtere Engpass ist

Der häufigste Denkfehler bei lokaler KI: Man schaut auf die SSD und vergisst den Arbeitsspeicher. Die SSD entscheidet, wie viele Modelle auf dem Rechner liegen. Der RAM entscheidet, was du davon tatsächlich ausführen kannst.

Als grobe Faustregel gilt: Ein Modell braucht im Betrieb ungefähr seine Dateigröße an RAM, plus Platz für den KV-Cache des Kontextfensters. Der KV-Cache wächst linear mit der Kontextlänge und kann bei langen Kontexten selbst mehrere Gigabyte belegen. Dazu kommt alles, was sonst noch läuft — macOS, Browser mit dreißig Tabs, IDE, Docker, Slack.

Daraus ergibt sich diese praktische Einordnung:

• 16 GB RAM — 3B-Modelle laufen gut, 7B-Modelle laufen, werden aber eng, sobald parallel gearbeitet wird. Für einen ersten Eindruck ausreichend, für Dauerbetrieb frustrierend.
• 24–32 GB RAM — der Sweet Spot. 7B- und 8B-Modelle laufen komfortabel, 14B-Modelle sind machbar, und der Rechner bleibt daneben benutzbar.
• 48–64 GB RAM — 14B-Modelle werden entspannt, 30B-Modelle kommen in Reichweite, längere Kontexte und RAG-Setups mit größeren Indizes werden praktikabel.
• 96 GB und mehr — hier werden 70B-Modelle in Q4 realistisch. Das ist Spezialhardware, keine Standardausstattung.

Ein Detail, das viele überrascht: macOS reserviert nicht den gesamten unified memory für die GPU. Es gibt ein Limit dafür, wie viel Speicher als GPU-adressierbar freigegeben wird. Auf Maschinen mit viel RAM lässt sich dieses Limit anheben, was bei grenzwertig großen Modellen den Unterschied zwischen „läuft” und „läuft nicht” ausmachen kann. Wer daran schraubt, sollte allerdings wissen, was er tut — ein zu hoch gesetztes Limit macht das System instabil, weil macOS selbst zu wenig Speicher behält.

Speicherbandbreite: die Zahl, über die niemand redet

Zwei MacBooks mit identischem RAM können bei lokalen LLMs unterschiedlich schnell sein. Der Grund ist die Speicherbandbreite, und die unterscheidet sich zwischen den Chip-Varianten erheblich: Ein Basis-M-Chip liegt deutlich unter einem Pro, und der wiederum unter einem Max.

Das ist bei Inferenz kein Nebenaspekt, sondern der dominierende Faktor. Textgenerierung ist speicherbandbreiten-limitiert: Für jedes einzelne erzeugte Token müssen die Modellgewichte durch den Speicher gelesen werden. Doppelte Bandbreite bedeutet daher näherungsweise doppelte Tokens pro Sekunde — bei identischem Modell und identischem RAM.

Praktische Konsequenz: Ein MacBook Air mit 24 GB kann ein 7B-Modell laden, das ein MacBook Pro mit Max-Chip ebenfalls lädt. Beide funktionieren. Aber das Pro antwortet spürbar flüssiger. Wenn lokale LLMs ein zentraler Teil deines Workflows werden sollen, ist die Chip-Variante wichtiger als die letzten 256 GB SSD.

Konkrete Tokens/s-Werte für einzelne Mac-Konfigurationen stehen im Hardware-Guide. Wer lieber mit grafischer Oberfläche testet statt im Terminal, findet den gleichen Vergleich mit LM Studio — die Messwerte sind vergleichbar, weil beide Tools llama.cpp als Unterbau nutzen.

Quantisierung: der eigentliche Hebel

Quantisierung reduziert die Präzision der Modellgewichte und damit Speicherbedarf und Rechenaufwand. Die gängigen Stufen:

• Q8 — nahezu verlustfrei, aber etwa doppelt so groß wie Q4. Lohnt sich auf einem MacBook selten.
• Q5_K_M — guter Kompromiss, wenn RAM vorhanden ist und Qualität zählt.
• Q4_K_M — der Standard. Qualitätsverlust ist in der Praxis meist kaum wahrnehmbar, der Speichergewinn dagegen erheblich.
• Q3 und darunter — spürbarer Qualitätsverlust, besonders bei längeren deutschen Texten und beim Befolgen komplexer Anweisungen. Nur als Notlösung.

Die für MacBooks wichtigste Erkenntnis daraus: Ein größeres Modell in Q4 schlägt fast immer ein kleineres Modell in Q8. Wenn du zwischen einem 14B-Modell in Q4 und einem 7B-Modell in Q8 wählen kannst und beide passen, nimm das 14B. Mehr Parameter bei gröberer Quantisierung liefern in aller Regel bessere Ergebnisse als weniger Parameter bei feinerer.

Details zu Quantisierungsstufen und Kontextlängen stehen bei Llama lokal installieren und Mistral lokal installieren.

Wie du dein Modellset zusammenstellst

Ein aufgeräumtes Set aus vier Modellen ist praktisch wertvoller als eine Bibliothek aus zwanzig. Bewährt hat sich diese Aufteilung:

1. Ein schnelles Alltagsmodell (3B, Q4) für Zusammenfassungen, Umformulierungen, Klassifikation. Antwortet nahezu verzögerungsfrei, läuft auf jedem MacBook.
2. Ein Allrounder (7B–8B, Q4) als Standardmodell für die meisten Aufgaben.
3. Ein Coding-Modell, sofern du regelmäßig Code schreibst. Spezialisierte Modelle schlagen hier Allrounder gleicher Größe deutlich.
4. Ein Embedding-Modell für RAG lokal, falls du eigene Dokumente durchsuchbar machen willst. Diese Modelle sind klein und fallen speichermäßig nicht ins Gewicht.

Optional kommt ein größeres Modell (14B) dazu, das du gezielt für schwierige Aufgaben startest — nicht als Dauerläufer.

Der Einstieg selbst dauert wenige Minuten und ist im Ollama Tutorial Schritt für Schritt beschrieben.

Neue Modelle richtig bewerten

Wenn ein neues Modell gerade diskutiert wird, ist selten sofort klar, welche Variante als Ollama-Modell oder GGUF-Datei verfügbar ist und wie sich die Quantisierungen verhalten. Benchmark-Tabellen aus Ankündigungen helfen dabei wenig — sie messen englische Standard-Benchmarks, nicht deinen Alltag.

Ein Mini-Eval mit fünf eigenen Prompts ist aussagekräftiger als jede Benchmark-Tabelle:

1. Eine Zusammenfassung eines längeren deutschen Textes aus deinem Arbeitskontext
2. Eine konkrete Code-Frage aus deinem aktuellen Projekt
3. Eine Fachfrage, deren richtige Antwort du kennst — als Halluzinations-Test
4. Eine Aufgabe mit strikter Formatvorgabe (JSON, Tabelle, Stichpunkte)
5. Eine RAG-Frage gegen eigene Dokumente, falls du RAG einsetzt

Miss dabei nicht nur die Qualität, sondern auch Tokens pro Sekunde und ob das Modell bei langem Kontext stabil bleibt. Modelle, die bei 2.000 Token überzeugen und bei 16.000 Token abbauen, fallen in Benchmarks nicht auf, im Alltag dagegen sofort.

Gerade für Selbstständige, Agenturen und Unternehmen im DACH-Raum ist außerdem die Lizenzfrage relevant — welche Modelle kommerziell nutzbar sind, steht bei Sicherheit und DSGVO.

Praktische Empfehlung

Starte nicht mit dem größten Modell, das dein Rechner theoretisch stemmt. Installiere Ollama, lade ein kleines starkes Modell, arbeite eine Woche damit und miss, wo es dir konkret nicht reicht. Erst dann lädst du ein größeres daneben und vergleichst an denselben Aufgaben.

Wenn der Qualitätsunterschied im Alltag klein ist, nimm das schnellere Modell. Lokale LLMs gewinnen nicht dadurch, dass sie Cloud-Modelle in Benchmarks schlagen — das tun sie meist nicht. Sie gewinnen durch private Daten, planbare Kosten und Verfügbarkeit ohne Netz. Ob dieser Tausch für dich aufgeht, steht in der ausführlichen Abwägung unter Cloud vs. Lokal.

Zur Ausgangsfrage: 512 GB SSD sind für Ollama auf dem MacBook reichlich bemessen. Halte 100 GB frei, räume mit ollama rm auf, was du nicht nutzt, und investiere das gesparte Geld in RAM statt in Speicher. Ein 512-GB-MacBook mit ausreichend unified memory ist für kompakte Modelle, deutsche Texte, Coding-Hilfe und lokale Wissensarbeit ein ernstzunehmendes Arbeitsgerät.