原贴链接

我很好奇，我听说其他后端，特别是exllamav2在很多情况下比llama.cpp更快，特别是当有多张显卡甚至多台机器运行它的时候，模型文件也容易获取，所以是有需求的。然而我发现的任何应用，即使是那些支持某种可插拔后端的应用，通常也只提供llama.cpp的CPU、llama.cpp的Metal、llama.cpp的CUDA、llama.cpp的Vulkan版本，仅此而已。exllama似乎只被像oogabooga或LoLLMs这样通常有点蹩脚且不太好用的Web UI所支持。所以我的问题是为什么会这样呢？exllama和其他后端真的难到没人想去碰它吗？llama.cpp有LM studio、Msty、GPT4All、Jan、Jellybox和其他几个选项，有些甚至支持StableDiffusion模型，但对于文本生成来说，似乎没人想要集成其他后端，我只是想知道大多数应用等通常使用llama.cpp而不是其他的是否有好的原因。

讨论总结

原帖好奇为什么没有支持除llama.cpp之外后端的类似LMStudio/Msty/GPT4All类型应用，评论从多个角度进行分析，如llama.cpp在兼容性、集成简易性、依赖关系、支持范围、负载分担、可访问性等方面的优势，也有提及其他后端存在的情况、面临的问题以及应用场景等，整体氛围比较理性、客观。

主要观点

  1. 👍 llama.cpp在兼容性上相比其他后端可兼容到更早的Maxwell
    • 支持理由：其他更好的后端需要Ampere，存在四代的差距
    • 反对声音：无
  2. 👍 llama.cpp支持广泛，可将任务卸载到CPU并能使用Vulkan后端，是最通用的
    • 正方观点：它有着最广泛的支持，可以在CPU和GPU之间分担负载，甚至仅使用CPU进行推理
    • 反方观点：无
  3. 🔥 很多人没有足够VRAM来本地运行模型，所以llama.cpp更适用
    • 正方观点：llama.cpp可在CPU和GPU间分担负载或只用CPU推理，适合多数人的硬件情况
    • 反方观点：无
  4. 💡 可访问性使支持CPU侧载的应用更受关注，这是llama.cpp被广泛应用的原因之一
    • 解释：多数人关注可访问性，支持在CPU上侧载的应用会胜出
  5. 💡 其他推理后端规模不足以专门集成，使用OpenAI兼容的API更合适
    • 解释：相比专门集成其他后端，使用OpenAI兼容的API能满足需求

金句与有趣评论

  1. “😂 broad compatibility: llama works down to Maxwell while all the better backends practically require Ampere. that’s a 4 generational gap”
    • 亮点：简洁地指出llama.cpp在兼容性方面的优势
  2. “🤔 llama.cpp has the broadest support. Not only that you can offload to CPU and you can use the Vulkan back end. It’s really just the most versatile one.”
    • 亮点：概括了llama.cpp的支持范围广、功能多样的特点
  3. “👀 The main reason must be because with llama.cpp you can share load between CPU and GPU, or even use only CPU for inference.”
    • 亮点：点明了llama.cpp在CPU和GPU负载处理方面的优势是其被广泛应用的重要原因
  4. “💡 Cause the most people’s attention is drawn to accessibility, and apps that allow sideloading onto CPU win the race regardless of how good they are.”
    • 亮点：提出可访问性对应用受关注程度的影响
  5. “😎 I think other inference backends are not large - scale enough to be worth special integration, and using the OpenAI - compatible API is enough.”
    • 亮点：从规模和实用性角度看待其他推理后端的集成问题

情感分析

总体情感倾向是比较理性客观的。主要分歧点在于对llama.cpp和其他后端的评价，部分人认为llama.cpp有诸多优势所以被广泛应用，而另一些人则指出其他后端也有其价值或者存在未被广泛应用的其他原因（如规模不够大、可执行文件太大等）。可能的原因是大家从不同的技术角度（如硬件支持、开发便利性等）和应用场景（如专业工作、普通用户使用等）出发来考虑问题。

趋势与预测

  • 新兴话题：可能会有更多关于如何平衡llama.cpp和其他后端优势，以开发出更理想应用的讨论。
  • 潜在影响：对相关人工智能应用在后端选择、性能优化、适用场景等方面的决策有参考意义，影响本地LLM应用的开发方向。

详细内容：

标题：为何某些应用不支持除 llama.cpp 外的后端？

在 Reddit 上，一则题为“why is there no LMStudio/Msty/GPT4All type app that supports backends other than llama.cpp?”的帖子引起了广泛关注，获得了众多点赞和大量评论。该帖主要探讨了在众多相关应用中，尽管存在诸如 exllamav2 等在某些情况下可能比 llama.cpp 更快的后端，但大多数应用似乎仍仅支持 llama.cpp 的几种模式，而不集成 exllama 等其他后端的现象。

这一讨论引发了多个焦点观点。有人指出，llama.cpp 具有广泛的兼容性，能支持到 Maxwell ，而其他更好的后端通常要求 Ampere ，存在 4 代的差距；它还易于集成，能编译成可轻松链接的库，且不需要 Python 作为依赖项。也有人认为 llama.cpp 支持最广泛，能灵活地在 CPU 和 GPU 之间分配负载，是最通用的选择。还有人提到 LM Studio 在 Mac 上支持 MLX 及 llama.cpp ，希望能有 exllama 支持。

有人表示主要原因在于大多数人的注意力被可访问性吸引，支持在 CPU 上加载的应用无论好坏都会更受欢迎；llama.cpp 不仅是推理应用，还有很多简单工具来处理权重，且在 95%的情况下，人们不需要推理 UI，一个原始 API 就足够了。

此外，有用户分享道：“我花了一年时间开发本地 LLM 应用，探索了各种可能。Python 在 ML 开发中占主导，但对本地应用有一些严重问题。Rust 编译为二进制，跨平台支持好，但学习曲线难。Javascript 有吸引人的选项，但存在一些复杂性。Llama.cpp 在 C++中极具吸引力，支持几乎任何硬件。”

对于这一话题，争议点在于不同后端的性能、兼容性以及开发的复杂性。共识在于 llama.cpp 在某些方面具有显著优势，但对于是否应更多地集成其他后端仍存在分歧。

究竟是因为 llama.cpp 确实过于出色，还是其他后端的集成存在难以克服的困难？这值得我们进一步思考和探讨。