Lokale Modelle auf einem M4 mit 24 GB Arbeitsspeicher ausführen

• Auch auf einem M4 MacBook Pro mit 24 GB lässt sich eine Konfiguration lokaler Modelle für grundlegende Aufgaben, Recherche und Planung einrichten
• Qwen 3.5-9B Q4 erreicht etwa 40 Token/Sekunde und bietet Thinking-Modus, Tool-Nutzung sowie 128K Kontext
• Es kann komplexe Probleme nicht so lange selbstständig lösen wie Spitzenmodelle, daher sind schrittweise Anweisungen nötig
• Elixir-Credo-Warnungen wurden behoben, aber das Lösen von Rebase-Konflikten scheiterte ohne Dateibearbeitung
• Lokale Modelle haben Vorteile wie Offline-Nutzung und keine Abokosten, bringen aber große Trade-offs bei Leistung und Konfiguration mit sich

---

Laufzeitumgebung für lokale Modelle und Auswahlkriterien

• Auf einem M4 MacBook Pro mit 24 GB Arbeitsspeicher wurde mit Setups zum Ausführen lokaler Modelle experimentiert. Zwar unterscheiden sich die Ergebnisse von Ausgaben führender SOTA-Modelle, aber eine Konfiguration für grundlegende Aufgaben, Recherche und Planung ohne Internetverbindung war möglich
• Als Tools für die lokale Ausführung stehen Ollama, llama.cpp und LM Studio zur Verfügung, jeweils mit unterschiedlichen Einschränkungen und Modellangeboten
• Bei der Modellauswahl musste es in den Speicher passen und zugleich genug Spielraum lassen, um übliche Electron-Apps parallel auszuführen; benötigt wurde ein Kontextfenster von mindestens 64K, idealerweise 128K oder mehr
• 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 Schwierigkeiten bei der Tool-Nutzung
• Die Konfigurationsoptionen reichen von bekannten Werten wie temperature bis hin zu speziellen Optionen wie K Cache Quantization Type; je nachdem, ob Thinking aktiviert ist, können andere Werte passend sein

Qwen 3.5-9B in 4-Bit-Quantisierung

• qwen3.5-9b@q4_k_s war in LM Studio das beste Modell, das gleichzeitig etwa 40 Token/Sekunde, aktiviertes Thinking, erfolgreiche Tool-Nutzung und ein 128K-Kontextfenster bot
• Es verliert leichter den Fokus als Spitzenmodelle, gerät gelegentlich in Schleifen und interpretiert Anfragen manchmal falsch, war aber für ein Modell, das auf einem MacBook Pro mit 24 GB noch Raum für andere Arbeitsbereiche lässt, ziemlich brauchbar
• 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 in die configuration gewechselt und unten im Inference-Tab der folgende Wert zum Prompt Template hinzugefügt werden

{%- set enable_thinking = true %}

• Dieses Modell wurde sowohl mit pi als auch mit OpenCode verwendet. pi fühlte sich reaktionsschneller an, bot aber trotz des Vorteils, ein eigenes Harness direkt aufbauen und anpassen zu können, zu wenige sinnvolle Standardwerte
• Es konnte passieren, dass mehr Zeit in die Abstimmung von pi floss als in das eigentliche Projekt

pi-Konfiguration

• In ~/.pi/agent/models.json wurde der OpenAI-kompatible Endpunkt 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 ablenkende Thinking-Blöcke auszublenden, wurde "hideThinkingBlock": true zu ~/.pi/agent/settings.json hinzugefügt

OpenCode-Konfiguration

• In ~/.config/opencode/opencode.json wurde LM Studio als lokaler OpenAI-kompatibler Provider eingetragen und Tool-Nutzung, 131072 Kontextlänge sowie 32768 maximale Token festgelegt

{
  "$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"
}

Unterschiede zu Spitzenmodellen

• Modelle wie Qwen 3.5 9B Q4 konnten komplexe Probleme nicht über längere Zeit so eigenständig lösen wie Spitzenmodelle
• Ein kompletter App-Build auf einmal war keine geeignete Anforderung; im schlimmsten Fall wurde nur das Notebook heiß, ohne Ergebnis zu liefern
• Besser geeignet war ein interaktiver Workflow mit klarer Kommunikation in einzelnen Schritten und vielen konkreten Anweisungen
• Beim Einsatz lokaler Modelle muss der Nutzer mehr Denken und Planung selbst übernehmen und präzisere Anweisungen geben, aber als Recherchehilfe, Rubber-Duck und Assistent zum schnellen Abrufen von Details zu Programmiersprachen und Kommandozeilenaufrufen waren sie nützlich
• Es ist keine von großen AI-Unternehmen beworbene Verzehnfachung der Produktivität, aber es bietet sinnvolle Unterstützung und ein interessantes Nutzungserlebnis

Aufgaben, die funktionierten, und Aufgaben, die scheiterten

• Behebung von Elixir-Credo-Warnungen

  • Nach dem Update des Elixir-Linters credo auf die neueste Version traten Warnungen im Code auf, und Qwen wurde gebeten, mix credo --strict auszuführen und Lösungsvorschläge zu machen, jedoch ohne Änderungen vorzunehmen
  • Qwen fand an vier Stellen in Testdateien das Problem, dass mit length/1 geprüft wurde, ob Listen nicht leer sind, und schlug vor, statt length(list) > 0 besser list != [] zu verwenden
  • Als danach um die Bearbeitung gebeten wurde, führte Qwen vier parallele Änderungen sauber aus
  • Diese Aufgabe war zwar einfach genug, um sie selbst zwischen Terminal und Editor zu erledigen, diente aber als praktische Unterstützung

• Umgang mit Rebase-Konflikten in einer Dependabot-PR

  • Nach einem Dependency-Update gab es Git-Konflikte in einer Dependabot-PR. Da Dependabot den Rebase verweigerte, wurde der Branch manuell heruntergeladen und rebased, anschließend wurde Qwen um Prüfung gebeten
  • Die Konflikte waren einfach gelagert: Es mussten jeweils nur die neueren Versionen der einzelnen Abhängigkeiten gewählt werden. Qwen empfahl, sentry auf 13.0.1 und tailwind auf 0.4.1 zu belassen
  • Als jedoch die tatsächliche Änderung verlangt wurde, versuchte Qwen git add mix.lock && git rebase --continue auszuführen, obwohl die Konfliktmarker noch vorhanden waren und keine Datei geändert worden war
  • Auch dass git rebase --continue einen Editor öffnet, wurde nicht erkannt; OpenCode blieb hängen, wobei dieses Verhalten auch ein Einzelfall gewesen sein könnte

Vorteile und Grenzen lokaler Modelle

• Lokale Modelle bringen große Trade-offs mit sich, haben aber den Vorteil, dass sich auch im Flugzeug ohne Internetverbindung arbeiten lässt
• Wenn der Rechner ohnehin angeschafft wird, beschränken sich die Kosten auf den Stromverbrauch, und ein Abonnement ist nicht nötig
• Das Training der Modelle verursacht weiterhin hohe Umweltkosten, doch Open-Model-Unternehmen liegen beim Umwelteinfluss weit entfernt von der Spitzengruppe, und mit eigener Hardware sinkt die Abhängigkeit von Rechenzentren
• Es macht Spaß, selbst an den Einstellungen zu feilen und zu experimentieren
• LLMs haben bereits großen Einfluss ausgeübt und bringen viele negative Seiten mit sich, wirken aber dennoch wie eine Technologie, die bleiben wird; Experimente mit lokalen Modellen fühlten sich wie ein Weg an, mit dieser Technologie nachhaltiger und positiver zu interagieren

[GN⁺]

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.

  • Stimmt. Gerade in den letzten 6 Monaten sind Abogebühren für Frontier-Modelle für viele zu Betriebskosten geworden.
    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.
  • Inzwischen ist es technisch einfach geworden, zu Hause große Modelle für Offline-Zwecke zu betreiben. Einen großen Anteil daran hat China, wo Top-Modelle offen veröffentlicht werden.
    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.

  • Gemma 4 ist wirklich gut. Es hat schon Dinge richtig getroffen, die Opus 4.7 verpasst hat, und obwohl es Ecken und Kanten hat, finde ich laufend Einsatzfälle, in denen es praktisch gleichwertig nutzbar ist.
    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.
  • Die kleinen Qwen-3.6-Modelle sind bei der Kontextverarbeitung etwas besser als Gemma 4, aber besonders Gemma 4 26B ist clever darin, in dieser Größenklasse eine sehr kleine und effiziente Lösung zu liefern.
    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
  • Für die meisten Editieraufgaben nutze ich das kleinere Gemma E2B, und es funktioniert überraschend gut.
    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.
  • Es wäre hilfreich, wenn du die Zeit bis zum ersten Token und die Tokens pro Sekunde teilen könntest.
  • Mich würde interessieren, ob sich Gemma gefühlt besser verhält als qwen3.

• 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.

  • Der Satz „mit Frontier-Modellen überhaupt nicht vergleichbar“ wird nicht oft genug gesagt.
    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.
  • Statt qwen3.5 9b sollte man qwen3.6.35 a3b ausprobieren. Das ist eine völlig andere Liga.
  • Dass GPT OSS 20B auf Mac-Hardware langsam läuft, überrascht mich ziemlich.
    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.

  • Mit Sonnet 3.5 habe ich weit mehr gemacht als nur Autocomplete und kleine Funktionen.
  • Ohne kleinlich sein zu wollen, aber viele 4–12B-Modelle liegen irgendwo zwischen GPT-3.5 und GPT-4o-mini.
    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.

  • Ich glaube, die Schlussfolgerung ist etwas falsch. Dass qwen3.5 9b weit von aktuellen Modellen entfernt ist, ist selbstverständlich. Es ist ein 9B-Modell und etwa ein Jahr alt, oder?
    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.
  • Excel und juristische Texte können sogar deutlich schlimmer sein als Code. Dort sind Fehler unter Umständen schwerer zu erkennen.
    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.

  • Man sollte nicht nur auf die Tokens pro Sekunde schauen, sondern auch auf die Zeit bis zum ersten Token.
    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.

  • War der Grund für das so kleine Modell die hohe Tokenrate pro Sekunde?
    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.
  • Auf derselben Konfiguration nutze ich ein 30B-MoE-Modell mit 65K Tokens als Sub-Agent mit Tools, und es schreibt ziemlich guten Code.
    Dass ein dichtes 9B-Modell eher schwach ist, würde ich unterschreiben.
  • Online liest man viel Unsinn in der Richtung, lokale Modelle seien besser als Opus 4.7. Für normale Nutzer stimmt das einfach nicht.
    Ich habe die maximale Konfiguration des aktuellen M5 MacBook Pro und lokale Modelle ebenfalls getestet, und es ist meistens nur gerade so funktionsfähig.
  • Mich würde interessieren, wie die OpenRouter-Version im Vergleich zu ChatGPT 5.5 oder Claude Opus 4.6 abschneidet.

• 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.