llama.vscode: lokale FIM-Vervollständigung mit llama.cpp im Editor

Welches Problem llama.vscode löst und für wen

Die Erweiterung richtet sich an Entwickler, die Completion im Editor nutzen wollen, ohne Prompts und Codeausschnitte an einen entfernten Dienst zu schicken. Der Ansatz ist bewusst zweigeteilt: VS Code spricht mit einem llama.cpp-Server, der auf derselben Maschine läuft. Damit liegen Modellgewicht, Inferenz und Kontextverarbeitung in der eigenen Verantwortung. Das ist der eigentliche Unterschied zu den meisten Completion-Erweiterungen im Marketplace, die einen Cloud-Endpunkt voraussetzen. Die README nennt als Ziel ausdrücklich hochwertige und performante lokale FIM-Completions auch auf Consumer-Hardware. Wer eine Workstation ohne dedizierte GPU besitzt, muss allerdings mit Qualitätseinbußen rechnen. Die README sagt das für CPU-Konfigurationen selbst: die Qualität sei deutlich niedriger.

FIM, Ring-Kontext und Cache-Wiederverwendung als Mechanismus

Das Modell arbeitet mit Fill-in-the-Middle: es bekommt Text vor und nach der Cursorposition und ergänzt die Lücke. Die Erweiterung sammelt dafür Kontext aus der Umgebung des Cursors. Wie weit dieser Kontext reicht, lässt sich konfigurieren. Zusätzlich gibt es einen Ring-Kontext, der Chunks aus geöffneten und bearbeiteten Dateien sowie kopierten Text einbezieht. Der interessante Teil steckt in der Kontextwiederverwendung: die README verlinkt einen Pull Request im llama.cpp-Repository, der laut Beschreibung sehr große Kontexte auch auf schwacher Hardware ermöglicht. Das Prinzip ist, dass sich aufeinanderfolgende Anfragen den bereits verarbeiteten Präfix teilen, statt den Kontext jedes Mal neu zu berechnen. In der Praxis bedeutet das, dass die Latenz nicht linear mit der Kontextgröße wächst, solange der Anfang des Kontexts stabil bleibt. Wer häufig zwischen weit auseinanderliegenden Dateien springt, verliert diesen Vorteil teilweise, weil sich der gemeinsame Präfix ändert. Die Erweiterung zeigt Leistungsstatistiken an, mit denen sich dieses Verhalten im eigenen Editor beobachten lässt.

llama.cpp installieren: automatisch oder per Paketmanager

Die Erweiterung kann llama.cpp inzwischen selbst einrichten. Laut README geschieht das automatisch beim Start von llama-vscode, entweder über das offizielle Shell-Skript von llama.app oder über brew auf macOS und Linux beziehungsweise winget unter Windows. Der manuelle Weg bleibt dokumentiert: brew install llama.cpp auf macOS, winget install llama.cpp unter Windows. Für andere Systeme verweist die README auf die Release-Binaries oder einen Build aus dem Quellcode, wobei das bin-Verzeichnis in den Pfad aufgenommen werden muss. Danach wählt man über das llama-vscode-Menü einen Env aus, also eine Gruppe von Modellen für Completion, Chat, Embeddings und Tools. Die README empfiehlt den Serverstart abhängig vom VRAM: llama serve --fim-qwen-30b-default oberhalb von 64 GB, --fim-qwen-7b-default oberhalb von 16 GB, --fim-qwen-3b-default unterhalb von 16 GB und --fim-qwen-1.5b-default unterhalb von 8 GB. Für reine CPU-Systeme nennt sie zwei Konfigurationen mit Qwen2.5-Coder in 1.5B und 0.5B, beide mit --port 8012, --ctx-size 0 und --cache-reuse 256. Der Parameter --cache-reuse ist dabei der Hebel, der zur oben beschriebenen Kontextwiederverwendung passt.

Tastenkürzel und der Agent als zweite Baustelle

Im Editor übernimmt Tab einen vollständigen Vorschlag, Shift+Tab nur dessen erste Zeile, Ctrl/Cmd+Rechts das nächste Wort. Mit Ctrl+L lässt sich der Vorschlag manuell umschalten. Diese Aufteilung ist praktisch, weil sie unterschiedlich viel Vertrauen in das Modell erlaubt: eine Zeile anzunehmen ist billiger zu korrigieren als ein ganzer Block. Der Agent ist ein separates Feature mit eigener Oberfläche in der Explorer-Ansicht, erreichbar über Ctrl+Shift+A. Laut README arbeitet er mit lokalen Modellen, wobei gpt-oss 20B derzeit als beste Wahl genannt wird, und kann auch externe Modelle etwa über OpenRouter ansprechen. Er nutzt MCP-Server, die in VS Code installiert und gestartet sind, und bringt neun interne Tools mit, darunter custom_tool zum Abrufen von Datei- oder Webseiteninhalten und custom_eval_tool, mit dem sich eigene Tools in JavaScript schreiben lassen. Die maximale Schleifenzahl ist konfigurierbar. Wer nur Completion will, kann diesen Teil ignorieren, muss aber wissen, dass die Modell- und Env-Verwaltung beides abdeckt.

Wo die Erweiterung an ihre Grenzen stößt

Der wichtigste Vorbehalt steht in der README selbst: FIM-kompatible Modelle sind Voraussetzung. Ein beliebiges Chat-Modell ohne Fill-in-the-Middle-Training liefert keine brauchbaren Vorschläge, auch wenn es sich laden lässt. Zweitens hängt die Qualität direkt an der VRAM-Menge. Die Empfehlungen springen von 1.5B unter 8 GB bis 30B über 64 GB, und die README räumt für CPU-Betrieb ausdrücklich niedrigere Qualität ein. Wer auf einem Notebook ohne dedizierte GPU arbeitet, bekommt also nicht dieselbe Erfahrung wie mit einer Workstation. Drittens ist die Erweiterung kein eigenständiges Produkt: ohne laufenden llama.cpp-Server funktioniert sie nicht. Das ist ein bewusster Zuschnitt, aber er verlagert Betriebsaufwand in den Editor. Viertens fehlt auf der Repository-Seite eine Homepage, und die README verweist für Details zu Serverstart und Agent mehrfach auf das Wiki. Wer eine vollständig selbsterklärende Konfiguration erwartet, wird an diesen Stellen nachlesen müssen.

llama.vim als Referenz und was der Unterschied ist

Die README nennt llama.vim aus demselben Repository als Referenz für die ursprüngliche Implementierung und verlinkt es unter dem Abschnitt zu anderen IDEs. Beide Projekte teilen damit die Grundidee: ein lokaler llama.cpp-Server, FIM-Completions, Kontextwiederverwendung. Der Unterschied liegt in der Oberfläche und im Umfang. llama.vscode bringt zusätzlich eine Agent-Ansicht, MCP-Anbindung, Telegram-Zugriff, Deep Links der Form vscode://ggml-org.llama-vscode?view=agent&prompt=Hello und eine Modellverwaltung inklusive Suche und Download direkt von Huggingface mit. Wer in Neovim arbeitet, findet dort die schlankere Variante ohne diese Zusatzschichten. Wer VS Code nutzt und den Agenten oder MCP-Tools braucht, bleibt bei llama.vscode. Die Wahl ist also weniger eine Frage der Completion-Qualität, die aus derselben Engine stammt, als eine Frage der Editorumgebung und des gewünschten Funktionsumfangs.

Wartung, Lizenz und Modellpflege

Das Repository steht unter MIT-Lizenz, was die Einbindung in eigene Abläufe und Änderungen am Code erlaubt, solange Lizenz- und Copyright-Hinweise erhalten bleiben. Das ist keine Rechtsberatung, aber die Lizenz ist eine der permissivsten und stellt für die meisten Teams keine Hürde dar. Die Release-Historie zeigt einen kurzen Takt: v0.0.65, v0.0.64 und v0.0.63 liegen jeweils wenige Wochen auseinander, der letzte Push fällt mit dem jüngsten Release zusammen. Daraus lässt sich ableiten, dass mit häufigen Updates zu rechnen ist, was auf der einen Seite schnelle Fehlerkorrekturen bedeutet und auf der anderen Seite regelmäßige Nachzieharbeit in einer Umgebung, in der Erweiterungen zentral verteilt werden. Ein eigener Wartungsaufwand entsteht zusätzlich durch die Modelle: die README listet vordefinierte Modelle und Envs, deren Namen sich mit neuen Versionen ändern können. Wer eine feste Env-Konfiguration im Team verteilt, sollte diese Namen und die zugehörigen Serverflags im Blick behalten, weil ein Wechsel des Standardmodells die Completion-Qualität spürbar verschieben kann.

Redaktionelles Fazit

Für Teams, die Completion-Daten nicht an einen Cloud-Anbieter senden wollen und bereit sind, llama.cpp selbst zu betreiben, ist llama.vscode ein nachvollziehbarer Einstieg: MIT-Lizenz, klare Trennung zwischen Editor-Erweiterung und lokalem Server. Wer keine GPU mit mindestens 8 GB VRAM oder Geduld mit CPU-Konfigurationen hat, sollte zuerst die Qualität der kleinen Modelle prüfen. Vor dem Rollout im Team lohnt ein Blick in das Wiki des Repositories, weil die README nur die Grundkonfiguration zeigt und Details zu Serverstart und Kontextweitergabe dorthin auslagert.

Offizielle Quellen

1. ggml-org/llama.vscode on GitHub
2. Issues
3. License: MIT
4. README
5. Releases