News · 2026-08-17

llama.cpp tagged v0.1.0 after ten thousand build numbers

llama.cpp, the inference engine behind most local AI setups, published a tag named v0.1.0 on August 17, 2026 -- its first semantic-looking version number after years of shipping by build number. The release was cut at commit 7c35571 at 09:08. It is a packaging milestone rather than a promise: the release page carries no API-stability or semantic-versioning commitment, and the project's releases page is still dominated by build-number tags like b10472.

Key facts

• Release v0.1.0 was published August 17, 2026 at 09:08, pinned to commit 7c35571, on a repository with roughly 124,000 stars.
• No API-stability or semantic-versioning promise appears on the release page; project discussion history says llama.cpp has used rolling releases, with specific tags or commits as the practical pinning mechanism.
• A separate open contribution, pull request #27210 by contributor stew675, adds an adaptive speculative-decoding mode and reports coding throughput rising from 78.8 tokens per second at a fixed draft depth to 86.4 with adaptation on dual Radeon AI PRO R9700 cards.
• Primary sources: the llama.cpp GitHub release page and the open pull request.

Why does a version number matter? Because for most of llama.cpp's life there has not been one. The project ships continuously, tags builds by sequential number, and expects downstream users to pin a commit. That works fine for people who track the repository daily and badly for everyone packaging it -- distribution maintainers, Python wrapper authors, container image builders, anyone who has to write "depends on llama.cpp >= X" in a manifest. A v0.1.0 tag is the first thing in that ecosystem that looks like a version to a dependency resolver.

The word to keep in view is "looks." Nothing on the release page commits the project to semantic versioning going forward, and the leading zero in 0.1.0 is itself the standard convention for "no stability guarantees yet." The safe reading is that packaging caught up with reality, not that the API froze. Anyone pinning against it should keep pinning commits.

The more interesting change is not in the release at all. Pull request #27210, titled "spec : add adaptive MTP draft depth," is still open and proposes a new speculative-decoding mode. Speculative decoding speeds up generation by guessing several tokens ahead cheaply and then verifying them in one pass with the real model -- if the guesses are right you got several tokens for the price of one, and if they are wrong you throw them away and lose a little time. The draft depth is how many tokens you guess. Set it too low and you leave speed on the table; set it too high and you spend most of your time discarding wrong guesses.

Today that depth is a fixed number the user picks once. The proposal makes it a controller: start at a floor and let the engine raise or lower the depth based on how well its guesses are landing. The author's benchmarks on a Qwen3.8-27B model quantized to 8 bits, running on two Radeon AI PRO R9700 cards, show the payoff is workload-dependent in a way that is genuinely instructive. On coding, fixed depth 2 gives 67.2 tokens per second, fixed depth 3 gives 78.8, and adaptive starting from a floor of 2 gives 86.4. On prose, the same four configurations land at 53.3, 56.4, 54.4 and 54.8 -- effectively flat. On harder prose, flatter still.

That split is the whole story of speculative decoding in one table. Code is repetitive and structurally constrained, so a cheap draft model guesses long runs correctly and deeper speculation pays. Prose is genuinely less predictable, the drafts get rejected, and no amount of adaptive depth manufactures throughput that the token distribution will not support. Autocomplete works well on boilerplate and poorly on an argument, for exactly the same reason.

Alongside all of this, an independent practitioner published a detailed benchmark of the same model on a single consumer RTX 3090 that is the most useful artifact of the three. It reports 131,072 tokens of usable context with vision enabled, verified by actually filling it, and 63.7 tokens per second sustained decode at 380 watts. It also identifies a concrete fix for a vision crash -- setting the CUDA compute type to fp32, which measured 66.11 tokens per second with the fix against 65.28 without, meaning the fix is effectively free. Its myth-busting section is the part worth reading twice: on that card a draft depth of 2 beats 3, lowering the context size buys no meaningful speed, temperature mainly changes draft acceptance rather than answer quality, and reasoning mode helps only at the edge of the model's capability. The writeup also notes that Qwen3.8-27B is a hybrid architecture rather than a plain transformer, with only about one layer in four keeping a KV cache -- which is most of why it fits on a 24-gigabyte card at all, and connects to what we covered when that model shipped.

The caveat: the adaptive-drafting numbers come from a single contributor's benchmark table on an unmerged pull request, on one hardware configuration, and have not been independently reproduced. The 3090 figures are one person's careful measurements on one card. Both are worth more than a vendor claim and less than a controlled study.

Primary source, verified: read the paper →

Ground Truth. (2026, August 17). llama.cpp tagged v0.1.0 after ten thousand build numbers. Ground Truth. https://groundtruth.day/news/llama-cpp-tagged-v0-1-0-after-ten-thousand-build-numbers.html

@misc{groundtruth:llama-cpp-tagged-v0-1-0-after-ten-thousand-build-numbers,
  title  = {llama.cpp tagged v0.1.0 after ten thousand build numbers},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {aug},
  url    = {https://groundtruth.day/news/llama-cpp-tagged-v0-1-0-after-ten-thousand-build-numbers.html}
}

Topics: local-inference · open-source · llama-cpp · speculative-decoding · developer-tools