推論執行環境
llama.cpp 0.2.0 Separates Stable Releases from Nightly Builds, Finally Letting Package Maintainers Pin Compatible Versions
llama.cpp 0.2.0 officially introduces semantic versioning for slower-moving stable releases, while retaining the existing `b[number]` tags for development builds produced for nearly every commit. The new system reduces versioning risks for Debian, Homebrew, and downstream bindings, but “stable” does not mean long-term support or comprehensive validation across hardware platforms.
The central change in llama.cpp 0.2.0 is not a single kernel acceleration but its release model: `vX.Y.Z` now denotes a slower-moving stable release suitable for downstream distribution, while the `b[number]` tags generated for nearly every commit to the main branch are explicitly designated as nightly/development builds. For applications, language bindings, and Linux packages that have long had no choice but to track build numbers, this provides a version reference that can be pinned, compared, and used to define upgrade policies.
The maintainers also require the ggml embedded in llama.cpp to exactly match a released ggml version whenever an official tag is created. This is an important ABI and packaging detail: Debian now splits the executable tools, `libllama`, development headers, and ggml backends such as CUDA, HIP, and Vulkan into separate packages. If the embedded version drifts from the system library, loading or inference can fail even when compilation succeeds. Semantic versioning makes dependencies easier for package managers to express and allows downstream projects to retain a tested baseline before adopting support for new models.
Version 0.2.0 also incorporates numerous runtime changes, including an Arm SME2 F32 GEMV kernel, a SYCL Q5_K kernel and loading fixes, Adreno OpenCL compatibility handling, tensor splitting for LFM2/LFM2-MoE, an LFM2 DSpark draft model, configurable devices for multimodal projection, and adjustments to quantization or KV-cache paths for Metal, CUDA, and Vulkan. These features now have a stable tag that integrations can target without tracking the main branch directly.
The limitation is that the project remains in the 0.x series; its versioning rules and automated release process have only just been established, and improvements to release summaries are still listed as pending work. A stable tag is also not equivalent to LTS, a security audit, or confirmation that every backend has been tested. Downstream projects should track the `libllama` API, REST interface, ggml version, and model formats separately, and establish regression tests on the actual deployment hardware used with CUDA, Metal, Vulkan, SYCL, and other backends.