Skip to main content
Think about the last time you used an AI system: you typed into a browser or an app and the model (hosted by a provider such as Anthropic or OpenAI) responded from a remote data center. That hosted model is accessed by API calls and billed per request. A model, however, is fundamentally a file — a very large file of numeric weights. Some vendors keep that file behind an API; others publish it. When a model is published you can download it and run it on your own hardware, including a laptop or desktop. This article demonstrates running a model locally with Ollama, shows that no data leaves your machine, and explains the hardware resources you need to run models locally. Demo setup
  • Ollama is installed on the machine. Ollama downloads model files and runs them locally.
  • Example models on disk:
Interactive local run
  • Start an interactive session with a local model (example: gpt-oss:20b). The model loads into memory and you can chat directly from the terminal:
At this point everything is local: Ollama loaded the model file from disk into memory and generated the response on-device. You can even verify that no external API calls are required by disabling network connectivity: with Wi‑Fi off the same session and responses still work because the model runs entirely on your hardware. Example: calling a local model from Python Below is a condensed and corrected example of a Python script that posts a system prompt and user text to Ollama’s local endpoint (run_local.py). The snippet highlights the important pieces: configuration, finding local prompt files, building the request body, and where streaming code would be implemented.
Example structured output from a local run
  • After running the script, the model prints a concise incident summary, supporting log evidence, remediation steps (runbook), escalation guidance, and local usage metrics:
Inspecting running models with Ollama
  • You can inspect Ollama-managed processes to see memory usage and whether the model is running on GPU or CPU:
Key takeaways about running models locally
Running models locally keeps data on your machine and eliminates per-request billing, but it requires capable hardware, local storage for model files, and management of the runtime tooling.
Two simple rules determine whether a model will run well on a laptop or desktop:
  • Rule 1 — Memory decides what fits
    • On systems with unified memory (e.g., Apple Silicon), CPU and GPU share the same pool. The GPU-usable portion is often some fraction of total unified memory (a rough community rule of thumb is around three‑quarters).
    • The model weights plus the context window must fit in that GPU-usable memory.
    • Rough size rules (compressed/quantized precisions commonly used for local running):
  • Longer context windows increase memory needs on top of the model weights.
  • Rule 2 — Bandwidth decides how fast
    • Each token generation step requires reading model weights (or the active parts) from memory; throughput is therefore limited by memory bandwidth.
    • As a simple upper-bound estimate: generation speed ≈ memory bandwidth ÷ model size (tokens/s).
    • Example estimates for a system with ~273 GB/s memory bandwidth:
  • Models using mixture-of-experts (MoE) architectures can be faster per token when only a subset of experts are activated.
Warning: Trying to run a model that doesn’t fit in available memory will fail to load or will fallback to CPU-only execution, which is dramatically slower. Always check model size + context requirements before launching.
Example: swapping to a larger model
  • Stopping a smaller model (gpt-oss:20b) and launching a much larger one (gemma4:31b) will often succeed on machines with sufficient memory but will load slower and generate tokens much more slowly. Example:
You’ll notice:
  • Larger models take longer to load and reduce generation throughput.
  • Fans, power draw, and thermal throttling can increase as the GPU/CPU works harder.
  • Larger models may produce more thorough or higher-quality outputs, but at the cost of time and power.
Alternative local UIs: Unsloth (GUI)
  • Ollama is one option; others provide local GUIs. Unsloth is an example: a model hub and chat interface that runs models locally and can manage downloads and fine-tuning.
Screenshot of a model hub web interface showing a sidebar list of machine learning models. The main pane shows details for a selected model ("gemma-4-26B-A4B-it-qat-GGUF") with download options and a performance chart.
Unsloth highlights:
  • A model hub UI to search and download models that fit your machine.
  • Local chat interface (“New Chat”) that behaves like hosted chat UIs.
  • Options to fine-tune or instruct models on your own documents and datasets.
Conclusion
  • Some models are available only as hosted services; others are downloadable and runnable locally.
  • Running a model locally keeps data on your hardware and eliminates per-request bills, but requires sufficient memory and memory bandwidth and some operational effort.
  • When deciding whether to run locally or use a hosted API, measure:
    • Memory footprint = model weights + desired context window.
    • Expected generation throughput ≈ memory bandwidth ÷ model size.
Links and references

Watch Video