Eighteen months of unsecured Ollama servers, reconstructed from the commit history of three scanners that publish what they find along with hundreds of mysterious servers that aren't as they appear.
Thousands of real machines have Ollama left open on the internet. Some of them, for years... we've got the receipts. This is what they are running, where, and for how long.
The buttons above switch to other slices: the share running an uncensored model, a 30B-plus model, or four-bit weights. Each frame counts a five-month window.
Each country's share of the exposed servers, stacked to 100%. Reading it as a share rather than a raw count cancels out the swings in how much the scanners covered at any moment, so what's left is the composition.
Servers grouped by the lab that trained the base model, not the model name, so Qwen stays one line as it moves from 2.5 to 3 to 3.6. A server counts once per vendor it hosts, so shares sum past 100%.
Each model as a share of the exposed servers over time, so the survey's changing coverage cancels out. Tags collapsed to the base name; pick any model to add or drop it.
Model sizes come from the tag when it states one, like
gpt-oss:120b. A :latest tag is resolved against ollama.com by
its manifest digest: llama3.2:latest shares a digest with
llama3.2:3b-instruct-q4_K_M, which names both the parameter count and the
quantisation.
Shown as a share of installs whose size is known. Coverage is under the chart.
How hard the weights are compressed. q4 is Ollama's
default for most models and dominates the chart. The deviations from it are the
interesting part.
Servers grouped by the /24 they sit in, a rough stand-in for one operator. Each column is a block size. The bar spans the middle half of lifespans, the line is the median, the whisker reaches the 10th and 90th percentiles. Lifespan rises with block size up to five servers, then falls.
Each circle is a day a model's server count jumped further than its own normal churn explains. Up is a block coming online, down is a block going offline. Height is how many robust deviations (MAD) the jump was, circle area is how many servers moved at once. Hover for the model and where the jump sits against its normal daily range.
Every server's lifespan, from its first sighting to its last. Most are gone within a week, but a stubborn tail stays reachable for months, and hundreds for more than a year.
Every sighting of a host, across the git scanners, FOFA, Shodan and our own re-probe, is a sample of how long it stayed reachable. Fit a survival curve on the window where sampling was dense and you get the chance a server is still up a given number of days after it first appears. Most exposures are gone in days. A small core persists for months. The shaded band is the model's confidence.
A single scanner only ever catches a slice of the live population on any given day, so the raw count understates it and jumps around with coverage. Feeding every host's sightings and its later liveness check into the survival model gives a smoother estimate of how many servers were probably alive each month. This is a modelled estimate from sampling, not a headcount, so read the shape rather than the exact number. The band is a 300-run bootstrap that also varies how long the persistent core is assumed to last, which is why it fans out in recent months where the estimate depends most on that assumption.
Each dot is a model. Across is how many hosts run it; up is the average library size of those hosts, meaning how many models they run in total.
The popular defaults sit on minimal single-purpose boxes, while cloud-proxied and specialised models ride on big multi-model rigs. Popularity anti-correlates with library size.
Circle size is the model's parameter count. Coloured by lab, with uncensored and abliterated models pulled out in red as a behaviour of their own; the dashed line is the typical library.
Every server placed by the first two octets of its IPv4 address. The X-Axis is the first octet, the Y-Axis the second, circle area the number of servers in that /16 that week. Pick a lab and the fill shows each neighbourhood's share running its models. Whole regions of the address space favour one lab.
One of the three scanners, OllamaSpider, scrapes Shodan and sweeps up hundreds of live hosts that respond to the Ollama API unlike a normal server. Each reports some subset of one small, fixed pool of old models, sizes constant to the byte, a handful of rotating version strings, and chat replies drawn from a small phrase bank.
In a fresh 4,407-host snapshot they are about ⅓ of everything answering as Ollama. The other ⅔ are ordinary real servers.
What causes the third that isn't, we cannot say. It could be a coordinated deployment, a honeypot, or a badly broken configuration copied onto thousands of machines and forgotten. This chapter lays out what was observed and stops there.
OllamaSpider scrapes Shodan and grabs endpoints on ports that were never Ollama. The other two feeds verify their hosts and do not carry this. Open Ollama servers are not mostly fake, and there are thousands of real ones. This is a claim about a specific set of hosts in a specific feed.
These hosts are live and responding. Something on each one answers
the Ollama API with a model list, a version string, a chat reply. All of them advertise
some subset of one small, fixed pool of old, unremarkable models
(llama2:latest, llama3:latest, openchat:7b,
qwen2.5:1.5b and a couple of others), frozen since early 2024, each at a
size constant to the byte wherever it appears.
Ask one a question and the reply reads like filler from a small phrase bank rather than a model's answer. Ask its version and you get one of four fixed strings. Ask a model for its details and the response is empty, yet the running-model endpoint reports every one of them loaded and running at once, which no real host does.
Ask it to run a model that does not exist and it answers anyway; tell it to pull or delete a model and it reports success while nothing changes. Every command fails the same way: it always says yes. It is hundreds of hosts actively answering, and answering the same narrow way.
The sharpest test does not come from the scanners. In a fresh snapshot
of 4,407 hosts that answer as Ollama, ollama version splits the
population in two. Real servers report one of 172 different versions in a natural
long tail. The responders return one of just four fixed strings, which stand as a tight
near-equal band far above every real version. The four are in
orange.
Hosts report a subset of the same handful of models, at sizes constant to the byte. The most common single catalogue in the feed, reported in full by tens of thousands of them, is:
Each model's size is constant to the byte, where genuinely pulled models vary by quantisation and version:
Spread across ports that mostly are not Ollama's. The same machine appears once per port:
Everything else here comes from commit logs. This does not. The project owner sent one instruction with a single correct answer to every OllamaSpider host advertising a given model and read the replies. A real model answers. A fake one replies with filler that quotes the prompt back.
Three runs, two test questions, three models from the fixed catalogue:
Line up all three probe captures and the replies give themselves away. Every one is an opener, then the word Regarding with your prompt quoted back, then a filler clause, then a closing question, each drawn from a tiny fixed pool.
Seven
openers, eight middles, five closers make possible sentences,
assembled by pre[rand] + your text + mid[rand] + post[rand]. This is string
concatenation, not a model.
A real Ollama host reports one version. These return four fixed strings
in near-equal proportion, from 0.1.0 to 0.6.3. It is the same
rotate-a-fixed-list trick as the chat replies, applied to the version field.
Ollama listens on 11434. These hosts mostly do not. They answer on ports assigned to databases, service meshes and Windows remote management. This is the port mix of these responders, not of open Ollama servers in general.
ollama.com publishes the real blob size of every library tag, so a reported size can be checked against an outside fact. Each row is one host: the small dot is the tag's real published size, the large dot the size it reports for that tag.
Probing live hosts directly turned up a separate oddity. Hundreds of
real, working Ollama boxes advertise a closed-weights model that cannot exist on
Ollama: gpt-4, gpt-4o, claude-3-opus, and newer
names like claude-opus-4.8, gpt-5.5 and
gemini-3.5-flash. Of the live hosts we reached, 726 carried at least one
of these.
They never appear alone. Every one of those 726 also runs genuine open
models, usually Qwen, DeepSeek, or an abliterated Huihui build, so these are not empty
decoys but real servers with fake names planted among the real ones. And the fake names
carry no hf.co/ prefix the way the genuine models on the same boxes do, so
they are made on the machine with ollama cp or a Modelfile, not pulled from
Hugging Face. There is no upstream repo claiming to be GPT-4. It is local theatre.
Two very different levels of effort sit behind it. On 708 hosts the
premium name points at a real but tiny 638 MB, 1.1B, Q4_0 llama blob, a small
model wearing a big label. About 500 of them share one byte-identical blob, so this is a
single artifact copied across hundreds of machines, not hundreds of separate pranks. A
smaller, more deliberate seven fabricate the manifest outright: zero-byte entries whose
parameter_size is the literal string synthetic, listing
current premium models they demonstrably do not hold, each sitting beside per-host
gateway-diagnostic entries. That tier looks like a catalogue kept
up to date on purpose, or a scanner planting its own write-test marker. We cannot tell
which from here.
One detail gives the game away: which names get faked. Whenever a real
model actually sits behind the fake label, the label is a 2024 trophy, almost always
gpt-4, gpt-4o or claude-3-opus. The current
flagships, claude-opus-4.8 or gpt-5.5, turn up only as the
empty synthetic manifests, never with weights behind them. So nobody parks a cheap model
behind a current name and invites you to test it. The impersonation is frozen where it
started, reaching for models that were the state of the art when these boxes were set up
and have since been passed by weights anyone can download for free. Even the successful
version of this lie now points at something a small open model would beat.
The fake names are not the only small thing on these boxes. Setting the fakes aside and measuring the real models, hosts carrying a premium name run noticeably smaller models than clean hosts: a median of 1.9 GB against 4.7 GB, with 42% under a gigabyte versus 16%. They also cluster on old Ollama versions, a fifth of them on 0.30.2 alone, where clean hosts spread across many including current releases. So the premium label tends to sit on an older, lighter, less maintained box.
Unknown, and the data does not let us pretend otherwise. What is established is narrow. Within OllamaSpider's feed, hundreds of live hosts answer the Ollama API with a frozen set of old models, sizes that do not match the published blobs, rotating version strings, and phrase-bank replies.
The behaviour matches no published
honeypot, tarpit or mock-server project, checked against GitHub, the web, and the
honeypot literature. The closest, funnypot, echoes the model name rather
than the prompt and runs on a single host.
The causes are all guesses and range widely. A honeypot, though the bait is worthless. Real servers that refuse outside probes, and we watched one genuine box do exactly that. A coordinated deployment. Or a badly misconfigured setup copied onto thousands of machines and forgotten. We cannot choose between them from here. Narrowing it would take infrastructure work: reverse DNS, ASN and subnet clustering, and whether one operator's fingerprints recur.
The raw feed behind Chapter 1. Two scanners contribute: one FOFA-based, six countries only, and one accumulating list. A third, OllamaSpider, is excluded here. Only 15.6% of what it reports sits on Ollama's port against about 47% for the other two, it sprawls across 7,911 ports including CouchDB and Consul, and half its servers fall in the responder blocks from Chapter 2.
Total deduplicates a server seen by both.
Model tags ending -cloud are dropped throughout, since those proxy to
Ollama's hosted service and commit no weights, disk or GPU on the reporting machine. They
are 0.27% of installs but 15% of everything at 90B parameters and above.
Collapse duplicates also folds together groups of 50+ addresses reporting the same model list on the same day.