原贴链接

根据最近这个被拒绝的请求（https://github.com/ollama/ollollama/pull/8134），ollama短期内不会引入草稿模型和推测解码。我非常想要这个功能。我在mlx上试用过，它似乎不仅仅是提高了一点速度。它似乎是采用了草稿模型的“特性”并整合到更大的模型中。我猜这是一种调控方式？想象一下给一个128k上下文模型输入小故事之类的！不管怎样，我想使用mlx，但我的使用场景不只是苹果设备。有人有建议吗？

讨论总结

原帖提到ollama不会很快引入推测解码功能，询问有什么替代方案。评论者们推荐了多种方案，如kobold.cpp、llama.cpp、vLLM等，并围绕这些方案展开讨论。包括各方案是否支持特定模型、在不同平台上的运行情况、功能特性等。同时还涉及到ollama拒绝PR可能是要重写后端替换llama.cpp的推测，以及llama.cpp代码库好坏的争议，整个讨论氛围比较理性，大家从不同角度分享自己的经验和观点。

主要观点

  1. 👍 kobold.cpp可作为ollama的替代方案
    • 支持理由：具有推测解码功能，基于llama.cpp，若ollama适用则kobold.cpp也可能适用，还增加了Ollama API标准支持。
    • 反对声音：无。
  2. 🔥 llama.cpp从长远看可能是较好选择但存在局限
    • 正方观点：对于某些使用者来说，llama.cpp从长远看可能是较好选择。
    • 反方观点：目前对视觉模型的支持存在局限，在llama - server中是否支持推测性解码存在争论，对某些特定模型支持不足。
  3. 💡 ollama拒绝PR可能是要重写后端替换llama.cpp
    • 解释：noiserr认为ollama要重写后端完全替换llama.cpp，工作任务量巨大且可能无法支持llama.cpp所支持的所有硬件，影响很多用户，但也有人认为llama.cpp代码库糟糕，重写不是坏事。
  4. 🤔 推测解码的好处因使用场景而异
    • 解释：bfroemel指出像创意写作这种输出多变的场景使用推测解码会更慢，而编码、总结、编辑等任务效果较好。
  5. 👀 vLLM支持推测解码且速度比ollama快
    • 解释：评论者推荐vLLM，提到VLLM支持推测解码，在开启推测解码之前就比ollama更快。

金句与有趣评论

  1. “😂 nutrient - harvest: kobold.cpp has speculative decoding, it’s based on llama.cpp like ollama so if ollama works for you kobold should too”
    • 亮点：简洁地阐述了kobold.cpp作为ollama替代方案的原因。
  2. “🤔 ServeAlone7622：Honestly that might be my best bet in the long run.”
    • 亮点：表达了对llama.cpp的一种长远看法。
  3. “👀 nullnuller：llama.cpp still doesn’t support speculative decoding in llama - server which is a bummer.”
    • 亮点：指出llama.cpp在llama - server中不支持推测性解码这一遗憾之处。
  4. “😎 noiserr：Yeah, I think they are crazy personally. There is no way they will be able to support all the hardware llama.cpp supports, and they will break Ollama for a lot of users, particularly those not running Nvidia hardware.”
    • 亮点：强烈表达了对ollama重写后端替换llama.cpp可能带来问题的看法。
  5. “💡 bfroemel: 推测解码的好处是高度特定于使用场景的 - 任何具有高输出可变性（例如创意写作）的任务使用推测解码都会变慢。”
    • 亮点：强调了推测解码的效果与使用场景的关系。

情感分析

总体情感倾向比较理性、客观。主要分歧点在于ollama重写后端替换llama.cpp是好是坏，以及llama.cpp代码库的优劣。可能的原因是不同使用者从自身的使用体验、需求以及对技术发展的期望等不同角度出发看待这些问题。

趋势与预测

  • 新兴话题：随着对不同替代方案的讨论，可能会进一步深入比较这些方案在不同场景下的性能表现。
  • 潜在影响：对相关模型开发社区在功能开发、优化以及技术选型方面可能产生影响，例如促使ollama重新考虑是否引入推测解码功能，或者推动llama.cpp在视觉模型支持等方面的改进。

详细内容：

标题：关于 Ollama 暂不支持推测解码及替代方案的热门讨论

近日，Reddit 上有一个热门帖子引起了大家的关注，标题为“Speculative decoding isn’t coming to ollama anytime soon, any alternatives?”。这个帖子提到，根据最近被拒绝的PR，ollama 短期内不会引入推测解码和草案模型。发帖者表示非常希望拥有这个功能，还称在 mlx 上尝试过，感觉不仅能加快令牌速度，还能将草案模型的“声音”融入到更大的模型中，想象能给 128k 上下文模型提供小故事。由于使用场景并非单纯的苹果系统，所以想问问大家有没有其他建议。此帖获得了较高的关注度，引发了众多讨论。

讨论的焦点主要集中在替代方案和对推测解码的见解上。有人认为 kobold.cpp 有推测解码，它和 ollama 都基于 llama.cpp，所以如果 ollama 适用，kobold 应该也可以。还有人提到 kobold 最近添加了 Ollama API 标准支持，如果使用只与 Ollama 兼容的应用，kobold 也能胜任。也有人安装了 kobold 但不知道如何实现推测解码。

有人直接使用 llama.cpp，并认为从长远来看这可能是最好的选择，因为 Ollama 对某些特定需求不支持。有人指出 llama.cpp 对某些视觉模型的支持不足。有人认为推测解码不应允许草案模型修改大模型的输出，如果是这样就是个 bug。

有用户分享了自己使用相关模型的经历，比如在 Mac 上使用推测解码，并介绍了相关的操作命令。

也有人对是否采用 llama.cpp 进行了讨论，有人认为改写后端替换 llama.cpp 完全是疯狂之举，无法支持所有硬件，会给很多用户带来不便。但也有人认为 llama.cpp 的代码库不好，改写是个不错的主意。

在讨论中，还提到了各种模型的特点和优势，以及不同模型在不同场景下的表现。

总之，关于 Ollama 暂不支持推测解码的问题，大家各抒己见，提供了丰富的替代方案和见解，为遇到类似问题的用户提供了有价值的参考。