最近写了一个 elisp 的小工具通过主流的大模型来进行代码补全 (gemini, gpt, claude 等等)。
目前使用下来体验感受还是挺不错的，这些 llm 模型本身参数量更大，capability 自然更加强大，返回的代码通常质量都比代码补全专用的模型 （通常都是些小模型）要强一些，当然代价就是输出速度要慢很多，满足实时补全的话还是很勉强。一点区别是他们经常会返回多行补全，要比 copilot codeium 这些偏保守以返回单行为主的频率要高很多。
表扬一下使用体感比较好的模型是 gemini-1.5-flash 和 open-mistral-nemo。这些比较新出的“小”模型的输出都很不错，能够完全理解你的需求是要做 “补全”，不会给你套回答问题的模版，在速度方面虽然不能达到实时补全的效果，但是也可以在几秒内迅速输出补全结果。像 gpt-3.5-turbo, claude-haiku 这些比较老的小模型就不能满足需要了，完全不能理解我的需求，返回的代码质量完全不可用。
另外评价一下几个新出的小模型：
- gpt4o-mini 的代码输出质量是没问题的，但是感觉回答的味道太重了，让它做代码补全还是像问答机器人一样，返回的结果太像回答问题的模版，不过通常不会给你套上开头的那种废话，还是可用的。感觉 openai 可能为了让这个小模型的跑分牛逼，用了大量的 gpt4 生成的问答模版数据来训练。
- llama-3.1-8b 的问题和 gpt4o-mini 差不多，还要再严重一点，回答的时候还是经常带上模版回答的那种开头的废话，另外感觉代码质量也要比 4o-mini 要略略略差一点，但是可能是错觉。
同时我也尝试了一些专门支持直接进行 text completion (FIM)，而不需要使用 chat 的问答模版的 llm：
- codestral-22b，这个的代码质量是没有问题的，但是感觉因为模型有点大，在速度方面不能满足我的需求，有条件本地部署的话应该是最佳选择。或者官方能开放一个 7b 版的小模型也不错。
- deepseek-coder，代码质量是 ok 的，但是不知道他们的官方 API 到底用的是多大的模型，也有可能是因为 deepseek platform 的 GPU 性能一般，所以感觉推理速度不太能满足我的需求。
目前市面上的提供 API 服务的 LLM 大部分还是以 chat LLM为主，支持 text completion 的 LLM 很少，像我这样没有强大的本地 GPU 来部署模型的，想用代码补全就还是只能做 prompt 工程调试写 prompt 让 chat llm 来干这活，不过好在最新出的这些小模型的理解能力还是很强的，能够理解我的需求。如果有条件部署本地的 gpu，感觉用专门的 text completion model 应该要比使用 chat llm 效果更好。
还有常见的 llm 的小问题，例如：
- 返回的结果括号配不平。
- 返回的结果有时会包含部分这一行光标前面的内容。
- 返回的结果有时会包含这一行光标后面的内容。
这就导致目前我使用的时候主要都是在一行的开头来调用补全，尽量避免在一行写到了一半再进行补全。
个人认为这些问题 codeium，copilot 等 app 应该也是有对 llm 的输出结果做了后处理来解决的，应该不是它们用的小模型就能解决这些问题。
最后就是价格， gpt-4o-mini 或者 gemini-flash 这样的小模型，我的 max 上下文长度大概是 4000 tokens（12800 characters）左右，在我不用实时补全的情况下，一天大概零点几刀吧，用一个月应该比 copilot 要划算。
更新 2024-07-31 ：用了一段时间 open-mistral-nemo 后感觉没有那么好，对于上下文的记忆能力比 gemini-flash / gpt-4o-mini 都差一些，可能比 llama-3.1-8b强一些。优点在于它会遵循指令，缺点在于有的时候会完全忘记 cursor position，返回的结果和 cursor position 所在的上下文完全没有关系，现在在小模型排名里我会认为它低于 gpt-4o-mini 和 gemini-flash。我目前仍然认为 gemini-1.5-flash 是小模型里手感最好的，之后会回来再次更新我的体验。
5 个赞
感谢分享。
近期我在用 copilot 插件，还可以，但我有些担忧隐私问题。另外靠组织拼车用 copilot 似乎不太稳，近期也在考虑替代选项
你用过 codeium 嘛？在 emacs 里面补全质量怎么样？
用过，codeium 的 capf 实现完全不可用，主要还是 capf 和异步补全的兼容性太差，如果你要用 codeium 的 capf 就没办法用 lsp 补全了。如果想要用自动补全建议配合 lsp-bridge 使用，或者就使用 cape 的 cape-capf-interactive 函数来把 codeium-calf 转换到 minibuffer 里手动补全。
codeiun补全 boilerplate 代码是没问题的，理解复杂代码的能力比 copilot 稍微差一点点的水平，但是差距不太大。不过 codeium 的多行补全要比 copilot 更保守，copilot 通常比较长的 boilerplate 代码马上能反应过来给你多行补全，但是 codeium 你要接受几次单行补全后才能反应过来返回多行补全。
我有很长时间没用过 copilot了，不知道它现在的跨文件的代码补全能力怎么样，codeium 是有一定的跨文件补全能力的（比较局限，也时灵不灵）。
copilot 的 emacs 插件有一个 bug （好像还没解决）会导致 copilot server 在后台悄悄死掉需要时不时重启 copilot，不知道现在还有没有这个问题，codeium 没有这个问题。
2 个赞
今天使用了 groq 非常惊喜，llama 3.1 70b 的模型能够达到 300+ token 每秒的输出速度 比 gpt4o-mini 和 gemini-flash 还快。这样的速度已经完全可以将 request timeout 设置为 1s 来做自动补全了，而且 70b 的模型尺寸也是达到了一个中杯的量级，在理解能力，代码完成能力上要比 10b 以下的小模型强不少。最重要的是，目前还是 免费 免费！
2 个赞
看起来这是一个不必自己运行模型的选择？我一直没有尝试本地运行模型，主要原因是我的机器都是七八年前的老机器，没有显卡，处理器也不太够用。这玩意还很消耗内存。我不同网络的多台机器上都要使用补全，等于就要部署多次，否则通过网络访问很慢。
如果使用 groq，该使用 emacs 的什么插件呢？
最近我又把 groq 换成了 fireworks。groq 虽然快而且免费，但是访问高峰的时候会拒绝你的请求（尤其是在美国时间的工作时间）。fireworks 比 groq 要慢一些，但是也算够快 （100 token 每秒），关键是不会限流，访问很稳定。
至于实现，你可以看一下 llm.el ，基于 llm-chat-streaming 来写一些函数就可以了。我是从头自己写了一个实现。
2 个赞
我了解了下 fireworks，似乎它需要付费？0B - 16B $0.20
请教下 16b 这种规格的对处理日常工作（技术问题、编程）够用吗？
建议用 gemini-flash。速度比 4o-mini 快，仅针对本应用场景的遵循指令比 4o-mini 更强，价格几乎可以忽略。我这个月用到现在价格不到 0.2 刀。长期用下来 llama 72b 还不如 Gemini-flash。gpt 4o 和 claude 3.5 sonnet 毫无疑问是更强的，但是速度更慢，价格也更贵。
ELF
10
大家应该把“代码补全”和“编程辅助”区分一下。
辅助编程，最近试了下CURSOR，真惊艳啊。EMACS领域目前相似的包是这个ELYSIUM，挺新的，还比较简陋，我试过CLAUDE和GEMINI做后端，CLAUDE还凑合，GEMINI能用，但都不太稳，跟CURSOR没法比，慢慢会成熟吧。另外一个封装包ADIDER.EL，感觉是目前EMACS比较理想的CURSOR替代。
至于代码补全，个人感觉传统的LSP补全工作已经挺好了，辅以AI辅助效果足够，至于专门的像CODEDIUM那种AI代码补全工具似乎没多大前景。
ai 确实更适合做代码助手，用来做代码补全有点大材小用了。主要是强大的模型没办法满足补全的实时要求，弱的模型又太弱。而且 chat llm 的 sft 的训练模式都是按照对话的形式来的，更适合直接用自然语言给它提需求。
现在我也在用 aider，它的基于 treesitter 构建的 repo-map 我觉得是一个很有创意的点子，作为整个 project 的大纲喂给 llm 非常合适，也被 avante.nvim 抄走了（不知道是不是 aider 的原创的还是抄 cursor 的）。其他的 code assistant 形式的工具还在观望。