Ollama Cloud Models: Run 120B Parameter LLMs Without a GPU

For a long time, running a big open model meant one thing. You needed a big GPU. If you wanted to try a 120 billion parameter model, you either had a workstation with a lot of VRAM or you gave up and used a hosted API from someone else.

Ollama Cloud changes that. You keep the same Ollama you already installed, the same commands, the same port on localhost, and the same client libraries. The only thing that changes is a suffix on the model name. Add :cloud and the work runs on Ollama’s servers instead of your laptop.

This tutorial walks through the whole thing. Signing in, running your first cloud model, calling it from Python and JavaScript, mixing local and cloud models in one app, and working out what it costs.

What Ollama Cloud actually is

It helps to be clear about what is happening under the hood, because the design is simple and that is the best part.

Your local Ollama daemon still runs on http://localhost:11434. When you ask it for a model whose name ends in -cloud, it does not load weights into your GPU. It forwards the request to Ollama’s hosted service, streams the tokens back, and hands them to your client as if the model were running on your machine.

That means your existing code does not change. If you wrote a Python script last month against llama3.2, you can point it at gpt-oss:120b-cloud by editing one string. No new SDK, no new base URL, no new auth header in your app.

Step 1: Update and sign in

Cloud models need a recent build. Check what you have:

ollama --version

If you are on an older release, grab the current one from ollama.com/download. On Linux the one line installer still works:

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

Now sign in. Cloud models are tied to an ollama.com account, so this step is required:

ollama signin

This opens a browser window. Log in or create a free account, approve the device, and come back to the terminal. You only do this once per machine.

Step 2: Run your first cloud model

Here is the moment where it clicks. Run a 120 billion parameter model on a laptop that could never hold it:

ollama run gpt-oss:120b-cloud

You get the familiar Ollama chat prompt. Ask it something. The response streams back the same way a local model would, except your fans stay quiet and your memory stays free.

Type /bye to leave the session.

To see what else is available, browse the cloud filter in the model library at ollama.com/search?c=cloud. At the time of writing the catalog includes families like GLM, DeepSeek, Kimi, Qwen, Gemma, Nemotron, MiniMax and GPT-OSS. Some of these are very large coding models. Some carry very long context windows.

The naming pattern is consistent. A local tag looks like gpt-oss:20b. The cloud version of the same thing is gpt-oss:20b-cloud. Some models use a plain :cloud tag, like gemma4:cloud.

Step 3: Call it from Python

Pull the model reference first so your local daemon knows about it, then install the client:

ollama pull gpt-oss:120b-cloud
pip install ollama

Note that the pull here is quick. It is registering a pointer, not downloading 65 gigabytes of weights.

Now a streaming chat script:

from ollama import Client

client = Client()

messages = [
    {'role': 'user', 'content': 'Explain how a Kubernetes readiness probe differs from a liveness probe.'}
]

for part in client.chat('gpt-oss:120b-cloud', messages=messages, stream=True):
    print(part['message']['content'], end='', flush=True)

Compare that to the local version of the same script. The only difference is the model string. That is the whole point of the design.

Step 4: Call it from JavaScript

npm i ollama

import { Ollama } from 'ollama';

const client = new Ollama();

const response = await client.chat({
  model: 'gpt-oss:120b-cloud',
  messages: [{ role: 'user', content: 'Write a Dockerfile for a Node 22 app.' }],
  stream: true,
});

for await (const part of response) {
  process.stdout.write(part.message.content);
}

Step 5: Plain HTTP with curl

If you are wiring this into something that is not Python or Node, the REST API is unchanged:

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

Same host, same port, same JSON shape. Any tool that already speaks to Ollama will speak to cloud models with no changes.

Step 6: Skip the local daemon entirely

Sometimes you do not want a local Ollama in the path at all. Think of a CI job, a serverless function, or a container that should stay small. In that case you can talk to ollama.com directly with an API key.

Create a key at ollama.com/settings/keys, then export it:

export OLLAMA_API_KEY=your_api_key_here

Point the client at the hosted host instead of localhost:

import os
from ollama import Client

client = Client(
    host='https://ollama.com',
    headers={'Authorization': f"Bearer {os.environ['OLLAMA_API_KEY']}"}
)

response = client.chat(
    model='gpt-oss:120b-cloud',
    messages=[{'role': 'user', 'content': 'Summarise the CAP theorem in three sentences.'}]
)

print(response['message']['content'])

Keep the key out of your source. Use an environment variable, a secrets manager, or your CI provider’s secret store. Never commit it.

A practical pattern: route by task

The interesting use of cloud models is not replacing local ones. It is mixing them. Small, high volume, privacy sensitive work stays on your machine. Hard work goes up to a bigger model.

Here is a small router that does exactly that:

from ollama import Client

client = Client()

LOCAL_MODEL = 'llama3.2'
CLOUD_MODEL = 'gpt-oss:120b-cloud'


def ask(prompt, heavy=False, private=False):
    """Send simple or sensitive prompts locally, hard ones to the cloud."""
    if private or not heavy:
        model = LOCAL_MODEL
    else:
        model = CLOUD_MODEL

    response = client.chat(
        model=model,
        messages=[{'role': 'user', 'content': prompt}]
    )
    return model, response['message']['content']


# Routine classification stays on the laptop
print(ask('Is this log line an error or a warning? "disk usage at 71%"'))

# A hard refactor goes to the big model
print(ask('Refactor this 400 line service into clean modules...', heavy=True))

# Anything touching customer data stays local, no matter how hard it is
print(ask('Summarise this support ticket from a named customer...', heavy=True, private=True))

That last case matters. Cloud models mean your prompt leaves your machine. If you are handling customer records, internal source code under NDA, or anything covered by a compliance rule, keep it local. The suffix makes the boundary easy to audit, because you can grep your codebase for -cloud and see every place data leaves the building.

What it costs

Ollama publishes tiers rather than pure pay as you go, and each paid tier comes with a pool of monthly usage credits plus a concurrency limit.

The free tier is enough to evaluate the feature and run a few sessions against the starter models. If you are building an agent that fires many calls in a loop, watch the concurrency number as closely as the credits. One concurrent request on the free tier means an agent doing parallel tool calls will queue.

Check the current numbers at ollama.com/pricing before you plan a budget, since tiers do move.

Things worth knowing before you commit

• Cloud models need network. The main reason people pick Ollama is offline work. A cloud model gives that up. Plan a local fallback if your app has to keep working on a train.
• Latency is different. Local models have near zero time to first byte once loaded. Cloud models add a round trip. For interactive chat it is fine. For a tight loop with hundreds of tiny calls, the round trips add up.
• Context is generous. Cloud models generally run at their full context window without you tuning anything, which is a real advantage over a local model you had to quantise and truncate to fit.
• The API surface is identical. Tool calling, structured outputs and streaming all behave the way they do locally, so you can prototype against a small local model and switch to a large cloud one for production quality without a rewrite.

Running this from a container

Most people reading this run things in Docker, so it is worth covering how cloud models change the container story. They change it a lot.

A normal Ollama container is heavy. You need the NVIDIA runtime, a GPU passed through, and a volume big enough to hold the weights. That is a real amount of setup before you can run a single prompt.

If you are only using cloud models, none of that applies. There is no GPU to pass through and nothing to cache on disk. Your app container talks to ollama.com over HTTPS and that is the whole dependency.

Here is a compose file with no Ollama service at all:

services:
  app:
    build: .
    environment:
      OLLAMA_HOST: https://ollama.com
      OLLAMA_API_KEY: ${OLLAMA_API_KEY}
      OLLAMA_MODEL: gpt-oss:120b-cloud

Put the key in a local .env file that is in your .gitignore:

OLLAMA_API_KEY=your_api_key_here

And read all three from the environment in your app, so the same image runs against local or cloud depending on how it is deployed:

import os
from ollama import Client

host = os.environ.get('OLLAMA_HOST', 'http://localhost:11434')
model = os.environ.get('OLLAMA_MODEL', 'llama3.2')
key = os.environ.get('OLLAMA_API_KEY')

headers = {'Authorization': f'Bearer {key}'} if key else {}
client = Client(host=host, headers=headers)

response = client.chat(
    model=model,
    messages=[{'role': 'user', 'content': 'Say hello.'}]
)
print(response['message']['content'])

That is the pattern worth stealing. Three environment variables and your code does not care where the model lives. A developer on a workstation with a GPU runs it locally against llama3.2. CI runs it against a cloud model because build agents do not have GPUs. Production picks whichever suits the workload and the budget.

If you do want a local Ollama in the mix as a fallback, keep it as its own service and let the app choose at runtime:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama:/root/.ollama
    ports:
      - "11434:11434"

  app:
    build: .
    depends_on:
      - ollama
    environment:
      OLLAMA_HOST: http://ollama:11434
      OLLAMA_MODEL: llama3.2

volumes:
  ollama:

Note the named volume. Without it every restart re-downloads the model, which is slow and wastes bandwidth. This is the single most common mistake in Ollama compose files.

One thing to watch in CI. If your pipeline runs tests against a cloud model, every test run spends credits and competes for your concurrency slots. Mock the model in unit tests and save the real calls for a small set of integration tests that run on merge, not on every push.

Wrapping up

Ollama Cloud is a small feature with a big effect. One suffix, and the ceiling on model size disappears. Your tooling, your scripts and your muscle memory all carry over.

The best way to use it is not to move everything up. Keep the small stuff local where it is fast, free and private, and reach for -cloud when the task genuinely needs a frontier sized model. Write the routing logic once, as in the example above, and you get the good parts of both.

Try it now:

ollama signin
ollama run gpt-oss:120b-cloud

Two commands and you are running a model that would not fit on most desktops.