Lokale LLMs für agentisches Coding nutzen

• Angesichts stark steigender Preise für Cloud-Flagship-Modelle eine Übersicht darüber, wie sich lokale Modelle fürs Coding ohne hohe Kosten nutzen lassen
• Lokale Modelle erreichen zwar nicht die Leistung von SOTA-Modellen, aber mit gutem Preis-Leistungs-Verhältnis und einer verstärkten deterministischen Harness lässt sich die Qualität um bis zu das 6-Fache steigern
• Für Coding bietet Gemma 4 eine gute Balance zwischen allgemeinen Aufgaben und Codegenerierung und eignet sich dank Unterstützung für Tools Use, Vision und Reasoning gut für die Integration in VS Code
• Enthält die vollständige Einrichtung, um mit LM Studio einen Modellserver zu starten und ihn mit benutzerdefinierten Endpunkten in VS Code Copilot und Pi zu verbinden
• Wenn die Hardware nicht ausreicht, können kostenlose Modelle über OpenRouter als Alternative dienen; lokale Modelle bleiben jedoch bei Offline-Nutzung und Datenschutz im Vorteil

---

Hintergrund der Preiserhöhungen

• GitHub Copilot ist vom Kreditmodell auf nutzungsbasierte Abrechnung umgestiegen, und selbst bisher kostenlose Modelle sind nicht mehr gratis
• Da GitHub ein Token-Reseller ist, fällt die Preissteigerung noch stärker auf. Flagship-Modelle erscheinen, ohne dass ihre Leistungssteigerung mit dem Tempo der Preissteigerung mithält
  • Google Flash 3.5 ist dreimal teurer als Flash 2.5
  • GPT 5.5 ist dreimal teurer als GPT 5
  • Claude wurde im Preis sogar gesenkt, weil es bereits zu teuer war

Realität und Stärken lokaler Modelle

• Lokale Modelle kommen nicht an die Leistung von SOTA-Modellen wie Claude, GPT oder Gemini heran, aber es gibt einige Nuancen
  • Preis-Leistungs-Verhältnis: Bei Cloud-Modellen steigen die Kosten im Verhältnis zum Leistungsgewinn exponentiell
  • Deterministische Harness: Mit besserem Tooling und klareren Anweisungen lässt sich die Qualität schwächerer Modelle um bis zu das 6-Fache verbessern
  • Die Benchmark-Falle: Modelle lassen sich nicht sinnvoll auf eine einzelne Zahl reduzieren, und jedes AI-Lab fokussiert Benchmarks, die den eigenen Modellen liegen; deshalb sollte man mit dem eigenen Workload selbst testen
  • Geopolitische Effekte: Was US-Labs gratis veröffentlichen, ist nicht das Beste vom Besten. gpt-oss-20b ist zu alt, und Anthropic veröffentlicht keine Open Weights. Gemma 4 ist das einzige wirklich ernstzunehmende Modell; außerdem lohnt sich ein Blick auf leistungsfähige offene Modelle chinesischer Labs wie Qwen, Kimi und GLM
• Aus Sicht des „brain rot“-Phänomens sind schwächere Modelle sogar gut für die geistige Fitness, weil der Nutzer stärker eingreifen muss
  • Es ist wie Fahrradfahren: langsamer, aber gesünder. Bei Wissensarbeit gilt oft: „slow is fast“
  • Das Ziel ist nicht, Denken maximal an Maschinen auszulagern. Für kurzfristige Geschwindigkeit sollte man nicht die eigene zukünftige Relevanz opfern
  • Techniken für schwächere Modelle funktionieren auch bei großen Modellen. Mit schwachen Modellen zu arbeiten ist wie Hard-Mode spielen: Wer das beherrscht, nutzt große Werkzeuge später effektiver

Modellauswahl — Gemma 4

• Für Coding dominieren chinesische Modelle die Spitzenplätze auf dem Hugging Face Leaderboard, darunter Qwen, DeepSeek, Kimi, Llama und Gemma
• Gemma 4 besteht aus mehreren Varianten
  • E2B: Das „E“ steht für Edge. Mit 2B Parametern läuft es auf den meisten Systemen, birgt aber ein hohes Risiko für Halluzinationen oder unvollständige Aufgaben
  • E4B: Doppelt so groß wie E2B. Günstig beim Download und in der Einrichtung, daher empfohlen für den Einstieg
  • 12B: Versteht Bilder nativ ohne Decoder und ist dadurch bei Frontend- und visuellem Coding schneller. Audio wird ebenfalls nativ unterstützt, ist für Coding-Workloads aber weniger relevant
  • 26B A4B: Eine MoE-Architektur (mixture of experts), bei der von 26B Parametern nur 4B aktiv sind. Intelligenter als E4B und passend für Grafikkarten mit 8–12 GB VRAM (bevorzugtes Modell des Autors)
  • 31B: Googles größtes Open-Weight-Modell. Kein MoE, benötigt daher viel VRAM. Auf einer AMD-APU mit 1–2 TPS praktisch unbenutzbar
  • QAT-Varianten (z. B. E4B QAT) benötigen weniger Speicher bei nahezu gleicher Qualität. Unsloth arbeitet an weiteren Optimierungen

Komponenten für den Betrieb lokaler Modelle

• Für lokale Modelle braucht man Harness, Modell, Runtime und Modellmanager
  • Harness: VS Code Copilot, Copilot CLI, Pi usw. Das sind deterministische Komponenten (klassischer Code) rund um das Modell als probabilistisches Element
  • Modell: Gewichtungsdateien eines tiefen neuronalen Netzes. Quantisierung (Q8, Q4 usw.) ist konzeptionell ähnlich wie Bildauflösung; Formate sind etwa GGUF oder MLX

• Runtime (Inference Engine)

  • Llama.cpp: Die populärste Open-Source-Runtime, lädt GGUF und MLX. Hat nichts mit Metas Llama-Modellen zu tun und wird intern von LM Studio verwendet
  • MLX: Apples Runtime für Macs mit M1, M2 usw.
  • ONNX Runtime: Läuft über transformers.js im Browser via WebGPU und unterstützt auch iOS- und Android-Geräte
  • vLLM: Open Source aus dem Umfeld von UC Berkeley, primär für leistungsstarke Server gedacht und schwerer einzurichten

• Modellmanager

  • Ollama: Begann als Terminal-CLI und bekam später eine leichte GUI. Ein in Go geschriebener Wrapper um Llama.cpp. Open Source
  • LM Studio: Kostenlos, aber nicht Open Source. Bietet SDKs für Python und TypeScript sowie eine REST API und kann spezifische Funktionen lokaler Modelle wie dynamisches Laden steuern
  • Jan: Kostenlos und Open Source, eine ähnliche Alternative zu LM Studio mit weniger Funktionsumfang
  • Unterstützung für eine OpenAI-kompatible API ist die Schlüsselfunktion, da viele AI-Anwendungen mit diesem De-facto-Standard arbeiten

LM-Studio-Server einrichten

• Den Server per Schalter im „Developer“-Button starten. Für den Betrieb auf anderen Maschinen oder in Containern Serve on Local Network aktivieren, für Web-App-Zugriffe Enable CORS
• LM Studio verwendet JIT-Laden (Just In Time) und lädt Modelle erst bei einer Anfrage. Über TTL lässt sich steuern, wie lange sie im Speicher bleiben
  • Cold Start: Wenn ein Modell noch nicht geladen ist, dauert die erste Anfrage etwa 10–30 Sekunden länger, ähnlich wie bei AWS Lambda. Das beeinflusst die Kennzahl TTFT (Time To First Token)
  • Kurzes Kontextfenster: In der Standardeinstellung kann das Kontextfenster nur 4k betragen und muss manuell erhöht werden. Die meisten VS-Code-Copilot-Modelle haben 200–400k

• Kontextlänge und Speichereinstellungen

  • VRAM-Bedarf je Kontextlänge: 262144 (Maximum) = 25.74 GB, 4096 (Standard) = 18.16 GB, 150000 (bevorzugt vom Autor) = 22.45 GB
  • Für Coding belegt der System-Prompt oft 20–40k Token, daher sollten mindestens 100k Token geladen werden
  • Ein zu großes Kontextfenster verlangsamt die Tokengenerierung. Optimal ist der Punkt, an dem die Harness den Kontext automatisch komprimiert
  • Idealerweise laufen alle Modell-Layer auf der GPU; empfohlen wird, den Schieberegler für GPU Offload auf das Maximum zu setzen. CPU-Layer erfordern außerhalb von Apple Silicon (UMA) Datenkopien zwischen CPU und GPU

• KV-Cache-Quantisierungstrick

  • K Cache Quantization Type auf Q8_0, V Cache Quantization Type auf Q4_0 setzen
  • Dabei bleiben die Keys in höherer Auflösung als die Values. So sinkt der GPU-Speicherbedarf von standardmäßig 28.75 GB auf 22.45 GB
  • Die Einstellungen müssen gespeichert werden; sonst fallen sie beim nächsten Modell-Ladevorgang auf die Standardwerte zurück
  • VS Code Copilot kennt keine benutzerdefinierten Kontextfenster pro Anfrage, daher muss LM Studio sich die Einstellung für REST-API-Aufrufe merken
• Liegt die TPS unter 10, ist das fürs Coding kaum noch praktikabel, weil man mehr Zeit auf das Warten auf das Modell verwendet

Copilot mit benutzerdefiniertem Endpunkt verbinden

• Erfordert eine aktuelle VS-Code-Version (zum Zeitpunkt des Schreibens 1.122.1). Hinzufügen über Modellwähler → Zahnrad → „Add Models“ → „Custom Endpoint“
  • Namen vergeben (z. B. „Local LM Studio“), API Key eingeben (oder Enter, falls keiner gesetzt ist), dann die Form des Inference-API wählen
  • Von den drei API-Typen funktioniert nur Chat Completions reibungslos
• In der JSON-Konfiguration Werte wie url, maxInputTokens und maxOutputTokens manuell setzen
  • Die Option thinking korrekt konfigurieren (wird von Gemma 4 unterstützt)
  • Das Array supportsReasoningEffort ist modellabhängig; die 26B-Version bietet feinere Kontrolle als E4B
  • Für 4B: maxInputTokens 64000 / maxOutputTokens 16000, für 26B MoE: 100000 / 50000
• Beim ersten Prompt sendet Copilot einen riesigen System-Prompt samt Tool-Definitionen, wodurch es bei der ersten Interaktion zu 2–5 Minuten Verzögerung kommt. Das Laden des Modells dauert 30 Sekunden, die Verarbeitung des Prompt-Eingangs etwa 5 Minuten
  • Das passiert nur einmal pro Sitzung, da LM Studio Prompt-Caching anwendet. Pi hat dieses Problem nicht, weil sein System-Prompt klein ist

• Schneller Test und Umgebung

  • Ohne AGENTS.md oder SKILL wird per One-Shot-Prompt ein Snake-Spiel erzeugt, um die Leistung von Gemma 4 26B A4B zu demonstrieren
  • Verwendete Umgebung: Lenovo ThinkPad L16 Gen 2, AMD Ryzen 7 PRO 250 APU, 64 GB DDR5 (5,600 MT/s), Aurora Linux. Der Autor hält auch 32 GB für ausreichend

Pi einrichten

• Die Verbindung zum lokalen LM-Studio-Server ist einfach, und die Einstellung contextWindow passt besser zum Konfigurationsmodell von LM Studio
• baseUrl auf http://host.containers.internal:1234/v1 und api auf openai-completions setzen
  • Für 4B contextWindow 64000 / maxTokens 16000, für 26B MoE 150000 / 50000, zusätzlich eine Zuordnung über thinkingLevelMap definieren

Vor- und Nachteile lokaler Modelle

• Vorteile: Offline-Betrieb, hoher Datenschutz, schnelle Reaktionszeiten je nach Hardware, Workflow, Modell und Konfiguration
• Nachteile
  • Open-Weight-Modelle sind nicht so intelligent wie proprietäre Flagship-Modelle, aber mit einer geeigneten Harness samt Guardrails (lint, Tests, AGENTS.md) lässt sich die Coding-Genauigkeit stark verbessern
  • Wenn das LLM auf derselben Maschine läuft, führt die Hardwarelast zu Leistungseinbußen
  • Cold Starts, die Verarbeitung des ersten Prompt-Eingangs (Cache Miss) und hohe anfängliche Hardwarekosten
• Wer mit LM Studio vertraut ist, kann später auch direkt ohne GUI mit Llama.cpp arbeiten. Die meisten Harnesses unterstützen benutzerdefinierte Endpunkte und lassen sich daher mit lokalen LLMs verbinden

OpenRouter als kostenlose Modell-Alternative

• OpenRouter ist ein einheitlicher API- und Routing-Dienst, der über einen einzigen Endpunkt und Account Hunderte von Modellen zugänglich macht
• Copilot, Zed und Pi unterstützen OpenRouter nativ; man muss nur ein API-Token erzeugen und verbinden
  • Um Kostenexplosionen zu vermeiden, wird empfohlen, ein benutzerdefiniertes Guardrail mit einem Limit von 1 US-Dollar pro Monat anzulegen und nur kostenlose Modelle auf die Allowlist zu setzen
  • Beim Erstellen eines neuen API-Schlüssels sollte max credit auf 0 gesetzt werden
• Nachteile: Prompts und Daten können fürs Training verwendet werden (es gibt eine ZDR-Einstellung), Internetverbindung ist erforderlich, und OpenRouter könnte kostenlose Modelle künftig einstellen
• Vorteile: Kein lokaler Download und keine Einrichtung nötig, außerdem wird der laufende Rechner nicht langsamer

• Update 2026-06-09

  • Es wird nun Deepseek V4 Pro verwendet. Die Leistung liegt fast auf dem Niveau von Claude Opus 4.8, bei einem 5-fach größeren Kontextfenster und etwa 17- bis 86-fach niedrigeren Kosten
  • Zwischen Pi und OpenRouter gab es einen Preisunterschied von etwa dem Faktor 3, weil OpenRouter Anfragen an den teureren Endpunkt GMICloud weitergeleitet hatte
  • Für komplexe Aufgaben wurde direkt ein Deepseek-Konto eröffnet. Für einfache Aufgaben, zum Verständnis von Verhalten und in datenschutzsensiblen Szenarien bleiben lokale Modelle dennoch die erste Wahl

[kurthong]

Passend zum Zeitalter der großen LLMs nutze ich ein selbst erstelltes Plugin. Ich hatte es auch schon einmal bei der GN SHOW vorgestellt, und ich denke, es ist ebenfalls eine gute Möglichkeit, es so an die eigenen Bedürfnisse anzupassen und zu verwenden.

https://github.com/hang-in/tunaLlama

[click]

Letztlich lief es auf die Erkenntnis hinaus, dass man statt lokaler Modelle dann doch zu deepseek v4 pro gewechselt ist.
Es ist auch nicht gerade einfach, bei jeder Aufgabe ständig das Modell zu wechseln, daher war es letztlich auch schwierig, an der Strategie festzuhalten, für einfache Arbeiten lokal laufende Modelle zu verwenden.