ggml-org/llama.vim とは何ですか？

llama.vim は llama.cpp の llama-server に対して FIM 補完と指示ベース編集を投げる Vim プラグインで、モデルと推論はすべて外部サーバー側にある。設定キーとプロファイル機構を確認し、自前でサーバーを立てられない環境では選ばない判断までを整理する。

ggml-org/llama.vim は商用利用できますか？

できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

ggml-org/llama.vim は今もメンテナンスされていますか？

されています。最後のコミットは 6 日前です。

ggml-org/llama.vim はどのプログラミング言語で書かれていますか？

主に Vim Script です（GitHub の言語統計による）。

llama.vim レビュー: llama.cpp 前提の Vim 補完プラグインの仕組みと設定

ひと目でわかる

これは何？: llama.vim は llama.cpp の llama-server に対して FIM 補完と指示ベース編集を投げる Vim プラグインで、モデルと推論はすべて外部サーバー側にある。設定キーとプロファイル機構を確認し、自前でサーバーを立てられない環境では選ばない判断までを整理する。
誰に向いている？: 採用すべきなのは、llama.cpp の llama-server を自分で起動して運用できる Vim 利用者である。FIM 対応モデルを選び、endpoint_fim と endpoint_inst を自前のサーバーに向けられることが前提になる。
商用利用できる？: できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 6 日前です。
何の言語で書かれている？: 主に Vim Script です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · ggml-org/llama.vim

llama.vim が埋めるのは補完サーバーと Vim の間の隙間

llama.cpp をローカルで動かせば、モデルを外部に送らずにコード補完を回せる。ただし llama-server は HTTP の API を提供するだけで、カーソル位置の前後を切り出し、補完結果をバッファに差し込み、Tab で確定させるといった編集操作は面倒を見ない。llama.vim はこの隙間を埋める。README の冒頭は「Local LLM-assisted text completion」とだけ述べており、推論そのものをプラグインが行うとは書いていない。対象読者は、Vim を常用し、補完のためにクラウドへソースを送りたくない、あるいは送れない開発者である。Insert モードでのカーソル移動に反応して自動提案を出し、Tab で全体、Shift+Tab で先頭行だけを受け入れる。加えて leader lli で指示ベースの編集を起動できる。補完と編集で別々のエンドポイントを使い分けられる点は、この種のプラグインでは珍しい。

FIM リクエストとリングコンテキストの流れ

処理の流れは README と実装ファイルの配置から読み取れる範囲でこうなる。プラグインは endpoint_fim で示された llama-server に FIM 形式のプロンプトを送る。プロンプトにはカーソル周辺のテキストに加え、開いているファイルや編集済みファイル、ヤンクしたテキストから切り出したチャンクが混ざる。README はこれをリングコンテキストと呼び、例のスクリーンショットでは 64 チャンクのうち 30 チャンクが使われ、1 チャンクが破棄されたと表示されている。注目したいのは、大きなコンテキストを低スペック環境でも扱えるようにする仕組みが llama.cpp 側の PR 9787 として参照されている点だ。つまりコンテキスト再利用の賢さはプラグインではなくサーバー側の実装に依存する。生成時間の上限はプラグイン側の設定で制御でき、性能統計も画面に出る。提示された例では 1.5B モデルで 15186 トークン中 260 トークンが新規計算、生成は 24 トークン、所要 1245 ミリ秒と記録されている。これは README に載った一例であり、筆者が同じ環境で再現した数値ではない。

導入はプラグインとサーバーの二段構え

インストールはプラグインマネージャ次第で、vim-plug なら Plug 'ggml-org/llama.vim' の一行、Vundle なら ~/.vim/bundle への git clone と Plugin 行の追加、lazy.nvim なら 'ggml-org/llama.vim' を返すテーブルになる。ただしこれだけでは動かない。README は「The plugin requires a llama.cpp server instance to be running」と明記しており、endpoint_fim と endpoint_inst の両方または片方に到達可能な llama-server が必要になる。サーバーの導入は macOS なら brew install llama.cpp、Windows なら winget install llama.cpp、その他はソースビルドかリリースバイナリになる。起動時の推奨設定は VRAM 量で分かれ、64GB 超なら llama-server --fim-qwen-30b-default、16GB 超なら --fim-qwen-7b-default、16GB 未満なら --fim-qwen-3b-default、8GB 未満なら --fim-qwen-1.5b-default と示されている。モデルは FIM 対応である必要があり、README は Hugging Face のコレクションを参照している。

g:llama_config で触れるキーと触れないキー

設定は g:llama_config に辞書を代入する。プラグイン読み込み前に let g:llama_config = { 'show_info': 0 } と書くか、読み込み後に let g:llama_config.show_info = v:false のように個別に代入する。lazy.nvim では init 関数の中で vim.g.llama_config = { auto_fim = false } のように設定する例が示されている。キーマップは keymap_fim_trigger、keymap_fim_accept_full、keymap_fim_accept_line、keymap_fim_accept_word と、指示ベース編集用の keymap_inst_trigger、keymap_inst_rerun、keymap_inst_continue、keymap_inst_accept、keymap_inst_cancel を個別に差し替えられる。ここで注意したいのは、プラグイン側で指定できるのは接続先ホストまでで、使うモデルは model_fim と model_inst で別に指定するという README の説明だ。サーバーごとにモデル名が違う場合、サーバー側で alias を付けて名前を揃える運用が想定されている。設定項目の全量は :help llama_config か autoload/llama.vim を参照する形になっており、README だけでは網羅できない。

プロファイル切り替えと永続化の挙動

複数のマシンで llama-server を動かしている場合、g:llama_config.profiles に名前と URL の組を並べ、g:llama_config.profile で既定を選ぶ。README の例では spark が http://192.168.0.66:8080、gmktec が http://192.168.0.65:8080 として登録されている。実行時に :LlamaProfile で一覧を表示し、:LlamaProfile spark で FIM と指示ベース編集の両方の送り先を切り替える。プロファイル名はコマンドライン補完に対応し、選択は永続化される。:LlamaProfileReset を使うと .vimrc に書いたプロファイルまたはカスタムエンドポイントの設定に戻せる。ここは設計として素直だが、注意点もある。モデル名はプロファイルに含まれないため、サーバー間でモデル名が揃っていなければ切り替えのたびに model_fim と model_inst の整合を自分で取ることになる。README がサーバー側の alias 運用をわざわざ例示しているのは、この手間を回避するためだと読める。

llama.vim が向かない場面

最大の制約は、llama-server が別プロセスとして動き続ける必要があることだ。プラグインを入れただけでは補完は一切出ない。サーバーの起動、モデルのダウンロード、VRAM の確保まで含めて自分で面倒を見る前提であり、補完のために環境構築をしたくない層には明らかに過剰である。次に、モデル選択の自由度はプラグイン側にはない。README は FIM 対応モデルを要求し、推奨設定も VRAM 別のプリセット名で示されている。特定のモデルを試したい場合、それは llama-server の起動オプションの話であって llama.vim の設定ではない。加えて、提示された資料には補完の精度やレイテンシを環境別に比較したデータはなく、README に載る数値はあくまで個別のスクリーンショットの記録である。大規模なコードベースで実用に足るかは、自分のマシンとモデルの組み合わせで測る以外に判断材料がない。指示ベース編集も、送った内容がそのままサーバーに渡る点は理解しておくべきだ。

Copilot 系プラグインとの違いは推論の置き場所

比較対象として分かりやすいのは GitHub Copilot 系の Vim プラグインである。あちらは補完の推論がベンダーのサービス側で行われ、利用者はモデルを選ばず、VRAM も消費しない。代わりにソースの断片が外部へ送られる。llama.vim はこの関係を反転させ、推論を自分のマシンか自分のネットワーク内の llama-server に置く。プロファイル機能で 192.168.0.66 のような LAN アドレスを指定できるのは、その反転を前提にした設計だ。したがって選択基準は機能の多寡ではなく、コードを外に出せるかどうか、そしてサーバー運用のコストを払えるかどうかになる。もう一つの違いはモデルの固定度で、Copilot 側はモデルが提供側の都合で変わり得るのに対し、llama.vim は model_fim と model_inst に書いた名前のモデルがサーバーに載っている限り挙動が変わらない。再現性を重視するならこちらが有利で、逆に常に最新モデルの恩恵を受けたいなら不利になる。

保守コストとライセンスの確認点

プラグイン本体は Vim Script で書かれ、ライセンスは MIT である。MIT はソースの改変と再配布を許す寛容な条件だが、著作権表示とライセンス文の保持が求められる。ここで注意すべきは、プラグインのライセンスと、接続先で動かすモデルのライセンスは別物だという点である。README は FIM 対応モデルのコレクションを参照しているが、各モデルの利用条件はそれぞれの配布元で確認する必要がある。ライセンス解釈についてはここで断定しない。保守の観点では、llama.vim は llama.cpp の API とモデルの挙動に依存するため、サーバー側を更新するとプロンプトの組み立てやコンテキスト再利用の前提が変わり得る。プラグインのバージョンは v0.1.0 が記録されており、まだ若い。設定項目の全量が :help llama_config と autoload/llama.vim に置かれている以上、README だけを読んで導入を決めるのは避け、サーバー側の起動オプションと合わせて両方を確認したい。

編集部の結論

採用すべきなのは、llama.cpp の llama-server を自分で起動して運用できる Vim 利用者である。FIM 対応モデルを選び、endpoint_fim と endpoint_inst を自前のサーバーに向けられることが前提になる。逆に、サーバーを立てる手間をかけたくない場合や、補完品質をモデル選択で細かく調整したい場合は向かない。導入前に確認するのは 3 点で、llama-server が動くマシンの VRAM 量、model_fim と model_inst に指定するモデル名がサーバー側のエイリアスと一致しているか、そして :LlamaProfile で切り替えたプロファイルが期待どおり永続化されるかである。

公式情報源

コミュニティノート