llama.cpp v0.2.0 让稳定版与 nightly 作出不同承诺
llama.cpp 现在在 nightly 构建之外也提供语义化版本发布。它的第一个稳定标签与一个构建标签共享代码，说明渠道名称描述的是策略，而不是质量。
多年来，llama.cpp 发布带构建编号的标签，速度几乎与代码变化一样快。8 月 21 日，项目增加了第二条轨道：v0.2.0 发布版开启了稳定版慢速发布的一致语义化版本线，而 b[NUM] 标签仍然属于快速 nightly 或开发渠道。
这并不意味着每次本地推理升级都安全。它只是为下游团队提供了一个更清晰的固定版本，并在较新的 GPU、模型或性能修复仅存在于 nightly 构建中时，让团队可以有意识地作出选择。
当可复现性和下游兼容性比最新变更更重要时，使用 vX.Y.Z 发布版。当你的硬件或工作负载需要某个特定且经过验证的提交时，使用 b[NUM] 构建。无论哪种情况，都要固定确切的标签和提交，验证下载的二进制文件，并在推广前运行同一套冒烟测试。
稳定版和 nightly 是两种发布策略，而不是质量等级
新的标签名称描述了发布节奏和目标受众。llama.cpp 的发布说明称，稳定版 vX.Y.Z 标签发布得更慢，适合下游分发和普通用户。现有的 b[NUM] 标签在大多数提交之时或其附近创建，更早暴露当前功能，稳定性也可能较低。
项目更详细的发布与版本策略补充了一个重要的打包边界。当 llama.cpp 内部副本中的 ggml 与已发布的 ggml 版本一致时，稳定版 llama.cpp 标签就会被切出。这让下游分发者能够基于系统安装的 ggml 构建 llama.cpp，并拥有一个定义明确的兼容性节点。Nightly 构建继续使用 llama.cpp 内部的开发版副本，该副本可能与单独发布的库产生差异。
这已经不只是命名问题。Homebrew 将其 llama.cpp 公式切换到 v0.2.0 标签和确切提交，在关闭开发模式的情况下构建，并链接到打包的系统 ggml。同一公式仍保留 master 作为可选择加入的 head 构建。因此，稳定版和当前开发版作为不同的依赖选择共存。
| 问题 | 选择稳定版 vX.Y.Z |
选择 nightly b[NUM] |
|---|---|---|
| 什么促使升级？ | 计划中的维护窗口或受支持的发布策略 | 稳定版中没有的指定模型、后端、驱动、安全性或回归修复 |
| 团队能够吸收多少变化？ | 按较慢节奏进行审查后的发布差异 | 确切的提交差异，并且可能有更快的后续变更 |
如何使用 ggml？ |
系统库或下游软件包从发布兼容性节点中受益 | 构建携带 llama.cpp 当前的内部 ggml 副本 |
| 需要什么证据？ | 发布说明，加上工作负载和打包测试 | 动机所在的拉取请求或提交，加上同一套完整测试门槛 |
| 记录什么？ | 语义化标签、完整提交、产物摘要、构建标志、后端和模型修订版 | 构建标签、完整提交、产物摘要、构建标志、后端和模型修订版 |
| 如何回滚？ | 上一个已接受的语义化版本及其产物 | 上一个已接受的 nightly 或稳定版基线，并与候选版本分开保留 |
Nightly 并不自动意味着更快，稳定版也不是声称所有回归都已经消失。这些标签说明代码是如何被选择和发布的。性能和正确性仍取决于模型、量化方式、后端、编译器、驱动、硬件、提示词组合、上下文长度和服务器设置。
v0.2.0 和 b10566 指向同一份代码，但服务于不同工作
第一个稳定版发布暴露了一个有用的细节。v0.2.0 和 b10566 标签都解析到提交 bb4caa7540188872173c44d161602d9271386413。稳定版页面确立了语义化版本发布，并链接到 nightly b10566；b10566 发布版则携带了该提交对应的预构建 macOS、Linux、Android、Windows 和 iOS 产物。
这种区别改变了应当固定的内容：
- 下游源代码构建或软件包应标识
v0.2.0及其完整提交。该标签传达稳定版发布契约。 - 使用项目预构建压缩包的团队应记录
b10566、确切的文件名和其摘要，因为这些二进制文件位于构建标签的发布页面上。 - 如果不检查确切的提交范围，就不应把后续 nightly 描述为“v0.2.0 加上修复”。截至雅加达时间 8 月 24 日，仓库已经在不同提交上发布了 b10603。
发布说明还说明了为什么按版本作出性能承诺会产生误导。v0.2.0 的变更范围包含后端、服务器、模型支持、内存、构建和发布工程工作。有些变更针对 Metal、SYCL、OpenCL、Vulkan、CUDA 或特定模型架构；另一些则是回滚。没有单一的速度数字能够概括这种混合内容。
测试性能前先验证来源
b10566 二进制发布版链接到 GitHub 的产物证明，并为其中的文件发布 SHA-256 摘要。产物证明是将产物与其源代码仓库及构建工作流连接起来的签名声明。GitHub 的证明文档明确说明了边界：来源信息有助于确立产物在哪里以及如何构建，但不能证明代码安全或没有回归。
只从项目发布页面下载确切的平台压缩包，然后在解压前验证它。使用当前的 GitHub CLI 时，文档记录的命令形式是：
gh attestation verify ./llama-b10566-bin-ubuntu-x64.tar.gz \
--repo ggml-org/llama.cppGitHub CLI 参考解释了验证策略和输出。成功结果应与预期仓库、产物文件名、SHA-256 摘要、标签和提交一起，存入部署记录。验证失败或缺少验证是停止条件，而不是改用未跟踪镜像重试的理由。
只固定 master、latest、head 或包管理器的移动渠道，会让之后的事故更难重建。标签更好，而确切提交则能独立于渠道名称标识源代码。
稳定版和 nightly 回应不同的维护需求
不同寻常的 v0.2.0 与 b10566 配对让这种区别具体化：这些标签指向同一份源代码提交，但语义化版本发布传达稳定性契约，而构建标签携带可下载的产物。后续 nightly 可能包含所需的后端或模型修复，但它也会偏离稳定版所选择的确切代码。
因此，“稳定版还是 nightly”是维护决策，而不是基准测试结论。模型、量化方式、硬件、后端、上下文和工作负载可能主导性能，而来源信息只能确立产物来自哪里，并不能证明它安全或没有回归。
因此，llama.cpp 新发布策略最有用的信号是组织层面的：下游用户终于有了语义化锚点，同时仍能使用快速变化的构建。这个锚点是否适合某次部署，仍取决于特定工作负载所需的能力或修复。