Ollama Cloud pricing vs self-hosted GPU: which setup makes sense?

“Ollama in the cloud” can now mean two different things.

You can use Ollama Cloud, where Ollama runs selected models on infrastructure it manages. Or you can install Ollama yourself on a rented cloud GPU and run the same kind of local Ollama server you would run on a workstation.

The interface can look almost identical. The infrastructure is not.

With Ollama Cloud, Ollama chooses and operates the hardware. You consume a hosted model through the Ollama CLI or API.

With a self-hosted GPU, you choose the hardware, install Ollama, download the model, decide how much context to allocate, and control when the GPU runs.

A simple way to choose is:

Neither approach is inherently better.

‍

‍

They solve different operational problems.

What is Ollama Cloud?

Ollama Cloud is Ollama's hosted inference service.

Cloud models still appear through the familiar Ollama interface, but their inference is offloaded to Ollama's infrastructure rather than your own GPU. You can run one through the CLI with a cloud-tagged model such as:

ollama run gpt-oss:120b-cloud

or call Ollama's hosted API directly. Ollama describes cloud models as a way to run larger models that would not fit on a personal computer while continuing to use the same local tools and API conventions.

That makes Ollama Cloud fundamentally different from putting Ollama on a cloud VM.

With Ollama Cloud, the model is remote.

With self-hosted Ollama on a cloud GPU, the machine is remote, but Ollama and the model are running on that machine under your control.

That distinction matters for cost, model availability, data flow, hardware control, and troubleshooting.

How much does Ollama Cloud cost?

As of August 2026, Ollama lists these individual plans:

New Max subscriptions are currently paused while Ollama adds capacity. Team plans start at five seats, so the minimum seat charge is $125 per month.

‍

‍

There is an important detail behind those numbers.

Ollama does not describe individual plan limits as a fixed number of tokens. Usage depends on the model and the amount of input, cached input, and output processed. Different cloud models consume different amounts of the allowance because they require different amounts of compute.

That makes an exact “$20 buys X million tokens” comparison impossible from the subscription price alone.

Ollama Cloud pricing and GPU rental aren't directly comparable

A hosted inference subscription and a rented GPU charge you for different things.

Ollama Cloud sells access to managed model inference.

A cloud GPU sells you a running machine.

On Compute with Hivenet, an RTX 5090 currently starts at €0.75 per GPU-hour, billed per second while the instance runs.

That means self-hosted GPU cost is easy to calculate:

But that table tells you nothing about how many useful tokens those hours produce.

A small model serving continuous batched traffic can produce far more work per GPU-hour than a large reasoning model receiving occasional requests.

Ollama Cloud has the opposite problem for comparison: the subscription price is clear, but individual plan allowances are intentionally expressed as usage levels rather than a universal token quota.

So there is no responsible universal break-even point between “Ollama Pro at $20” and “rent a GPU.”

You need the workload.

When Ollama Cloud makes more sense

Ollama Cloud is the simpler answer when you want the model rather than the infrastructure.

It is especially useful when:

• the model is too large for hardware you want to operate yourself
• your usage fits comfortably inside the plan limits
• you want to use the same Ollama CLI without managing CUDA or Linux
• you want large models for occasional requests
• you do not care which specific GPU serves the model
• you do not need to pin a particular local checkpoint or runtime configuration

Ollama's current cloud catalog includes models that are substantially larger than typical desktop-GPU workloads, and cloud models are automatically run at their full supported context length.

For experimentation, that is convenient.

You can concentrate on whether the model works for the task.

When self-hosted Ollama makes more sense

Self-hosting becomes useful when the infrastructure itself matters.

You choose:

• the exact GPU
• how much VRAM is available
• the model build
• whether the model stays loaded
• context length
• which ports exist
• how the API is exposed
• whether Ollama's cloud features are enabled
• when the server starts and stops

That makes self-hosted Ollama particularly useful for development environments, private experiments, internal model services, repeatable benchmarks, and workloads where you want to know exactly what machine produced the result.

You are also responsible for that machine.

Someone has to install the software, monitor disk and VRAM, manage network access, and update the runtime.

Control and responsibility arrive together.

Does self-hosted Ollama send prompts to Ollama?

For models running locally in Ollama, Ollama says it does not receive your prompts or responses.

In this context, “local” means local to the Ollama server. If you install Ollama on a Hivenet VM, the model is local to that VM even though the VM itself is in a data center rather than under your desk.

When you use Ollama Cloud, prompts and responses are processed by Ollama's hosted service. Ollama says that content is not stored, logged, or used for training.

If you want to prevent an Ollama installation from using Ollama Cloud features at all, Ollama provides:

OLLAMA_NO_CLOUD=1

or the equivalent disable_ollama_cloud server setting. This also disables Ollama's hosted web-search functionality.

That is a useful option for environments where you want the runtime to stay strictly on your own instance.

What GPU does Ollama need?

There is no single Ollama GPU requirement.

Ollama is the runtime. The model determines most of the memory requirement.

A small 4B or 8B model may fit easily on modest hardware.

A quantized 20B or 30B model can fit comfortably within a 32GB GPU.

A 70B model requires far more memory and may need multiple GPUs, CPU offloading, or a larger-memory accelerator.

Ollama officially supports NVIDIA RTX 50-series GPUs, including the RTX 5090, and currently lists NVIDIA driver version 531 or newer among its NVIDIA requirements.

If model sizing is the part you're unsure about, start with our RTX 5090 VRAM guide.

For larger models, the Llama 3.3 70B GPU requirements guide shows why 70B moves beyond one 32GB card.

Ollama changes context length according to available VRAM

This is one of the most useful pieces of Ollama behavior to understand.

Ollama currently chooses a default context length based on available VRAM:

Ollama recommends at least 64K for context-heavy workloads such as coding agents and web search, while warning that increasing context increases memory use.

‍

‍

An RTX 5090 has 32GB of VRAM, so Ollama currently falls into the 32K default context tier on a single card.

That is a sensible starting point.

Do not increase context to 128K merely because the model advertises a 128K window.

The additional KV cache has to live somewhere.

A model can fit while its maximum context does not

Suppose a model consumes 14GB of a 32GB card.

That appears to leave 18GB.

That remaining memory has to cover the runtime and context cache.

A 128K context can consume far more KV-cache memory than a 32K one. Parallel requests increase the requirement again.

This is why “the model file is 14GB” and “the model needs 14GB of VRAM” are not equivalent statements.

For Ollama specifically, use:

ollama ps

to see how the running model is placed.

Ollama reports the active context and whether the model is running entirely on the GPU, entirely on the CPU, or split between them. Its documentation recommends keeping the model fully on the GPU for best performance where possible.

A good one-GPU Ollama example

For the practical setup, we will use:

gpt-oss:20b

Ollama's current model package is approximately 14GB and has a 128K model context window. Ollama says the MXFP4 model is designed to run on systems with as little as 16GB of memory.

That makes it a comfortable example for a 32GB RTX 5090.

We are not using it because it is the only sensible Ollama model.

We are using it because it leaves enough room to demonstrate the deployment without choosing a tiny model that tells us little about GPU memory.

Step 1: launch an RTX 5090 VM

Create a virtual machine in Compute with Hivenet.

For this tutorial, use:

1. 1 × RTX 5090
2. Ubuntu
3. SSH access
4. enough storage for the models you intend to pull

Each RTX 5090 provides 32GB of GDDR7 VRAM. Hivenet GPU configurations can scale beyond one card when your workload needs more capacity.

The Compute quickstart covers VM creation and SSH access.

Once connected, check the GPU:

nvidia-smi

You should see the RTX 5090 before installing Ollama.

Step 2: install Ollama

Ollama's current Linux installer is:

curl -fsSL https://ollama.com/install.sh | sh

The standard Linux installation also sets Ollama up to run as a service.

Check it:

ollama -v

Then check the service:

sudo systemctl status ollama

If it is not running:

sudo systemctl start ollama

Step 3: run a model

Pull and start the 20B model:

ollama run gpt-oss:20b

On first use, Ollama downloads the model.

After loading, enter a simple prompt:

Explain why GPU VRAM limits the size of a local language model.

Once you have a response, leave the interactive session with:

/bye

The Ollama server continues running.

Step 4: make sure Ollama is actually using the GPU

Run:

ollama ps

You want the PROCESSOR column to show:

100% GPU

Ollama uses this field to show whether a model is fully GPU-resident, fully on CPU, or split across CPU and GPU memory.

Also check:

nvidia-smi

while the model is loaded.

You should see Ollama consuming GPU memory.

If ollama ps shows a CPU/GPU split, the model or configured context is larger than the GPU can hold comfortably.

Reducing context or choosing a smaller model is usually better for performance than silently pushing a large portion of inference onto the CPU.

Step 5: call Ollama through its native API

Ollama serves its API locally on:

http://localhost:11434

by default.

Test it:

curl http://localhost:11434/api/chat \
 -d '{
   "model": "gpt-oss:20b",
   "messages": [
     {
       "role": "user",
       "content": "Give me three practical uses for a 20B open-weight model."
     }
   ],
   "stream": false
 }'

You now have a model API running on the RTX 5090.

No separate web application is required.

Step 6: use the OpenAI-compatible API

Ollama also supports parts of the OpenAI API.

That makes it easier to point software already written for an OpenAI-style endpoint at a self-hosted Ollama server.

Install the client:

pip install --upgrade openai

Then:

from openai import OpenAI

client = OpenAI(
   base_url="http://localhost:11434/v1/",
   api_key="ollama",
)

response = client.chat.completions.create(
   model="gpt-oss:20b",
   messages=[
       {
           "role": "user",
           "content": "Explain tensor parallelism in plain English."
       }
   ],
)

print(response.choices[0].message.content)

Ollama documents /v1/chat/completions, /v1/responses, embeddings, model listing, and other OpenAI-compatible endpoints, although it does not claim complete compatibility with every OpenAI API feature.

That qualification matters when you move an existing application.

Test the features you actually use.

Step 7: connect securely from your own computer

Ollama binds to:

127.0.0.1:11434

by default.

For development, I would keep it that way.

The local Ollama API does not require authentication, so exposing port 11434 directly to the public internet without an authentication layer is a poor default.

Instead, use SSH port forwarding.

On your own computer, take the SSH command Hivenet provides for the instance and add:

-L 11434:localhost:11434

Conceptually:

ssh \
 -L 11434:localhost:11434 \
 <your-normal-hivenet-ssh-target>

Then software on your computer can use:

http://localhost:11434

while the actual Ollama server remains bound to the VM's loopback interface.

That is a cleaner development setup than opening an unauthenticated inference API to the world.

If you need a public API, add a real boundary

For production use, an SSH tunnel is obviously not an application architecture.

If the Ollama service must be reachable by other systems, put an authenticated HTTPS layer in front of it.

Ollama documents exposing its service through reverse proxies such as Nginx and allows changing the bind address through OLLAMA_HOST.

The key point is that:

OLLAMA_HOST=0.0.0.0:11434

makes the service reachable on the network.

It does not add authentication.

Network exposure and access control are separate jobs.

How to increase Ollama's context length

On one 32GB GPU, Ollama currently defaults to 32K context.

If your workload needs more, you can set the server context through:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Ollama specifically recommends at least 64K for coding tools, agents, and web-search-heavy workflows.

If Ollama runs as a Linux systemd service, configure the environment variable through the service rather than starting a second server manually:

sudo systemctl edit ollama.service

Then add:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=64000"

Reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Then check:

ollama ps

Do not assume the larger context fits just because Ollama starts.

Watch GPU placement and VRAM.

Keeping the model loaded can improve response time

By default, Ollama currently keeps a model in memory for five minutes after use.

You can control that through the API's keep_alive parameter.

For example, keep the model loaded:

curl http://localhost:11434/api/generate \
 -d '{
   "model": "gpt-oss:20b",
   "keep_alive": -1
 }'

Or unload immediately after a request:

curl http://localhost:11434/api/generate \
 -d '{
   "model": "gpt-oss:20b",
   "keep_alive": 0
 }'

Keeping the model resident reduces reload delays.

It also means that VRAM remains occupied.

On a machine serving several models, that becomes part of memory planning.

Ollama can run several requests, but VRAM still decides how far you can go

Ollama supports concurrent processing when enough memory is available.

If several models need to be loaded and there is not enough GPU memory, requests can be queued while Ollama unloads idle models and makes room. For GPU inference, Ollama says a new model must fit completely in VRAM to be loaded concurrently with other GPU-resident models.

This is one reason a model that uses almost all 32GB is less flexible than one that uses 14GB.

Unused VRAM can become:

• context
• parallel requests
• another model
• cache
• breathing room for the runtime

The largest model you can load is rarely the same thing as the best model to serve.

Can Ollama use multiple GPUs?

Yes.

Ollama can detect multiple supported GPUs, and its scheduler uses available VRAM when placing models. You can also restrict which NVIDIA GPUs Ollama sees using:

CUDA_VISIBLE_DEVICES

Ollama recommends GPU UUIDs rather than numeric IDs when you need stable device selection.

Multiple GPUs become useful when a model no longer fits on one card.

That is the territory we cover in our Llama 3.3 70B GPU requirements guide.

For serious production serving, however, I would compare Ollama against a serving engine designed specifically around high-throughput inference before deciding that multi-GPU Ollama is your final architecture.

Ollama or vLLM?

Ollama is unusually convenient.

It handles model download, model formats, local serving, hardware placement, a simple CLI, and APIs behind one interface.

That makes it excellent for:

• development
• local and remote experimentation
• internal tools
• individual model endpoints
• testing model families
• applications already built around the Ollama API

vLLM has different priorities.

It is designed around production inference, continuous batching, KV-cache management, distributed serving, and high-throughput OpenAI-compatible endpoints.

We already compare those choices in vLLM vs TGI vs TensorRT-LLM vs Ollama.

The useful question is not which project is “better.”

It is whether you want a convenient model runtime or an inference server optimized around serving throughput.

Ollama Cloud or Hivenet Inference API?

There is another distinction worth making.

Ollama Cloud is a managed model service built around the Ollama interface and model catalog.

Hivenet Inference API is also managed inference, exposed through OpenAI-compatible endpoints.

If your only requirement is “give my application a model API,” both belong in the managed-inference category rather than the rented-GPU category.

If your requirement is:

I want to install Ollama myself, choose my checkpoint, control the machine, and decide when the GPU runs,

then Compute with Hivenet is the relevant product.

That separation keeps the infrastructure decision honest.

Cloud models can disappear; local models are under your control

There is one operational difference that deserves more attention.

Ollama periodically retires cloud-hosted models as its catalog changes. Its documentation explicitly warns that applications relying on retired cloud models may need to be updated. Local models are not affected by those cloud retirements.

That is normal for a managed model service.

Someone has to maintain the catalog.

But it means a hosted model name should be treated as an external dependency.

When you self-host a model file, you control when that checkpoint changes.

The burden also becomes yours: security updates, runtime compatibility, storage, and model upgrades no longer happen because the provider changed the catalog.

Managed services trade some control for maintenance.

Self-hosting trades maintenance for control.

Don't rent a GPU to imitate Ollama Cloud badly

If you want a model for twenty minutes, Ollama Cloud is probably the easier starting point.

Spinning up a GPU VM, configuring Linux, downloading a 20GB checkpoint, securing an API, and tearing the environment down again is infrastructure work.

That work becomes reasonable when you gain something from it:

• fixed hardware
• predictable GPU memory
• custom checkpoints
• private model files
• controlled upgrades
• benchmark repeatability
• long-running internal services
• workload economics that favor your own instance

Otherwise, use the managed service.

The point of self-hosting is control, not proving that you can administer Linux.

Don't pay for an idle GPU either

The inverse mistake is leaving a self-hosted GPU running because the model might be needed later.

At €0.75 per hour, a single RTX 5090 running continuously costs:

24 × €0.75 = €18 per day

and roughly:

30 × €18 = €540 over a 30-day month

before considering any other resources.

Hivenet uses per-second on-demand billing, so intermittent Ollama workloads should take advantage of the ability to stop compute when it is not needed.

A self-hosted endpoint only becomes economical when the usage pattern makes sense.

Which Ollama setup should you choose?

Use Ollama locally on your own hardware when your machine already has enough GPU memory and you want the simplest private setup.

Use Ollama Cloud when you want hosted models without operating a GPU server, particularly when the model is larger than your available hardware.

Use Ollama on a rented GPU when you want the Ollama workflow but also need control over the model, hardware, configuration, data path, or runtime.

Use vLLM on rented GPUs when high-throughput production inference matters more than Ollama's local-first convenience.

Use a managed inference API when operating the serving layer adds no value to what you are building.

That is a more useful distinction than trying to declare one deployment universally cheaper.

Ollama Cloud FAQ

What is Ollama Cloud?

Ollama Cloud is Ollama's hosted inference service. Cloud-tagged models use Ollama-managed infrastructure instead of your local GPU while remaining accessible through the Ollama CLI and APIs.

Is Ollama Cloud free?

Ollama currently offers a Free plan with light cloud usage. Pro costs $20 per month, while additional Team and Max options have different allowances and concurrency.

How much is Ollama Pro?

Ollama currently lists Pro at $20 per month or $200 per year. It includes 50 times the cloud usage of Free and up to three concurrent cloud models.

Does Ollama Cloud charge per token?

Individual Ollama plans use model-dependent usage limits rather than one fixed token allowance. Input, cached input, output, and model compute requirements affect consumption.

Can Ollama run on a cloud GPU?

Yes. Ollama can be installed on a normal Linux GPU VM. The model then runs on the GPU attached to that VM rather than through Ollama Cloud.

Does Ollama support the RTX 5090?

Yes. Ollama's current NVIDIA hardware-support list explicitly includes the RTX 5090.

How much VRAM does Ollama need?

The requirement depends on the model, precision, and configured context length. Ollama itself does not have one fixed VRAM requirement.

What context length does Ollama use on an RTX 5090?

Ollama currently defaults to 32K context for systems with 24–48 GiB of VRAM. A 32GB RTX 5090 falls into that tier. Larger contexts can be configured but require additional VRAM.

What port does Ollama use?

Ollama's local API uses port 11434 by default and binds to 127.0.0.1.

Does Ollama's local API require authentication?

No. Ollama does not require authentication for its API on localhost:11434. If you expose a self-hosted server remotely, add an appropriate security boundary rather than assuming the API authenticates users itself.

Does Ollama send local prompts to the cloud?

Ollama says prompts and responses from locally run models are not sent to ollama.com. Cloud models are processed by Ollama's hosted service; Ollama says their prompt and response content is not stored, logged, or used for training.

Can I disable Ollama Cloud?

Yes. Set OLLAMA_NO_CLOUD=1 or enable disable_ollama_cloud in Ollama's server configuration. This disables cloud-model and hosted web-search features.

Can Ollama use several GPUs?

Yes. Ollama supports multi-GPU systems and lets you restrict visible NVIDIA GPUs with CUDA_VISIBLE_DEVICES.

Is Ollama better than vLLM?

They have different strengths. Ollama emphasizes convenient model management and local or cloud use through one interface. vLLM is designed around high-throughput production inference and distributed serving. The better choice depends on the workload.

‍