- Praktisches Setup zum Ausführen lokaler LLMs auf einem M4 MacBook Pro mit 24 GB Speicher, um grundlegende Coding-Aufgaben, Recherche und Planung ohne Internetverbindung zu erledigen
- Das derzeit am besten funktionierende Modell ist Qwen 3.5-9B (Q4-Quantisierung), das in LM Studio etwa 40 Token/Sekunde erreicht und den Thinking-Modus, Tool Use sowie ein 128K-Kontextfenster unterstützt
- Von der Wahl des Ausführungstools über das Modell bis zu den Konfigurationsoptionen ist der Setup-Prozess mit Ollama, llama.cpp, LM Studio usw. komplex, und jedes Tool hat eigene Einschränkungen
- Es ist zwar schwer, komplexe Probleme wie mit SOTA-Modellen autonom zu lösen, aber mit einem interaktiven Workflow in Einzelschritten ist es als Research-Assistent oder für Rubber-Duck-Debugging gut nutzbar
- Der Betrieb ist ohne Abo und nur mit Stromkosten möglich und hat als nachhaltigere Form der AI-Nutzung, die die Abhängigkeit von Big Tech verringert, einen gewissen Wert, allerdings mit deutlichen Trade-offs bei Leistung und Einrichtung
Laufzeitumgebung für lokale Modelle und Auswahlkriterien
- Es wurden Setups für die Ausführung lokaler Modelle auf einem M4 MacBook Pro mit 24 GB Speicher getestet. Auch wenn die Ergebnisse nicht an SOTA-Modelle heranreichen, war eine Konfiguration möglich, die grundlegende Aufgaben, Recherche und Planung ohne Internetverbindung bewältigt
- Als Tools für die lokale Ausführung stehen Ollama, llama.cpp und LM Studio zur Verfügung; sie unterscheiden sich jeweils bei Einschränkungen und verfügbaren Modellen
- Bei der Modellauswahl musste das Modell in den Speicher passen und zugleich noch genug Spielraum lassen, um übliche Electron-Apps parallel laufen zu lassen; außerdem wurde ein Kontextfenster von mindestens 64K, idealerweise 128K oder mehr, benötigt
- Kürzlich getestete Modelle wie Qwen 3.6 Q3, GPT-OSS 20B und Devstral Small 24B passten zwar in den Speicher, waren in der Praxis aber schwer nutzbar; Gemma 4B lief gut, zeigte jedoch Schwächen bei der Tool-Nutzung
- Die Konfigurationsparameter reichen von bekannten Werten wie temperature bis zu speziellen Optionen wie K Cache Quantization Type; je nachdem, ob Thinking aktiviert ist, können unterschiedliche Werte passend sein
Qwen 3.5-9B in 4-Bit-Quantisierung
- qwen3.5-9b@q4_k_s war das beste Modell, wenn es in LM Studio lief: rund 40 Token/Sekunde, aktivierbares Thinking, erfolgreiche Tool-Nutzung und ein 128K-Kontextfenster zugleich
- Im Vergleich zu SOTA-Modellen lässt es sich leichter ablenken, gerät gelegentlich in Schleifen und interpretiert Anfragen manchmal falsch, ist aber für ein Modell, das auf einem MacBook Pro mit 24 GB läuft und noch Platz für andere Arbeitsumgebungen lässt, ziemlich ordentlich
- Die empfohlenen Einstellungen für Thinking-Modus und Coding-Aufgaben waren wie folgt
temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0
- Um Thinking zu aktivieren, muss in LM Studio nach Auswahl des Modells zu Configuration gewechselt und unten im Tab Inference der folgende Wert zu Prompt Template hinzugefügt werden
{%- set enable_thinking = true %}
- Dieses Modell wurde sowohl mit pi als auch mit OpenCode verwendet. pi wirkte reaktionsschneller, bot aber trotz des Vorteils, das Harness direkt selbst aufbauen und anpassen zu können, zu wenige vernünftige Standardwerte
- Es konnte passieren, dass mehr Zeit in die Feinabstimmung von pi floss als in das eigentliche Projekt
pi-Konfiguration
- In
~/.pi/agent/models.json wurde der OpenAI-kompatible Endpoint von LM Studio zusammen mit dem Modell qwen3.5-9b@q4_k_s eingetragen
{
"providers": {
"lmstudio": {
"baseUrl": "http://localhost:1234/v1";,
"api": "openai-completions",
"apiKey": "lm-studio",
"models": [
{
"id": "qwen3.5-9b@q4_k_s",
"reasoning": true,
"compat": { "thinkingFormat": "qwen-chat-template" }
}
]
}
}
}
- Um die ablenkenden Thinking-Blöcke auszublenden, wurde in
~/.pi/agent/settings.json "hideThinkingBlock": true ergänzt
OpenCode-Konfiguration
- In
~/.config/opencode/opencode.json wurde LM Studio als lokaler OpenAI-kompatibler Provider registriert und Tool-Nutzung, eine Kontextlänge von 131072 sowie 32768 maximale Token konfiguriert
{
"$schema": "https://opencode.ai/config.json";,
"provider": {
"lmstudio": {
"npm": "@ai-sdk/openai-compatible",
"name": "LM Studio (local)",
"options": {
"baseURL": "http://127.0.0.1:1234/v1";
},
"models": {
"qwen3.5-9b@q4_k_s": {
"name": "Qwen 3.5 9B Q4_K_S",
"tools": true,
"context_length": 131072,
"max_tokens": 32768
}
}
}
},
"model": "lmstudio/qwen3.5-9b@q4_k_s"
}
Unterschied zu SOTA-Modellen
- Modelle wie Qwen 3.5 9B Q4 waren nicht auf dem Niveau, komplexe Probleme über längere Zeit wie Spitzenmodelle selbstständig zu lösen
- Die Aufforderung, eine komplette App in einem Durchgang zu erstellen, war dafür ungeeignet und konnte am Ende nur zu einem heißen Laptop ohne Ergebnis führen
- Besser funktionierte ein interaktiver Workflow mit klarer Kommunikation in einzelnen Schritten und vielen Anweisungen
- Wer lokale Modelle nutzt, muss mehr Denken und Planung selbst übernehmen und präziser anweisen, aber als Recherchehilfe, Rubber Duck oder als Assistent zum schnellen Abrufen von Details zu Programmiersprachen und Kommandozeilenaufrufen war es nützlich
- Es war zwar nicht die von großen AI-Unternehmen beworbene Verzehnfachung der Produktivität, bot aber dennoch spürbare Unterstützung und ein interessantes Nutzungserlebnis
Aufgaben, die funktionierten, und Aufgaben, die scheiterten
-
Beheben von Elixir-Credo-Warnungen
- Nach dem Upgrade des Elixir-Linters
credo auf die neueste Version traten Warnungen im Code auf, und Qwen wurde gebeten, mix credo --strict auszuführen, Lösungsvorschläge zu machen, aber nichts zu bearbeiten
- Qwen fand in vier Testdateien das Problem, dass
length/1 verwendet wurde, um zu prüfen, ob Listen nicht leer sind, und schlug vor, statt length(list) > 0 besser list != [] zu verwenden
- Als anschließend um die Bearbeitung gebeten wurde, führte Qwen die vier parallelen Änderungen sauber aus
- Diese Aufgabe war zwar einfach und hätte auch direkt zwischen Terminal und Editor erledigt werden können, diente aber als bequeme Unterstützung
-
Rebase-Konflikte in einem Dependabot-PR beheben
- Nach einem Dependency-Update gab es Git-Konflikte in einem Dependabot-PR. Da Dependabot den Rebase verweigerte, wurde der PR lokal heruntergeladen und rebased, bevor Qwen um Prüfung gebeten wurde
- Die Konflikte waren einfach gelagert: Es musste jeweils die neuere Version der betreffenden Dependencies gewählt werden, und Qwen empfahl, bei
sentry 13.0.1 und bei tailwind 0.4.1 beizubehalten
- Als jedoch die tatsächliche Änderung angefordert wurde, versuchte Qwen
git add mix.lock && git rebase --continue auszuführen, obwohl die Datei nicht geändert war und die Konfliktmarker noch vorhanden waren
- Dass
git rebase --continue einen Editor öffnet, wurde ebenfalls nicht erkannt, OpenCode blieb hängen, wobei es sich auch um einen einmaligen Vorfall gehandelt haben könnte
Vorteile und Grenzen lokaler Modelle
- Lokale Modelle bringen große Trade-offs mit sich, haben aber den Vorteil, dass auch im Flugzeug ohne Internetverbindung gearbeitet werden kann
- Wenn man ohnehin einen Computer kauft, beschränken sich die Kosten auf den Stromverbrauch, und ein Abo ist nicht nötig
- Das Training der Modelle verursacht weiterhin hohe Umweltkosten, aber Open-Model-Unternehmen gehören nicht zu den größten Verursachern, und mit eigener Hardware sinkt die Abhängigkeit von Rechenzentren
- Das Tüfteln und Experimentieren macht Spaß
- LLMs haben bereits großen Einfluss und auch viele negative Seiten, wirken aber wie eine Technologie, die bleiben wird; Experimente mit lokalen Modellen fühlten sich wie eine nachhaltigere und positivere Art an, mit dieser Technologie umzugehen
1 Kommentare
Hacker-News-Kommentare
LLMs lokal laufen zu lassen ist spannend und mächtig, aber in der Praxis ziemlich mühsam, wenn man tatsächlich Arbeit erledigen will
Man muss im Voraus planen, Spezifikationen erstellen und alles vorbereiten, während große Modelle wie OpenAI oder Claude oft schon mit ein paar Sätzen direkt verstehen, worum es geht.
Wenn man ohnehin schon ernsthafte Arbeit mit großen Modellen macht, sollte man sie einfach weiter nutzen.
Bei Vision-/OCR-Aufgaben sehe ich das aber anders. Kleine und mittelgroße Open-Weights-Modelle sind dort ähnlich gut wie der aktuelle Stand der Technik, und bei großen Batch-Jobs sind die Kosten für Prefill-Tokens ziemlich ärgerlich.
Außerdem wird oft vergessen, dass man selbst für kleine LLMs, wenn man sie wie einen stabilen privaten Dienst nutzen will, 16–24 GB RAM/VRAM dauerhaft freihalten und den Dienst ständig laufen lassen muss.
Das eigentliche Kernproblem ist am Ende das Geld.
Ich finde, wir sind fast an einem wirklich brauchbaren Punkt angekommen.
Gemma 4 31B fühlt sich wie die neue Baseline für lokale Modelle an. Natürlich ist es Frontier-Modellen unterlegen, aber es wirkt weniger wie ein wissenschaftliches Experiment als die bisherigen lokalen Modelle, die ich ausprobiert habe, einschließlich GPT OSS 120B und Nemotron Super 120B.
Auf einem M5 Max mit 128 GB RAM steigt der RAM-Verbrauch bei Nutzung des vollen 256K-Kontextfensters auf etwa 70 GB, dazu kommen rund 14 GB System-Overhead.
Auf einer Maschine mit 64 GB Panther Lake und voller Arc B390 oder auf einem 48-GB-Snapdragon-X2-Elite-System dürfte es mit 128K–256K Kontextfenster laufen, und mit 32 GB könnte man vielleicht mit Mühe ein 32K-Kontextfenster hinbekommen.
Noch vor einem Jahr hätte es sich wie ein unrealistischer Traum angefühlt, solche Leistung auf einer gehobenen, aber fast schon Mainstream-nahen Konfiguration zu sehen.
Am Ende ist die Frage: „Was kann ich diesem Modell zuverlässig anvertrauen?“ Opus weiß definitiv mehr und kann komplexere Aufgaben erledigen, aber mit gutem Kontext ist Gemma erstaunlich stark.
Der Unterschied zwischen den Aufgaben, die ich beiden Modellen zutraue, ist überraschend klein. In privaten Tools und mehreren Projekten hatte ich zuletzt sehr gute Ergebnisse, und es ist das erste lokale Modell, bei dem ich in einem nichttrivialen Projekt im Agent-Modus der Implementierung von Features wirklich vertrauen konnte.
https://thot-experiment.github.io/gradient-gemma4-31b/
Das ist ein relativ komplexes Tool, das Gemma 4 innerhalb von OpenCode fast vollständig gebaut hat, und über mehrere Stunden hinweg war nur etwa viermal manuelles Eingreifen nötig.
Q6_K_XL, 128K Kontext @ q8, Lesen etwa 800 tok/s, Schreiben etwa 16 tok/s.
Ich warte auf turboquant und MTP in llama.cpp; wenn die Gerüchte stimmen, könnten 256K und 25–30 tok/s drin sein.
Direkt nach dem Release war die Benchmark-Leistung so beeindruckend, dass ich auch einen Beitrag dazu geschrieben habe [0]. Beim Einsatz in Agentic-Coding-Umgebungen mit längerem Kontext ist die Position in den Ranglisten danach allerdings etwas gefallen.
[0] https://gertlabs.com/blog/gemma-4-economics
Der Ablauf ist: mit einem aktuellen Modell planen und mit einem kleinen Modell ausführen. Wenn der Plan sauber ist und keine Mehrdeutigkeiten übriglässt, die das kleine Modell interpretieren muss, funktioniert das gut.
Ich wünschte, ich hätte diesen Beitrag gesehen, bevor ich nach einem ganzen Wochenende zur gleichen Schlussfolgerung gekommen bin.
Ich habe auf demselben Laptop einen künstlichen Test gemacht und etwa 50 Lint-Fehler in einem kleinen Vibe-Coding-C++-Repository beheben lassen. Ich hatte gehofft, dass viele kleine Aufgaben erledigt werden, ohne zu oft steckenzubleiben.
GPT OSS 20B war nutzbar, aber langsam, hat unnötige Sätze hinzugefügt oder Dinge wiederholt und oft behauptet, Probleme behoben zu haben, ohne den Code tatsächlich zu ändern.
Qwen 3.5 9B zusammen mit Opencode war deutlich schneller und hat auch unter Kompression die meisten Lint-Warnungen ohne Hänger abgearbeitet und alle Warnungen mit korrekten Fixes behoben.
Ich habe auch eine 4-Bit-MLX-Quantisierung von Qwen 3.5 9B ausprobiert, aber am Ende ist sie wegen Speichermangel abgestürzt; nach dem Wechsel auf GGUF mit llama.cpp lief es ohne Abstürze.
Mit Frontier-Modellen ist das überhaupt nicht vergleichbar. Es ist viel langsamer, liegt schon bei Basisinformationen daneben und schafft nichttriviale Aufgaben nicht in einem Durchgang.
Als ich eine Zusammenfassung der Projektarchitektur erstellen ließ, behauptete es, das Repository verwende Bibliotheken, die dort nirgends vorkommen. Das mag für jeden anders aussehen, aber es hat trotzdem einen gewissen Nutzwert, und ich hoffe, dass lokale LLM-Umgebungen mit der Zeit auch auf vernünftiger Hardware deutlich besser werden.
Lokale LLMs sind großartig, aber wenn man viele Beiträge dazu liest, kann leicht der Eindruck entstehen, sie seien fast auf dem Niveau von Opus 4.7.
Auf HN gibt es eine sehr kleine, laute und begeisterte Gruppe, die die Fähigkeiten lokaler LLMs stark übertreibt.
Unter gleich großen Modellen gehörte es zu den schnellsten, die ich lokal auf einer GPU ausprobiert habe, allerdings nur auf Nvidia-Karten.
Später habe ich gesehen, dass es ein MoE mit nur 3,6B aktiven Parametern ist, was vieles erklärt.
Es ist hilfreich, realistisch zu betrachten, was man mit lokalen Modellen machen kann, vor allem mit so kleinen Modellen wie dem 9B des Autors.
Ein 9B-Modell ist ungefähr auf dem Niveau von Sonnet 3.6, also gut für Autocomplete und kleine Funktionen, aber sobald es ein größeres Problem verstehen soll, verliert es den Faden.
Trotzdem ist es interessant und macht Spaß, damit zu experimentieren. Ich baue aus Spaß viele Dinge wie lokale Agent-Harnesses.
Mein aktuelles Projekt ist ein Agent ohne Installation: https://gemma-agent-explainer.nicklothian.com/
Python, SQL und React laufen komplett im Browser. Für die beste Erfahrung empfehle ich Gemma E4B.
Es ist noch aktiv in Entwicklung, und wegen der Unterstützung für die HTML5 Filesystem API und LiteRT wird Chrome benötigt. Die meisten Chromium-basierten Browser könnten aber ebenfalls unterstützt werden.
Der Unterschied zu den meisten anderen Agenten ist, dass er keine Installation benötigt. Das Modell läuft mit LiteRT/LiteLLM im Browser und ist performanter als Transformers.js. Über die Filesystem API ist auch optionaler Lesezugriff auf ein Sandbox-Verzeichnis möglich.
Es ist selbst dokumentierend, sodass man im Live-Hilfepanel Fragen wie „Wie wird der System Prompt verwendet?“ stellen kann und Antworten erhält, weil es Zugriff auf den eigenen Quellcode hat.
Wenn man auf „Tour“ klickt, sieht man alles; nächste Woche soll es als Open Source veröffentlicht werden.
Allerdings ändern sich die Benchmarks, mit denen Leute Modelle bewerten, viel zu oft, weshalb gute Vergleiche schwer zu finden sind. Zur Einordnung: Sonnet 3.6 kam etwa ein Jahr nach GPT-3.5 heraus.
Wenn man kritisch ist, stimmt es natürlich, dass diese Modelle bei komplexen Coding-Aufgaben nicht auf dem Niveau der aktuellen Spitzengruppe sind.
Aber ein großer Teil der Büroarbeit besteht aus Dingen wie Excel-Bearbeitung, Dateiverschiebungen, der Übersetzung trockener juristischer Dokumente, E-Mail-Entwürfen oder PowerPoint-Fleißarbeit.
Solche Aufgaben lassen sich mit Modellen ab 30–35B durchaus bewältigen, mit dem zusätzlichen Vorteil, dass Unternehmensdaten privat bleiben.
Wenn Leute über lokale Modelle sprechen, meinen sie eher die Modelle vom April dieses Jahres: Qwen 3.6 27B und, wenn die GPU zu schwach ist, qwen 35b a3b.
Diese Modelle kann man ernsthaft mit Modellen auf aktuellem Spitzenniveau vergleichen.
Ein bekanntes Beispiel ist der London-Whale-Fall von JPMorgan, bei dem ein Excel-Fehler zu einem Verlust von 6 Milliarden Dollar führte.
Ich denke über ein M5 Pro MacBook mit 18/20 Kernen und 64 GB RAM nach, aber es ist extrem schwer, echte Modell-Benchmarks zu finden.
Es wäre hilfreich, wenn jemand sagen könnte, wie viele Tokens pro Sekunde bei Q4- und Q6-Quantisierungen von Qwen 3.6 35B/A3B ungefähr zu erwarten sind.
Lokale Inferenz bewegt sich stark in Richtung MoE-Modelle, und bei vielen davon sind die Tokens pro Sekunde ordentlich, aber die Zeit bis zum ersten Token ist schrecklich.
Ich habe auf Bluesky einige willkürliche Einstellungen notiert, die ich auf einem 32-GB-M2-Studio nutze, und würde mich über Feedback freuen.
Ich bin jemand, der Dinge schlecht einschätzen kann, wenn ich sie nicht direkt vor Augen habe, daher teile ich das in der Hoffnung auf Hilfe.
https://bsky.app/profile/mooresolutions.io/post/3mliilyf2i22...
Auf einem M4 Pro 48GB lasse ich ein qwen 3.6 9b quantisiertes Modell laufen, und für einfache pi.dev/cc-basierte Entwicklung ist es gerade so brauchbar.
Für wirklich sinnvolle Arbeit scheint ein 128-GB-Desktop der Sweet Spot zu sein. Solche Maschinen sind derzeit allerdings schwer zu bekommen.
Lokal zu arbeiten macht Spaß, aber man darf nicht vergessen, dass die eigene Zeit auch nicht kostenlos ist.
Bei privaten Projekten wechsle ich zunehmend zu OpenRouter und betreibe selbst mit den größten qwen-Modellen ernsthafte Nutzung für weniger als 2–3 Dollar pro Tag.
Mit einem M4 Pro 48GB könntest du auch größere Modelle laufen lassen, daher wäre ein größeres Modell vielleicht sinnvoller, wenn Modellintelligenz der entscheidende Faktor für den Nutzen ist.
Dass ein dichtes 9B-Modell eher schwach ist, würde ich unterschreiben.
Ich habe die maximale Konfiguration des aktuellen M5 MacBook Pro und lokale Modelle ebenfalls getestet, und es ist meistens nur gerade so funktionsfähig.
Auf einer 4090 mit 24 GB nutze ich für qwen3.6:27B die aktuellen Speicheroptimierungen für Aktivierungen von turboquant/rotorquant und komme auf etwa 128K Kontext.
Ich würde sehr empfehlen, mindestens in diese Modellklasse hochzugehen. Die Kombination aus q4_xl+rotorquant ist ziemlich gut.
Es gibt auch Referenzcode, den man Agenten zum Ausprobieren geben kann.
https://github.com/rapatel0/rq-models
Ich halte es für sinnvoller, ein paar tausend Dollar für einen Mac auszugeben als für API-Abos.
Lokale Modelle ermöglichen es, jederzeit und überall zu arbeiten, ohne sich Sorgen um Datenschutzverletzungen machen zu müssen.