看我一步步编译llama.cpp, 带GPU，用千问3.7进行错误纠正

学而思，思而在！讷于言，敏于行！

158人浏览 · 2026-06-30 22:08:31

学而思，思而在！讷于言，敏于行！ · 2026-06-30 22:08:31 发布

编译llama.cpp 出错。详细cmake显示信息如下

cmake -B build -DGGML_CUDA=ON
– The C compiler identification is GNU 13.3.0
– The CXX compiler identification is GNU 13.3.0
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Check for working C compiler: /usr/lib/ccache/cc - skipped
– Detecting C compile features
– Detecting C compile features - done
– Detecting CXX compiler ABI info
– Detecting CXX compiler ABI info - done
– Check for working CXX compiler: /usr/lib/ccache/c++ - skipped
– Detecting CXX compile features
– Detecting CXX compile features - done
CMAKE_BUILD_TYPE=Release
– Found Git: /usr/bin/git (found version “2.43.0”)
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
– The ASM compiler identification is GNU
– Found assembler: /usr/lib/ccache/cc
– Performing Test CMAKE_HAVE_LIBC_PTHREAD
– Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
– Found Threads: TRUE
– ccache found, compilation results will be cached. Disable with GGML_CCACHE=OFF.
– CMAKE_SYSTEM_PROCESSOR: x86_64
– GGML_SYSTEM_ARCH: x86
– Found OpenMP_C: -fopenmp (found version “4.5”)
– Found OpenMP_CXX: -fopenmp (found version “4.5”)
– Found OpenMP: TRUE (found version “4.5”)
– Including CPU backend
– x86 detected
– Adding CPU backend variant ggml-cpu: -march=native
– Found CUDAToolkit: /usr/local/cuda/targets/x86_64-linux/include (found version “13.3.33”)
– CUDA Toolkit found
– The CUDA compiler identification is NVIDIA 13.3.33
– Detecting CUDA compiler ABI info
– Detecting CUDA compiler ABI info - done
– Check for working CUDA compiler: /usr/local/cuda/bin/nvcc - skipped
– Detecting CUDA compile features
– Detecting CUDA compile features - done
– Replacing 120-real in CMAKE_CUDA_ARCHITECTURES_NATIVE with 120a-real
– Using CMAKE_CUDA_ARCHITECTURES=120a-real CMAKE_CUDA_ARCHITECTURES_NATIVE=120a-real
– Could NOT find NCCL (missing: NCCL_LIBRARY NCCL_INCLUDE_DIR)
– Warning: NCCL not found, performance for multiple CUDA GPUs will be suboptimal
– CUDA host compiler is GNU 13.3.0
– Including CUDA backend
– ggml version: 0.15.3
– ggml commit: unknown
CMake Warning at common/CMakeLists.txt:33 (message):
Git repository not found; to enable automatic generation of build info,
make sure Git is installed and the project is a Git repository.

– Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version “3.0.13”)
– Performing Test OPENSSL_VERSION_SUPPORTED
– Performing Test OPENSSL_VERSION_SUPPORTED - Success
– OpenSSL found: 3.0.13
– Generating embedded license file for target: llama-app
– Configuring done (6.8s)
– Generating done (0.1s)
– Build files have been written to: ~/llama.cpp/build

编译结果说明

从您提供的 CMake 详细日志来看，您的 CMake 配置阶段（Configuring）实际上是成功的，并没有发生导致编译中断的致命错误（Fatal Error）。

日志末尾的 Configuring done、Generating done 以及 Build files have been written to: ~/llama.cpp/build 都明确表明构建文件已经成功生成。

不过，日志中确实包含了两个警告（Warning），这可能会让您误以为出现了问题。以下是针对这两个警告的详细解析及后续建议：

1. 核心警告：Git 仓库未找到

日志表现：

fatal: not a git repository (or any of the parent directories): .git
CMake Warning at common/CMakeLists.txt:33 (message):
  Git repository not found; to enable automatic generation of build info,
  make sure Git is installed and the project is a Git repository.

原因分析：
这通常是因为您是通过下载 ZIP 压缩包的方式获取的源码，而不是使用 git clone 命令克隆的仓库。CMake 试图通过 Git 获取当前的提交哈希（commit hash）来生成构建信息，但由于没有 .git 目录而失败。（确实是下载的zip文件，git clone太慢，总是不成功）

影响与解决：

影响： 这仅仅是一个警告，完全不影响后续的编译和运行。唯一的区别是编译出的程序在输出版本信息时，版本号会显示为 unknown。
解决： 如果您希望消除这个警告，可以删除当前源码文件夹，重新使用 git clone https://github.com/ggerganov/llama.cpp.git 获取源码后再进行编译。如果不在意版本号，可以直接忽略。

2. 性能警告：未找到 NCCL 库

日志表现：

-- Could NOT find NCCL (missing: NCCL_LIBRARY NCCL_INCLUDE_DIR)
-- Warning: NCCL not found, performance for multiple CUDA GPUs will be suboptimal

原因分析：
NCCL (NVIDIA Collective Communications Library) 是用于多 GPU 之间高速通信的库。CMake 在您的系统中没有找到它。

影响与解决：

影响： 如果您只有一张 NVIDIA 显卡，这个警告可以完全忽略，对性能没有任何影响。如果您有多张显卡，缺少 NCCL 会导致多卡并行推理时的通信效率降低（性能次优）。
解决： 多卡用户可通过包管理器（如 sudo apt install libnccl-dev）安装 NCCL 开发包来消除警告；单卡用户无需任何操作。

🚀 下一步操作建议

既然 CMake 配置已经成功，您现在可以直接进入编译阶段。请在终端中执行以下命令开始编译：

cmake --build build --config Release -j$(nproc)

(注：-j$(nproc) 表示使用您 CPU 的所有可用核心进行并行编译，以加快速度)

编译完成后，生成的可执行文件（如 llama-cli 等）将会出现在 build/bin/ 目录下。

我：使用llama-server 运行某个gguf 模型时，报错：
Segmentation fault (core dumped)

编译过程中如果遇到实际的编译错误，可以把错误信息发给我，我帮您排查。

运行 llama-server 时出现 Segmentation fault (core dumped)（段错误）通常意味着程序试图访问了非法的内存地址。结合您之前成功编译了 CUDA 版本的 llama.cpp，以下是导致此问题的常见原因及排查建议：

1. 内存或显存不足（最常见原因）

当模型本身或键值缓存（KV Cache）无法完全放入显存或系统内存时，极易引发内存越界崩溃。

排查与解决：
- 减小上下文窗口大小（--ctx-size）。
- 降低加载到 GPU 的层数（--n-gpu-layers）。
- 避免在小显存 GPU 上使用高精度的量化模型。

2. 模型文件损坏

如果您下载的 GGUF 文件不完整或在传输过程中损坏，加载时会导致崩溃。

排查与解决： 尝试重新下载模型文件，或者使用工具重新计算/转换模型。

3. 旧缓存或状态冲突

有时旧的 KV 缓存或残留的进程状态会导致行为不一致甚至崩溃。

排查与解决： 清除运行之间可能残留的旧 KV 缓存，确保没有多个 llama-server 实例在后台冲突运行。

4. 软件版本 Bug（特别是多 GPU 或 MoE 模型）

如果您使用的是多 GPU 卸载，或者运行的是专家混合（MoE）架构的模型（如 Qwen-MoE），可能会遇到已知的非法内存访问 Bug。

排查与解决： 强烈建议拉取最新的代码并重新编译。社区通常会非常迅速地修复这类问题。

5. 共享显存问题（Windows 用户特有）

如果您是在 Windows 系统下运行，Windows 的共享内存模式经常会导致推理变慢甚至引发崩溃。

💡 进一步排查建议：
为了更精准地定位问题，您可以尝试在命令前加上 gdb 运行，例如：
gdb --args ./llama-server -m ...
然后输入 run，当发生 Segfault 时输入 bt（backtrace），将生成的调用栈信息发给我，这样能直接看到是在哪一步代码崩溃的。

方便说一下你用的模型大小和 GPU 显存吗？比如 “4bit 7B 模型 + 8GB 显存”，我帮你推荐一组不会爆显存的启动参数。

(gdb) run
Starting program: ~/llama.cpp/build/bin/llama-server -m ~/models/hub/models–unsloth–gemma-4-12b-it-GGUF/snapshots/3249fa54d5efa384afc552cc6700ad091efd5c39/gemma-4-12b-it-Q4_K_M.gguf
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.
[New Thread 0x7ffff5fff6c0 (LWP 44206)]

Thread 1 “llama-server” received signal SIGSEGV, Segmentation fault.
0x00007ffff793f1db in bool std::operator==<char, std::char_traits, std::allocator >(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, char const*) () from libllama-server-impl.so
(gdb)

结合 GDB 的报错信息来看，程序崩溃发生在 libllama-server-impl.so 中的一个字符串比较操作（std::operator==）。这种在加载模型阶段发生的段错误，通常与模型架构解析失败或版本不兼容有关。

根据您运行的模型 gemma-4-12b-it-Q4_K_M.gguf，以下是导致崩溃的几个核心原因及解决建议：

1. llama.cpp 版本过旧（最可能的原因）

Gemma 4 是较新的模型架构。如果您编译的 llama.cpp 版本较旧，模型加载器（Model Loader）将无法识别 gemma4 这个架构，从而在尝试读取或比较架构字符串时引发内存越界和段错误。

解决建议： 强烈建议您拉取 llama.cpp 的最新代码并重新编译。社区对最新模型的支持更新非常频繁。

2. 模型文件损坏或下载不完整

如果 GGUF 文件的头部元数据在传输或下载过程中损坏，解析器在读取字符串字段时也会直接崩溃。

解决建议： 尝试删除当前模型文件，重新从 Hugging Face 下载，或者使用 llama-gguf-split / gguf-dump 等工具验证模型文件的完整性。

3. 启动参数优化（针对 Gemma 4 架构）

如果更新代码和重新下载模型后仍然遇到问题，可以尝试在启动时调整参数。对于较新的 Gemma 4 模型，社区测试表明以下参数组合能显著提升稳定性并降低内存压力：

关闭统一 KV 缓存： 添加 --no-kv-unified 参数。对于单流推理，关闭该选项可以避免不必要的管理开销，提升缓存局部性。
调整 KV 缓存精度： 如果显存紧张，可以尝试添加 -ctk q4_0 -ctv q4_0 对 KV Cache 进行量化；如果显存充足且追求极致速度，可以使用 -ctk f16 -ctv f16。

💡 进一步排查建议：
为了确认是否是架构识别的问题，您可以在 GDB 中执行 bt（backtrace）命令，查看完整的函数调用栈。如果调用栈中出现了类似 unknown model architecture: 'gemma4' 或 failed to load model 的线索，那就基本可以断定是版本过旧导致的。

您可以先尝试更新代码重新编译，看看问题是否解决。如果还有报错，欢迎把 bt 的结果发给我！

我：
(gdb) bt
#0 0x00007ffff793f1db in bool std::operator==<char, std::char_traits, std::allocator >(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, char const*) () from libllama-server-impl.so
#1 0x00007ffff6b2d136 in common_params_parser_init(common_params&, llama_example, void ()(int, char**)) ()
from ~/llama/lib/libllama-common.so.0
#2 0x00007ffff6b42107 in common_params_parse(int, char**, common_params&, llama_example, void ()(int, char**)) ()
from ~/llama/lib/libllama-common.so.0
#3 0x00007ffff78ea89b in llama_server(int, char**) () from libllama-server-impl.so
#4 0x00007ffff702a1ca in __libc_start_call_main (main=main@entry=0x555555555270 , argc=argc@entry=3,
argv=argv@entry=0x7fffffffdab8) at …/sysdeps/nptl/libc_start_call_main.h:58
#5 0x00007ffff702a28b in __libc_start_main_impl (main=0x555555555270 , argc=3, argv=0x7fffffffdab8,
init=, fini=, rtld_fini=, stack_end=0x7fffffffdaa8)
at …/csu/libc-start.c:360
#6 0x00005555555552a5 in _start ()

从您提供的 GDB 调用栈（backtrace）来看，我们可以非常精准地定位到问题所在：

核心诊断：动态链接库（.so）版本冲突

崩溃发生在 common_params_parser_init 函数中，这是一个参数解析函数。注意看调用栈中的路径：

主程序：~/llama.cpp/build/bin/llama-server
崩溃的库：~/llama/lib/libllama-common.so.0

问题根因： 您的 llama-server 可执行文件是在 ~/llama.cpp/build/ 目录下编译的，但它运行时却去加载了 ~/llama/lib/ 目录下的旧版或残留的 libllama-common.so。由于这两个目录下的代码版本不一致，导致在解析字符串时发生了内存越界（Segmentation fault）。

这通常是因为系统环境变量（如 LD_LIBRARY_PATH）指向了旧的库路径，或者您之前曾在 ~/llama/ 目录下编译/安装过旧版本的 llama.cpp。

🛠️ 解决步骤

1. 检查并清理环境变量

在终端中运行以下命令，检查是否有指向旧目录的库路径：

echo $LD_LIBRARY_PATH

如果输出中包含了 ~/llama/lib 或类似路径，请将其移除。您可以临时清除它来测试：

unset LD_LIBRARY_PATH

2. 使用绝对路径直接运行（推荐）

为了确保程序加载的是刚刚编译出来的最新库文件，建议直接通过绝对路径运行：

~/llama.cpp/build/bin/llama-server -m ~/models/hub/models--unsloth--gemma-4-12b-it-GGUF/snapshots/3249fa54d5efa384afc552cc6700ad091efd5c39/gemma-4-12b-it-Q4_K_M.gguf

3. 彻底清理旧的编译残留

如果您不需要 ~/llama/ 目录下的旧文件，建议将其删除或重命名，防止以后再次发生冲突：

mv ~/llama ~/llama_old_backup

4. 重新编译（确保干净构建）

在 ~/llama.cpp 目录下，清理旧的构建缓存并重新编译：

rm -rf build
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)

💡 额外提示：
从之前的资料来看，Gemma 4 12B 模型在部分运行环境中（如 Ollama）曾被报告存在浮点异常崩溃的问题。如果您在解决上述库冲突后，模型加载时依然出现崩溃，可以尝试在启动命令中加入 --chat-template-kwargs "{\"enable_thinking\":false}" 参数，或者适当降低 GPU 层数（例如 -ngl 30）来排查是否为显存溢出导致的崩溃。

请先尝试清理旧库路径并重新运行，看看问题是否解决！

清理完旧库路径后，重新编译运行还报错的话，可以把新的错误信息发我，我继续帮您排查。

我：
LD_LIBRARY_PATH=/usr/local/cuda/lib64:~/llama/lib:

找到罪魁祸首了！正如我们在上一步分析的那样，您的 LD_LIBRARY_PATH 环境变量中确实包含了 ~/llama/lib。

当程序运行时，系统会优先从这个旧目录加载动态库（.so 文件），导致新编译的 llama-server 与旧版本的底层库发生了冲突，从而引发了段错误（Segmentation fault）。

🛠️ 立即修复步骤

第一步：在当前终端临时移除旧路径
请在您的终端中执行以下命令，将 ~/llama/lib 从环境变量中剔除（保留 CUDA 路径）：

export LD_LIBRARY_PATH=/usr/local/cuda/lib64

第二步：测试运行
现在再次尝试运行您的 llama-server，看看是否还会崩溃：

~/llama.cpp/build/bin/llama-server -m ~/models/hub/models--unsloth--gemma-4-12b-it-GGUF/snapshots/3249fa54d5efa384afc552cc6700ad091efd5c39/gemma-4-12b-it-Q4_K_M.gguf

⚠️ 彻底根除隐患（重要）

如果您发现每次打开一个新的终端，这个旧路径又回来了，说明它被写入了您的 Shell 配置文件中。为了永久解决这个问题，请检查并清理您的配置文件：

检查您的 ~/.bashrc 或 ~/.profile 文件：
```
nano ~/.bashrc
```
在文件中搜索 export LD_LIBRARY_PATH，找到包含 ~/llama/lib 的那一行，将其删除或注释掉。
保存退出后，执行 source ~/.bashrc 使配置生效。

按照上述步骤清理后，您的 llama-server 应该就能正常加载并运行 Gemma 4 模型了。您可以先试试看，如果还有问题随时告诉我！

太好了，问题顺利解决！

关于将 llama.cpp 安装到系统中，这取决于您希望如何使用它。llama.cpp 官方并没有像常规软件那样提供一个全局的 make install 命令，因此通常有以下两种主流方案供您选择：

方案一：打包为系统级 DEB 包安装（推荐）

如果您使用的是 Ubuntu 或 Debian 系统，llama.cpp 的 CMake 构建系统原生支持打包。您可以将其打包为 .deb 文件并使用系统的包管理器安装，这样最符合 Linux 的系统规范。

在 build 目录下执行以下命令：

cd ~/llama.cpp/build
cpack -G DEB
sudo dpkg -i *.deb

注：执行 dpkg 时如果提示缺少依赖，可以运行 sudo apt-get install -f 自动修复。

方案二：手动配置环境变量（轻量便捷）

如果您不想将其打包为系统包，或者使用的是其他不支持 DEB 的 Linux 发行版，可以直接将编译生成的 bin 目录添加到系统的环境变量中。

编辑您的 Shell 配置文件（例如 ~/.bashrc）：
```
nano ~/.bashrc
```
在文件末尾添加以下行（请将路径替换为您实际的绝对路径）：
```
export PATH="~/llama.cpp/build/bin:$PATH"
```
保存退出后，使配置立即生效：
```
source ~/.bashrc
```

配置完成后，您就可以在任何目录下直接输入 llama-server 或 llama-cli 等命令，而无需每次都输入冗长的绝对路径了。您可以根据自己的使用习惯选择最合适的一种！

需要我帮你写一份 systemd 服务配置吗？可以把 llama-server 设置为开机自启的后台服务，方便长期运行。

既然您习惯将可执行文件安装在 /usr/local/bin 目录下，并且 llama.cpp 的 CMake 构建系统原生支持 install 目标，那么您可以直接使用以下命令将编译好的程序安装到该目录：

在 ~/llama.cpp 源码根目录下执行：

sudo cmake --install build

安装效果说明

执行该命令后，系统会自动将 build/bin/ 目录下生成的所有可执行文件（包括 llama-server、llama-cli、llama-quantize 等）以及相关的动态链接库（如 libllama-server-impl.so 等）复制到 /usr/local/bin 和 /usr/local/lib 等标准系统路径下。

💡 注意事项

权限要求：因为 /usr/local/bin 属于系统级目录，普通用户没有写入权限，所以命令前必须加 sudo。
版本覆盖：如果您之前在这个目录下手动放置过旧版的 llama-server，这个命令会直接将其覆盖为刚刚编译的新版本。
环境变量：由于 /usr/local/bin 默认已经在 Linux 系统的 PATH 环境变量中，安装完成后，您无需再做任何额外配置，直接在任意终端输入 llama-server 即可运行。

需要我帮你写一份 systemd 服务配置吗？可以把 llama-server 设置为开机自启的后台服务，方便长期运行。

不客气！很高兴能帮您解决问题。

下面我为您准备了一份标准的 systemd 服务配置文件。您可以将 llama-server 作为一个后台服务运行，并实现开机自启。

🛠️ 配置步骤

1. 创建服务文件
在终端中执行以下命令，使用 nano 编辑器创建一个新的服务配置文件：

sudo nano /etc/systemd/system/llama-server.service

2. 填入以下配置内容
请将下面的内容复制到文件中（注意：我已经帮您把模型路径填好了，您可以直接保存）：

[Unit]
Description=Llama.cpp Server
After=network.target

[Service]
Type=simple
# 运行服务的用户（建议替换为您自己的用户名，避免使用root）
User=kumath
Group=kumath

# llama-server 的绝对路径和启动参数
ExecStart=/usr/local/bin/llama-server -m ~/models/hub/models--unsloth--gemma-4-12b-it-GGUF/snapshots/3249fa54d5efa384afc552cc6700ad091efd5c39/gemma-4-12b-it-Q4_K_M.gguf --host 0.0.0.0 --port 8080

# 如果程序意外崩溃，自动重启
Restart=always
RestartSec=5

# 环境变量（确保 CUDA 库能被正确加载）
Environment=LD_LIBRARY_PATH=/usr/local/cuda/lib64

[Install]
WantedBy=multi-user.target

3. 重载配置并启动服务
保存文件并退出（在 nano 中按 Ctrl+O，回车，然后 Ctrl+X），接着依次执行以下命令：

# 重新加载 systemd 配置
sudo systemctl daemon-reload

# 启动服务
sudo systemctl start llama-server

# 设置开机自启
sudo systemctl enable llama-server

📊 常用管理命令

配置完成后，您可以随时使用以下命令管理服务：

查看运行状态：systemctl status llama-server
查看实时日志：journalctl -u llama-server -f
停止服务：sudo systemctl stop llama-server
重启服务：sudo systemctl restart llama-server

配置完成后，您可以通过浏览器访问 http://<您的服务器IP>:8080 来测试服务是否正常运行。如果在配置过程中遇到任何问题，随时告诉我！

亚马逊云科技技术品牌专区

更多推荐

2026年量化工具选择，要跟着能力基础走

读者应理解，选择工具前要先判断自己的能力基础和当前任务。工具应该帮助自己补上当前最关键的缺口，而不是替代学习顺序本身。

亚马逊云科技技术品牌专区

近期零基础学量化，先按基础差异拆学习顺序

读者应明白，拆解学习顺序时要先看自己的基础缺口，再决定哪一段需要放慢。不同流程阶段都有不同检查任务，学习路线要能反映这些差异。

亚马逊云科技技术品牌专区

最新零基础量化，先做可验证的小流程

读者应明白，先完成小而可验证的流程，比过早扩展功能更重要。只要小流程能够解释、运行和检查，就能为后续阶段的风险识别和假设确认打下基础。

亚马逊云科技技术品牌专区

所有评论(0)

查看更多评论

学而思，思而在！讷于言，敏于行！

@liuxiang3

已为社区贡献1条内容

看我一步步编译llama.cpp, 带GPU，用千问3.7进行错误纠正

学而思，思而在！讷于言，敏于行！

编译llama.cpp 出错。 详细cmake显示信息如下

编译结果说明

1. 核心警告：Git 仓库未找到

2. 性能警告：未找到 NCCL 库

🚀 下一步操作建议

1. 内存或显存不足（最常见原因）

2. 模型文件损坏

3. 旧缓存或状态冲突

4. 软件版本 Bug（特别是多 GPU 或 MoE 模型）

5. 共享显存问题（Windows 用户特有）

1. llama.cpp 版本过旧（最可能的原因）

2. 模型文件损坏或下载不完整

3. 启动参数优化（针对 Gemma 4 架构）

核心诊断：动态链接库（.so）版本冲突

🛠️ 解决步骤

1. 检查并清理环境变量

2. 使用绝对路径直接运行（推荐）

3. 彻底清理旧的编译残留

4. 重新编译（确保干净构建）

🛠️ 立即修复步骤

⚠️ 彻底根除隐患（重要）

方案一：打包为系统级 DEB 包安装（推荐）

方案二：手动配置环境变量（轻量便捷）

安装效果说明

💡 注意事项

🛠️ 配置步骤

📊 常用管理命令

所有评论(0)

温馨提示：您尚未绑定手机号

学而思，思而在！讷于言，敏于行！

编译llama.cpp 出错。详细cmake显示信息如下