Lokale LLMs im Feldtest: mein MacBook, meine Zahlen, mein Rat

1 · Der Crash, der mir RAM beigebracht hat

Ich bin mit der falschen Zahl im Kopf gestartet: 34 GB frei auf der Festplatte, also massig Platz. Stimmt auch, nur ist die Festplatte beim lokalen Modell die falsche Größe. Was zählt, ist der freie Arbeitsspeicher im Moment des Ladens. Ein Modell muss komplett in den RAM, und zwar zusätzlich zu allem, was sonst läuft: Browser, Editor, ein, zwei KI-Sitzungen. Bei mir bleiben davon im Alltag nur 4 bis 8 GB übrig.

Ich habe es trotzdem mit den Großkalibern probiert: ein 18-GB-Modell und daneben noch ein 14-GB-Modell heruntergeladen. Das Laden hat den Speicher gesprengt, das System fing an auszulagern, und der ganze Rechner ist eingefroren. Kein eleganter Fehler, sondern hartes Aus.

Die Lehre war sofort praktisch und gilt für jede lokale-Modell-Arbeit: vor dem Laden den freien RAM prüfen, nicht die Platte. Nur Modelle nehmen, die sicher reinpassen. Immer nur eines gleichzeitig. Und das Modell nach jeder Anfrage sofort wieder entladen (bei Ollama heißt der Schalter keep_alive: 0). Mit dieser Disziplin lief danach alles stabil, auch bei knappem Speicher.

2 · Das Setup: Ollama, MLX und ein Stolperstein

Mein Testfeld: ein MacBook Pro M4 Pro mit 24 GB unter macOS 15.7. Zwei Engines im Vergleich. Ollama (Version 0.24) ist das bequeme Werkzeug: ein Befehl lädt ein Modell, ein Daemon hält es bereit, und es spricht dieselbe Schnittstelle wie die großen Cloud-Anbieter. MLX ist Apples eigenes Rechen-Framework für die M-Chips, schlanker und näher an der Hardware.

Beide waren in Minuten installiert. Der Stolperstein lag woanders: Das vorinstallierte Python war Version 3.14, ganz frisch. Der bekannte Terminal-Agent Aider ließ sich darauf nicht installieren, eine Bau-Komponente fehlt für diese Python-Version noch. MLX dagegen lief auf 3.14 problemlos. Kleiner, aber typischer Befund: Wer ganz vorne mitschwimmt, zahlt manchmal mit kaputten Abhängigkeiten. Für echte Agenten-Werkzeuge nimmt man besser ein etwas älteres Python.

Damit der Crash sich nicht wiederholt, habe ich für jede Messung denselben Sicherheitsgurt benutzt: ein fester Prompt, das Modell lädt, antwortet, und wird sofort wieder entladen.

3 · Die Zahlen: Lesen und Schreiben, getrennt gemessen

Eine einzige Tokens-pro-Sekunde-Zahl führt in die Irre, weil zwei völlig verschiedene Dinge passieren. Erst liest das Modell die ganze Eingabe ein (das hängt an Rechenleistung), dann tippt es Wort für Wort die Antwort (das hängt an der Speicherbandbreite). Das Tippen ist das, was du als Tempo spürst. Ich habe beides getrennt gemessen, mit demselben rund 1.100 Token langen Prompt, jeweils der Median aus mehreren warmen Läufen.

Das Muster ist klar und ein bisschen unbequem: kleiner ist schneller. Das 1,5B-Modell tippt rund dreimal so schnell wie das 7B-Modell. Der Grund steht oben: Für jedes einzelne Wort muss das ganze Modell einmal durch den Speicher, und ein kleineres Modell ist eben schneller durch. Alle vier kleinen Modelle tragen eine freie Lizenz (Apache oder MIT), das war mir wichtig, weil das später auch für das Weitergeben an andere zählt. Bewusst nicht dabei: Llama 4 (für eine Person mit Sitz in der EU eine Lizenzfalle) und die älteren Gemma-Versionen.

4 · Ollama gegen MLX: meine Engine-Empfehlung

Jetzt die Engine-Frage, im Plan heißt sie D2. Ich habe dasselbe Modell (der 3B-Coder, gleiche 4-Bit-Quantisierung) einmal über Ollama und einmal über MLX laufen lassen, identischer Prompt.

MLX tippt rund 25 bis 30 % schneller und hält den Speicher niedrig, das ist genau der Teil, den man als flüssiger erlebt. Trotzdem ist meine Empfehlung nicht „nimm das Schnellere". Ollama gewinnt überall dort, wo es im Alltag zählt: Modelle laden und aufräumen mit einem Befehl, eine Standard-Schnittstelle, die jedes Agenten-Werkzeug versteht, und vor allem das automatische Entladen, das mich nach dem Crash gerettet hat. MLX ist mehr Selbstbau.

5 · Schafft es den Bug? One-Shot gegen Agenten-Loop

Tempo ist eine Sache, Können die andere. Als Härtetest habe ich denselben kleinen Datum-Bug genommen, der im ersten Teil schon der rote Faden war: ein Buchungs-Formular schlägt manchmal einen Samstag als Termin vor, obwohl samstags zu ist. Der Fehler steckt in einer Hilfsdatei (eine Funktion erkennt nur den Sonntag als Wochenende, nicht den Samstag), und genau das macht ihn fies: Man muss eine zweite Datei aufmachen, um ihn zu finden. Es gibt einen kleinen Test, der nur grün wird, wenn die Ursache wirklich behoben ist.

Ich habe jedes Modell zweimal drangelassen. Einmal als einzelne Frage („schau dir die Dateien an und finde den Fehler"). Und einmal im Agenten-Loop: das Modell schlägt eine Korrektur vor, ich schreibe sie hin, lasse den Test laufen und gebe ihm die Fehlermeldung zurück, bis grün, so wie es Aider oder Cline tun.

In der einzelnen Frage hat kein kleines Modell den Bug gefunden. Sie zeigten auf die falsche Datei, behaupteten teils, der Code sei schon richtig, und gaben den fehlerhaften Code unverändert zurück. Im Loop dagegen hat jedes Modell, sogar das winzige 1,5B, in einer einzigen Runde die richtige Ursache behoben, mit exakt derselben sauberen Korrektur.

Warum der Unterschied? Im Loop bekommt das Modell die fehlschlagende Test-Meldung zurück, und die nennt das Symptom beim Namen: „Samstag wird nicht als Wochenende erkannt". Diese Lokalisierung, also die halbe Arbeit, liefert der Test, nicht das Modell. Das ist der ehrliche Kern: Struktur schlägt rohe Modellgröße. Ein guter Test plus eine Schleife heben ein kleines lokales Modell auf ein Niveau, das es allein nicht erreicht.

Genau dieser Befund ist der Grund, warum mein nächstes größeres Projekt auf das Muster „mehrere Modelle plus Prüf-Schleife" setzt statt auf ein möglichst großes Modell. Bei knapper Hardware ist das der wirksamste Hebel.

6 · Was ich dir rate

Wenn du auf einem Mac mit 16 bis 24 GB lokal mit Code arbeiten willst, ist das mein Stand nach diesem Tag:

Der nächste Schritt für mich: das eigentliche Projekt, eine schlanke, lokale KI-Basis, auf der man sich seinen Stack selbst zusammenstellt. Die Zahlen von heute sind das Fundament dafür. Die Werkzeuge stehen, die Engine ist entschieden, und ich weiß jetzt aus Erfahrung, nicht aus der Tabelle, was meine Maschine wirklich kann.