llama.vim：把 FIM 補全拉回自己的機器
Vim plugin for LLM-assisted code/text completion
秒懂
- 它是什麼？
- 這個外掛把 Vim 的插入模式接到本機 llama.cpp 伺服器，用 ring buffer 累積跨檔案上下文。它解決的是延遲與隱私問題，代價是你得自己養一台推論伺服器。
- 適合誰用？
- llama.vim 適合已經在跑 llama.cpp、在意程式碼不出本機、且願意自己調伺服器參數的 Vim 使用者；如果你的機器沒有可用的 GPU 或統一記憶體，或你需要的是多檔案重構而不是逐行補全，這個外掛不是對的工具。導入前先確認三件事：你的硬體對應 README 哪一檔建議設定、llama-server 是否已在 endpoint_fim 指定的位址回應、以及你要用的模型是否在 ggml-org 的 FIM 模型集合內。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 Vim Script（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
誰需要一個自己架的本機補全
雲端補全工具的問題不在品質，在於每一次按鍵都把游標附近的程式碼送出你的機器。對多數團隊這無所謂，對處理客戶資料、未公開的演算法或受合約約束的程式庫的人來說，這條線不能跨。llama.vim 的定位就在這裡：README 開頭寫的是 local LLM-assisted text completion，補全請求送到你自己指定的 llama.cpp 伺服器，不經過第三方。
第二類使用者是硬體已經到位的人。如果你手上有一張 16GB 以上的顯示卡，或是一台統一記憶體的 Mac，你其實已經有能力跑一個夠用的補全模型，只是缺一層編輯器整合。README 的建議設定直接按 VRAM 分級，從 --fim-qwen-1.5b-default 一路到 --fim-qwen-30b-default，這種寫法預設讀者知道自己機器有多少記憶體。
反過來說，如果你只是想要一個裝好就能用的補全，這個專案會讓你失望。它不是套件管理器裡按一下就結束的東西，而是一組需要你同時維護編輯器設定與推論伺服器的組合。
ring context 才是這個外掛真正的設計
多數編輯器補全外掛的上下文就是當前檔案，頂多加幾行前後文。llama.vim 走的是另一條路：它維護一個 ring buffer，把開啟過的檔案、編輯過的區塊以及你 yank 過的文字切成 chunk 放進去。README 的截圖說明把這件事寫得很具體，畫面上顯示 ring buffer 裡有 30 個 chunk 的額外上下文，上限是 64，這次請求新計算的 prompt token 是 260，生成 24 個 token。
這裡的關鍵在於「新計算」三個字。外掛會盡量重用已經算過的上下文，只把真正變動的部分送去推論。README 的 Features 段落把這件事連到 llama.cpp 的一個 PR，說法是即使在低階硬體上也能支援非常大的上下文。這解釋了為什麼一個 1.5B 模型配上 32768 token 的上下文上限在筆電上還跑得動：大部分 token 的 KV 快取沒有重算。
代價是狀態。ring buffer 會被填滿，截圖裡也顯示已經有 1 個 chunk 在本次 session 被淘汰。被淘汰的上下文不會回來，所以你在一個大專案裡跳來跳去之後，補全品質取決於最近碰過哪些檔案，而不是整個專案。這是設計取捨，不是 bug，但文件沒有說明淘汰策略的細節，只有 :help llama_config 和 autoload/llama.vim 原始碼可以查。
兩種互動模式，兩套按鍵
外掛提供兩條路徑。第一條是 FIM 補全，在插入模式下隨游標移動自動觸發，按 Tab 接受整段建議，Shift+Tab 只接受第一行，另外可以綁一個鍵只接受第一個詞。第二條是指令式編輯，用 <leader>lli 觸發，你給一句自然語言指令，外掛改寫選取的內容，<leader>llr 重跑，<leader>llc 繼續生成，Tab 接受，Esc 取消。
這兩條路徑走的是不同的模型與端點。設定裡的 model_fim 和 model_inst 是分開的，endpoint_fim 和 endpoint_inst 也是。這代表你可以讓補全用一個 1.5B 的小模型求速度，指令式編輯用大一點的模型求品質，兩者共用同一個 llama-server 或分別指向不同機器。README 沒有說明這種混搭的實際延遲表現，只給了分開設定的方法。
自動觸發這件事要留意。auto_fim 預設是開的，每次游標移動都可能送出請求。在慢速硬體上這會變成持續的背景負載，關掉它並改用 keymap_fim_trigger 手動觸發是合理的選擇，README 也給了 lazy.nvim 的 init 函式範例。
安裝與設定：從 llama-server 開始
安裝分兩層。外掛本身用 vim-plug 一行 Plug 'ggml-org/llama.vim'，或 Vundle 手動 clone 到 ~/.vim/bundle，或 lazy.nvim 的規格表。伺服器端則依平台而異：macOS 用 brew install llama.cpp，Windows 用 winget install llama.cpp，其他系統從 llama.cpp 的 release 取二進位檔或自行編譯。
啟動伺服器的指令按 VRAM 分級。超過 64GB 用 llama-server --fim-qwen-30b-default，超過 16GB 用 --fim-qwen-7b-default，低於 16GB 用 --fim-qwen-3b-default，低於 8GB 用 --fim-qwen-1.5b-default。這些是 llama.cpp 內建的模型別名，不是你隨便挑一個 GGUF 就能套用。
設定集中在 g:llama_config 這個變數。README 給的例子包括 show_info 關掉行內資訊、auto_fim 關掉自動補全、四組 FIM 按鍵與五組指令式編輯按鍵。多伺服器情境用 profiles 這個字典，鍵是名字，值是 URL，例如 spark 指向 http://192.168.0.66:8080，gmktec 指向 http://192.168.0.65:8080，再用 profile 指定當前使用哪一個。命令列上用 :LlamaProfile 列出與切換，:LlamaProfileReset 還原 .vimrc 裡的設定，切換結果會被保存下來。
有一點文件講得很清楚：profiles 只能換主機，不能換模型，模型由 model_fim 與 model_inst 決定。想要讓設定與 profile 解耦，得靠伺服器端的別名，例如在伺服器設定裡寫 alias = inst_model,pi，然後把 model_inst 設成 inst_model。這是 llama.cpp 伺服器設定檔的功能，不是外掛的功能，兩邊要一起改才會生效。
它不適合誰：硬體門檻與模型限制
最硬的一條限制是模型必須支援 FIM。README 直接說 the plugin requires FIM-compatible models，並連到 ggml-org 在 Hugging Face 上的一個集合。這不是建議清單，是必要條件。拿一個純 chat 模型接上去，補全不會照你預期的方式運作，因為 FIM 需要模型理解中間填空的格式。
第二條是硬體。README 的最低一檔是低於 8GB VRAM 跑 1.5B 模型，而範例截圖裡的 M1 Pro 搭配 Qwen2.5-Coder 1.5B Q8_0，一次請求花了 1245 毫秒。這個數字出現在官方文件裡，不是實測，但它說明了小模型加低階硬體的體驗大概是什麼量級：一秒多的等待，在打字節奏上是有感的。如果你的機器連這個都跑不動，外掛不會降級成某種雲端模式，它就是沒有建議。
第三條是工作型態。這個外掛做的是游標處的補全與選取範圍的改寫。它不會幫你跨檔案重構、不會改動整個專案的呼叫慣例、也不會理解你的型別系統。需要那類操作的人，找的是 agent 型的工具，不是補全外掛。
跟 Copilot 這類工具的實際差別
最直接的替代品是 GitHub Copilot 的 Vim 外掛，以及各種走同一路線的雲端補全服務。差別不在功能清單，在三件事的取捨。
第一是推論位置。Copilot 在雲端跑，你不需要任何本機算力，回應速度取決於網路與服務端排程。llama.vim 把這件事完全交給你，速度快慢是你自己的 GPU 決定的，離線也能用。第二是上下文策略。雲端服務通常以當前檔案為主，加上一些鄰近檔案的啟發式判斷，具體機制不對外公開。llama.vim 的 ring buffer 是明擺在原始碼裡的，chunk 數量、淘汰行為、上下文上限都在設定與狀態列上看得到。第三是模型選擇。Copilot 綁定服務商的模型，你只能等它更新。llama.vim 讓你換任何 FIM 相容的 GGUF，代價是你得自己判斷哪個模型適合你的語言與硬體。
如果你的團隊已經在用 Copilot 而且沒有資料外流的顧慮，換過來只會增加維運負擔。反過來，如果外流顧慮是真的，那 llama.vim 是目前少數把整條鏈路放在你手上的 Vim 選項，而且它隸屬 ggml-org，跟 llama.cpp 同一個組織，介面帶來的相容性風險相對低。
維護成本與授權的實際含意
外掛本身是 MIT 授權，README 的 badge 也標明這點，用在商業環境沒有授權上的障礙。但整個系統的維護成本不在外掛，在 llama.cpp。你必須自己追 llama.cpp 的版本，因為外掛依賴的端點行為與模型別名由那邊決定。llama-server 的參數、預設模型別名、甚至 API 路徑都可能隨上游變動，外掛的更新節奏不一定跟得上。
模型是另一個變動源。FIM 模型集合會增減，你現在調好的 1.5B 模型可能過一陣子被新版本取代，換模型意味著重新調參數、重新感受延遲。這不是一次設定就結束的事。
專案只有一個 release，v0.1.0，時間在 2026 年 8 月，而最後一次 push 是同年 9 月。版本編號說明它還很年輕，介面雖然已經有 :help llama_config 這種完整文件，但設定鍵的穩定性沒有長期記錄可查。導入時把 g:llama_config 的內容集中寫在一個檔案裡，會比散落在 .vimrc 各處容易在升級後排查。
編輯結論
llama.vim 適合已經在跑 llama.cpp、在意程式碼不出本機、且願意自己調伺服器參數的 Vim 使用者；如果你的機器沒有可用的 GPU 或統一記憶體，或你需要的是多檔案重構而不是逐行補全，這個外掛不是對的工具。導入前先確認三件事：你的硬體對應 README 哪一檔建議設定、llama-server 是否已在 endpoint_fim 指定的位址回應、以及你要用的模型是否在 ggml-org 的 FIM 模型集合內。這三項任一不成立，外掛就只是安靜地不給建議。
社群筆記