Ollama in 13 posts, never with a version: a measurement

A report that says "Ollama manages 4 tokens per second on this card" gives a number with no reference point as long as the version is missing. We looked at how that holds up in our own texts and on our own servers. The result sits with us, not with the project.

Version record, briefly: A version record names, for a runtime such as Ollama or vLLM, the installed version, the host and the date of the measurement. It belongs with every measured value because both projects publish new versions every few days, and throughput, model support and security status can change between two of them. Without it, a number can later neither be repeated nor matched to a vulnerability report.

What our own posts say

The blog's content tree was searched on 4 November 2026 for "Ollama". 13 posts since 1 February 2026 mention it, plus two older ones from 2024 and 2025 that we do not count. This post is the 14th. Not one of the 13 names an Ollama version.

Mostly Ollama sits in a list, such as "vLLM, Ollama" as options for hosting your own models. Three posts get more specific, and all three describe somebody else's setup:

The test of the Asus Ascent QN10 quotes a statement that Ollama and LM Studio run on the CPU only on Snapdragon X(2) Elite. That is the reviewer's claim in Alex Ziskind's video of 20 Sep 2026 (video); we did not measure the device ourselves. The quote gives no Ollama version.
The post on Strata on an RX 6800 reports that the author of a third-party self-experiment landed at 3 to 4 tokens per second with Ollama in August. The version is missing there too.
The post on the Violoop agent names Ollama as the reference in a vendor comparison, again without a version.

What the three share: we place other people's measurements, and other people's measurements rarely arrive with a version.

The check on our fleet

The search ran over SSH on 4 November 2026 and changed nothing on any machine: binaries, container images, running services. This is our own check, summarised here; the raw output is not part of the post.

Host (role)	Ollama found on 04 Nov 2026	What computes there
Gateway, search, RAG	no binary, no container	LiteLLM routing
Production inference, 4 cards	no binary, no container	vLLM 0.32.0, read inside the container
Embedding and reranking	no binary	vLLM 0.30.0, read inside two containers
Agent and build host	no binary	no inference service
Mail gateway, company network	no binary, no container	no inference
Log and alert host	no binary	no inference

Our own measurement, unit: installations found per host, as of 4 Nov 2026. None of the six hosts runs Ollama. How our stack is built without it is in the post on our own AI stack with LiteLLM and vLLM.

As a side result, two vLLM versions run in the same house: 0.32.0 on the big machine, 0.30.0 on the small services. We read the version each container reports itself and ignored the image label. A vulnerability report with a lower bound can therefore only be answered per container.

How fast the projects ship

These numbers come from the projects' GitHub API, queried on 4 November 2026. We only counted; we did not measure the software itself.

Project	Window	Stable versions	Pre-releases	Newest
Ollama (MIT licence)	06 Aug to 04 Nov 2026	34	2	v0.40.14 of 03 Nov 2026
vLLM	06 Aug to 04 Nov 2026	7	1 release candidate (v0.33.0rc3, 02 Nov 2026)	v0.32.0 of 18 Oct 2026

On counting: the API does not flag vLLM's release candidate as a pre-release, so we took it out by its name. For Ollama the average gap between two stable versions is 2.6 days, and the longest is just under nine days (5 Sep to 14 Sep 2026, v0.34.0 to v0.34.1). The v0.40.14 release ships 17 files, among them packages for Windows (x86-64 and ARM64), Linux with ROCm for AMD, and MLX variants.

Another detail from the list: version numbers do not follow the calendar. v0.40.0 appeared on 25 Sep 2026, v0.35.0 only on 28 Sep and v0.35.1 on 29 Sep. Reading "higher number = newer release" goes wrong here. That is one more reason to write the date next to the number.

One open request that the Strata post points to, for context: Ollama issue #18071 ("Need to have qwen3.8-flash-next on Ollama cloud") has been open since 27 Aug 2026 and had one comment on 4 Nov 2026, from 1 Oct, asking whether anything was happening. The issue carries the labels "cloud" and "model", but we saw no reply or commitment from the project in the issue itself. It is an example of model support that can change between two versions.

These are recommendations and not a report on procedures already in force at our company.

Every measured value carries host, operating system, version and date in the same line. For Ollama, ollama --version gives the version; read it in the same terminal as the measurement.
For containers, the version the running container reports is what counts. The image label is only a name.
Where you cannot measure yourself, the text says the number comes from foreign hardware and which version the other party named. If none was named, the text says that as well.
A vulnerability report with a version lower bound is checked per container, because services in the same house rarely share the same level.

Our post vLLM v0.33.0 and llama.cpp b12033 asks a different question, namely when a version exists at all (tag, release, image); this one is about which version ran on our machines and what we failed to write down so far. We do not change our older posts retroactively; the versions were not measured at the time and cannot be added now. More posts on running local models are collected under the topic AI in production. Companies that run their own AI stack and want the versions documented cleanly will find the setup described under Corporate LLM.