夜雨聆风先回答一个很多人心里的疑问：我用 Ollama 用得好好的，为什么还有一批发烧友绕过它，直接上 llama.cpp？
答案有点反常识——不是因为 llama.cpp 更快。
事实上，Ollama、LM Studio 底层跑的都是 llama.cpp 这个 C/C++ 推理引擎（ggml 内核），大家用的 GGUF 模型格式也是它定义的。同一个 GGUF 文件，在 llama.cpp、Ollama、LM Studio 里通用，跑的是同一套内核，不存在谁比谁快。Ollama 只是在外面套了一层"省心封装"，帮你自动选参数、管模型。
那发烧友图什么？图的是底层控制权。Ollama 替你决定了多少层放显卡、上下文开多大、用哪个量化——这在 8GB 这种"斤斤计较"的显存上，恰恰是最想自己捏在手里的三个旋钮。今天我就把 llama.cpp 从源码编译到榨干 8GB 的全套操作走一遍。所有内容围绕 RTX 4060 / 5060 8GB 这档硬件。
一、为什么必须自己编译
这是第一个坑：llama.cpp 的默认预编译二进制不开 GPU。你直接下一个跑，它老老实实用 CPU，慢到怀疑人生，然后你就误以为"本地大模型不过如此"。
要用上显卡，必须自己带 CUDA 编译。步骤其实很短：
git clone https://github.com/ggml-org/llama.cppcd llama.cppcmake -B build -DGGML_CUDA=ONcmake --build build --config Release这里有个一定要划重点的坑：现在开启 CUDA 的 flag 是 -DGGML_CUDA=ON。网上一大堆老教程还写着 -DLLAMA_CUDA=ON——那个已经废弃了，照抄会编译失败或者根本没开 GPU。看到 LLAMA_CUDA 就知道这篇教程过期了。
编译前提是本机装好了 CUDA Toolkit 和对应驱动。编完，可执行文件在 build/bin/ 下，核心就两个：llama-cli（命令行对话）和 llama-server（启 API 服务）。
二、跑起来：三个旋钮决定生死
编完就能跑。最基础的命令行对话：
llama-cli -m model.gguf -ngl 35 -t 6 -c 2048拆开看这几个参数，在 8GB 上每一个都关乎能不能跑起来：
-ngl 35：把 35 层（也就是全部层）offload 到 GPU。这是榨性能的核心开关，层放显卡越多越快。-t 6：CPU 线程数，一般设成物理核心数。-c 2048：上下文长度，直接决定 KV cache 吃多少显存。
想要一个能被别的程序调用的服务，就用 llama-server：
llama-server -m model.gguf -ngl 35它会起一个 OpenAI 兼容的 API（默认 8080 端口），任何支持 OpenAI 接口的客户端、脚本都能直接连——这点和 Ollama 是对等的。
还有一招特别省事，不用手动下模型，直接从 HuggingFace 拉了就跑：
llama-server -hf bartowski/xxx-GGUF:Q4_K_M冒号后面跟量化 tag，它自动下载对应文件并启动。这就顺势引出了 8GB 玩家最该搞明白的一件事——量化到底怎么选。
三、GGUF 量化选型表（8GB 必读）
量化就是把模型权重从高精度压到低精度，换来体积和显存的暴跌，代价是一点点质量损失。选对了，8GB 能跑得又稳又好；选错了，要么塞不下，要么模型变"笨"。
以 7-8B 模型为例，把常见量化摆在一起对比：
| Q4_K_M | 8GB 首选 | ||
| IQ4_XS |
核心结论：8GB 就认准 Q4_K_M，想再省一点用 IQ4_XS。 这两档在质量和体积之间的平衡最适合我们这档卡。
千万别用 Q3、Q2——体积是更小，但复杂推理会出现断崖式下跌，逻辑、代码、多步推理这些场景直接崩，省下来的那点显存根本不值。
还有一条我反复验证过的原则，很多人搞反了：同样的显存预算下，"大模型 + 低精度" 通常好过 "小模型 + 高精度"。也就是说，先挑一个能塞进 8GB 的最大参数量模型，再往下降精度，而不是抱着小模型死磕 Q8。所以选型顺序是：先看能塞下多大的模型，再决定压到哪一档量化。
四、8GB 实战调参：把显存榨到最后一滴
有了模型，剩下就是和显存斗智斗勇。8GB 的账要这么算：
模型本体（Q4_K_M 的 7-8B）约占 4.4GB。别忘了 KV cache——它随上下文长度增长，通常另占 1-3GB。两块加起来，8GB 其实相当紧。
我的实战配置：
llama-cli -m qwen-7b-q4_k_m.gguf -ngl 35 -t 6 -c 2048-ngl 35：7-8B 一般 32-33 层，写 35 保证全部层进 GPU，跑满 GPU 加速。-c 2048：上下文压到 2048，给 KV cache 留出余量，避免开机就 OOM。
如果报显存不足（OOM）怎么办？ 不用换模型，先降 -ngl：
llama-cli -m qwen-7b-q4_k_m.gguf -ngl 25 -t 6 -c 2048从 35 降到 25，会把一部分层挪回 CPU，大约省下 2GB 显存。代价是速度下降（那几层走 CPU 慢），但至少能跑起来。这就是 llama.cpp 相比 Ollama 最爽的地方——这个 offload 的度，你自己一格一格地调。
至于速度，社区实测 8GB 卡跑 Q4_K_M 的 7-8B 大致在流畅可用的量级，日常问答、写代码完全够用，具体数字受卡、驱动、上下文影响挺大，这里就不给死数了。
五、去哪儿下 GGUF：认准这三家
GGUF 满天飞，质量参差不齐。我只从这三个源下，闭眼信得过：
bartowski：量程最全，从 IQ2 到 Q8 全都有，还带 imatrix 优化，8GB 选型的第一站。 unsloth：动态量化 + 修好了聊天模板（很多模型模板是坏的，输出会乱，unsloth 帮你修好）。 ggml-org：llama.cpp 官方转换，最原汁原味。
搜模型时认准这几个发布者，能避开一大堆坏文件和乱质量。
彩蛋：llama-server 现在能直接跑 MCP 工具
顺便说个不少人还不知道的更新：2026 年 3 月起，llama.cpp 内置的 web UI 已经并入完整的 MCP 客户端支持，llama-server 能直接挂 MCP 工具跑起来。也就是说，你的本地模型不再只会"聊天"，还能调工具、查资料、操作外部服务——这恰好是本地部署最让人兴奋的下一步。
谁适合上手
如果你已经用 Ollama 入门，想再往里钻一层、把 8GB 的每一分显存都攥在自己手里，那 llama.cpp 值得装。上手路径很清晰：装 CUDA → -DGGML_CUDA=ON 编译 → 从 bartowski 下一个 Q4_K_M 的 7-8B → -ngl 35 -c 2048 跑起来 → OOM 就降 -ngl。跑通这一条，你对本地推理的理解会和只用封装工具时完全不同。
之前写过的那篇 8GB 长上下文实战，讲的是 KV cache 怎么随上下文膨胀、256K 怎么塞进小卡——和今天的 -c 调参正好是一体两面，没看过的可以回头补上。
而彩蛋里提到的 MCP，就是下一篇的主角：怎么给本地模型接上一整套 MCP 工具箱，让它从"会说"变成"会做"。这一步打通，本地 AI 才算真正长出手脚。
