llama.cpp 原理：如何在普通硬件跑本地大模型

TL;DR — llama.cpp 是一个 C++ 项目，它通过 GGUF 格式、分块量化以及 CPU+GPU 卸载机制，让在普通硬件上运行开源权重 LLM 成为常态。本文将拆解这三个机制的实际工作原理，以及什么时候直接使用 llama.cpp 比用 Ollama 这样的封装工具更合适。

在出现一键启动的前端界面之前，在各个模型卡片页都有托管量化仓库之前，曾有一个单文件的 C++ 项目，可以加载 Meta 的 checkpoint 并在 MacBook 的 CPU 上运行它。这个项目就是 llama.cpp，它让"开源权重"和"能在你笔记本上跑"变成了同一句话。本系列文章中凡是提到 GGUF、量化级别或 GPU 卸载的地方，其背后都是这个代码库在支撑。

它解决的核心问题

第一个 LLaMA 权重泄漏时，以 PyTorch checkpoint 的形式存在，依赖 CUDA 运行时、Python 环境，以及足够容纳 FP16 权重的 VRAM。一个 FP16 的 7B 模型大约需要 14 GB——超出了当时大多数消费级 GPU 的显存。llama.cpp 用纯 C/C++ 重写了推理路径，不依赖任何外部库，让同一个 7B 模型在 4 GB 以下、仅用 CPU、达到对话速度运行了起来（据 moderncpp.dev 的技术分析）。该文章还指出，该项目已在 GitHub 上获得了超过 105,000 颗星，但星数是结果，不是重点：它是后续每一个开源权重发布时在数小时内就会配套提供（或被社区转换为）GGUF 文件的原因。

GGUF：让这一切成为可能的可移植文件格式

GGUF 是一种扁平二进制格式——头部是张量元数据，随后是按页对齐偏移布局的张量数据。没有 protobuf，没有 HDF5，也没有 JSON 塞进压缩包（对比之下 PyTorch 的 .pt 格式就是这么做的）。元数据可以一次解析完毕，而由于张量数据位于对齐偏移处，llama.cpp 可以直接将整个文件交给 mmap() 而非读入内存。内核将文件映射到进程地址空间，页面按需调入——模型"加载"更像是 TLB 查询而非磁盘读取（同上，moderncpp.dev 文章中的解释）。这是 llama.cpp 在热页缓存状态下几乎瞬时启动多 GB 模型的关键原因之一。

量化：内存真正去哪了

GGUF 的量化格式以块为单位压缩权重。以 Q4_0 这个最简单的情况为例：GGML 将权重按每 32 个为一组，计算一个 FP16 缩放因子，然后每个权重存为一个 4 位整数。这样 32 个权重占用 18 字节，即每个权重 4.5 比特，相较 FP16 压缩了 3.6 倍，相较 FP32 压缩了 7.1 倍（据 moderncpp.dev 的拆解）。Q4_0 的 7B 模型约 3.8 GB，因此能装进廉价笔记本的 RAM 中。

实际使用时你会选择 K-quant 系列而非旧格式。Acing AI 的一篇指南清晰地指出了最佳选择：Q4_K_M 约为全精度的四分之一大小，质量损失极小，是理性的默认选项；如果有多余的显存，Q5_K_M 或 Q6_K 可以填补剩余质量差距；Q8_0 接近无损，但体积是 Q4 的两倍，通常意味着你应该用 Q4 跑一个更大的模型。作为内存经验法则，Internals Decoded 将 Q4_K_M 定位为每十亿参数约 0.6–0.7 GB VRAM——7B 模型可以装进 6 GB 显存，34B 模型需要约 20 GB。

KV cache 独立于权重单独累计，尤其在长上下文场景下。llama.cpp 也支持对 KV cache 进行量化——--cache-type-k q8_0 --cache-type-v q4_0 约能将 KV cache 内存减半，同时质量损失很小（据 Internals Decoded 和 Acing AI 两处来源）。仅这一个参数往往就是模型能否装下还是在长 prompt 时 OOM 的分水岭。

CPU+GPU 卸载：跑下比显存还大的模型

当模型无法完全装入时，最关键的参数是 -ngl（GPU 层数）。设为 99，llama.cpp 会尽可能把层放到 GPU 上，放不下的跑在 CPU 上但会有速度损失——启动日志会显示实际有多少层落在了 GPU 上（正如 Acing AI 指出的）。对于混合专家模型，这会更精细：Hugging Face 的一篇 MoE 卸载指南描述了将"始终激活"的参数——attention、dense FFN、shared expert FFN——分配到 GPU，而通过类似 -ot "blk\.([0-9]|[1-2][0-9]|30)\.=CUDA0,exps=CPU" 的正则表达式将稀疏的 routed-expert FFN 权重卸载到 CPU。由于 GPU 在 prompt 处理上远快，llama.cpp 会在大批量时将 CPU 上的权重 opportunistic 地复制到 GPU——由 -b（逻辑 batch size）和 -ub（物理 batch size）控制，据同一篇指南，这两个参数在 CPU+GPU MoE 配置下通常会推到 4096。

什么时候直接使用 llama.cpp

Ollama 封装 llama.cpp 是有原因的——大多数人不必手动调优张量卸载正则。但确实存在一系列场景，封装反而成了障碍：

精确量化控制。你想对某个模型用 Q5_K_M，对另一个用 Q4_K_M，或者你想测试多出来的那些比特是否真的改变了输出质量。llama-server -hf model:Q6_K 会直接从 Hugging Face 拉取并服务特定量化版本（据项目自身文档）。

奇特或受限硬件。llama.cpp 通过 Metal 将 Apple Silicon 作为一等公民对待，支持 x86 上的 AVX/AVX2/AVX512/AMX，甚至支持 RISC-V 的 RVV/ZVFH（据项目 README）。如果你的目标是边缘设备、老旧工作站，或通过 Vulkan 或 SYCL 使用非 NVIDIA GPU，llama.cpp 的后端列表才是真正的兼容性答案。

挤下略大的模型。用 -ngl 30 部分 GPU 卸载加其余放 CPU，或用 -ot 做 MoE expert 分割，可以让你在 16–24 GB 显存的卡上跑起 27B 或 35B-A3B 模型——而如果天真地全量加载到 GPU 会被直接拒绝。

无需 Python，无需依赖链。纯 C/C++ 二进制文件比 PyTorch 堆栈更容易嵌入到嵌入式流水线、基础镜像最小的容器，或 CI 任务中。

内存压力下的长上下文服务。显式设置 -c 而非信任标注的最大上下文，结合 --cache-type-k q8_0 --cache-type-v q8_0，这就是在本来会在模型完整窗口下 OOM 的硬件上服务 32K 上下文的方法——Acing AI 专门演示了这一模式。

llama.cpp 不适用的场景：大规模高吞吐多用户服务，这种场景下经批处理优化的引擎如 vLLM 在同等 GPU 上能远超它；以及快速一次性实验，这种场景下 Ollama 一条命令确实更快到达可用模型。llama.cpp 的复杂度是值得的——当你需要精确控制每一字节内存去向的时候。

核心项目位于 GitHub 的 ggml-org/llama.cpp，构建于 ggml 库之上，由开源贡献者社区维护。关于 GGUF 布局、mmap 加载和 Q4_0 量化数学的内部细节分析来自 Modern C++ // dev。VRAM 每十亿参数的法则和 KV cache 量化笔记来自 Internals Decoded 关于 Ollama 和 llama.cpp 内部机制的文章。量化选择指导、容量表和长上下文参数演示来自 Acing AI 的本地服务配置指南。CPU+GPU MoE expert 卸载技术和启动命令来自 Doctor-Shotgun 的 Hugging Face 博客文章。

明天的文章将介绍 NVIDIA 的 Nemotron 3 Nano 30B，这是一款混合专家模型，每次只有约 3B 参数处于活跃状态——本系列"用小算力预算跑出大模型质量"这一主题的又一个例证。

附录——一张图看懂领域格局