你好，
我正在尝试为nixpkgs打包新版本(在llama.cpp被vendor之后),遇到了一些问题。本质上，ollama试图非常聪明和通用地构建，但这与提供打包的llama.cpp和llama.cpp的系统所要实现的目标相矛盾。
由于我们已经准备好了带有所有复杂cuda/rocm/apple依赖项和标志的llama.cpp包，因此没有必要为ollama重复所有这些工作。虽然我正在寻找一个好的方法来取消vendor并使用现有的库(使用您提供的补丁),但这变得越来越有问题。您的自定义分发对您有用，但我希望能够构建一个具有特定配置的版本，引用现有的llama.cpp。
你是否考虑将你的更改上游到llama.cpp?作为包管理者，我的满意路径是：ollama依赖于llama.cpp,可以选择性地要求环境变量指向特定的共享库。
此外，还有多个小问题，例如：
- 直接使用cmake和编译器，而不是拥有完整的cmake构建 https://github.com/ollama/ollama/blob/a468ae045971d009b782b259d21869f2767269fa/llm/generate/gen_common.sh#L87
- 使用g++而不是
$CXX,这在某些系统上破坏了构建 https://github.com/ollama/ollama/blob/a468ae045971d009b782b259d21869f2767269fa/llm/generate/gen_common.sh#L89
将所需的功能全部恢复到llama.cpp中，或者至少提供一个可以放置在llama.cpp/examples中的drop-in文件夹(这样在ollama中就不需要进行复杂的构建时修改/生成),将是一个很大的改进。它可能还会在未来为您节省一些头痛，当您更新llama.cpp时。
2条答案
按热度按时间qzlgjiam1#
一个替代的想法：
dxxyhpgq2#
正如您所指出的，我们携带补丁，尽管通常我们试图将这些补丁上游。更大的挑战是，我们用一个轻量级的外观
extern "C"interface Package 示例服务器，这样我们就可以将其作为库链接。通常，服务器只被构建为可执行文件，而不是上游库，所以我们也修改了cmake构建来实现这一点。我们的补丁和 Package 器目前比分叉更轻量级。这是由于我们如何利用llama.cpp的演变，我们过去使用子进程将服务器作为可执行文件并依赖其高级逻辑。从长远来看，我们可能会转向利用llama.cpp中的官方上游extern "C"接口，或者我们可能会完全过渡到其他库，如直接CUDA/ROCm/Metal访问，或LLM为中心的库，如MLX、TensorRT-LLM等。这是一个动态的空间，我们正在关注这些各个项目如何演变和适应LLM用例。短期内，我不确定纯粹利用llama.cpp作为预编译库是否可行。从长远来看，这可能是可能的，也可能变得无关紧要。