这周本地部署圈子里，应该不少人刷到过类似的消息：“llama.cpp 更新大版本 0.2.0 了，快更新”，很多还带一个扎眼的数字——速度提升 42%。
先别急着跟着动手，把这次更新到底改了什么、哪些是真的、哪些还没验证、你到底该不该更，一次说清楚。
先看时间线：一周内发生了什么
llama.cpp 这个底座，跑过本地大模型的人基本都间接用过——Ollama、LM Studio 底下都是它。但它长期以来没有真正意义上的"版本号"，只有连续的构建号（bXXXX 那种）。这个月情况变了：8 月 17 日，llama.cpp 在 GitHub 上打出 v0.1.0 标签，随后又补了 v0.1.1。知乎到本周，0.2.0 大版本直接来了。
生态的反应比想象中快。whisper.cpp 那边已经有人编译时卡在"正在拉取 llama.cpp 依赖（v0.1.2）"这一步上求助。知乎下游项目开始把 llama.cpp 当成可以精确固定的依赖，这在构建号时代是做不到的。
“速度提升 42%”？目前没有靠谱的实测
把 B 站、知乎、微博都翻了一遍，这个 42% 的来源基本都指向那条"快更新"的视频，而视频标题本身就带着问号。哔哩哔哩截至目前，没有找到官方 changelog 或第三方对照测试给这个数字背书。
跟踪 llama.cpp 仓库动态的一份 AI 日报里有句话说得挺准：版本号本身不提升推理速度，它解决的是"线上到底跑了哪一版"这种很朴素、也很要命的问题。知乎语义化版本带来的是下游打包、依赖固定、回滚的坐标系——以前你只能说"我跑的是某天那个构建"，现在可以直接说 v0.1.1 或 0.2.0。
所以如果群里有人拿"42%"劝你更新，可以先问一句：哪个模型、哪张卡、哪个量化下测的？
为什么我建议别信"更新必然更快"
llama.cpp 社区自己就有反例。这个月有用户实测了官方的"权重预取"PR（#21067）：思路是把下一层要用的权重提前搬运，藏住 PCIe 传输的等待时间，在稠密模型上确实有效——但在 MoE 模型上反而慢了 47.8%。知乎一个官方 PR 都能因场景不同而效果相反，何况一个包含大量改动的大版本。本地推理的速度收益，从来都是"模型×硬件×量化"三者共同决定的：同一个 Qwen3.8-27B，5060 Ti 16G 用 4 位量化能跑 47 tok/s（129K 上下文）。微博V100 级别的老卡 30 tok/s 左右，开了 MTP 能到 40+。微博同一个模型三种速度，"42%"到底适用于哪一种，没人回答得了。
这次真正值得关注的：几个具体特性
这个月 llama.cpp 生态里真正在帮本地党提速的，是几件具体的事：
DFlash2 投机解码：通过 llama.cpp 的 PR 推进的加速方案，有人单张 4090 24G 跑 Qwen3.8-27B Q4 做到 80 tok/s 的生成速度（部分用法需要自己编译特定分支源码）。哔哩哔哩
MTP 多 token 预测：V100 这类老卡能从 30 tok/s 提到 40+；不过也有实测说在 4090 上关掉原生 MTP、换 DFlash2 更快。微博两条路线还得看卡选。
Responses API 支持：社区反馈 llama.cpp 现在能暴露兼容 OpenAI Responses API 的接口，可以直接接 Codex 这类编码 Agent 用；
自适应 MTP 深度（PR 27210）：用状态机动态调投机深度，作者在双 Radeon AI PRO R9700 上测 Qwen3.8-27B Q8_0，编码样例从固定深度的 78.8 tok/s 提到 85-86；但他自己也写明普通和困难散文任务没超过固定深度，而且这个 PR 还没合并。知乎
这些提速故事值得看，但它们都是"具体配置下的实测"，不是版本号本身的功劳。
所以到底要不要更新？三类用户三种做法
1）自己编译 llama.cpp 的用户（直接用 llama-server / llama-cli）
可以试 0.2.0，但做个保险动作：旧 build 目录先别删，用同一个模型、同一个提示词、同一套量化，更新前后各跑一遍对比 tok/s，慢了就直接回退。有了语义化版本，回退也变成了标准操作——git checkout 到 v0.1.1 重新编译，就能回到老版本，不像构建号时代那样难以精确复现。
2）Ollama 用户
llama.cpp 是 Ollama 内置打包的，你不需要手动编译什么，跟着 Ollama 官方的发版节奏走就行。另外说个反直觉的事实：Ollama 不一定比自编译慢——有用户在 7900XTX 上实测，Ollama 跑 41 t/s，自己编译的 llama-server 反而只有 35.88 t/s，后来给 llama-server 加了两个参数才追回来。知乎这类用户调参数比追版本更有性价比。
3）LM Studio 用户
同 Ollama，底层引擎版本由软件方管理，跟软件更新走即可。
还有一类用户要小心：如果你在编译 whisper.cpp 这类依赖 llama.cpp 的项目，注意它固定的 llama.cpp 版本，最近编译卡住、报错的，不少就是版本对不上导致的。
两个信号，值得继续盯
接下来一两周，社区会不会出现 0.2.0 的可靠对照实测——尤其是 Qwen3.8-27B 这类热门稠密模型，和 MoE 模型（预取那个反例提醒我们，MoE 上的变化可能是反方向的）。你自己模型和卡组合下的实测，比任何转述都可靠。
自适应 MTP（PR 27210）的合并进展。如果合并，对开了 MTP 的用户是稳定收益——但记住作者自己说的，目前只有编码类任务测出了提升。
最后说句实在的：llama.cpp 终于有了正经版本号，这事值得点赞，但它是"可回滚、可复现、可管依赖"的好消息，不是"免费提速"的承诺。以后谁再说"这个版本更快了"，先问一句哪一版、什么卡、什么模型——这才是语义化版本该有的打开方式。
