llama.vim：把 llama.cpp 的 FIM 补全接进 Vim
Vim plugin for LLM-assisted code/text completion
秒懂
- 它是什么？
- 这个插件本身不做推理，它只负责把光标周围的上下文打包成 FIM 请求发给本机 llama.cpp 服务端，再把返回的补全贴回缓冲区。判断它是否适合你，取决于你是否愿意自己维护一个推理服务端。
- 适合谁用？
- 适合已经在用 Vim、手上有一台能跑 llama.cpp 的机器、并且不接受把代码片段发到外部服务的人。不适合想要开箱即用、或者没有稳定推理硬件的人：插件只提供客户端，llama-server 的下载、模型选择、显存分配都要你自己处理。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 6 天前。
- 用什么语言写的？
- 主要是 Vim Script（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是编辑器与推理服务端之间的那段胶水
Vim 本身没有内建的补全模型接口，llama.cpp 只暴露 HTTP 服务端，两者之间缺一层东西：决定什么时候发请求、发多少上下文、返回的文本怎么落到缓冲区、用户怎么接受或拒绝。llama.vim 就是这层。它不包含任何模型权重，也不做推理，README 明确写着插件需要一个运行中的 llama.cpp 服务端实例，地址由 g:llama_config.endpoint_fim 和 endpoint_inst 指定。
目标用户很具体：用 Vim 或 Neovim 写代码、希望补全在本地跑、并且愿意自己起一个 llama-server 的人。仓库主题里同时打了 copilot 和 llama 两个标签，定位就是 Copilot 式交互的本地替代。如果你的编辑器是 VS Code，这个插件对你没有意义；如果你的机器跑不动量化后的 1.5B 模型，它同样没有意义。
两种请求模式：FIM 补全与指令编辑
插件提供两条独立的功能线，走两个不同的端点。第一条是 Fill-in-Middle 补全：在 Insert 模式下随光标移动自动触发，把光标前后的文本一起送进模型，让模型填中间那段。第二条是指令编辑，用 <leader>lli 触发，属于对选中或当前区域的改写请求，对应 endpoint_inst。两者默认键位不冲突，但 FIM 的接受键是 Tab，指令编辑的接受键也是 Tab，键位表里 keymap_fim_accept_full 和 keymap_inst_accept 都指向 <Tab>，实际使用中需要靠触发上下文区分。
FIM 的接受粒度有三档：Tab 接受整段，Shift+Tab 只接受第一行，还有 keymap_fim_accept_word 用于只接受一个词。这个分层是实际写代码时最有用的部分，因为模型给出的多行补全经常只有第一行是对的。
上下文靠环形缓冲复用，而不是每次重算
这是插件里唯一需要认真理解的设计。README 的 Features 里写着 ring context with chunks from open and edited files and yanked text，并且链接到 llama.cpp 的一个 PR，说明它支持在低端硬件上处理很大的上下文。
从示例截图里的统计文本可以还原出机制：状态行会显示当前使用的上下文 token 数、最大值、环形缓冲中的 chunk 数量、已淘汰的 chunk 数、排队中的 chunk 数，以及本次请求新计算的 prompt token 数。M1 Pro 上跑 Qwen2.5-Coder 1.5B Q8_0 的那张图给出一组具体数字：上下文 15186 token，上限 32768，缓冲里 30 个 chunk（共 64 个），淘汰 1 个，队列 0 个，本次新算 prompt 260 token，生成 24 token，耗时 1245 毫秒。
关键在于新算的 prompt 只有 260 token，而不是一万多。插件把打开和编辑过的文件、以及 yank 的文本切成 chunk 放进环形缓冲，服务端侧复用之前的 KV 缓存，只有新进入窗口的部分才需要重新计算。这就是它能在消费级硬件上维持大上下文的原因。代价是缓冲容量固定为 64 个 chunk，超出后旧 chunk 被淘汰，跨文件长时间工作会丢掉早期上下文。README 没有给出 chunk 的切分粒度和淘汰策略的细节，这部分只能读 autoload/llama.vim 源码确认。
安装：插件三行，服务端才是主要工作量
插件侧的安装按 README 给的三种方式任选。vim-plug 是 Plug 'ggml-org/llama.vim'；Vundle 需要先 git clone 到 ~/.vim/bundle 再在 vundle#begin() 段里加 Plugin 'llama.vim'；lazy.nvim 直接给 'ggml-org/llama.vim'。
配置统一走 g:llama_config 这个字典，README 给了两种写法。可以在插件加载前写 let g:llama_config = { 'show_info': 0 }，也可以之后用 let g:llama_config.show_info = v:false 直接赋值。用 lazy.nvim 时要在 init 回调里设置，例如把 auto_fim 设为 false 关闭自动补全。
服务端按平台装：macOS 用 brew install llama.cpp，Windows 用 winget install llama.cpp，其他系统从源码构建或取 release 二进制。启动参数 README 按显存分档：超过 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 上的一个集合。
多机场景靠 profile 切换，但模型名不在切换范围内
如果你有两台机器跑不同的模型，可以配置命名 profile：把 g:llama_config.profiles 设成一个字典，键是名字，值是形如 http://192.168.0.66:8080 的地址，再用 g:llama_config.profile 指定当前项。:LlamaProfile 列出可用 profile，:LlamaProfile spark 切换到指定项，命令支持补全，选择会被持久化，:LlamaProfileReset 恢复 .vimrc 里配置的 profile 或自定义端点。
这里有个 README 自己点明的边界：profile 只能切换主机，切不了模型。模型由 model_fim 和 model_inst 两个配置项决定。作者的绕法是让各台服务端用一致的模型命名，或者在服务端配置里给模型加别名，例如在 [qwen3.8-27B] 段下写 alias = inst_model,pi，然后客户端把 model_fim 设成 fim_model、model_inst 设成 inst_model，这样切换 profile 时请求的模型名不变，由服务端别名解析到实际权重。这个设计能用，但要求你在服务端侧维护别名表，属于把复杂度从客户端挪到了服务端。
它不适合谁：没有服务端就没有插件
最直接的失败模式是服务端没起来。插件不会替你启动 llama-server，也不会在端点不可达时给出有用的提示。README 里没有描述任何连接失败、超时或重试行为，所以端点配错、端口写错、服务端 OOM 退出，在编辑器这一侧的表现需要你自己排查。
第二个限制来自硬件档位。官方预设最低一档是 --fim-qwen-1.5b-default，对应不足 8GB 显存。低于这个配置的机器，README 没有给出方案。1.5B 量化模型给出的补全质量与 7B、30B 差距明显，这一点从 README 把预设按显存分档本身就能看出来，它没有声称小模型能替代大模型。
第三个是上下文淘汰。环形缓冲只有 64 个 chunk，长时间在大型代码库里跨文件跳转会持续淘汰旧内容。README 没有提供调整缓冲容量的配置项说明，只说完整选项列表见 :help llama_config 或 autoload/llama.vim 源码。如果你需要模型稳定记住整个项目，这个插件的设计目标与此不同。
替代方案：Copilot 与 continue 类插件的差别在服务端归属
最直接的对照是 GitHub Copilot。差别不在补全交互，而在推理发生在哪里：Copilot 的模型跑在 GitHub 侧，你不需要显卡、不需要下载权重、不需要维护进程，代价是代码片段要发出去，且补全质量与可用性由服务方决定。llama.vim 把这两件事全部翻转过来，本地推理换来了数据不出机器，也换来了你自己承担运维。
另一类是同样接本地或远程后端的编辑器插件，例如 Neovim 生态里的 continue 类方案。它们的差异在于抽象层数：这类插件通常自带后端管理、模型切换面板和多后端适配，配置面更大；llama.vim 只认 llama.cpp 的 HTTP 端点，配置项就是 g:llama_config 一个字典，源码集中在 autoload/llama.vim 一个文件里。README 开头写的是 the plugin aims to be very simple and lightweight，这句话同时也是它的边界说明：想要一个统一管理多个推理后端的界面，这个插件不提供。
维护成本与许可
插件是纯 Vim Script，MIT 许可，仓库未归档，最近一次推送是 2026-09-08，发布过 v0.1.0。MIT 意味着你可以修改、再分发、商用，只需保留版权声明与许可文本；这里不构成法律意见，涉及公司合规请走内部流程。
真正的升级成本不在插件，而在 llama.cpp 那一侧。插件依赖服务端的 FIM 接口和 KV 缓存复用行为，README 直接链接到 llama.cpp 的一个 PR 来说明上下文复用能力，说明这个能力由服务端提供而非插件实现。llama.cpp 迭代频繁，服务端接口或预设名称变动时，插件侧可能需要跟着调整；而插件自身只有 v0.1.0 一个版本，说明它的版本节奏与服务端不同步。把 llama-server 固定在一个已知可用的版本，是控制这类风险的具体做法。
编辑结论
适合已经在用 Vim、手上有一台能跑 llama.cpp 的机器、并且不接受把代码片段发到外部服务的人。不适合想要开箱即用、或者没有稳定推理硬件的人：插件只提供客户端，llama-server 的下载、模型选择、显存分配都要你自己处理。上手前先确认三件事：`:LlamaProfile` 能否列出并切换到你的服务端；`g:llama_config.model_fim` 与 `model_inst` 是否与 llama-server 上配置的别名对得上；以及你的显存档位对应哪个 `--fim-qwen-*-default` 预设。这三点任一没对齐，补全请求就会静默失败，而插件不会替你诊断服务端。
社区笔记