Ollama :cloud Model Tags in 2026: What They Do to Your GPU (Hint: Nothing)
TL;DR: Ollama’s -cloud model tags (like gpt-oss:120b-cloud) run inference on Ollama’s datacenter servers, not on the GPU sitting in your case. Your prompts leave your machine, your card stays at 0%, and if you didn’t notice the suffix you’re using a hosted API while thinking you’re “running local.” Spotting them is a two-second check; replacing them is one ollama pull.
What you’ll be able to do after this:
- Tell in one glance whether a model is actually running on your GPU or being shipped to Ollama’s cloud
- Swap every major
-cloudmodel for a genuinely local equivalent that fits a 24GB card - Lock your setup down so inference can’t silently route off-box
Honest take: Cloud tags aren’t a scam — they’re a convenient way to touch a 671B model you can’t fit. But if privacy or “no monthly bill” is why you set up Ollama, a
-cloudtag quietly defeats both. Checkollama ps: a real local model shows GB of size and100% GPU; a cloud model doesn’t.
What a -cloud tag actually is
Ollama shipped cloud models as a preview in 2026, and they behave almost exactly like local ones — which is the whole problem. When you run a cloud model, Ollama pulls only a tiny manifest (just metadata, so the “download” finishes in seconds because there’s nothing to download), registers it with your local instance, and from then on ollama run, ollama list, and the /api/chat endpoint all work normally.
The catch is where the compute happens. Per Ollama’s own docs, cloud models “use inference compute on ollama.com” — the tokens are generated on datacenter hardware and streamed back to you. Your local daemon is just a relay. That’s why the tell-tale is the suffix: cloud model tags end in -cloud (for example gpt-oss:120b-cloud), or carry a cloud icon on the model page.
This is genuinely useful when you want it. A 24GB card can’t hold DeepSeek V3.1 671B at any usable quant — we did that math in the Qwen3-Coder 480B hardware guide and the Kimi K2.7 guide, and the answer is always “multi-GPU or cloud.” Cloud tags let you call those models from the same CLI and API you already script against. The failure mode is using one by accident and assuming your GPU did the work.
How to spot a cloud model in two seconds
Three checks, fastest first.
1. Read the tag. Run ollama list and look at the NAME column. Anything ending in -cloud runs remotely:
ollama list
# NAME ID SIZE MODIFIED
# qwen3:30b a1b2c3d4e5f6 18 GB 2 days ago ← local
# gpt-oss:120b-cloud 000000000000 0 B 5 minutes ago ← cloud
A cloud entry weighs essentially nothing on disk — there’s no weights file, just the manifest.
2. Run ollama ps while a model is loaded. This is the same command we lean on in the Ollama-not-using-GPU fix and the tokens-per-second guide, and it’s the honest arbiter. A real local model looks like this:
ollama ps
# NAME ID SIZE PROCESSOR CONTEXT UNTIL
# gemma4:latest c6eb396dbd59 9.6 GB 100% GPU 131072 2 minutes from now
9.6 GB resident, 100% GPU. A cloud model has no local footprint to report — there’s no multi-GB weight block sitting on your card, because your card isn’t doing the inference.
3. The nvidia-smi test — the one that settles arguments. Open two terminals. In one, watch the GPU:
watch -n 0.5 nvidia-smi
In the other, send a long prompt. During a genuine local run you’ll see GPU utilization jump to 80–95% and power draw climb (an RTX 3090 pulls ~285–350W under load). During a cloud run the GPU never moves — 0% utilization, idle power, because the work is happening a thousand miles away. If you ever wonder “is this actually local?”, this test answers it in one prompt.
The full cloud lineup (and the local model that replaces each)
As of Ollama v0.31.1 (July 2026), the preview cloud catalog is the set of models too big for consumer VRAM. Here’s each one with a local stand-in that runs on a single 24GB GPU:
| Cloud model | Why it’s cloud-only | Run this locally instead |
|---|---|---|
gpt-oss:120b-cloud | 120B, ~65GB+ at usable quant | gpt-oss:20b — fits 16GB, our GPT-OSS 20B guide clocks ~225 tok/s on a 4090 |
qwen3-coder:480b-cloud | 480B MoE, ~180GB+ | qwen3-coder-next Q4_K_M on 24GB — hardware guide |
deepseek-v3.1:671b-cloud | 671B MoE, 200GB+ | Qwen3.6 35B-A3B or Gemma 4 31B on 24GB (see the shootout) |
kimi-k2:1t-cloud | 1T MoE, ~325GB at 2-bit | No single-GPU path — Kimi K2.7 guide explains why |
glm-4.6:cloud | 355B+ MoE | Codestral 2 22B or Qwen3.6 35B-A3B for coding on 24GB |
qwen3-vl:235b-cloud | 235B vision-language | Gemma 4 vision tiers on 16–24GB |
The pattern holds across the board: the reasoning-and-coding work most home labbers actually do fits on a used RTX 3090 (24GB, 936 GB/s, ~95 tok/s on a 7B, roughly $1,050 in July 2026) or a new RTX 4090. The trillion-parameter models genuinely need the cloud — but you rarely need them for a coding autocomplete loop. For a fuller breakdown of when local wins, see why local LLMs got good in 2026.
What it costs (and why “local” was supposed to be free)
Cloud tags aren’t a flat-rate API. Ollama Cloud runs three tiers in 2026: Free ($0), Pro (~$20/month), and a Max tier (~$100/month). Crucially, the free tier is metered by GPU time, not tokens — session limits reset every 5 hours and weekly limits reset every 7 days, and heavier models (a 671B burns your quota far faster than a 20B) drain it quicker. Free allows one concurrent model; Pro three; Max ten.
Compare that to the reason most people build a home rig in the first place. A used RTX 3090 at ~$1,050 draws about 285–350W under load; at $0.12/kWh that’s roughly $0.04/hour of electricity, and after the card is amortized the marginal cost of a token is basically the power bill. We ran the full buy-vs-rent numbers in RunPod vs local GPU: local wins decisively once you’re generating meaningful volume daily. A -cloud tag quietly opts you back into a metered plan you may have bought hardware specifically to escape.
If you genuinely need occasional access to a 671B model, that’s a fine use of the free tier — or of a RunPod pod where you control the whole box. Just do it on purpose.
The privacy angle: your prompts leave the machine
This is the part that bites self-hosters. When Ollama runs a model locally, nothing leaves your computer — zero network requests for the inference itself. That’s the entire premise behind our local AI privacy audit.
A -cloud model breaks that premise. Your prompt and the response are transmitted to Ollama’s servers to be processed. To Ollama’s credit, their policy states cloud prompts are handled transiently, aren’t used for training, and aren’t stored beyond the time needed to serve the request. But “handled transiently on someone else’s server” is a categorically different privacy posture than “never left the room.” If you’re feeding a model proprietary code, client data, or anything you self-host because it’s sensitive, a cloud tag is exactly the leak you were trying to avoid.
The config that keeps every inference local (the honest version)
Here’s where a lot of guides give bad advice. You’ll see OLLAMA_HOST=127.0.0.1 recommended as the “airgap” fix. It isn’t — OLLAMA_HOST controls what address your Ollama server binds to (who can reach it), not whether outbound cloud calls happen. Binding to localhost is good hygiene, but it does nothing to stop a -cloud model from phoning home.
The setup that actually guarantees local-only inference is three layers:
1. Don’t pull -cloud models. The simplest guarantee. If it’s not in ollama list, it can’t run. Audit with:
ollama list | grep cloud
# (no output = you're clean)
2. Don’t sign in. Cloud models require authentication. If you never run ollama signin and never set OLLAMA_API_KEY, a cloud model errors out instead of silently running: Error: you need to be signed in to Ollama to run Cloud models. That error is a feature — it’s the tripwire.
3. For a hard guarantee, block it at the network. If the machine must never leak a prompt, don’t rely on discipline — enforce it. Bind the server locally and confirm nothing else is listening:
export OLLAMA_HOST=127.0.0.1:11434 # inbound: local clients only
sudo lsof -i -P | grep ollama # should show ONLY 127.0.0.1:11434
Then block outbound traffic to ollama.com at your firewall, or run the box fully offline during inference. On a truly air-gapped host, cloud tags simply can’t function — which is the point.
Verify the whole thing end to end with the nvidia-smi test above: load your model, send a prompt, and watch the GPU pin to 80–95%. If the card lights up, the tokens are yours.
FAQ
Does pulling a -cloud model use my GPU at all?
No. Inference runs entirely on Ollama’s servers; your local GPU stays at 0% utilization. Your machine only relays the request and the response.
How do I tell if a model I already have is cloud or local?
Run ollama list. Cloud models end in -cloud and show ~0 B size (no weights on disk). Confirm with ollama ps (a local model shows GB of size and 100% GPU) or the nvidia-smi test.
Are cloud tags free? There’s a Free tier ($0), but it’s metered by GPU time with session limits that reset every 5 hours and weekly limits every 7 days. Pro is ~$20/month and a Max tier is ~$100/month. Heavy models drain the free quota fast.
Is my data safe with cloud models? Ollama says cloud prompts are processed transiently, not trained on, and not stored beyond the request. But the prompt does leave your machine — a different privacy posture than local inference, where nothing is transmitted at all.
What’s the fastest way to guarantee local-only inference?
Never sign in and never pull -cloud models. Without authentication, cloud models refuse to run. For a hard guarantee, block outbound access to ollama.com at your firewall.
Can I use a cloud model on purpose for a 671B I can’t fit?
Absolutely — that’s the legitimate use. ollama signin, then ollama run deepseek-v3.1:671b-cloud. Just know it’s a hosted API, not local compute, and budget for the metered plan.
Sources
- Ollama Cloud documentation — how cloud models work,
ollama signin, inference on ollama.com - Ollama Cloud models blog — preview announcement and model list
- Ollama API authentication docs —
ollama signin,OLLAMA_API_KEY,-cloudtag examples - Ollama cloud models search — current cloud catalog (gpt-oss, deepseek-v3.1, qwen3-coder, kimi-k2, glm-4.6, qwen3-vl)
- Ollama Cloud pricing — Free/Pro/Max tiers, GPU-time metering, session and weekly limits
- Ollama privacy policy — transient processing, no training, data-retention statement
- Ollama version history — v0.31.1 (July 2026) current release
Prices and plan details as of July 2026 and move frequently — verify current pricing on ollama.com before committing. For AI coding tool backends, see aicoderscope.com; for self-hosting setup guides, aifoss.dev.
Recommended Gear
- RTX 3090 — 24GB, 936 GB/s, ~95 tok/s on a 7B; the value king for genuinely local inference under 24GB
- RTX 4090 — faster decode (~135 tok/s on a 7B) if you want headroom without leaving your machine
Was this article helpful?
Thanks for the feedback — it helps improve future articles.
Need hands-on help?
I offer 1-on-1 technical consulting for local AI setup, GPU selection, and AI coding tool configuration — same topics covered on this site.
Book a session — $49 / hour →