Skip to main content
APPLIED AI · SESSION 03

Running Open-Weight LLMs Locally

The session that took the mystery out of open source AI: the vocabulary, how to pick a model that fits your job, and the actual repo we ran on stage.

Presented August 6, 2026. Joseph Copenhaver led this one. Jake Hodges introduced it and closed it out.

Joseph Copenhaver & Jake HodgesAugust 202610 min read
Share:
Summarize with:ChatGPTClaudeGrok
01 - VOCABULARY

The words that get thrown around

AI
The umbrella everything hides under.
LLM
Large language model. The engine of this whole talk.
OODA loop
Observe, orient, decide, act. The rhythm an agent runs on.
Graph
How work and knowledge get structured and traversed.
RSI
Recursive self-improvement. A model modifying its own behavior.
MCP
Model Context Protocol. How a model reaches tools and data.
Context
Everything the model can see right now.
Turn
One exchange. Your input, its output.
Preload
What you seed before the first turn.
Inference
The model actually running. Tokens in, tokens out.
Stochasticism
The randomness built into every response.
Steering
Nudging output toward what you actually want.
Tokens
The currency of it all. The chunks a model reads and writes.
Temperature
Turn it up, get more "creative" randomness.
These words get confused with what actually makes AI, AI. What gets called AI today is all of them and none of them in isolation. The point of learning the vocabulary is to become a steward for a system that keeps a human in the loop, not to memorize trivia.
02 - MATCHMAKING

Pick the model for the job, not the job for the model

Start with constraints.

Before downloading anything, write down what you're trying to do, what outcome you want, and your actual constraints - hardware, time, privacy, budget. The task defines the model. Never the other way around.

Models have personalities.

Different models carry different strengths and weaknesses, and different capacity for something that looks like reasoning. Not every task needs that. Reformatting a spreadsheet is not the same job as writing a legal brief.

More parameters is a trade, not a win.

A bigger model usually takes longer and can be more precise, but only inside the domain it was actually trained on. Don't ask a model built for one kind of task to do a completely different one and expect it to go well.

03 - GETTING IT RUNNING

Run the demo yourself, step by step

Before you start
  • Docker installed
  • At least 120 GB free disk space — the model itself is large
  • 16 GB RAM recommended. You can go lower (a Raspberry Pi with 8 GB RAM works) but drop to a ~2B parameter model.
  • No GPU required. It just runs slower on CPU.
Step 1 — Clone the repo

The repo includes an agents.md file, so any AI agent — Claude, Copilot, ChatGPT, or anything else — can read it and set the project up for you. Not just Claude Code.

Terminal
git clone https://github.com/josephcopenhaver/llm-examples
Step 2, Path A — Let your AI agent do it (recommended for most people)

Paste the repo link into your AI agent of choice and tell it to clone and run the project by following the README and agents.md. This is the easiest path — you do not need to know what Docker Compose is doing.

Paste this into your AI agent
Clone https://github.com/josephcopenhaver/llm-examples and set it up by following its README/agents.md — start the stack and confirm it's running.
Step 2, Path B — Run the model directly (manual / faster for local use)

If you already have Ollama installed and want a raw terminal interface rather than the full stack, you can pull and run the model with one command. This is the faster path for quick experiments.

Terminal
ollama run qwen3:4b
Step 3 — Start the full stack

From the cloned repo directory, run:

Terminal — from repo root
docker compose up

This starts three things in sequence: Ollama (the model runtime), Open WebUI (the chat frontend), and then waits for the model to finish initializing. When the terminal output settles, the web UI is ready.

Image placeholder
Terminal output showing docker compose up starting Ollama and Open WebUI services, with container health checks completing
Terminal output after docker compose up — Ollama and Open WebUI containers starting, model initializing
Step 4 — Open the chat UI

Open your browser to http://localhost:3000. Create a login. It is local only — a throwaway email and password is fine, nothing goes anywhere. The model will already be pre-selected in the interface.

Image placeholder
Open WebUI chat interface loaded in a browser, showing the model pre-selected and a text input ready to use
Open WebUI loaded in the browser after setup — model pre-selected, ready to chat
What to expect on the first run
The first run is slow. The model has to download and then load into memory — this can easily take longer than the demo appeared on stage. Subsequent runs start fast because the model is already cached. The terminal shows tokens per second (t/s) once it is actually generating. That number is what changes as you adjust hardware and model size.
Step 6 — Try it

Start with simple prompts to confirm it is working:

"How are you?"Basic response check
"Hi"Shortest possible turn — confirms the loop is alive
"What time is it?"Tool call test — see below

That third prompt is a deliberate test. The model does not know the current time. When you ask, it makes a tool call: it asks a system tool for a timestamp, gets the value back, and writes a response from that data. That is tool calling in one sentence — the model noticing it needs external information, fetching it through a tool, and incorporating the result. Everything that makes agentic AI work is a bigger version of this same pattern.

04 - TEST AND TUNE

Hardware buys speed, not truth

Hardware is the speed lever, not the quality lever.

VRAM determines what fits in memory. GPU cores and memory bandwidth determine how fast tokens move. Better hardware means faster responses — not smarter ones. The same model gives you the same class of answer on a laptop or a cluster. One is just slower getting there.

Model choice and quantization are the quality levers.

Quantization is the process of compressing a model's weights to fit smaller hardware. A highly quantized model runs faster and uses less memory, but loses some capability in the process. Model choice — which model, at which quantization level — is where you actually control the quality and capability of what comes back.

The practical approach: start big, trim down.

Start with the largest model your hardware can tolerate without thrashing. Confirm the output quality is good enough for the task you actually need it to do. Once you know the base model can do the job at all, then start trimming — smaller model, higher quantization — until you hit the best tradeoff of speed, quality, and resource cost. Do not bother tuning temperature or other knobs until you have confirmed the base model is capable in the first place.

05 - CURATE

Tell it who you are and what you need

Three things to give any model before you rely on it: who you are (your role, your expertise, your standards), what you need (outcome, style, format), and how you process information (bullets or prose, code or diagrams, terse or verbose). This does more for the quality of what you get back than any hardware upgrade.

System prompt framing: identity first, rules second
When you are starting out, do not lead with restrictions. "Don't do X, always do Y" produces a model that is guarded rather than useful. Instead, give the model identity and context: who you are, how you think, how you want it to integrate its responses into your workflow. This creates a feedback loop where the model is orienting toward you rather than avoiding a list of prohibited behaviors. Once that base works well, layer in specific constraints where you actually need them.
Where open-weight models are genuinely the right call
You have a backlog of tasks that just needs to get done, a person on your team already knows how to do the work and could explain it clearly, and that person doesn't have the time or attention to grind through all of it by hand. You bring the judgment. The model brings the throughput.
06 - REVIEW / EXTEND / GOVERN

Powerful loops need short leashes

An LLM doesn't contain the world's knowledge or your business processes. It contains math that predicts the next chunk of text given the last chunk of text. That means you have to seed it with the understanding it needs, and you have to build a way to check its work. Anything is possible and everything can go wrong, so bring a firewall.

Tools named on stage for keeping structure outside the model's context window
  • n8n for self-hostable visual workflows
  • Langflow or Flowise for visual LLM pipelines
  • Airflow or Prefect for task orchestration
  • Plain task tracking in Taskwarrior, GitHub Issues, or a kanban board
  • MCP servers for exposing tools and state to a model in a way you actually control
07 - STEWARD'S CHECKLIST

Five items before you deploy anything

1
Learn the words - jargon fluency is steering fluency
2
Match the model to the task - constraints first
3
Buy speed with hardware, buy correctness with testing - verify before you tune
4
Curate identity and intent - who you are, what you need
5
Govern the loop - small tasks, structure that lives outside the model, a human still in it
Autonomous systems are powerful. Stewardship is what keeps them useful.
08 - NEXT STEPS

Where to go from here

You have the walkthrough. Clone the repo, run docker compose up, and try it against a real task you are currently paying API or subscription tokens for. That is the whole assignment.

ROAI Newsletter · Practical AI, every week
Get practical AI tips that actually move the needle.
No spam. Unsubscribe anytime. Privacy Policy.