Type one command. ollama run llama3. Wait a moment while it downloads, and then you are chatting with a capable AI model that is running entirely on your own laptop. No account. No API key. No internet needed after that first download. No bill that grows with every message. And, the part that matters to a lot of people, not a single word of what you type ever leaves your machine.

For years, “using an LLM” meant renting someone else’s computer in the cloud and trusting them with your data. Ollama is the tool that made the other option, running the model yourself, feel almost too easy. If you’ve used Docker, the vibe is identical: docker run gives you a running container in one line; ollama run gives you a running language model in one line. Same “it just works” feeling, pointed at AI.

Let me actually explain it, properly and from the ground up: what Ollama is, the genuinely clever trick that lets a giant model fit on a normal laptop, how you drive it, who leans on it and why, and, honestly, where it hits a wall. By the end you’ll understand not just how to use it but why it works.

The core pitch: your AI, your hardware

Cloud AI (the usual way)

  • Runs on someone else's servers
  • Needs an API key and internet
  • You pay per token, forever
  • Your data goes to a third party

Ollama (local)

  • Runs on your own machine
  • No key, works fully offline
  • $0 per token, no metering
  • Data never leaves your computer
The trade in one glance. You give up the cloud's effortless scale and its access to the very biggest models, and in return you get privacy, zero per-use cost, offline access, and no vendor lock-in. For a whole class of users, that trade is not close.

What Ollama actually is (and what it sits on)

Here’s an honest thing most intros skip: Ollama did not build a new AI engine from scratch. Underneath, it uses a well-known open-source engine called llama.cpp, which is the piece that actually does the hard math of running the model efficiently on ordinary hardware, even just a CPU. That engine is powerful but fiddly to set up and drive by hand.

What Ollama added is the part humans love: it wrapped that engine in a dead-simple, Docker-style experience. Ollama handles downloading the right model file, storing it, loading it, serving it, and giving you one clean command for each of those. Think of it as the friendly front desk for a powerful-but-grumpy backend.

You: ollama run llama3one simple command
Ollamadownloads, stores, loads, serves the model
llama.cppthe engine that runs the math efficiently
Your CPU / GPU + RAMwhere it all actually runs
The stack. You talk to Ollama; Ollama drives llama.cpp; llama.cpp squeezes the model onto your hardware. Each layer hides the messy part below it, which is exactly why "run a local LLM" went from a weekend project to a single command.

The clever bit: how a huge model fits on a normal laptop

This is the question that should be nagging you. Modern models are enormous, billions of numbers (weights). Stored in full precision, an 8-billion-parameter model is around 16GB, and bigger ones are far larger. How does that fit on a laptop with 16GB of RAM? Two tricks, and they’re worth understanding because they’re the whole reason local AI is possible.

Trick one: quantization. Each weight in a model is normally a high-precision 16-bit number. Quantization stores it with fewer bits, say 4, instead. It’s like saving a photo as a slightly-compressed JPEG instead of a giant RAW file: much smaller, and to the eye, nearly identical. Ollama’s models come pre-quantized (the common default is called Q4_K_M), so a 16GB model shrinks to roughly a quarter of the size.

Full precision (FP16)~16 GB
16-bit weights
8-bit quantized (Q8)~8.5 GB
8-bit
4-bit quantized (Q4_K_M, the default)~4.9 GB
4-bit
The same 8B model at different precisions. Cutting from 16-bit to 4-bit shrinks it to roughly a third of the memory, which is the difference between "won't fit" and "runs comfortably" on a normal machine. This compression is what puts real models within reach of consumer hardware.

“But surely you lose a lot of quality?” Less than you’d think, and this is measurable, not hand-waving. Large-scale evaluations (Red Hat published results across half a million tests, and there’s solid academic work like the llama.cpp quantization study on arXiv, 2601.14277, if you want the deep end) land on a clear pattern: 8-bit keeps over 99% of the original accuracy; 4-bit keeps about 98.9%. And the bigger the model, the less quantization hurts it, huge models at 4-bit perform almost identically to their full-precision selves.

Full (FP16)
100%
8-bit (Q8)
99%+
4-bit (Q4)
98.9%
Accuracy retained after quantization (from large-scale evaluations). You shrink the model to a quarter of its size and give up barely one percent of quality. That lopsided trade, tiny quality cost for massive size savings, is why 4-bit is the sensible default and why local AI is practical at all.

Trick two: memory-mapping (mmap). The model file uses a format called GGUF (a single tidy file holding the weights, the tokenizer, and the settings). Because of how it’s stored, the computer doesn’t have to load the entire file into RAM at once, it reads the parts it needs, when it needs them. That’s why a machine that technically has less RAM than the model’s full size can still run it. The file sits on disk; only the working pieces live in memory.

The commands you’ll actually use

Ollama’s command set is small and mirrors Docker on purpose, so it’s easy to remember. Here are the ones that matter:

ollama run llama3Chat with a model (downloads it first if needed)
ollama pull mistralDownload a model without running it yet
ollama listShow the models you have and their disk sizes
ollama psShow which models are loaded in memory right now
ollama rm llama3Delete a model to free up disk space
ollama show llama3Print a model's details and settings
ollama create mymodelBuild your own custom model from a Modelfile
ollama serveStart the local API on port 11434
If you know Docker, this reads like home: pull, run, list, ps, rm, they mean what you'd guess. This deliberate familiarity is a big part of why Ollama felt approachable from day one.

Taking a model, and making it your own: the Modelfile

How does Ollama “take” a model? Two ways. The easy way: ollama pull grabs a ready-made one from Ollama’s library (or you point it at a GGUF file from Hugging Face). The powerful way: you write a Modelfile, which is to Ollama exactly what a Dockerfile is to Docker, a short recipe describing a custom model.

Modelfile
# start from an existing model FROM llama3 # give it a personality / rules SYSTEM "You are a terse assistant for a Kerala tea-shop owner. Reply in one line." # tune its behaviour PARAMETER temperature 0.6
A Modelfile. FROM picks a base (an Ollama model, or a GGUF/Safetensors file). SYSTEM sets its standing instructions. PARAMETER tunes behaviour like creativity. Run ollama create teashop and you have your own named model. You can even ollama push it to share, just like a Docker image.

One more thing that makes Ollama quietly powerful for developers: ollama serve exposes an OpenAI-compatible API on localhost:11434. That means code written for OpenAI’s API can point at your local Ollama by changing one URL, and suddenly it’s running on your machine for free. Swapping cloud for local becomes a one-line change.

Who actually uses it, and why

This isn’t a hobbyist toy. The people reaching for Ollama usually have a concrete reason the cloud can’t satisfy:

Privacy-bound industries
Healthcare, law, finance, government A hospital can't send patient records, a law firm can't send briefs, to a third-party API. HIPAA, GDPR, SOC 2 often make local the *only* legal option. With Ollama the data never leaves the building. Finance was one of the earliest adopters for exactly this.
Developers
Private coding + app building A local coding model (Qwen Coder, DeepSeek Coder) wired into VS Code gives a private pair-programmer with zero cloud dependency. Great for building and testing LLM apps without burning API credits on every run.
Cost-conscious teams
High-volume, repetitive tasks If you're summarizing or classifying millions of items, per-token cloud fees explode. Local inference is $0 per token after the hardware, so heavy repetitive workloads get dramatically cheaper.
Researchers + tinkerers
Experiments and offline use Swap models freely, run on a plane, build RAG pipelines over private documents. No metering means you can experiment without watching a bill tick up.
The common thread isn't "we hate the cloud", it's a hard requirement the cloud can't meet: data must stay in-house, cost must be flat, or access must work offline. Where any of those bind, Ollama is often the answer.

How people actually run it: your machine, your platform

A fair question: what do you need to run this? The happy surprise is “less than you’d guess.” The floor is about 8GB of RAM and no GPU at all, enough to run small models on plain CPU. But the experience changes a lot with your hardware and platform, and each of the big three has its own character.

Mac · Apple Silicon The quiet champion Every M-series chip accelerates Ollama through Metal, with zero setup. Its secret weapon is unified memory: the GPU and CPU share the same RAM, so a 32GB Mac can run models that would need 32GB of dedicated GPU memory on a PC. Fantastic value for local AI.
Windows · NVIDIA The speed king A modern NVIDIA card (RTX 40/50 series) is auto-detected through CUDA, no flags, no rebuilds. At equal memory, NVIDIA generates tokens faster than anything else. The catch is that GPU VRAM is separate and pricier per gigabyte.
Linux · AMD / NVIDIA The flexible one Full NVIDIA support, plus AMD GPU acceleration via ROCm (Linux-only as of 2026). The go-to for servers, air-gapped deployments, and anyone who wants total control of the stack.
Three platforms, three personalities. Apple Silicon's unified memory makes Macs punch far above their price for local AI; NVIDIA wins raw speed; Linux wins flexibility and server deployment. All three need essentially zero manual GPU wrangling now, which wasn't true a couple of years ago.

The single most useful rule of thumb is how much memory maps to how big a model (at the common 4-bit quantization). This ladder tells you what fits:

4 GB
3B to 4B models. Small but genuinely useful. Gemma 3n is a great default.
8 GB
7B to 8B models. The sweet spot for most people. Llama 3.1 8B, Qwen Coder 7B.
12 GB
12B to 14B models. Noticeably smarter. Gemma 3 12B.
24 GB
32B models. The tier that's "transformative for coding." Qwen Coder 32B.
48 GB+
70B models. Near-frontier quality at home. Llama 3.3 70B.
Roughly: your usable memory (RAM on a Mac, VRAM on a PC GPU) at 4-bit tells you the model size you can run. On a capable machine, expect 40 to 80+ tokens per second, comfortably faster than you read. This ladder is the one thing to remember before picking a model.

Case studies: what this looks like in the real world

Abstract benefits land harder as real deployments. A few documented ones (details paraphrased from public write-ups):

Finance
A financial-services firm's support automation Ran fine-tuned local models for customer support, keeping confidential data in-house rather than shipping it to a cloud API.
reported ~40% faster responses, ~30% lower cost
Banking
A global bank's compliance chatbot Deployed a fine-tuned Llama 3.3 70B trained on financial regulations and support logs, wired into ticket routing, so sensitive queries never left their systems.
reported ~92% accuracy on complex queries
Healthcare
Medical LLMs and clinical docs Research efforts like EPFL's Meditron ship medical models runnable via Ollama, letting hospitals do AI-assisted documentation and decision support with no external data exposure.
HIPAA-safe: data never leaves the network
Defense / regulated
Air-gapped deployments In environments with literally no internet (defense, some finance and healthcare), Ollama runs fully offline, which is often the only way AI is permitted at all.
works with zero network access
The common thread across every case: a hard constraint (regulatory, privacy, or air-gap) that the cloud simply cannot satisfy, met by moving the model in-house. The reported numbers are from public write-ups, treat them as directional, but the shape is consistent: local AI unlocks use cases the cloud legally or practically couldn't.

The honest limits (where Ollama stops making sense)

A teaching post owes you the ceiling, not just the pitch. Ollama is genuinely great, and it is not magic. Where it struggles:

LimitationWhat it means for you
The biggest models need serious hardwareFrontier-size models want GPUs most people don't own (an H100 runs ~$25,000). You run *good* local models, not the absolute largest.
CPU-only is slowWithout a decent GPU, expect only a few words per second, fine for short tasks, painful for long generation or coding.
Weak under concurrencyOllama shines for one user at a time. Serving many concurrent users, throughput drops sharply; tools like vLLM are built for that instead.
Still needs some engineeringQuantization trade-offs, GPU memory, tuning, it's simple to start, but squeezing good performance still takes know-how.
The pattern: Ollama is optimal for single-user, privacy-sensitive, or cost-sensitive workloads on capable-but-normal hardware. It is not the tool for serving a frontier model to a thousand users at once. Know which situation you're in.

That’s why many real setups go hybrid: Ollama for the private, high-volume, everyday work, and a cloud API for the rare task that truly needs a frontier model. And because Ollama speaks the OpenAI API format, flipping between the two is, again, a one-URL change. Best of both worlds, chosen per task.

The takeaway

Ollama’s achievement isn’t a new AI, it’s access. It took a powerful engine (llama.cpp), the clever compression that makes big models fit (quantization plus a memory-mappable GGUF file), and wrapped the whole thing in a Docker-simple experience anyone can drive in one command. The result: real AI that runs on your hardware, keeps your data yours, costs nothing per use, and works on a plane.

It won’t run the very largest models, and it isn’t built to serve a crowd. But for the enormous middle ground, a developer wanting a private assistant, a hospital that legally can’t use the cloud, a team drowning in per-token bills, Ollama turned “run your own LLM” from an intimidating project into a single line of typing. And the next time you watch a model answer you with your Wi-Fi switched off, you’ll know exactly what’s happening under the hood: a cleverly shrunk set of weights, memory-mapped off your disk, run by a quiet engine, all behind one friendly command.

← Back to blog