原贴链接

嘿，LLM爱好者们，

我一直在试验适合16GB VRAM的模型，用于编码聊天和自动完成任务。我尝试了以下模型：

  • Codegeex 9B
  • LLama3.1 8B
  • Granite 8B
  • Gemma2 9B
  • Codeqwen
  • Phi 3 Mini（更新版本）
  • Codestral

虽然Codestral表现优于其他模型，但它只能在较低的量化级别上合理运行，这对我所知对编码任务的性能有显著影响（有人有量化级别与编码性能的基准测试吗？）。目前，我使用Codegeex 9B进行聊天，使用Codeqwen-base进行自动完成。

我特别有兴趣使用Phi3进行编码，鉴于其在LMSys Arena上的令人印象深刻的基准测试结果和性能。然而，当我尝试通过Ollama使用它时，即使使用Q8量化，它也会产生低质量的结果，包括大量无用的注释和冗长的输出。有人遇到过这个问题或找到了解决方案吗？

理想情况下，我希望找到一个解决方案，使聊天和自动完成模型同时适应VRAM，消除切换它们时的延迟。

作为参考，我使用这个提示来测试模型的能力：

“在Python中编写一个A*搜索实现，使其通用化，接受用于启发式、邻居等的回调。以Markdown格式回答，并在最后提供一个使用示例。”

我认为一个模型“可用”，如果它提供了一个无错误的答案。Codeqwen、Codegeex和Codestral都通过了这项测试，而LLama3.1失败了。新的Phi3在LMSys Arena直接聊天时工作得很好，但在通过Ollama运行时，大约10次尝试后没有提供一个可用的响应。Granite工作了，但它经常忽略或未能提供一个工作示例。一些模型甚至超越了预期，提供了有用的注释和类型提示以及工作源代码，而没有被要求（例如，新的sus-colum-r）。

如果你有任何建议或见解，我很乐意听到！

附言：我非常感谢任何关于替代模型或配置的建议，这些可能会在16GB VRAM约束下提高性能。

编辑：刚刚尝试了Phi 3.1的fp16版本，温度设置为0，Top-p设置为1，现在工作正常了。我想这个模型对量化真的很敏感，因为即使是Q_8版本有时也会给出可疑的结果。

讨论总结

本次讨论主要集中在如何在16GB VRAM的限制下选择和优化适合编程聊天和自动补全任务的本地编码大语言模型（LLM）。参与者分享了各自尝试的不同模型（如Codegeex 9B、LLama3.1 8B、Granite 8B等）及其性能体验，特别关注了Phi3模型的表现和量化级别的影响。讨论中还涉及了模型推荐、参数调整、成本效益分析、隐私考虑以及未来硬件升级的计划。整体氛围积极，参与者寻求更高效的解决方案，并分享了有价值的见解和建议。

主要观点

  1. 👍 推荐使用deepseek-coder 16B模型，q6_K量化
    • 支持理由：DinoAmino推荐在q6_K量化下运行以获得最佳结果和性能。
    • 反对声音：Granite模型表现不佳，对IBM有更高期望。
  2. 🔥 Starcoder2-3B模型适合本地Python代码自动补全
    • 正方观点：reeceshuttle分享了使用经验，认为效果良好。
    • 反方观点：Granite模型在测试中表现不佳，weeblay未尝试Starcoder。
  3. 💡 Phi3模型在Ollama上使用时效果不佳
    • 解释：作者特别关注Phi3模型，但在Ollama上使用时遇到了问题。
  4. 👀 使用Google的最新API进行代码生成是一个可行的选择
    • 解释：Roland_Bodel_the_2nd建议使用Google的API，因其提供了免费层级且成本低廉。
  5. 🚀 作者计划升级到新的Ryzen 9000系列和更多RAM
    • 解释：作者目前受限于硬件，计划未来升级以改善性能。

金句与有趣评论

  1. “😂 DinoAmino：推荐使用deepseek-coder 16B模型，q6_K量化”
    • 亮点：直接有效的模型推荐，强调量化选择的重要性。
  2. “🤔 reeceshuttle：If you want even smaller models, I have used Starcoder2-3B (for local tab complete only) and found that it has worked well for me using python.”
    • 亮点：分享个人经验，推荐适合特定任务的小模型。
  3. “👀 Roland_Bodel_the_2nd：if you’re just doing code generation like in your example; definitely try Google’s latest offerings via API; they have a free tier and the cost is very low anyway”
    • 亮点：提出使用API的新思路，强调成本效益。

情感分析

讨论总体情感倾向积极，参与者分享了各自的经验和建议，寻求更高效的解决方案。主要分歧点在于模型选择和量化级别的影响，以及本地运行与使用API的成本效益分析。可能的原因包括对模型性能的不同体验和对硬件限制的共同关注。

趋势与预测

  • 新兴话题：微调模型和API使用的讨论可能会引发后续更多关于如何优化模型性能和成本效益的讨论。
  • 潜在影响：对编程模型性能的持续关注可能会推动更多针对特定任务的模型优化和硬件升级的需求。

详细内容：

标题：探索 16GB VRAM 下的最佳本地编码 LLM 配置

在 Reddit 上，一位 LLM 爱好者发起了一场关于在 16GB VRAM 条件下寻找最佳编码 LLM 配置的热烈讨论。该帖子获得了众多关注，评论数众多。原帖作者尝试了多种模型，如 Codegeex 9B、LLama3.1 8B 等，并分享了各自的表现和问题。

讨论焦点与观点分析：

  • 有用户推荐了 deepseek-coder 16B，认为采用特定量化方式能取得较好效果。
  • 有人提到 Starcoder2-3B 用于本地代码补全表现不错，但在聊天方面不确定。
  • 对于 Gemma2，不同用户的测试结果有所差异。
  • 一些用户认为在本地运行模型是为了避免数据共享，也有人认为从成本角度，使用 API 更划算。
  • 还有用户推荐了 mistral-nemo、deepseek-coder-lite-v2 等模型，并分享了使用体验。

比如，有用户分享道：“我使用 Starcoder2-3B 用于本地代码补全，发现效果不错。” 还有用户表示：“我做过计算，使用 API 调用更强大的模型并支付费用，比购买高端显卡在本地运行更经济。”

讨论中的共识在于大家都在积极探索在有限 VRAM 条件下的最佳解决方案。一些独特的观点如对不同模型的详细性能分析，丰富了讨论的内容。

总之，这场讨论为在 16GB VRAM 限制下寻求最佳编码 LLM 配置提供了丰富的参考和思路。