今年早些时候才开始较为认真地关注本地托管的大型语言模型（LLM）。首先使用的是ollama，使用了一段时间后，偶然发现它正在使用llama.cpp。决定给自己找点麻烦，尝试在Linux上为一张不太受支持的AMD显卡从源代码编译llama.cpp的ROCm后端，但没有成功。于是放弃并重新使用ollama。为自己构建了一个简单的故事编写辅助命令行工具，基于文件包含来简化知识管理，并为其添加了ollama API支持。ollama突然开始使用CPU进行推理，而ollama ps却声称正在使用GPU，于是决定寻找替代方案。找到了koboldcpp，尝试了同样的ROCm编译，但没有成功，于是决定运行常规版本，令我惊讶的是，它可以运行，发现它使用的是vulkan。这样持续了几个星期。决定再次尝试llama.cpp，但这次是vulkan版本，并且它成功了！llama - server提供了一个简洁且非常好用的网页界面，还提供了一个API端点（包括与OpenAI兼容的端点）。llama.cpp还附带了许多其他工具并且非常可调节。你不必等待其他依赖应用程序来提供此功能。llama.cpp就是你所需要的全部。
讨论总结
原帖作者认为llama.cpp功能强大，有干净的web - ui和API端点等，是使用本地托管LLM时的唯一所需。评论者们从不同角度进行讨论，有人推荐llama - swap等工具与llama.cpp结合使用，也有人提出llama.cpp存在多模态支持不足、性能在并发用户时较差、对草稿模型要求严格等问题，还有人提到其他工具如Ollama、koboldcpp、vllm等在某些方面具有优势，并且在软件是否为自由软件、llama - server是否能取代open webui等方面也有涉及，讨论氛围比较热烈且观点多样。
主要观点
- 👍 llama.cpp功能强大且易用
- 支持理由：有干净且功能强大的web - ui、提供API端点、自带很多工具且高度可调整、一旦构建好无太多设置即可使用模型、编写良好且易于从源代码构建。
- 反对声音：存在性能问题（如并发用户时）、对草稿模型要求更严格、缺乏张量并行和fp8支持、python适配器已被弃用和过时。
- 🔥 llama.cpp不是万能的，存在其他替代方案
- 正方观点：在多模态方面落后、某些情况下速度慢、运行多模型能力差、vulkan.cpp可实现跨供应商多GPU推理且能达到llama.cpp百分之80 - 90%的性能水平、MLX在金属上性能更好、mistral - rs支持新模型和一些特殊功能。
- 反方观点：原帖作者分享了自己在多种尝试后发现llama.cpp的优势，部分评论者也认可llama.cpp的主导地位和自身优势。
- 💡 Ollama有其独特优势
- 解释：适合推荐给对本地LLM感兴趣的非技术人员、包含使一些多模态/视觉语言模型工作的补丁、在使用CPU/CUDA时对非技术人员更易用、在模型文件操作方面可能比llama.cpp方便、导致系统VRAM溢出可能是ROCM的问题而非自身问题。
金句与有趣评论
- “😂 Ollama was created when llamacpp was hard to use by a newbie but that changed completely when llamacpp introduced llamacpp server in a second version ( first version was very rough yet ;)”
- 亮点：简单明了地阐述了Ollama创建的背景与llama.cpp发展历程的关系。
- “🤔 llama.cpp has given up on multimodal support. Ollama carries the patches to make a number of multimodal/VLMs work. So, I can’t agree that llama.cpp is all you need.”
- 亮点：直接指出llama.cpp在多模态支持方面的不足，成为反对原帖观点的关键依据。
- “👀 I love the new llama - server web interface, it’s simple, it’s super clean.”
- 亮点：表达了对llama - server的web界面的喜爱，从用户体验角度给出正面评价。
情感分析
总体情感倾向比较复杂，既有赞同也有反对。主要分歧点在于llama.cpp是否能满足所有需求，原因是在多模态支持、性能、易用性等方面不同评论者有不同的体验和需求。例如在多模态方面，有些评论者认为llama.cpp的缺失使其不能成为唯一选择，而有些评论者则更关注其在文本处理方面的表现。
趋势与预测
- 新兴话题：vulkan.cpp作为llama.cpp的潜在替代者可能会引发更多讨论，还有关于如何解决llama.cpp在性能、多模态支持等方面的不足。
- 潜在影响：如果llama.cpp在性能和多模态支持等方面得到改进，可能会进一步巩固其在本地LLM领域的地位；而如果其他替代工具不断发展，可能会改变用户在本地LLM工具选择上的格局。
详细内容：
标题：关于 llama.cpp 的热门讨论
最近，Reddit 上有一篇关于 llama.cpp 的帖子引起了广泛关注。该帖子作者详细讲述了自己与各种本地语言模型（LLM）打交道的经历，从最初尝试 ollama 到后来探索 llama.cpp 及其相关工具，最终发现 llama.cpp 功能强大且实用。这篇帖子获得了大量的点赞和众多评论。
讨论的主要方向包括 llama.cpp 与其他类似工具的比较，如 ollama、LM Studio 等，以及 llama.cpp 在不同硬件配置和应用场景下的表现。
核心问题和争议点在于 llama.cpp 是否真的如标题所说“is all you need”，还是存在一些局限性和不足之处。
讨论焦点与观点分析
有人认为 llama.cpp 具有诸多优势，比如提供了干净且功能强大的 Web-UI 和 API 端点，还自带众多实用工具且可高度自定义。比如，有人分享说：“llama-server 提供的 Web-UI 非常简洁易用，而且 API 端点兼容性强。”
然而，也有不同声音。有人指出 ollama 对非技术人员更友好，方便模型管理；LM Studio 虽然功能全面但存在资源消耗大、学习曲线高等问题。比如：“我倾向于向非技术人员推荐 ollama，它更容易上手。”
还有用户提到 llama.cpp 在多模态支持方面存在不足，而有些工具如 koboldcpp 在某些方面表现更出色。比如：“koboldcpp 在多显卡支持和便携性上有优势。”
同时，也有人分享了在使用 llama.cpp 过程中的个人经历和遇到的问题，比如模型切换时的不稳定、在特定硬件上的性能表现不佳等。例如：“我尝试了 llama-swap，但在模型切换一次后就不太可靠了。”
总之，讨论中既有对 llama.cpp 的称赞，也有对其局限性的探讨，反映了用户在选择和使用本地 LLM 工具时的多样性需求和思考。
感谢您的耐心阅读！来选个表情，或者留个评论吧！