llama.cpp b10012 ships 27 platform builds, a quiet snapshot of AI fragmentation

The llama.cpp b10012 release, tagged July 14 by the project’s automated release workflow, contains one code change: a fix for an enum-narrowing problem in the Hexagon DSP’s hmx-queue signal handling. The release notes run exactly that line. But the asset list tells a different story.

Twenty-seven downloadable binaries. That is the real news.

The project ships builds for macOS Apple Silicon (arm64), macOS Intel (x64), iOS, Ubuntu on x64 and arm64 and s390x, Android arm64, Windows x64 and arm64, plus a disabled macOS KleidiAI build and a pair of disabled openEuler variants. Each platform splits further by compute backend. Ubuntu alone gets ten tarballs: CPU, Vulkan, ROCm 7.2, OpenVINO 2026.2.1, SYCL FP32, SYCL FP16. Windows ships CUDA 12, CUDA 13, Vulkan, OpenVINO, SYCL, and HIP. Windows arm64 gets an OpenCL Adreno build.

This is not a story about a bug fix. It is a story about what happens when a project that started as a single-file C++ curiosity becomes the de facto cross-platform inference runtime for open-weight models.

The backend explosion

llama.cpp began in March 2023 as a weekend project by Georgi Gerganov to run LLaMA on a MacBook. It used the ggml tensor library, a CPU-first framework with no GPU support. The first release had one binary.

Twenty-eight months later, b10012 ships binaries for six GPU runtimes across four operating systems and three CPU architectures. The CUDA 12 and CUDA 13 builds use different CUDA runtime DLLs (12.4 and 13.3). The ROCm build targets version 7.2. The SYCL builds split FP32 and FP16. The Windows arm64 build targets Qualcomm Adreno GPUs through OpenCL.

Each backend represents a separate optimization path, a separate set of kernel specializations, a separate maintenance burden. The project’s build matrix now mirrors the hardware diversity of the entire AI inference market.

This is the fragmentation that centralized API providers like OpenAI and Anthropic do not have to solve. They target one GPU architecture (NVIDIA Hopper, Blackwell) in one cloud region. llama.cpp targets everything from an s390x mainframe to an iPhone to a Radeon RX 7900 XTX.

The disabled builds matter

Two entries in the b10012 asset list are marked DISABLED: the macOS Apple Silicon build with KleidiAI enabled, and the openEuler builds for x86 and aarch64.

KleidiAI is Arm’s micro-kernel library for AI inference on mobile and edge devices. The fact that the project has a KleidiAI build at all, even disabled, signals that the maintainers see Apple Silicon as a first-class inference target. The disabled status suggests a regression or incompatibility in the current release. The linked pull request (number 23780) will reveal the details.

The openEuler builds, targeting Huawei’s Ascend 310P and 910B accelerators through the ACL Graph backend, are also disabled. These builds represent the Chinese domestic AI hardware ecosystem. Their presence in the build matrix, even temporarily disabled, confirms that llama.cpp’s maintainers are actively porting to non-NVIDIA silicon.

What the build matrix reveals about the market

The CUDA 12 and CUDA 13 builds ship with different CUDA runtime DLLs. This is not an accident. NVIDIA’s CUDA 12 and CUDA 13 are not backward-compatible at the binary level for all applications. llama.cpp must ship both.

The ROCm 7.2 build targets AMD’s latest GPU software stack, which supports the MI300X and Radeon RX 7000 series. The SYCL builds target Intel GPUs (Arc, Data Center GPU Max). The Vulkan builds are the universal fallback, running on almost any GPU from any vendor, but with lower peak performance than the vendor-specific backends.

The Windows arm64 OpenCL Adreno build is the most niche: it targets Qualcomm Snapdragon X Elite laptops running Windows on Arm, using the GPU through OpenCL rather than DirectML or Vulkan. This is the build for the Microsoft Surface Pro 11 and Samsung Galaxy Book4 Edge.

Each build exists because someone in the community needs it. The project’s 120,000 GitHub stars and 20,600 forks represent a user base that runs inference on everything from a Raspberry Pi to a 4x A100 server.

The Hexagon fix is a tell

The single code change in b10012 is a fix for the Hexagon DSP’s hmx-queue signal handling. Hexagon is Qualcomm’s digital signal processor, used in Snapdragon mobile chips. The fix addresses an enum-narrowing problem, a C++ type-safety issue that would cause undefined behavior or compilation failure on certain toolchains.

This is the kind of fix that only matters if someone is running llama.cpp on a phone. The fact that the project ships an Android arm64 CPU build alongside the Hexagon fix tells you where inference is heading: toward the edge, toward the device, toward the phone in your pocket.

The fragmentation tax

Twenty-seven binaries is a maintenance liability. Each backend requires separate testing, separate CI infrastructure, separate bug reports. The project’s GitHub Actions infrastructure, visible in the automated release workflow, must build and validate each target. A single backend regression can delay the entire release.

The alternative is to drop backends. The project could ship only CUDA and CPU, covering 80% of users. But the project’s ethos is the opposite of that. llama.cpp exists to democratize inference, to let anyone run a model on any hardware they own. Dropping backends would betray that mission.

The result is a release like b10012: one bug fix, 27 binaries, and a quiet snapshot of how fractured the AI inference hardware market has become. NVIDIA dominates the datacenter, but the edge runs on Qualcomm, AMD, Intel, Apple, and Arm. Each vendor has its own software stack, its own kernel language, its own versioning scheme. llama.cpp sits in the middle, translating between them.

The project’s maintainers do not complain about this. They ship the builds. But the build matrix is a form of documentation. It records, in 27 tarballs, the cost of running AI outside the cloud.