llama.vim: lokale FIM-Vervollständigung in Vim, angebunden an llama-server

Welches Problem llama.vim adressiert

Vim kennt keine eingebaute Code-Vervollständigung auf Basis eines Sprachmodells. Wer in Insert-Modus tippt, bekommt bestenfalls Keyword- oder Buffer-Vervollständigung aus dem eigenen Projekt. llama.vim setzt an dieser Stelle an und holt Vorschläge von einem Modell, das lokal läuft. Die Zielgruppe sind Vim-Nutzer, die einen llama.cpp-Server selbst betreiben können und ihre Quelltexte nicht an einen externen Dienst übertragen wollen. Das README nennt als Kernfunktion ausdrücklich Fill-in-the-Middle-Vervollständigungen, also Vorschläge für die Lücke zwischen bereits geschriebenem Text davor und danach. Hinzu kommt eine instruktionsbasierte Bearbeitung, die über einen eigenen Keymap ausgelöst wird. Das Plugin ist damit kein allgemeiner Chat-Client im Editor, sondern ein Vervollständigungswerkzeug mit einer zweiten, explizit aufgerufenen Betriebsart.

Zwei getrennte Pfade: FIM und Instruktion

Das Plugin kennt zwei Endpunkte, die getrennt konfiguriert werden: g:llama_config.endpoint_fim und g:llama_config.endpoint_inst. Der FIM-Pfad wird laut README automatisch bei Cursorbewegung im Insert-Modus ausgelöst, sofern auto_fim nicht abgeschaltet ist. Der Instruktionspfad läuft dagegen über einen manuellen Auslöser, standardmäßig <leader>lli, mit eigenen Keymaps für Wiederholung, Fortsetzung, Annahme und Abbruch. Getrennt sind auch die Modellnamen: model_fim und model_inst. Diese Trennung erlaubt es, für die schnelle, häufig ausgelöste Vervollständigung ein kleineres Modell zu verwenden und für die selteneren Instruktionen ein größeres, ohne dass beide Anfragen denselben Server oder dasselbe Modell belegen müssen. Wer beides auf denselben Server zeigt, sollte bedenken, dass FIM-Anfragen bei jeder Cursorbewegung im Insert-Modus anfallen und damit den Server deutlich häufiger beschäftigen als die manuell gestarteten Instruktionen.

Kontextverwaltung über einen Ring aus Chunks

Der interessanteste Teil der Implementierung ist die Kontextverwaltung. Das README beschreibt einen Ring aus Chunks, die aus geöffneten und bearbeiteten Dateien sowie aus kopiertem Text stammen. Diese Chunks werden nicht bei jeder Anfrage neu aufgebaut, sondern zwischengespeichert und wiederverwendet. Das Beispiel im README nennt für einen Lauf auf einem M1 Pro mit Qwen2.5-Coder 1.5B Q8_0 konkrete Zahlen: 15186 genutzte Tokens bei einem Maximum von 32768, 30 Chunks im Ring bei einer Kapazität von 64, ein bisher verdrängter Chunk und null Chunks in der Warteschlange. Für diese Anfrage wurden 260 Prompt-Tokens neu berechnet und 24 Tokens generiert, die Antwort kam nach 1245 ms. Diese Zahlen stammen aus der Projektdokumentation und sind kein Benchmark dieser Redaktion. Sie zeigen aber, worauf das Design zielt: nur der neu berechnete Teil des Prompts kostet Rechenzeit, der Rest kommt aus dem Zwischenspeicher. Das README verweist dazu auf einen Pull Request in llama.cpp. Der Kontext ist global und wird laut README über verschiedene Dateien hinweg aufgebaut, was erklärt, warum der Speicherbedarf mit der Arbeitssitzung wächst und warum Chunks verdrängt werden, wenn der Ring voll ist. Wer eine sehr große Sitzung über viele Dateien laufen lässt, sollte mit Verdrängung rechnen. Das README beziffert die Konsequenzen daraus nicht.

Einrichtung: Plugin, Server, Modell

Die Installation erfolgt über den jeweiligen Plugin-Manager. Für vim-plug genügt die Zeile Plug 'ggml-org/llama.vim', für Vundle ein git clone nach ~/.vim/bundle mit anschließendem Plugin-Eintrag im vundle#begin()-Abschnitt, für lazy.nvim ein Tabelleneintrag mit dem Repository. Danach braucht es einen laufenden llama.cpp-Server. Das README nennt brew install llama.cpp für macOS und winget install llama.cpp für Windows, für andere Systeme den Selbstbau oder die Binaries aus den llama.cpp-Releases. Für den Server gibt das README Empfehlungen nach verfügbarem VRAM: llama-server --fim-qwen-30b-default bei mehr als 64 GB, --fim-qwen-7b-default bei mehr als 16 GB, --fim-qwen-3b-default bei weniger als 16 GB und --fim-qwen-1.5b-default bei weniger als 8 GB. Die Modellwahl ist nicht frei: Das Plugin verlangt laut README FIM-kompatible Modelle und verweist auf eine HuggingFace-Sammlung des Projekts. Die Konfiguration selbst läuft über die Variable g:llama_config, die vor dem Laden des Plugins gesetzt werden sollte, wie das README am Beispiel von show_info vermerkt. Einzelne Schlüssel lassen sich auch direkt zuweisen, etwa g:llama_config.show_info = v:false. Für mehrere Rechner kennt das Plugin benannte Profile: g:llama_config.profiles nimmt Paare aus Name und URL auf, g:llama_config.profile wählt das aktive aus. Der Wechsel erfolgt zur Laufzeit über :LlamaProfile, mit Vervollständigung der Profilnamen auf der Kommandozeile, und :LlamaProfileReset stellt die im .vimrc hinterlegte Konfiguration wieder her. Wichtig ist die Einschränkung, die das README selbst macht: Profile benennen nur die Hosts, nicht die Modelle. Wer über Profile hinweg konsistente Modellnamen braucht, muss laut README auf serverseitige Aliase zurückgreifen, etwa alias = inst_model,pi in der Serverkonfiguration.

Was das Plugin nicht leistet

Der deutlichste Vorbehalt steht implizit in der Architektur: Ohne laufenden llama-server tut llama.vim nichts. Das Plugin enthält kein Modell und keine Inferenz. Wer keinen Server betreiben will oder kann, für den ist es das falsche Werkzeug, unabhängig davon, wie gut die Vervollständigung im Betrieb wäre. Zweitens ist die Modellwahl eingeschränkt. Das README verlangt FIM-kompatible Modelle und verlinkt eine kuratierte Sammlung. Ein beliebiges instruct-Modell ohne FIM-Training lässt sich nicht einfach anstelle der empfohlenen Modelle einsetzen, auch wenn die Endpunkte technisch konfigurierbar sind. Drittens ist die automatische Auslösung im Insert-Modus eine Lastentscheidung. Jede Cursorbewegung kann eine Anfrage erzeugen, und die Verzögerung liegt laut dem dokumentierten Beispiel im Bereich von über einer Sekunde auf der genannten Hardware. Wer auf einem schwächeren Rechner arbeitet, sollte auto_fim abschalten und den Trigger-Keymap nutzen, statt die Vorschläge passiv erzeugen zu lassen. Viertens ist der Kontext global und sitzungsbezogen. Das ist für die Qualität der Vorschläge nützlich, macht das Verhalten aber schwer vorhersagbar, wenn in derselben Vim-Instanz an mehreren Projekten gearbeitet wird, deren Chunks sich den Ring teilen.

Abgrenzung zu Copilot und zu reiner Buffer-Vervollständigung

Die naheliegende Alternative ist GitHub Copilot in seiner Vim-Erweiterung. Der Unterschied liegt nicht in der Oberfläche, sondern im Ort der Berechnung. Copilot sendet den Kontext an einen entfernten Dienst und liefert Vorschläge zurück. llama.vim sendet an einen Endpunkt, den der Nutzer selbst betreibt, standardmäßig über g:llama_config.endpoint_fim und endpoint_inst konfiguriert. Daraus folgen die praktischen Unterschiede: keine Abhängigkeit von einem Konto oder einer Netzwerkverbindung, dafür Verantwortung für Hardware, Modellauswahl und Serverprozess. Auch die Kontextstrategie unterscheidet sich. Copilot arbeitet mit dem, was der Dienst aus der Anfrage ableitet. llama.vim hält dagegen einen lokalen Ring aus Chunks, die aus geöffneten und bearbeiteten Dateien und aus kopiertem Text stammen, und reicht nur den neu berechneten Teil des Prompts durch. Eine zweite Vergleichsgruppe ist die eingebaute Vervollständigung von Vim selbst. Sie ist sofort verfügbar und kostenlos, stützt sich aber auf bereits vorhandene Bezeichner im Buffer und schlägt nichts vor, was nicht irgendwo im Projekt steht. Genau diese Lücke füllt llama.vim, und der Preis dafür ist der Server.

Pflegeaufwand, Lizenz und offene Punkte

Das Repository steht unter der MIT-Lizenz. Diese erlaubt Weitergabe und Änderung, solange der Lizenztext und der Urheberrechtsvermerk erhalten bleiben. Wer das Plugin forkt und weiterverbreitet, muss das beachten. Das ist keine Rechtsberatung, sondern nur der Hinweis auf die Lizenzangabe im Repository. Der Pflegeaufwand liegt weniger beim Plugin als bei der Umgebung. llama.cpp wird aktiv entwickelt, und die Server-Binaries müssen zum jeweiligen Modell und zur Kommandozeilenschnittstelle passen. Das README empfiehlt ausdrücklich, die vollständige Optionsliste über :help llama_config oder den Quelltext in autoload/llama.vim nachzuschlagen, weil es sie nicht selbst auflistet. Wer das Plugin produktiv nutzt, sollte diese Datei lesen, bevor er sich auf Standardwerte verlässt. Für die Modelle verweist das README auf eine HuggingFace-Sammlung, ohne deren Umfang oder Aktualisierungsrhythmus zu nennen. Ob die dort geführten Modelle zu den eigenen VRAM-Grenzen und zu den gewünschten Sprachen passen, lässt sich aus dem README allein nicht ableiten. Das Repository enthält eine Versionsmarke v0.1.0 vom 24. August 2026 und wurde laut Metadaten zuletzt am 8. September 2026 aktualisiert. Aussagen über die Zuverlässigkeit im Dauerbetrieb lassen sich daraus nicht ableiten, und das README macht dazu keine Angaben.

Redaktionelles Fazit

Wer Vim nutzt, Code nicht an einen Cloud-Dienst schicken will und bereits Hardware für llama.cpp betreibt, findet hier ein Plugin mit klar umrissener Aufgabe: Vorschläge aus einem lokalen Server, konfiguriert über g:llama_config. Wer keinen llama-server betreiben möchte oder dessen Modell keine FIM-Unterstützung mitbringt, sollte es nicht einsetzen. Vor dem Ausprobieren zu prüfen sind der Endpunkt in g:llama_config.endpoint_fim, die Modellnamen in model_fim und model_inst sowie die Frage, ob die genutzten Modelle in der HF-Sammlung des Projekts als FIM-fähig geführt werden.

Offizielle Quellen

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