llama.cpp 的第一个正式稳定版 v0.2.0 在 8 月 21 日上线，到现在刚 4 天。B站已经出现《快更新！llama.cpp更新大版本0.2.0：速度提升42%？》这样的万播视频，评论区一堆人追问到底快了多少。哔哩哔哩但把 v0.2.0 官方发布说明里的 80 多个 commit 从头翻到尾，没有任何一条写着"提速 42%"。这一版带的不是普惠加速包，值不值得更新，得看你手里是什么硬件。
先搞清楚：两条版本线是什么意思
以前 llama.cpp 只有 b10xxx 这样的连续构建号，这次不一样，标准语义版本标签，给下游打包、固定依赖和回滚提供了更清楚的锚点。知乎具体节奏是：8 月 17 日创建 v0.1.0 标签，8 月 18 日 v0.1.2（对应 b10485 构建），8 月 21 日 v0.2.0 发布，nightly 那边则已经排到了 b10566。下游项目已经开始用这个锚点，whisper.cpp 的编译依赖目前就锁在 v0.1.2 上。
往后就是双轨并行：vX.Y.Z 是稳定线，官方定位是 stable, slower release cadence, recommended for downstream distribution and casual users；b 构建号是 nightly 线，更新快、功能新但更不稳定，面向开发者。GitHub有评论说得直白，版本号本身不提升推理速度，它解决的是"线上到底跑了哪一版"这种很朴素、也很要命的问题。知乎
80 多个 commit，到底改了什么
按方向数这 80 多个 commit：后端相关是大头，SYCL 7 条、OpenCL 6 条、Vulkan 5 条、Metal 4 条、CUDA 只有 2 条，剩下的多是 ggml 核心、CI、服务端和多模态组件的改动。其中跟速度最直接相关的是 CUDA 那条，CUDA: adding switch points per HW and quant type to tune the mvq->MMQ decode crossover，即按显卡型号和量化类型重新校准解码内核从 MMVQ 切到 MMQ 的切换点。GitHub这类优化是参数级的：某些硬件和量化组合的解码会快一点，但它给不出"人人 42%"的承诺。
Metal 这边连着三条 KV cache 反量化相关改动，针对大 batch 和 flash attention 场景；CPU 侧给 ARM 新指令集加了 KleidiAI SME2 的 GEMV kernel。更隐性的改动在服务端和工程侧：开了鉴权就把 models 接口私有化、sleep 期间可读 /metrics、GGUF 加载加了尺寸保护、发布包带上签名校验。这些都不提速一帧，但对把 llama-server 当服务跑的人来说，都是实打实的改进。
评论区的实测，比标题诚实
那条视频下面的评论区，气氛比标题务实得多。有升级过的用户直说，没有觉得快，从10488升级以后反而变慢了一点点。哔哩哔哩Mac 党也在下面提醒，本地推理吃的是内存带宽，这一版大概率吃不到什么红利。还有人问 0.20 在哪里下载，答曰指路 GitHub Releases 页。评论区始终没人拿出"42%"的实测，这个数字只能当标题看。
16GB 显存党在测什么：带宽才是天花板
另一边，小红书上的 16GB 显存党已经认真测了一段时间。有人用 16G 显存台式机跑 Qwen3.8-27B 的 UD-IQ3_S 量化，128k上下文，稳定40+ token/s，本地干重复的活完全够了。小红书另一份 4090 Laptop（16GB）笔记本测试，把三种量化拉出来对比：三种量化在相同条件下的生成速度都是 28~32 tok/s,差异在误差范围内，解码阶段的瓶颈是显存带宽。小红书看懂这一句，对这次更新的预期就落地了：解码速度被显存带宽锁死，解码内核切换点的微调，本来就不可能带来质变。
升不升级，按硬件对号入座
N卡（CUDA）用户：风险最低的一批，可以升。解码切换点校准主要利好这边；手上的 b 构建如果用着稳，也不必急着动。
A卡用户：选对构建比选对版本更重要。有 9070 用户实测后给出结论：我的9070用ROCm经常卡死，vulkan非常丝滑，直接用vulkan就行。小红书
Intel / 核显用户：SYCL 的 Q2_K 新 kernel 在发布前被 revert 了，这版别指望 Q2 加速；有核显用户实测提醒，兄弟们，试了，核显的sycl依然不如vulkan。哔哩哔哩
Mac 用户：Metal 的改动集中在 KV cache 反量化，多为大 batch 场景，日常对话提升有限。
跑服务的人：值得升。models 接口随鉴权私有化、sleep 期间可读 /metrics，都是实打实的安全与运维改进。
多卡用户：tensor-split 相关修复同样在发布前被 revert，多卡环境建议先在非关键机器上验证。
升级路径：两条命令的事
最简单的方式，是去 GitHub Releases 页下载预编译包，按自己的后端选对应后缀（win-cuda、vulkan、rocm、macos-metal 等），A卡优先试 vulkan 版，省得折腾驱动环境。
Windows 上还有更懒的办法：winget install llama.cpp，装完重开 PowerShell 就能用。知乎llama-server 跑起来后，浏览器打开就是自带的 Web UI，模型、对话、参数都能在页面里管，不用再自己搭前端。下游集成提醒一句：whisper.cpp 目前的编译依赖就锁在 v0.1.2，自己做集成的建议同样锁死 vX.Y.Z，别追 nightly。
两个还没合并的 PR，值得蹲
这次更新没带上、但值得盯着的实验有两个。一个是权重预取 PR #21067：理论上把 PCIe 传输时间藏进计算里，但社区在 MoE 模型上实测，短 prompt 的首字延迟（TTFT，就是你问完话到看到第一个字的等待时间），从 1085ms 涨到 1604ms，慢了 47.8%。知乎原因不复杂：MoE 每层激活哪几个专家，由路由器现场决定，预取猜不到，只能盲拷整个专家张量。小显存卡跑 MoE 的，这个补丁别急着上。
另一个是自适应 MTP 投机深度的 PR 27210：作者在 Qwen3.8-27B Q8_0、两张 Radeon AI PRO R9700 的测试中，报告编码样例从固定深度 3 的 78.8 Token/s 提到约 85–86 Token/s。知乎但普通和困难文本没跑赢固定深度，离正式合并还有距离。这两个 PR，才是"llama.cpp 下一波提速"真正的观察点。
最后说句结论
v0.2.0 的价值，不在"立刻变快"，而在"版本终于可以锁了"：稳定线给了下游和用户一个能长期依赖的锚点。想要速度，盯住那两个未合并的 PR；想要省心，0.2.0 就是现在可以放心写进生产环境的版本。升不升级按自己的硬件对号入座，比盯着标题里的 42% 实在得多。
