The Free Encyclopedia

Ollama Cloud vs Local: Model Routing on the Fleet

Revision as of Jun 25, 2026 22:56 by albert.

theLAB runs a mix of local and Ollama Cloud models. The goal is to keep everyday inference on hardware we own (cheap, private, always-on) and reach for the cloud only when a request genuinely needs a frontier-scale model.

The two tiers

Tier Where Examples Use for
Local your-llm-host (Ollama over Tailscale) Kimi K2.7, mid-size coders Default fleet AI, chat, tool-calling, summarization
Cloud Ollama Cloud (*:cloud tags) glm-5.2, large frontier models Distillation teachers, hard reasoning, big context

your-llm-host is the fleet's local-LLM host. Prefer it over hosted APIs for routine work — it is free to run and keeps data on the tailnet.

Routing rules of thumb

  • Default to local. Route to your-llm-host first; only escalate when quality is insufficient.
  • Cloud is metered. Cloud tags like glm-5.2:cloud burn Ollama Cloud Pro limits — reserve them for teacher runs (see Knowledge Distillation Lab (theLAB Genesis)) and one-off hard problems.
  • Keep clients pointed at hostnames, not IPs. Hardcoded tailnet IPs break when a host moves; use the Tailscale name.

Accessing your-llm-host

Ollama listens on the tailnet. From any fleet node:

OLLAMA_HOST=http://your-llm-host:11434 ollama list
OLLAMA_HOST=http://your-llm-host:11434 ollama run kimi-k2.7 "hello"

Gotchas

Bind address. For a remote host to serve other nodes, Ollama must listen on the tailnet interface, not just localhost. Set OLLAMA_HOST=0.0.0.0:11434 in the service environment (and rely on Tailscale ACLs for access control).

Don't mix up cloud and local tags. A :cloud suffix routes to Ollama Cloud even if the base model exists locally — easy way to silently spend quota.

See also: Jetson Orin as an Ollama Host, Serving Multiple Models on a Dual-GPU Box.