第一章 · 认识 llama.cpp：本地推理的极简主义

第一章 · 认识 llama.cpp：本地推理的极简主义

章节摘要：本章跟着一个具体的问题走：一台没有服务器级显卡的旧笔记本，凭什么能把 80 亿参数的大模型跑起来？我们从项目的起源故事讲起，拆开 token、量化位宽、上下文窗口这些绕不开的行话，最后把 llama.cpp 与 Ollama、vLLM、MLC 放在同一张桌上比较，让你在做任何实验之前先回答「该不该用它」这个前提问题。

一条主线

主线的起点是这台书里反复出现的实验机：2019 年的游戏本，i7-9750H 六核十二线程，16GB 内存，RTX 2060 只有 6GB 显存。2023 年它第一次尝试加载一个 130 亿参数模型时以失败告终——16GB 内存被占满，系统开始用硬盘假装内存，生成一个字要等十几秒。问题出在哪里？是模型太大、内存太小，还是用法不对？这一章不急着给答案，而是把回答这个问题需要的背景知识补齐：这个项目从哪来、它的极简哲学是什么、那些术语到底指什么、以及它和同类工具的分工边界在哪。读完你会发现，「跑不动」的结论下得太早了——工具选对、格式选对、位宽选对之后，这台机器能把 8B 模型跑出每秒十几个词的速度，这正是后续七章要逐一验证的实验承诺。

沿途站点

1.1 项目起源与哲学——从 whisper.cpp 与 llama.cpp 的作者 Georgi Gerganov 讲起：为什么在 Python 生态如日中天时，有人坚持用纯 C 语言重写推理引擎。你会看到「四个星期、一台 MacBook」的传说背后的工程逻辑：依赖越少，能跑的平台越多；离硬件越近，每瓦性能越高。

1.2 核心术语拆解——把 token、量化位宽、上下文窗口、困惑度这些概念放到同一张桌上讲清楚。它们是后面所有实验的自变量，看不懂它们，第 3 章的位宽实测就只是一串没有意义的数字。

1.3 选型对比——llama.cpp、Ollama、vLLM、MLC 四条路线同台比较：谁面向笔记本、谁面向服务器、谁适合嵌入式。这一节会给你一张决策表，避免「拿着 vLLM 硬刚 6GB 显存」这类方向性错误。

拐点与结论

本章最重要的认知转折在 1.3：选型不是选「最好」的工具，而是选「约束最匹配」的工具。vLLM 吞吐漂亮，但它假定你有多卡服务器；Ollama 体验顺滑，但它把 llama.cpp 包了一层壳，你想控制的量化细节、分层策略都被藏在了幕后；MLC 把模型编译进手机 App 很惊艳，但定制成本高。llama.cpp 的位置恰恰在「要控制、又只有一台普通机器」的交集上。想通了这一点，后面七章的一切实验（为什么抠显存、为什么量化、为什么要自己编译）都有了共同的出发点。

实验基线速查

全书共用的主线机器基准，后续每一章的实测数据都以它为参照：处理器 i7-9750H（六核十二线程，本书线程参数恒取六）、内存 16GB 双通道 DDR4-2666（理论带宽约 42GB 每秒）、显卡 RTX 2060 笔记本版 6GB（带宽约 336GB 每秒）、系统 Windows 11。基准模型为 Qwen2.5-7B-Instruct 的 Q4_K_M 档（体积约 4.7GB、二十八层），常用基线数字：纯 CPU 生成约每秒 9.8 token，全卸载生成约每秒 16.7 token。看到后文的任何数字，都可以回到这张卡上做相对比较。

读完你应该

• 能讲清 llama.cpp 与 ggml、GGUF 三者的关系，不再把它们混为一谈；
• 能向同事解释 token 是什么、为什么生成速度按「每秒 token 数」计量；
• 能说出量化位宽与模型体积、精度之间的因果链；
• 能对着自己的硬件配置与需求，用 1.3 节的决策表选定或排除 llama.cpp；
• 能读懂模型社区里「Q4_K_M」「n_ctx」「offload」这类行话构成的讨论。

下一章的接力

选定了工具，下一个问题是去哪儿弄模型文件。第 2 章进入 GGUF 格式的内部：这个单文件容器如何把权重、词表、架构参数装在一起，以及为什么 2023 年 8 月那次 GGML 到 GGUF 的格式迁移，是 llama.cpp 历史上影响最深远的一次重构。