你好,
我正在尝试为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作为预编译库是否可行。从长远来看,这可能是可能的,也可能变得无关紧要。