What each one is genuinely good at

Read this lesson harder than the others

This course is published by a company that sells a local AI tool. You should know that before you read a list of what local AI is good at.

A list like this is worth nothing if it only ever points one way. That is an advert in a teacher's jacket.

So here it is in both directions. The cloud half is the longer one, and it is not a grudging note at the end. It is the part that decides most real choices.

What local is genuinely better at

These are real advantages, not consolation prizes.

The flat cost changes how you work, which is easy to miss. When the tenth try costs the same as the first, you stop rationing your questions. A meter running in the corner makes people careful in a way that is not always useful.

• Privacy. Nothing is sent, so there is nothing to be stored, read or leaked. Ollama's own FAQ says it plainly: run locally and they do not see your prompts or your data.
• Working when nothing else does. No account, no internet, no outage, no company changing the rules.
• A flat cost. The thousandth question costs the same as the first, which is nothing beyond the power bill.
• Nothing changes under you. The file on your disk today behaves the same way next year.
• You can keep a copy. It is a file, so last year's version can sit beside this year's.
• No limit set by somebody else on how much you use. The only limit is how fast your own machine can go, and that one is real.

Backed by Ollama FAQ.

What the cloud is genuinely better at

Four things, and none of them are close.

The largest models. The biggest ones are far larger than a home machine can hold, and that is true of the ones anyone can download too. DeepSeek-V3 is a model you can download, and it holds 671 billion numbers. Even a heavily squeezed copy of it comes to 221 gigabytes.

You can watch that line being drawn in a real tool. Ollama runs models on your machine, and it also offers cloud models, which are names you type. One of them is gpt-oss:120b-cloud. Ollama says such models run without a powerful graphics chip, because the work goes to its own service instead.

Rare heavy jobs. Renting beats owning when you need a lot of power now and then. Model makers publish a price per million tokens, where a token is a chunk of a word. So a one-off job costs about what that job is worth. Buying a machine for a task you do three times a year does not add up.

Working with other people. A cloud tool gives a whole team the same thing, kept in one place, with nothing to install. Local means one machine. Five colleagues means five installs, five downloads and five separate sets of updates.

That gap widens quietly. In the shared lane, one person changes a setting and it changes for everybody. Locally, five people keep five sets of settings, and those drift apart without anyone deciding to.

There is also no ceiling to buy your way past. When a cloud job grows, you do not buy anything. When a local job grows past what your memory holds, that is a purchase. Lesson nineteen counts what that costs.

Backed by DeepSeek-V3 model card, DeepSeek-V3-GGUF: the Q2_K_XS file listing, 221 GB, Ollama: Cloud, Claude model pricing.

How soon the answer comes back

The next lesson asks how quickly an answer must come back. It is worth knowing now which way that points, because it is not the way most people assume.

For small work that fits on your machine, local is often the quicker one. Nothing travels. Lesson four measured this. On the fastest M4 Max in the llama.cpp table, a 7 billion parameter model in one compact form wrote about 83 tokens a second. That is quicker than you can read.

For work that needs a big model, it goes the other way, and it is not close. A model has to be held in memory all at once. Lesson four covers what happens when it will not fit. Part of it lands on the slower part of your computer, and the words crawl.

You can watch it happen. Ollama's ps command lists what is loaded and where it went. A line reading 48%/52% means about half the model is sitting on the slow part. That is what a job on a machine that nearly fits it looks like, and nearly is a bad place to be.

If it will not fit at all, there is no local speed to compare. The answer does not arrive late. It does not arrive. So for a job that needs a big model, a cloud answer comes back sooner than a local one ever will.

Backed by Performance of llama.cpp on Apple Silicon M-series, LLM benchmarking: metrics, Ollama: Cloud, Ollama FAQ.

When speed is not the question

Now the limits, because that claim gets stretched. A cloud answer is not instant. NVIDIA's benchmarking documentation lists what the wait before the first word is made of. Queuing behind other requests counts. So does the trip over the network. The model's own work is only part of it.

So a busy service on a poor connection can lose to a small model at home. And for work you set going and come back to, speed was never the question. Ask how long you will sit there waiting, not how fast the tool is.

Backed by Performance of llama.cpp on Apple Silicon M-series, LLM benchmarking: metrics, Ollama: Cloud, Ollama FAQ.

The fourth one: knowing recent things

Every model has a cut-off date. It learned from text gathered up to some day, and it knows nothing after it. Meta's model card for Llama 3.1 gives a cut-off of December 2023 for a model released in July 2024. That gap is normal.

Cloud tools handle this better in two ways. The vendor moves you onto newer models with nothing to download, so the cut-off you sit behind creeps forward on its own. And reaching the live web is the ordinary way those tools work.

Here is the part that gets left out. A local tool can search the web too, and then the search leaves your machine. Ollama's web search sends your query to its own service over the internet, and it needs an account.

So local plus web search is not the same as local. The answering may stay home. The question does not. It is worth knowing which parts of a tool go out.

Backed by Llama 3.1 model card, Ollama: Web search.

The comparison that tells you nothing

Here is the mistake almost everybody makes when weighing the two up.

You type the same short question into both. Both give a decent answer. So you decide they are much of a muchness, or that one clearly wins, on the strength of one reply.

Short, easy questions are exactly where the two lanes are closest. A small model handles those well, and track three was about getting the most from one. Nothing separates the lanes there, so nothing is learned.

The gap opens somewhere else. On long input. On work that has to be right. On unusual subjects. On anything where a quiet mistake would cost you.

So run a fairer test. Take a real piece of your own work, and pick an awkward one rather than a tidy one. Put it through both lanes. Then judge. It costs you an afternoon and it answers the question you actually have.

What neither one is better at

Both kinds can be confidently wrong, and neither will tell you when it is.

A bigger model is usually wrong less often. It is not never wrong. The gap between those two is where careless work happens.

Neither one knows your work, either. Both will fill a gap in your notes with something that reads well. Microsoft's own card for phi-4 warns that a model can produce content that sounds reasonable and is wrong. That is the dangerous kind of wrong, and it looks the same in both lanes.

So the checking is still yours, on both sides. Nothing in the rest of this track removes that, and any tool that suggests otherwise is selling.

Backed by phi-4 model card.