Local LLMs with Ollama · Lesson 1 of 13 · about 20 minutes

What an LLM is, and isn't

What a large language model actually does when it answers you: predict the next piece of text, over and over. You'll see why that makes it fluent, why it sounds just as sure when it's wrong, which jobs it's good at, and why CivicGrid only ever asks its model to read one name off a page.

By the end you'll know

  • What a large language model (LLM) does, in one sentence
  • What tokens, parameters and training are, in plain words
  • What temperature changes, and why a setting of 0 matters for real jobs
  • Why a model sounds just as confident when it's wrong
  • Which jobs suit a model, and which don't

Where you are

The other tracks on this site are about running things: containers, clusters, pipelines. This one is about running something that sounds much more mysterious, a large language model, or LLM, the kind of system behind ChatGPT and Claude. You'll run one on your own laptop, for free, with a tool called Ollama, and by the end you'll use it the way I do in production: for one narrow job, with every answer checked.

That last part is the theme of the whole track. A model is useful, and it's also wrong in ways that are easy to miss. Knowing why it's wrong is what lets you use it safely, so this first lesson is about what's actually going on inside. It's all ideas, so there's nothing to install yet.

Your phone already does this

Open a message on your phone and type "Running a bit". Above the keyboard, your phone suggests three words: maybe "late", "behind" and "early". It isn't reading your calendar or checking the traffic. It has seen a lot of messages, and it knows which words usually come next after "running a bit".

Tap a suggestion, and it suggests the next one. Keep tapping, and you get a whole sentence that sounds like you, about a situation the phone knows nothing about.

That's an LLM, in miniature. A large language model does the same thing, at an enormous scale: given some text, it predicts what comes next. Everything else, the answering, summarizing, translating and writing code, comes from doing that one step extremely well, over and over.

What's inside

Three words come up constantly. Here's what each means.

Tokens. A model doesn't see words the way you do. It reads and writes in tokens: common words, pieces of longer words, punctuation and spaces. "The cat" might be two tokens; a long or unusual word might be split into three or four pieces. Each model has a fixed list of tokens it knows. Qwen 2.5, the model family I use, knows 151,643 of them. A useful rule of thumb for English is that a token averages about three quarters of a word.

Training. Before a model can predict anything, it's shown a huge amount of text and practices predicting the next token, billions of times, adjusting itself a little after every guess. Qwen 2.5 was trained on about 18 trillion tokens. Training happens once, at the company that makes the model, on thousands of specialized chips. When you download a model, you're downloading the result.

Parameters. The result of training is a big list of numbers, called parameters (or weights). They're the model's learned sense of which tokens tend to follow which. The "7b" in qwen2.5:7b means about seven billion parameters. More parameters usually means a more capable model, and also a bigger file and more memory to run it, which is what Lesson 3 is about.

Here's the part that surprises most people: there's no database inside. The model doesn't store facts as facts, the way a spreadsheet does. It stores patterns. Ask it the capital of France and it answers "Paris" because, across all that training text, "Paris" overwhelmingly followed questions like that, not because it looked anything up.

One token at a time

When you send a model a question, here's the whole loop:

How a model writes its answerA loop of four steps. The text so far goes into the model. The model gives every token it knows a score. One token is picked, using the temperature setting. The picked token is added to the end of the text, and the loop starts again, until the model picks a token that means stop.The text so faryour question + answer so farScore every token151,643 of themPick onetemperature decides howAdd it to the endthen stop, or go againrepeat until the model picks a "stop" token
Every word of every answer comes out of this loop, one token at a time. The model never plans the whole answer first.

Two things follow from that loop. First, the model never writes the whole answer at once, which is why chat tools show text appearing word by word: you're watching the loop run. Second, each step only asks "what's a likely next token?", never "is this true?". Hold on to that; it's the most important idea in the track.

Temperature: how adventurous the pick is

After the model scores every token, something has to choose one. That's where temperature comes in, a setting you control.

  • At temperature 0, the top-scoring token wins every time. Same input, same output. Boring, and exactly what you want for a job like "read the name off this page".
  • At higher temperatures, lower-scoring tokens get a better chance. Answers vary each time you ask, which is good for brainstorming or a poem, and bad for anything you want to check.

Try it. Pick a sentence, set the temperature, and press Pick the next word a few times. At 0 you'll get the same word every time. Push it to 1.5 and watch the picks spread out. Then try the third sentence.

Try it: predict the next word

The cat sat on the ___

  • mat60%
  • floor16%
  • sofa9%
  • windowsill6%
  • bed5%
  • roof4%

Press the button a few times and watch what it picks.

An everyday sentence. Plenty of words fit, and "mat" is the most common ending in the text the model learned from.

These percentages are made up for the demo. A real model scores every token it knows, over 150,000 of them, before each word.

The third sentence is the one to think about. Maple Falls, Ohio, isn't a real town. There's no right answer, and yet every option the model offers is a confident-sounding name. "Unknown" is right at the bottom, because text that says "the mayor of [town] is" is almost always followed by a name. The model is doing exactly what it was built to do: continue the text plausibly. Chat models get extra training to answer questions like this with "I don't know", and often will. But that's a learned habit for certain kinds of question, not a check of the facts, and in Lesson 2 you'll watch a real model say it doesn't know this mayor, then write a headline naming one.

Why it sounds sure when it's wrong

When a model states something false with total confidence, it's called a hallucination. The name makes it sound like a malfunction, but it's really the model working normally. Fluent, plausible text is what it's trained to produce, and a wrong answer can be just as fluent as a right one.

That's why the model's tone tells you nothing. It doesn't feel unsure the way a person does. When it does say "I'm not certain", that's because those words were the likely continuation, not because it checked. Three situations make made-up answers much more likely:

  • The answer wasn't in its training text. A tiny town, a private company, your own systems. It has nothing to go on, so it fills the gap with something that fits the pattern.
  • The answer changed after training. Every model has a training cutoff, the date its training text ends. Anything after that, like a new mayor elected last month, it simply hasn't seen. It will answer anyway, with whoever held the job in its training text.
  • The question nudges it. Ask "Why is Maple Falls famous for its cheese festival?" and you'll often get a detailed festival history, because you told it there was one.

The fix isn't to find a model that never does this. It's to give the model the facts, ask a narrow question about them, and check the answer. That's what most of this track builds up to.

Good jobs and bad jobs

Once you see a model as a very good text-continuer, its strengths and weaknesses make sense.

Good jobs: working with text you hand it.

  • Pulling one thing out of a document: a name, a date, an amount
  • Summarizing or rewriting: shorter, plainer, more formal
  • Sorting text into categories: is this email a complaint, a question or spam?
  • Drafting a first version for a person to edit

Bad jobs: anything that needs facts it wasn't given, or exact working.

  • Facts about the world, especially recent or obscure ones
  • Exact arithmetic and counting, because it predicts digits rather than calculating (and it sees tokens, not letters, so counting letters in a word can trip it up too)
  • Decisions where nobody checks the result

A good test: could you check the answer against something? If the model is reading a page you gave it, you can check whether the name it gave is actually on the page. If it's answering from memory, there's nothing to check against.

In my real setup

CivicGrid keeps a mayor or leader for each of 3,064 U.S. cities, and leaders change after every election. Every week, a script on my homelab checks them with qwen2.5:7b, a small model running locally in Ollama.

The model never answers "who is the mayor of this city?" from memory. That would be the Maple Falls problem at scale. Instead, the script fetches the city's own website, and the model gets one narrow job: read the leader's name off this page text. The script runs it at temperature 0, so the same page always gives the same answer.

Then the script checks the answer. The name has to actually appear on the page; if it doesn't, the answer is thrown away. And even a name that passes is only a proposal: nothing changes in the database until I approve it on an admin page. In one weekly run of 2,403 cities, that meant 17 proposals for me to review, instead of 2,403 answers to take on trust. Lesson 8 walks through each of those checks.

Local or hosted

When you use ChatGPT or Claude in a browser, the model runs on the company's servers. That's a hosted model. This track is about local models: you download the parameters and run the model on your own machine.

Local models are smaller and less capable than the biggest hosted ones. But they're free to run, your text never leaves your computer, they work without internet access, and they don't change underneath you, because the model you downloaded stays exactly as it is until you update it. For narrow, checked jobs like reading a name off a page, a small local model is often all you need. Lesson 12 weighs both sides properly, including when paying for a hosted model is the better choice.

Spot the problem

Three situations. Work out what's wrong before you read the explanation.

The confident footnote. Someone asks a model for three sources to support a report. It returns three neatly formatted references, with authors, titles and years. Two of the papers don't exist. What happened? Nothing unusual: a reference has a very predictable shape, and the model produced text in that shape. It had no way to check whether the papers were real, and nobody asked it to. Hand it the actual documents instead, and ask it to quote from them.

Same question, different answers. A team builds a tool that sorts support emails into "billing", "technical" and "other". The same email gets sorted differently on different days. What's the likely cause? The temperature is above 0, so the model sometimes picks a lower-scoring label. For a sorting job you want temperature 0, so the same email always gets the same label, and you can test it.

The new mayor. A model is asked who the mayor of a mid-sized city is, and confidently names someone. The name is right, but only until last year's election. What's the problem? The training cutoff. The model's training text ended before the election, so the old mayor really was the most likely answer, according to everything it had seen. It can't know what changed after. That's why CivicGrid's checks read the city's current website, rather than asking the model from memory.

Where you are now

An LLM predicts the next token, over and over. Tokens are pieces of text, training is how it learned which tokens follow which, and parameters are what that learning left behind: patterns, not a database of facts. Temperature decides how adventurous each pick is, and 0 makes it repeatable. A model sounds equally sure whether it's right or wrong, so the safe way to use one is to give it the facts, ask a narrow question, and check the answer. Lesson 2 gets one running on your laptop.

Check yourself

  1. What does an LLM do at each step of writing an answer?

  2. What does the "7b" in qwen2.5:7b mean?

  3. Why use temperature 0 for a job like reading a name off a page?

  4. A model names the mayor of a town that doesn't exist. Why?

  5. Which of these is the best job for a small local model?

  6. What makes CivicGrid's use of a model safe to rely on?

Key terms

  • LLM (large language model): a model trained on huge amounts of text to predict what comes next.
  • Token: a piece of text a model reads and writes: a word, part of a word, or punctuation.
  • Training: showing a model huge amounts of text so it learns which tokens tend to follow which.
  • Parameters (weights): the learned numbers that make up a model. "7b" means about seven billion.
  • Temperature: how adventurous the pick of each next token is. At 0, the top token always wins.
  • Hallucination: a confident answer that's false. It's the model working normally, not breaking.
  • Training cutoff: the date a model's training text ends. It knows nothing after it.
  • Hosted and local: a model running on a company's servers, or on your own machine.
  • Ollama: a free tool for downloading and running models on your own machine.

Go deeper