Qu’est-ce que ggml-org/llama.vim ?

Un plugin Vim Script qui délègue la complétion et l'édition par instruction à une instance llama.cpp locale, avec un mécanisme de réutilisation de contexte pensé pour les machines modestes. Réservé à ceux qui acceptent de faire tourner un serveur à côté de leur éditeur.

Puis-je utiliser ggml-org/llama.vim à des fins commerciales ?

Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.

ggml-org/llama.vim est-il encore maintenu ?

Oui. Les derniers commits datent d’il y a 6 jours.

En quel langage de programmation ggml-org/llama.vim est-il écrit ?

Principalement Vim Script, d’après les statistiques de langage de GitHub.

llama.vim : complétion LLM locale dans Vim via llama.cpp

En bref

De quoi s’agit-il ?: Un plugin Vim Script qui délègue la complétion et l'édition par instruction à une instance llama.cpp locale, avec un mécanisme de réutilisation de contexte pensé pour les machines modestes. Réservé à ceux qui acceptent de faire tourner un serveur à côté de leur éditeur.
À qui s’adresse-t-il ?: llama.vim convient à qui travaille déjà avec llama.cpp et veut de la complétion FIM sans sortir de Vim ni envoyer son code à un service distant. Il ne convient pas à qui refuse de maintenir un serveur séparé, ni à qui attend une complétion instantanée sur un GPU de moins de 8 Go : le README descend jusqu'à un modèle 1.5B dans cette configuration.
Puis-je l’utiliser commercialement ?: Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
Est-il encore maintenu ?: Oui. Les derniers commits datent d’il y a 6 jours.
En quel langage est-il écrit ?: Principalement Vim Script, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Rédaction Hysen Labs · 10 septembre 2026 · ggml-org/llama.vim

Un client Vim, un serveur llama.cpp, et rien entre les deux

Le plugin ne contient pas de moteur d'inférence. Le README est explicite : il faut une instance llama.cpp en cours d'exécution sur g:llama_config.endpoint_fim et/ou g:llama_config.endpoint_inst. Toute la partie modèle, quantification, gestion du KV cache et découpage du prompt vit donc côté serveur, dans llama.cpp. llama.vim n'est qu'une couche de saisie et d'affichage : il surveille le curseur, assemble un prompt, appelle le serveur, montre la suggestion, et gère les touches d'acceptation. Cette séparation a une conséquence pratique immédiate : la qualité des complétions dépend presque entièrement du modèle choisi, pas du plugin. Elle a aussi une conséquence moins agréable : installer llama.vim ne suffit jamais. Il faut deux installations, deux mises à jour à suivre, et un port qui répond. Si votre poste ne peut pas faire tourner llama.cpp, le plugin n'a rien à proposer.

FIM et édition par instruction : deux flux distincts

Le plugin expose deux usages qui ne partagent pas le même point d'entrée. Le premier est la complétion Fill-in-Middle : le README annonce une suggestion automatique au déplacement du curseur en mode Insert, acceptée avec Tab pour la totalité, Shift+Tab pour la première ligne, et une touche séparée pour accepter un mot. Le second est l'édition par instruction, déclenchée par <leader>lli, avec des touches dédiées pour relancer, continuer, accepter et annuler. Les deux flux peuvent viser des serveurs différents, puisque les options endpoint_fim et endpoint_inst sont distinctes, tout comme les modèles via model_fim et model_inst. C'est une décision de conception qui a du sens : un modèle spécialisé FIM n'est pas forcément bon en suivi d'instruction, et inversement. Le revers est une configuration à deux têtes, où une erreur de nom de modèle côté instruction ne se voit qu'au moment où vous invoquez <leader>lli.

Le contexte en anneau, ou comment tenir un grand contexte sur du matériel modeste

L'élément le plus intéressant du projet est la gestion du contexte. Le README décrit un ring context alimenté par des morceaux provenant des fichiers ouverts, des fichiers édités et du texte yanké, et renvoie à une pull request de llama.cpp pour la réutilisation intelligente du contexte. L'exemple d'affichage fourni dans le README est instructif : sur une machine M1 Pro avec Qwen2.5-Coder 1.5B Q8_0, les statistiques indiquent un contexte utilisé de 15186 tokens pour un maximum de 32768, 30 chunks dans l'anneau sur 64 possibles, un chunk évincé, zéro en file, 260 tokens de prompt nouvellement calculés et 24 tokens générés en 1245 ms. Ce que ces chiffres montrent, c'est que le plugin ne renvoie pas tout le contexte au serveur à chaque frappe. Il ne recalcule que les tokens nouveaux et laisse le serveur réutiliser le préfixe déjà évalué. C'est ce qui rend l'approche viable sur du matériel de consommateur, et c'est aussi ce qui rend le comportement difficile à prévoir : le contenu de l'anneau dépend de votre historique d'édition, donc deux développeurs sur le même fichier n'obtiendront pas les mêmes suggestions.

Mise en route : les commandes et les clés de configuration

L'installation passe par le gestionnaire de plugins habituel. Avec vim-plug, une ligne suffit : Plug 'ggml-org/llama.vim'. Avec lazy.nvim, la spécification est { 'ggml-org/llama.vim' }, et c'est dans init que l'on place vim.g.llama_config si l'on veut désactiver la complétion automatique dès le chargement. Côté serveur, le README donne brew install llama.cpp sur macOS et winget install llama.cpp sous Windows, sinon une compilation depuis les sources ou les binaires publiés dans les releases de llama.cpp. Le lancement se fait avec un preset dépendant de la VRAM : llama-server --fim-qwen-30b-default au-delà de 64 Go, --fim-qwen-7b-default au-delà de 16 Go, --fim-qwen-3b-default en dessous de 16 Go, et --fim-qwen-1.5b-default sous 8 Go. La configuration du plugin se fait via g:llama_config, par exemple let g:llama_config = { 'show_info': 0 } pour masquer la ligne d'information, ou let g:llama_config.auto_fim = false. Les touches se redéfinissent avec keymap_fim_trigger, keymap_fim_accept_full, keymap_fim_accept_line, keymap_inst_trigger et les autres. Le README renvoie à :help llama_config et au fichier autoload/llama.vim pour la liste complète, ce qui signifie que la documentation exhaustive n'est pas dans le README mais dans le code.

Les profils nommés et leur limite assumée

Le plugin sait basculer entre plusieurs serveurs. On déclare un dictionnaire profiles associant un nom à une URL, par exemple 'spark' vers http://192.168.0.66:8080 et 'gmktec' vers http://192.168.0.65:8080, puis on sélectionne avec g:llama_config.profile. La commande :LlamaProfile liste les profils disponibles, :LlamaProfile spark bascule les requêtes FIM et instruction vers l'autre machine, et :LlamaProfileReset restaure ce qui est défini dans .vimrc. Le profil choisi est persisté. Le README signale lui-même la limite : seuls les hôtes sont configurables par ce biais, pas les modèles. La parade proposée consiste à utiliser des alias côté serveur, par exemple alias = inst_model,pi dans la section de configuration d'un modèle, et à nommer model_inst et model_fim de façon identique sur toutes les machines. C'est astucieux, mais cela déplace la cohérence de la configuration Vim vers les fichiers de configuration des serveurs. Si vous gérez trois machines, vous avez maintenant trois fichiers à garder alignés.

Ce que le projet ne fera pas pour vous

La contrainte la plus dure est celle des modèles. Le README précise que le plugin exige des modèles compatibles FIM et renvoie à une collection Hugging Face dédiée. Un modèle de chat généraliste, même excellent, ne conviendra pas au flux de complétion. Ensuite, la latence. L'exemple du README donne 1245 ms pour 24 tokens générés sur un M1 Pro avec un modèle 1.5B. Ce chiffre n'est pas une promesse de performance, c'est une mesure dans une configuration précise, mais il indique l'ordre de grandeur : sur du matériel modeste, la suggestion arrive après une pause perceptible. Un second exemple, sur M2 Ultra avec un modèle 7B, sert à montrer l'accumulation du contexte global entre fichiers et la latence dans une base de code volumineuse. Enfin, la documentation. Le README couvre l'installation, les touches et les profils, mais renvoie à :help et au source pour le reste. Il n'y a pas de section dédiée au dépannage, ni d'indication sur ce qui se passe quand le serveur tombe. Pour un plugin qui dépend d'un processus externe, c'est un manque réel.

Face à un client de complétion hébergé

L'alternative la plus évidente reste un client de complétion qui interroge un service distant, du type de ceux qui se branchent sur Vim ou Neovim via un serveur central. La différence n'est pas cosmétique. Avec llama.vim, le code envoyé au modèle ne quitte pas votre réseau : il va d'un socket local ou d'un socket vers une machine que vous contrôlez. En échange, vous portez le coût du matériel, de l'installation de llama.cpp et de la sélection du modèle. Un service hébergé inverse exactement ce compromis : aucune VRAM à acheter, un modèle de grande taille accessible, mais votre code transite par un tiers et vous dépendez de la disponibilité du service. Il existe une troisième voie, les greffons Vim qui embarquent directement une bibliothèque d'inférence sans serveur séparé. llama.vim a choisi l'inverse, et ce choix est cohérent avec son origine : le projet vient de ggml-org, l'organisation qui porte llama.cpp. Le plugin est en quelque sorte un client de référence pour ce serveur.

Maintenance, licence et coût de mise à jour

Le projet est publié sous licence MIT, ce qui autorise la réutilisation et la modification avec conservation de l'avis de licence. Rien dans le README n'indique de clause supplémentaire. La première version taguée, v0.1.0, date du 24 août 2026, et le dernier push sur master est du 8 septembre 2026 : le rythme est resserré, ce qui est cohérent avec un projet qui suit les évolutions de llama.cpp. Le coût de maintenance se situe surtout là. Le plugin lui-même est du Vim Script et le README le décrit comme volontairement simple et léger, mais la compatibilité avec les modèles et les presets dépend du serveur. Une mise à jour de llama.cpp peut changer les noms de presets, et les options de configuration ne sont documentées que dans :help llama_config et dans autoload/llama.vim. Concrètement, il faut relire le source après une mise à jour majeure, pas seulement le README.

Conclusion éditoriale

llama.vim convient à qui travaille déjà avec llama.cpp et veut de la complétion FIM sans sortir de Vim ni envoyer son code à un service distant. Il ne convient pas à qui refuse de maintenir un serveur séparé, ni à qui attend une complétion instantanée sur un GPU de moins de 8 Go : le README descend jusqu'à un modèle 1.5B dans cette configuration. Avant d'adopter, vérifier que votre modèle est bien listé dans la collection FIM de ggml-org, puis lancer llama-server avec le preset correspondant à votre VRAM et contrôler le compteur de contexte affiché par show_info.

Sources officielles

Notes de la communauté