Ein lokales Coding-Modell mit llama.cpp betreiben und in VS Code einbinden

KI-Coding-Agenten können ein Repository lesen, Patches entwerfen, die Testsuite laufen lassen und Code erklären, den man nie gesehen hat, und Teams werden damit messbar schneller. Umstritten bleibt die Rechnung. Autonome Agenten verschlingen Token: Eine einzige Anfrage wie „refaktoriere dieses Modul und repariere die fehlschlagenden Tests“ kann hunderttausend Input-Token verbrauchen, bevor überhaupt Code entsteht.

Zwischen Bezahlung pro Token und dem Verzicht auf KI gibt es einen Mittelweg: das Modell selbst hosten. Ein Laptop mit dedizierter GPU kann über llama.cpp ein fähiges Coding-Modell betreiben, es als OpenAI-kompatible HTTP-API bereitstellen und über die Erweiterungen Cline oder Kilo Code mit VS Code verbinden. Jedes zusätzliche Token kostet nichts, und keine Daten verlassen das eigene Netz. Hier ein Setup, das funktioniert hat.

Was man vorher braucht

Hardware: Eine dedizierte NVIDIA-GPU ist dringend zu empfehlen, und mehr VRAM ist besser. Typische Firmenlaptops haben rund 8 GB, was reicht, wenn man Modell und Quantisierung sorgfältig wählt. Auch der Arbeitsspeicher zählt, denn einen Teil des Modells lagert man bewusst dorthin aus.

Software: Das CUDA Toolkit ab Version 13.3 von der NVIDIA-Downloadseite installieren, mit dem lokalen exe-Installer für die eigene Plattform. Es liefert die Bibliotheken und APIs, die VRAM reservieren und das Modell auf der Grafikkarte ausführen, und man braucht es auch, falls man llama.cpp irgendwann selbst kompiliert. Dazu kommen ein Browser und ein Hugging-Face-Konto zum Herunterladen der Gewichte.

llama.cpp besorgen

llama.cpp ist hier die Inferenz-Engine. Sie ist in C und C++ geschrieben, führt GGUF-Modelle effizient auf normaler Hardware aus, nutzt CUDA und bringt einen HTTP-Server mit, der die OpenAI-API nachbildet. Genau auf dieser Funktion beruht das ganze Setup.

Die Quellen gibt es im llama.cpp-Repository, vorkompilierte Binaries für Windows und Linux liegen auf der Releases-Seite. Den Build passend zur eigenen CUDA-Version herunterladen, zum Beispiel ein Paket win-cuda-13.3-x64. Kompilieren ist nicht nötig. An einen einfachen Ort entpacken, etwa D:\ai\.

Zwei ausführbare Dateien sind wichtig:

• llama-cli.exe bietet einen interaktiven Chat im Terminal, praktisch zum Prüfen der Installation.
• llama-server.exe startet einen HTTP-Server mit einem /v1-Endpunkt im OpenAI-Stil und einer Chat-Oberfläche im Browser.

Das Modell auswählen

Alles andere ist Mechanik. Bei der Modellwahl gewinnt oder verliert man. Von Hugging Face das Format .gguf herunterladen, denn das liest llama.cpp.

Das Modell zur Aufgabe passend wählen, statt zu erwarten, dass eines alles kann:

• Coding und Agentenarbeit in der IDE sind der anspruchsvolle Fall. Der Agent braucht gutes Befolgen von Anweisungen, verlässliche Tool-Aufrufe und ein großes Kontextfenster, um mehrere Dateien gleichzeitig zu halten. Qwen3.6 35B A3B schlägt sich hier gut und ist der Standard für Agentenarbeit in der IDE. Die GGUF-Builds gibt es im unsloth-Repository, und kleine dichte Modelle decken den Rest ab.
• Schnelle Fragen und Antworten, Zusammenfassungen und Commit-Messages erledigt ein deutlich kleineres dichtes Modell problemlos, und es fühlt sich flotter an. Cline und Kilo Code erlauben beide, für solche Nebenaufgaben ein leichtes kleines Modell getrennt vom Haupt-Coding-Modell festzulegen.
• Schlussfolgern über lange Dokumente verlangt eher Kontextlänge als Parameterzahl, und man sollte VRAM für den KV-Cache übrig lassen.

Mixture-of-Experts-Modelle bevorzugen. „A3B“ im Namen bedeutet 35 Milliarden Parameter insgesamt, aber nur etwa 3 Milliarden aktiv pro Token. Man bekommt das Wissen eines großen Modells fast mit der Geschwindigkeit eines kleinen, deshalb läuft ein MoE auf begrenzter Hardware einem dichten Modell vergleichbarer Qualität locker davon.

Die Quantisierung ehrlich wählen. Quantisierung ist der Kompressionsgrad der Gewichte: Je niedriger die Q-Zahl, desto kleiner die Datei und desto schlechter die Ausgabequalität. Die Dateigröße ist ein guter Anhaltspunkt dafür, wie viel VRAM und RAM das Modell belegt. Mit 4 bis 8 GB VRAM im Bereich Q4 bis Q2 suchen, etwa UD-IQ4_XS oder UD-IQ2_M. Wer unsicher ist, gibt einem beliebigen KI-Assistenten die eigenen Daten, zuerst VRAM, dann Arbeitsspeicher, und fragt, welche Quantisierung passt. Das dauert zwei Minuten und lohnt sich.

Zuerst ein Smoke-Test

Beweisen, dass der Stack läuft, bevor man VS Code anfasst. Eine Eingabeaufforderung im llama.cpp-Ordner öffnen und ausführen:

"D:\ai\llama-b9590-bin-win-cuda-13.3-x64\llama-cli.exe" -m "D:\ai\llms\Qwen3.6-35B-A3B-UD-IQ2_M.gguf"

Zwei Dinge prüfen. Erstens: Das Banner erscheint, das Modell lädt, man kann im Terminal chatten, und eine Token-Rate wird angezeigt. Auf einer Laptop-GPU RTX PRO 2000 waren es rund 18 Token pro Sekunde für den Prompt und 30 für die Generierung. Zweitens: Task-Manager öffnen, dann Leistung, dann GPU, und prüfen, dass der dedizierte GPU-Speicher nach oben springt. Bewegt er sich nicht, läuft das Modell auf der CPU, und es gibt ein CUDA- oder Treiberproblem. Das zuerst beheben, sonst wird alles Weitere unbrauchbar langsam.

Den Server starten

Jetzt geht es richtig los. llama-server stellt sowohl die Browser-Oberfläche als auch die API bereit, mit der die IDE spricht:

"D:\ai\llama-b9590-bin-win-cuda-13.3-x64\llama-server.exe" ^
  -m "D:\ai\llms\Qwen3.6-35B-A3B-UD-IQ2_M.gguf" ^
  --host 0.0.0.0 ^
  --port 8080 ^
  -ngl all ^
  -c 64000 ^
  -fa on ^
  --cache-type-k q4_0 ^
  --cache-type-v q4_0 ^
  --n-cpu-moe 22 ^
  -b 2048 ^
  -ub 2048 ^
  --no-mmap ^
  --reasoning off ^
  --reasoning-format none ^
  --reasoning-budget 0

Auf die Meldung warten, dass der Server auf Port 8080 lauscht und alle Slots frei sind, dann http://localhost:8080 im Browser öffnen und Hallo sagen.

Was die Flags tun

Den Befehl nicht blind kopieren. Genau diese Einstellungen dreht man, wenn ein Modell nicht passt.

• Grundlagen: -m ist die Gewichtsdatei, --port setzt den HTTP-Port für Oberfläche und API, und --host 0.0.0.0 bindet an alle Schnittstellen, damit sich andere Rechner im LAN verbinden können, während man lokal weiter localhost nutzt.
• Platzierung auf der GPU: -ngl all schiebt die Standardschichten, also Attention-Blöcke und Nicht-MoE-Gewichte, in den VRAM. --n-cpu-moe 22 hält die Expertengewichte von so vielen Schichten im Arbeitsspeicher, damit der VRAM nicht überläuft, und ist das wichtigste Stellrad auf einer kleinen GPU.
• Speicher und Kontext: -c 64000 begrenzt das Kontextfenster in Token, und mehr Kontext kostet mehr Speicher. -fa on aktiviert FlashAttention-Kernel, die die Prompt-Verarbeitung beschleunigen und den VRAM-Overhead senken. --cache-type-k und --cache-type-v mit q4_0 speichern Key- und Value-Cache in 4 Bit, eine große Ersparnis bei langem Kontext.
• Durchsatz: -b und -ub legen die Batchgröße für das Prompt-Prefill und den GPU-Mikrobatch fest. Für besten Durchsatz gleich halten. --no-mmap lädt das ganze Modell vorab in den physischen Speicher, statt es seitenweise nachzuladen.
• Reasoning-Ausgabe: --reasoning off, --reasoning-format none und --reasoning-budget 0 schalten die eingebaute Chain-of-Thought-Verarbeitung ab, halten Think-Tags aus dem Stream heraus und geben explizitem Reasoning ein Token-Budget von null.

Die letzte Gruppe ist wichtiger, als sie aussieht. Agent-Erweiterungen erwarten saubere, parsebare Tool-Call-Ausgaben, und Reasoning-Spuren im Stream sind ein häufiger Grund, warum ein lokales Modell mit einem Agenten „einfach nicht funktioniert“.

Passt das Modell nicht, nicht gleich zu einer kleineren Quantisierung greifen. In dieser Reihenfolge vorgehen: -c verringern, dann --n-cpu-moe erhöhen, dann den KV-Cache quantisieren. Meist findet sich Platz.

Als Dienst betreiben

Ein Konsolenfenster dauerhaft offen zu lassen ist fragil. Unter Windows lässt sich llama-server.exe als Dienst registrieren, damit der Endpunkt nach einem Neustart wieder da ist. Auf einem gemeinsam genutzten Teamrechner statt auf einzelnen Laptops ist das praktisch Pflicht, und man sollte mit --ssl-cert-file und --ssl-key-file TLS davorschalten, damit Prompts und Code nie unverschlüsselt durchs Netz gehen.

VS Code anbinden

Der Wert eines OpenAI-kompatiblen Endpunkts liegt darin, dass Agent-Erweiterungen schon wissen, wie man ihn nutzt. Cline aus dem VS-Code-Marketplace installieren. Beim ersten Start fragt es, wie man es nutzen möchte. Die Option mit eigenem API-Schlüssel wählen, dann Settings und API Configuration öffnen und ausfüllen:

• Provider: der Eintrag OpenAI Compatible.
• Adresse: http://0.0.0.0:8080/v1, angepasst, falls der Server einen anderen Host oder Port nutzt.
• API Key: keiner.
• Model ID: der exakte Name, den der Server meldet, etwa Qwen3.6-35B-A3B-UD-IQ2_M.
• Context Window Size: 64000.

Das Kontextfenster muss zum -c-Wert passen, mit dem man gestartet hat. Glaubt Cline, es habe 128K, während der Server nur 64K reserviert hat, gibt es mitten in der Aufgabe Abschneidefehler und einen verwirrten Agenten.

Unter Advanced lohnt es sich, getrennte Modelle für die Modi Plan und Act einzuschalten. Ein stärkeres Reasoning-Modell entwirft den Plan, ein schnelleres führt ihn aus, was lokal genauso nützlich ist wie mit gehosteten APIs.

Kilo Code funktioniert fast genauso. Einen eigenen Provider hinzufügen, ihm eine ID wie llamacpp geben, die Base URL auf das /v1 des Servers zeigen lassen, und es erkennt das bereitgestellte Modell. Eine schmerzhaft gelernte Lektion: Das Modell explizit wählen, statt dem Standard zu vertrauen, und diese Wahl für jeden Modus (Code, Ask, Debug, Orchestrator und Plan) in der globalen Konfiguration wiederholen.

Sicherheit zuerst

Eine einzige falsche Einstellung in einer Agent-Erweiterung kann den Quellcode des Arbeitgebers ins offene Internet schicken. Der lokale Betrieb soll genau das verhindern, also sorgfältig absichern.

• Die Base URL jedes Mal prüfen. Sie sollte auf den eigenen Host zeigen. Zeigt sie woandershin, landet der Code dort.
• Telemetrie abschalten. In Cline unter den allgemeinen Einstellungen Fehler- und Nutzungsberichte deaktivieren.
• Web-Tools wie Browsen und Suche abschalten, sofern es keinen genehmigten Grund dafür gibt.
• MCP-Server abschalten, die man nicht kontrolliert, und Shell-Ausführung auf Nachfragen statt Erlauben stellen.
• Den YOLO-Modus für eine Firmen-Codebasis niemals einschalten. Von Agenten erzeugte Aufgaben ohne Bestätigung auszuführen ist genau so leichtsinnig, wie es klingt.
• TLS verwenden, sobald der Server nicht auf localhost läuft. Für einen gemeinsamen Team-Desktop HTTPS ausliefern und das Serverzertifikat auf jedem Client installieren, unter Windows per certutil.
• Keinen Code und keine Designs auf fremde Server hochladen. Lokale Inferenz gibt es, damit man das nicht muss.

Lohnt es sich?

Rechnet man nach, gewinnt lokal mühelos. Ein bezahlter Coding-Platz bedeutet eine feste Gebühr pro Person und ein monatliches Token-Limit. Pay-as-you-go-APIs wachsen mit der Nutzung, und mit gutem Tooling wird die Nutzung intensiv. Ein llama.cpp-Server auf dem eigenen Rechner kostet nur Strom und eine GPU, die man ohnehin hat.

Die Kompromisse sind ehrlich. Lokale Modelle sind langsamer als die gehosteten Spitzenmodelle und schwächer bei wirklich schwierigem Reasoning, und selbst die Einstellungen von Cline weisen darauf hin, dass es mit Spitzenmodellen am besten funktioniert. Man sollte nicht erwarten, das beste gehostete Modell bei Architekturentscheidungen zu ersetzen.

Aber in die Architektur fließen die meisten Token gar nicht. Der Großteil geht in Boilerplate, Refactorings, Testgerüste, Code-Erklärungen, Commit-Messages und repetitive Änderungen, und ein vernünftig gewähltes MoE-Coding-Modell schafft all das auf eigener Hardware zu Grenzkosten von null, während das geistige Eigentum im Haus bleibt. Zuerst die eigene GPU nutzen und die bezahlten Plätze für Arbeit aufheben, die sie wirklich braucht.