llama.cpp b10870 targets Intel Vulkan matmul — the published gains are prefill, not a universal speedup

ggml-org published llama.cpp b10870 on September 9, 2026. The nightly adds f16 B-type matrix-multiplication pipelines and warp-tile tuning for Intel coopmat1 in the Vulkan backend. (Source: llama.cpp b10870 release notes, 2026-09-09)

Key facts:

• b10870 is a nightly release, published on September 9, 2026.
• The release includes an Ubuntu x64 Vulkan binary and a Windows x64 Vulkan binary.
• The merged change is PR #27471, which changes one Vulkan source file.
• The author measured prompt processing with llama-bench -p 512 -n 0 on Windows.
• The numbers are upstream measurements, not an independent 7minai benchmark.

What this means if you run llama-server on Intel graphics

This is relevant if your local Qwen or GGUF endpoint uses Vulkan on an Intel Xe GPU. It is not a new llama-server flag and it is not evidence that every Intel, CUDA, Metal, or AMD run becomes faster. The code path is specifically described as Intel coopmat1 work; the release note also says the f16-B pipeline is enabled for dense matmul on all vendors, while MoE remains Intel-only. (Source: PR #27471, merged 2026-09-09)

The author’s Windows measurements are substantial, but narrow. On the Xe1-ARL_H test, Gemma 4 31B Q4_K_M prompt processing rose from 106.60 to 138.66 tokens/s without flash attention. That is a 30.1% increase, calculated from the values in the PR.

On the same test, Qwen3 8B Q4_K_M rose from 414.20 to 532.65 tokens/s. That is a 28.6% increase. (Source: PR #27471 benchmark table, Windows Xe1-ARL_H results)

Those are prefill results: the command uses -p 512 -n 0, so it processes a 512-token prompt and generates no completion tokens. If your pain is time to first token for long agent instructions, retrieved context, or repeated repository prompts, that is a meaningful signal. If your workload is long streaming generation, the PR does not establish a token-generation gain.

Upgrade deliberately, then measure the same workload

Start by recording your installed build and use the official Vulkan build instructions if you compile locally:

llama-server --version
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release

The project documents -DGGML_VULKAN=ON as the Vulkan build switch. (Source: llama.cpp build documentation)

Then test both prompt processing and generation with your model, quantization, context length, and driver. Do not replace a stable production binary solely because a nightly showed a gain on another Xe configuration. For a server whose bottleneck is repeated prefills, combine the upgrade with KV-cache reuse controls. For several concurrent users, track per-slot latency with the llama-server concurrency guide. Keep tool-enabled endpoints constrained as described in the safe built-in tools setup.

Sources

• llama.cpp b10870 release notes
• PR #27471 — f16 B-type pipelines and Intel coopmat1 tuning
• PR #27471 file diff
• llama.cpp Vulkan build documentation