ggml-org/llama.vscode 是什麼？

這個擴充把 llama.cpp 的 fill-in-the-middle 補全、聊天與 agent 接進 VS Code，模型與推論都在本機。判斷重點在於：你願不願意為了資料不外流，接受一套需要自己挑模型、自己管 VRAM 的設定流程。

ggml-org/llama.vscode 可以商用嗎？

可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。

ggml-org/llama.vscode 還在維護嗎？

有在維護。儲存庫最近一次提交在 10 天前。

ggml-org/llama.vscode 是用什麼程式語言寫的？

主要是 TypeScript（依據 GitHub 的語言統計）。

llama.vscode 評測：本機 FIM 補全與 Llama Agent 的實際取捨

秒懂

它是什麼？: 這個擴充把 llama.cpp 的 fill-in-the-middle 補全、聊天與 agent 接進 VS Code，模型與推論都在本機。判斷重點在於：你願不願意為了資料不外流，接受一套需要自己挑模型、自己管 VRAM 的設定流程。
適合誰用？: 如果你手上有一張 16GB 以上 VRAM 的顯示卡，而且程式碼不能離開本機，llama.vscode 值得直接裝來試：用 brew install llama.cpp 或 winget install llama.cpp 裝好後端，再從狀態列的 llama-vscode 選單執行 Install/Upgrade llama.cpp 與 Select/start env。反過來說，如果你的機器只有內顯、或你期待開箱就能用的補全品質，這個專案會讓你失望，README 自己也說 CPU-only 設定的品質會顯著較低。
可以商用嗎？: 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
還在維護嗎？: 有在維護。儲存庫最近一次提交在 10 天前。
用什麼語言寫的？: 主要是 TypeScript（依據 GitHub 的語言統計）。

以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。

開源專案深度解析

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

它解決的是推論位置問題，不是補全功能問題

雲端補全工具的功能早就夠用，真正的分歧點在於每一次按鍵都代表一段程式碼離開你的機器。llama.vscode 把這個環節搬回本機：推論由 llama.cpp 的 llama serve 負責，VS Code 端只是一個前端。README 開頭對自己的定位寫得很直白，是 local LLM-assisted text completion、chat 與 agentic coding 擴充。

目標使用者因此相當明確。一種是公司政策不允許把原始碼送到外部服務的工程師；另一種是手上有閒置 GPU、想拿來跑推論的人。這個專案對「完全不想碰模型設定」的開發者並不友善，安裝章節要求你先處理 llama.cpp 後端，再從 llama-vscode 選單挑一個 env。它不是那種裝完就忘的擴充。

FIM 補全與 ring context 的資料流

補全的核心是 FIM（fill-in-the-middle）：模型同時看到游標前後兩段文字，在中間生成候選內容。README 明確列出補全模型的必要條件，外掛需要 FIM-compatible 模型，並指向 ggml-org 在 Hugging Face 上的 llama.vim 集合。也就是說，一個普通的指令微調模型接上來不會自動變成補全模型，這是第一個容易踩到的門檻。

上下文不是只有當前檔案。README 描述了一個 ring context 機制，把開啟中與編輯過的檔案、以及被 yank 的文字切成 chunk 放進環狀緩衝。這解釋了為什麼它能在消費級硬體上宣稱支援很大的上下文：搭配 llama.cpp 的 smart context reuse（README 連到 PR 9787），重複的前綴可以沿用既有的 KV cache，不必每次重算。這條設計線是整個專案最實際的價值所在，也是它跟「把整份檔案塞進 prompt」的做法最大的差別。

操作面上，Tab 接受整段建議，Shift+Tab 只接受第一行，Ctrl/Cmd+Right Arrow 接受下一個詞，Ctrl+L 手動切換建議。這組鍵位值得在正式使用前先確認，因為它會和 VS Code 既有的 Tab 補齊行為競爭。

安裝路徑與 llama serve 的參數選擇

後端安裝已經自動化。點狀態列的 llama-vscode 或按 Ctrl+Shift+M 打開選單，選 Install/Upgrade llama.cpp，Mac 與 Windows 會自動處理；Linux 要自己去 llama.cpp 的 release 抓二進位檔並把 bin 目錄加進 PATH。手動路線則是 brew install llama.cpp 或 winget install llama.cpp。

模型選擇直接綁在 VRAM 上，README 給了四段建議。超過 64GB 用 llama serve --fim-qwen-30b-default；超過 16GB 用 --fim-qwen-7b-default；低於 16GB 用 --fim-qwen-3b-default；低於 8GB 用 --fim-qwen-1.5b-default。這四行是整個專案最實用的資訊，因為它把「我該跑哪個模型」這個問題變成一個硬體查表動作。

CPU-only 的情況 README 另外放在折疊區塊，並附上一句警告：品質會顯著較低。範例指令帶了 --port 8012、-ub 512、-b 512、--ctx-size 0 與 --cache-reuse 256，模型是 Qwen2.5-Coder-1.5B-Q8_0-GGUF 或 0.5B。--cache-reuse 這個參數值得注意，它正是前面 ring context 能省下重算成本的前提。用 -hf 下載的模型會落在 macOS 的 ~/Library/Caches/llama.cpp/、Linux 的 ~/.cache/llama.cpp、Windows 的 LOCALAPPDATA。

如果你不想從命令列起服務，選單裡的 Select/start env 會處理這件事。env 是一組模型的集合，選取或取消 env 會連帶處理裡面所有模型，README 也提供 env 的匯入與匯出。

Llama Agent 與 MCP：另一條產品線，成熟度不同

擴充內含 Llama Agent，在 Explorer 檢視中提供介面，用 Ctrl+Shift+A 開啟。README 說它可搭配本機模型，並直接點名 gpt-oss 20B 是目前的最佳選擇，也提到可以接 OpenRouter 之類的外部模型。工具面有 9 個內建工具，其中 custom_tool 回傳檔案或網頁內容，custom_eval_tool 讓你自己用 JavaScript 寫一個接收輸入、回傳字串的函式。

MCP 的支援方式值得說清楚：它用的是「已安裝並在 VS Code 中啟動的 MCP Server」所提供的工具，而不是自己另外管理一組 server。這個設計把生命週期責任交回 VS Code，好處是不用兩邊設定，代價是你得先讓那些 server 在 VS Code 裡跑起來。

README 另外提到可透過 Telegram bot 從手機取用 agent，以及 vscode://ggml-org.llama-vscode?view=agent&prompt=Hello 這種 deep link 可以直接開啟 VS Code 並帶入 prompt。這些是延伸用法，不是補全流程的一部分。把 agent 和補全混為一談會誤判這個專案：補全走的是 FIM 與 ring context，agent 走的是工具呼叫與迴圈，兩者的模型需求與失敗模式都不一樣。agent 的最大迴圈數可以設定，這在模型陷入重複呼叫時是唯一的剎車。

什麼情況下它不該是你選的工具

最明顯的限制是硬體。低於 8GB VRAM 只剩 1.5B 等級的模型，而 README 對 CPU-only 的評語是品質顯著較低。補全這種功能對延遲極度敏感，一個要等好幾秒才出現的建議，實務上等於沒有。README 有「控制最大生成時間」的設定項，但那是止血，不是解法。

第二個限制是模型必須 FIM 相容。你手上現成的 GGUF 如果不是為 FIM 訓練的，接上來不會得到可用的補全結果。這縮小了可選模型的範圍，也意味著你不能單純沿用自己慣用的聊天模型。

第三個限制來自 ring context 的取捨。把開啟與編輯過的檔案切塊放進上下文，對跨檔案重構有幫助，但這些內容會一併進入推論，佔用 context 與快取。README 提供「設定游標周圍上下文範圍」的選項，實際上你必須自己調到一個平衡點，調太大會拖慢，調太小又失去跨檔案的價值。

最後是維護成本。版本號仍停在 0.0.x，最近的釋出是 v0.0.65（2026-09-05）、v0.0.64、v0.0.63。這個節奏說明它還在快速變動，設定介面與選單項目隨時可能調整。授權是 MIT，對商業使用相對寬鬆，但 llama.cpp 後端與你下載的模型各自有自己的授權條款，尤其是模型權重，這部分要自己確認，本文不構成法律意見。

跟 llama.vim 的分工，以及跟雲端補全的差異

同一個組織下最直接的替代品是 llama.vim，README 在 Implementation details 與 Other IDEs 兩處都提到它。兩者的關係不是競爭而是分工：llama.vim 服務 Vim/Neovim，llama.vscode 服務 VS Code，而且 llama.vscode 的初版是以 llama.vim 為參考實作。真正的差異在使用者介面層：VS Code 版多了 Explorer 中的 agent 檢視、deep link、MCP 工具選擇、以及從 Hugging Face 直接搜尋下載模型。如果你本來就在 Neovim，沒有理由為了這些功能換編輯器。

跟雲端補全服務的差異則在架構層。雲端方案把模型放在對方機房，你付出的是程式碼外流與網路延遲，換來零設定；llama.vscode 把模型放在你的 GPU 上，你付出的是安裝步驟、模型選擇與 VRAM 管理，換來資料不出機器。這個交換沒有普遍正確的答案，取決於你的程式碼能不能離開本機。

還有一個容易被忽略的差異：llama.vscode 的補全品質直接等於你跑得動的模型品質，而不是供應商持續更新的模型品質。你的硬體決定了天花板，而且這個天花板不會因為擴充更新而自動上升。

採用前的具體檢查順序

先確認硬體落在哪個區間，再回頭看 README 的四段 llama serve 建議，這一步會直接決定你之後所有的體驗。如果你的 VRAM 低於 8GB，先想清楚你是否接受 1.5B 等級的補全品質，而不是先裝再說。

接著確認模型來源。用 -hf 從 ggml-org 的 FIM 集合下載最省事，因為那些模型已經對齊外掛的需求；自己帶模型的話，FIM 相容性是第一個要驗證的條件。

然後確認後端真的在跑。llama serve 的 --port 要跟擴充的設定一致，--cache-reuse 有沒有開會影響上下文重用的效果。若你走 CPU-only 路線，README 的範例用 --ctx-size 0 搭配 --cache-reuse 256，這組參數值得照抄再微調，而不是自己憑感覺設。

最後才是鍵位與生成時間。Tab、Shift+Tab、Ctrl/Cmd+Right Arrow、Ctrl+L 這四個動作會改變你原本的編輯習慣，先在小檔案上試，確認它不會干擾你既有的補齊流程，再決定要不要在日常工作的專案裡開著。

編輯結論

如果你手上有一張 16GB 以上 VRAM 的顯示卡，而且程式碼不能離開本機，llama.vscode 值得直接裝來試：用 brew install llama.cpp 或 winget install llama.cpp 裝好後端，再從狀態列的 llama-vscode 選單執行 Install/Upgrade llama.cpp 與 Select/start env。反過來說，如果你的機器只有內顯、或你期待開箱就能用的補全品質，這個專案會讓你失望，README 自己也說 CPU-only 設定的品質會顯著較低。動手前先確認三件事：你的模型是不是 FIM 相容、llama serve 的 --cache-reuse 有沒有開、以及你的 VRAM 落在哪個建議區間。

官方來源

社群筆記