[ggerganov/llama.cpp]支持在 CPU 上运行 GGML_USE_CUBLAS=ON 构建

应该在没有 CUDA 运行时但model.n_gpu_layers = 0.

master 中的当前行为在非 cuda 机器上抛出以下错误GGML_USE_CUBLAS=ON

掌握

中央处理器

CUDA_VISIBLE_DEVICES=-1 ./bin/main -m ../models/q8_0.v2.gguf -p "# Dijkstra's shortest path algorithm in Python (4 spaces indentation) + complexity analysis:\n\n" -e -t 4 --temp -1 -n 128

CUDA error 100 at /home/ubuntu/sky_workdir/llama.cpp/ggml-cuda.cu:5830: no CUDA-capable device is detected
current device: 48

这个公关

中央处理器

CUDA_VISIBLE_DEVICES=-1 ./bin/main -m ../models/q8_0.v2.gguf -p "# Dijkstra's shortest path algorithm in Python (4 spaces indentation) + complexity analysis:\n\n" -e -t 4 --temp -1 -n 128

llama_print_timings:        load time =     198.51 ms
llama_print_timings:      sample time =     100.40 ms /   128 runs   (    0.78 ms per token,  1274.95 tokens per second)
llama_print_timings: prompt eval time =    1383.23 ms /    20 tokens (   69.16 ms per token,    14.46 tokens per second)
llama_print_timings:        eval time =    9991.21 ms /   127 runs   (   78.67 ms per token,    12.71 tokens per second)
llama_print_timings:       total time =   11540.18 ms

CPU 但请求 ngl > 0

CUDA_VISIBLE_DEVICES=-1 ./bin/main -m ../models/q8_0.v2.gguf -p "# Dijkstra's shortest path algorithm in Python (4 spaces indentation) + complexity analysis:\n\n" -e -t 4 --temp -1 -n 128 -ngl 999

CUDA error 100 at /home/ubuntu/sky_workdir/llama.cpp/ggml-cuda.cu:478: no CUDA-capable device is detected

CUDA

./bin/main -m ../models/q8_0.v2.gguf -p "# Dijkstra's shortest path algorithm in Python (4 spaces indentation) + complexity analysis:\n\n" -e -t 4 --temp -1 -n 128 -ngl 999

llama_print_timings:        load time =     397.99 ms
llama_print_timings:      sample time =     101.63 ms /   128 runs   (    0.79 ms per token,  1259.51 tokens per second)
llama_print_timings: prompt eval time =      54.91 ms /    20 tokens (    2.75 ms per token,   364.23 tokens per second)
llama_print_timings:        eval time =    1768.41 ms /   127 runs   (   13.92 ms per token,    71.82 tokens per second)
llama_print_timings:       total time =    1979.19 ms

wsxiaoys

我们可能想要合并类似此 PR 的内容，以便第 3 方项目有更简单的方法来支持可选的仅 CPU 运行。不过，我不确定这是否是最好的方法。还有其他建议吗？

ggerganov

对此拉取请求进行原型设计时考虑的一些替代想法（假设GGML_USE_CUBLAS=ON）：

利用CUDA_VISIBLE_DEVICES环境变量：如果中不存在有效索引CUDA_VISIBLE_DEVICES，并且没有足够的 CUDA 可用性推导，我们可以公开一个不依赖于的有效 API ggml_cublas_init。
重新定位ggml_cublas_init到llama.cpp，类似于“metal”后端：我还没有深入研究这种方法，因为它似乎与 ggml 后端 v2 不兼容。

wsxiaoys

在 llama.cpp 适应使用 ggml-backend 后，其中大部分内容将变得过时。之后，实现的方法是返回ggml_backend_cuda_init（NULL或具有相同效果的东西）。我不能说 ggml-backend 何时可以在 llama.cpp 中使用，所以我认为添加一个临时解决方案是可以的，但考虑到这一点，IMO 最好的解决方案是将来最容易删除的解决方案。

slaren

我稍微清理了一下，认为 ggml_backend 迁移应该相对容易。

wsxiaoys

我尝试过-ngl 0，它似乎与仅 CPU 选项的性能相匹配。然而，这可能不是一个非常常见的用例。因此，我们应该考虑推荐使用CUDA_VISIBLE_DEVICES=-1。

wsxiaoys

行为可能-ngl 0已经改变，现在实际上会在 CPU 上执行所有操作，而无需像过去那样来回移动数据。如果您在测试中没有看到任何 GPU 使用情况，那么一切都应该很好。

ggerganov

事实并非如此，无论的值如何，CUDA 仍然用于大型矩阵乘法-ngl。

slaren

请 ping @cebtenzzre

wsxiaoys

我使用最新版本编译了代码，并将生成的可执行文件复制到没有显卡且未安装 CUDA 的计算机上。当我尝试运行 main.exe 文件时，它无法执行。相关错误信息如下：

zhangp365

[ggerganov/llama.cpp]支持在 CPU 上运行 GGML_USE_CUBLAS=ON 构建

回答

相关问题