Lokale KI auf einem MacBook Pro mit 16 GB RAM: Was wirklich funktioniert

Ammar Najjar · Veröffentlicht am 14. Juni 2026

productivitytoolsmacosai

Lokale KI-Coding-Assistenten klingen verlockend: keine API-Kosten, Code bleibt auf der eigenen Maschine, und das Ganze kostenlos. Aber ein Setup, das auf einem 16-GB-MacBook-Pro-M1 wirklich gut läuft, erfordert mehr Trial and Error, als die meisten Guides zugeben.

Dieser Beitrag fasst Monate realer Tests mit verschiedenen Tools, Runtimes und Modellen zusammen. Das Ergebnis hat mich selbst überrascht.

Das Ziel

Ziel war eine lokale, abonnementfreie KI-Entwicklungsumgebung für:

• Architekturdiskussionen und Dokumentation
• Repository-Erkundung und Planung
• Code-Änderungen und Bugfixes
• ADRs und Obsidian-Notizen
• Angular-, NestJS-, .NET-, Docker- und Kubernetes-Projekte

Alles lokal, alles auf einem MacBook Pro mit 16 GB RAM.

Die größte Entdeckung

Bevor ich zu Vergleichen und Benchmarks komme, die wichtigste Erkenntnis vorweg:

Agent-Fähigkeit > Coding-Benchmark-Score

Ein Modell, das Dateien findet, Code bearbeitet, Tools einsetzt und mehrstufige Workflows durchführt, ist oft nützlicher als ein Modell mit höherem Benchmark-Score, das diese Dinge nicht zuverlässig beherrscht.

Diese eine Erkenntnis hat die Rangfolge von Modellen und Tools komplett umgekrempelt.

Bewertete Tools

Drei Coding-Agent-Frameworks wurden eingehend getestet:

Zwei lokale Modell-Runtimes wurden verglichen:

Tool-Vergleichsergebnisse

OpenCode

OpenCode hat den Testsieg davongetragen, weil es für agentische Workflows konzipiert ist. Es plant, erkundet Repositories, generiert Dokumente und schreibt langformatige Inhalte zuverlässig.

Stärken: Planung, Architekturanalyse, Dokumentation, Repository-Erkundung, langformatige Inhalte
Schwächen: Braucht größeres Context Windowing; Leistung hängt stark von der Tool-Use-Fähigkeit des Modells ab.

Aider: Die Enttäuschung

Aider hat einen guten Ruf für Code-Bearbeitung. Mag in anderen Setups verdient sein. In diesem Workflow hat es deutlich enttäuscht.

Ein simpler Prompt wie Create a file containing one line: hello führte dazu, dass Aider irgendein JavaScript generierte, statt die Datei zu erstellen. Auch bei der Dateisuche und Dokumentation versagte es.

Fazit für diesen Workflow: nicht empfohlen.

Continue.dev

Das einfachste der drei. VSCode-Erweiterung installieren, auf ein lokales Modell zeigen, fertig. Prima für IDE-Chat, schnelle Erklärungen und Autocomplete. Nicht geeignet für Architekturarbeit oder alles, was mehrstufige Überlegungen braucht.

Runtime-Vergleich

Die Runtime erwies sich als wichtiger als gedacht.

Was mit Ollama und OpenCode schief lief

Bei der Verbindung von OpenCode mit lokalen Modellen über Ollama traten mehrere Probleme auf:

• Manche Modelle gaben gar keine Antwort zurück
• Manche Antworten brachen mitten in der Ausgabe ab
• Context-Handling war undurchschaubar, nie klar, was wirklich geladen war
• OpenCodes Agent-Prompt überforderte die kleinen Kontexte
• Inkonsistente Ergebnisse über verschiedene Sitzungen hinweg

Warum LM Studio besser funktioniert

Nach dem Umstieg auf LM Studio verschwanden die Probleme größtenteils:

• Die exakte geladene Modell-ID war via /v1/models einsehbar
• Die Context-Länge war sichtbar und in der UI konfigurierbar
• Die OpenAI-kompatible API machte Fehlersuche einfach
• Modelle, die via Ollama versagten, liefen mit LM Studio einwandfrei

Wichtige Erkenntnis: Die Modelle selbst waren nicht das Hauptproblem. Die Kombination Ollama und OpenCode war auf dieser Maschine weniger zuverlässig. LM Studio und OpenCode harmonierten mit denselben Modellen deutlich besser.

Du kannst jederzeit überprüfen, was LM Studio ausliefert:

curl http://localhost:1234/v1/models

Modellvergleich

Tool-Use-Tests in der Praxis

Einer der aufschlussreichsten Tests: einfach jedes Modell bitten, mit OpenCodes Tools Dateien zu erstellen und zu bearbeiten.

gemma4 verweigerte Bearbeitungsaufgaben, obwohl es die verfügbaren Tools sah. llama3.1:8b funktionierte, aber der Ressourcenverbrauch stand in keinem Verhältnis zum Nutzen.

qwen2.5-coder:7b schneidet bei Coding-Benchmarks gut ab, zeigt in der Praxis aber gemischten Tool Use und blieb als OpenCode-Agent hinter den Erwartungen zurück. Die Kernaussage: Benchmark-Scores sind kein Indikator für Agent-Fähigkeit.

qwen3.5:9b ist das Hauptmodell: starke Argumentation, zuverlässiger Tool Use, exzellent für Architektur und Dokumentation. qwen3.5:2b ist der schnelle Begleiter für schnelle Aufgaben und Notizen.

Das Context-Window-Problem

Eine der wichtigsten und überraschendsten Erkenntnisse.

OpenCode braucht mehr Kontext als gedacht

Beim Verbinden von OpenCode mit einem Modell mit 8k Kontext erschien sofort dieser Fehler:

n_keep: 26460 >= n_ctx: 8192

Später, nach Reduktionsversuchen:

n_keep: 8232 >= n_ctx: 8192

OpenCodes initialer System-Prompt übersteigt allein 8k Tokens. Das bedeutet: das Modell hat nie die erste Nachricht des Benutzers erhalten. Der Kontext war bereits voll, bevor das Gespräch begann.

Die Lösung: LM Studio Context auf 32.768 Tokens setzen und in der OpenCode-Modellkonfiguration angleichen.

Empfohlene Context-Größen

Der finale Stack

Nach all diesen Tests hat das empfohlene Setup drei Modi:

Primär: Architektur- & Dokumentationsarbeit

OpenCode + LM Studio + qwen3.5:9b
Context: 32,768

Verwendung für: Architektur-Reviews, Dokumentation, ADRs, Planung, Repository-Erkundung, Obsidian Notizen

Schnellmodus: Schnelle Aufgaben

OpenCode + LM Studio + qwen3.5:2b
Context: 32,768

Verwendung für: schnelle Fragen, Notizen, Zusammenfassungen, Repository-Erkundung

IDE-Begleiter

Continue.dev + LM Studio oder Ollama + qwen3.5:2b
Context: 8,192

Verwendung für: IDE-Chat, Code-Erklärungen, Autocomplete, kleine Bearbeitungen

Schnellentscheidungstabelle

Installation

Ollama (für Continue.dev)

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3.5:2b

LM Studio (für OpenCode)

Von der offiziellen LM-Studio-Website herunterladen. qwen3.5:9b für die primäre Arbeit oder qwen3.5:2b für den Schnellmodus laden, Context auf 32.768 setzen und den lokalen Server starten.

Tipp: LM Studios Zen Modelle sind auf Maschinen mit wenig RAM besonders effektiv. Für Apple Silicon optimiert und einen Versuch wert, wenn du gute Leistung ohne Speicherlimits erreichen willst.

Überprüfe, dass der Server läuft:

curl http://localhost:1234/v1/models

OpenCode

curl -fsSL https://opencode.ai/install | bash

Konfiguriere ~/.config/opencode/opencode.json um auf LM Studio zu zeigen. Der Modellname in der Konfiguration muss mit der exakten id übereinstimmen, die von /v1/models zurückgegeben wird:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio Local",
      "options": {
        "baseURL": "http://localhost:1234/v1"
      },
      "models": {
        "qwen/qwen3.5-9b": {
          "name": "Qwen 3.5 9B (Main)",
          "limit": {
            "context": 32768,
            "output": 2048
          }
        },
        "qwen/qwen3.5-2b": {
          "name": "Qwen 3.5 2B (Fast)",
          "limit": {
            "context": 32768,
            "output": 2048
          }
        }
      }
    }
  }
}

Continue.dev

Continue-Erweiterung in VSCode installieren und auf LM Studio oder Ollama mit qwen3.5:2b ausrichten.

Gelernte Lektionen

Zukünftiger Upgrade-Pfad

Bei Upgrade auf 32 GB RAM: größere Modelle und größere Kontexte evaluieren.

Bei Upgrade auf 64 GB RAM: 32B-Klasse Modelle und 64k-Kontexte neu bewerten.

Auf 16 GB RAM: speicherintensive Anwendungen (Docker Desktop, viele Browserfenster, IDE-Indizierung) nicht gleichzeitig mit einem geladenen 9B-Modell betreiben.

Fazit

Die größte Entdeckung war kein Modell, sondern eine Kombination:

OpenCode + LM Studio lieferte eine wesentlich bessere Erfahrung als jedes andere getestete Setup.

Das Setup, das auf einem 16-GB-MacBook-Pro-M1 funktioniert:

• OpenCode für Denken, Planen und Schreiben
• Continue.dev für IDE-Support und Autocomplete
• LM Studio als OpenCode-Runtime
• 32k Context für OpenCode, 8k für Continue.dev
• qwen3.5:9b als Hauptmodell, qwen3.5:2b für schnelle Aufgaben

Das Prinzip, das jede Entscheidung geleitet hat: Agent-Fähigkeit schlägt Benchmark-Scores.

Nach oben