How to Run an LLM Locally in 2026

10 min readai, llm

You can install a genuinely useful language model on a laptop in under five minutes, for free, and it will keep working on an airplane. That sentence would have been marketing in 2023. In 2026 it is simply true: the tooling has consolidated into two battle-tested stacks, the open-weight model families have closed most of the everyday-usefulness gap, and the binding constraint is no longer software but a single number — how much memory your machine has.

What has not changed is the ceiling. A 12B model quantized to 4 bits on your MacBook is not Claude or GPT, and no amount of enthusiasm makes it one. Running locally is a trade: you give up frontier capability and server-grade throughput, and in exchange you get privacy, offline operation, zero marginal cost per token, and a much better mental model of how these systems actually work.

This post walks the whole path: why (and why not) to bother, the memory arithmetic that decides what you can run, what real hardware handles, the two stacks worth knowing, which model families to download as of August 2026, and when you should skip all of it and just pay for an API.

Why run a model locally at all

Four reasons hold up in practice. Privacy: your prompts never leave the machine, which matters for client data, medical or legal text, personal notes, and proprietary code. Offline: a local model works on a plane, in a secure facility, or during an outage. Cost structure: after the hardware, every token is free — high-volume background jobs like tagging, summarizing, and deduplicating stop having a meter attached. Tinkering: you can inspect sampling, swap system prompts, try fine-tunes, and learn more in a weekend than months of API calls will teach you.

The honest case against: local models sit a clear tier below the frontier APIs on hard reasoning, and always will at consumer scale. Setup is easy now, but keeping models current is on you. A GPU or a high-memory Mac is real money up front. And a laptop serves one user at a time — there is no autoscaling, no SLA, and nobody on call. If any of those are dealbreakers, the decision is already made.

The memory math that gates everything

Everything about local LLMs reduces to one calculation: parameter count times bytes per weight. At 16-bit precision every parameter costs 2 bytes, so a 7B model needs roughly 14 GB for weights alone — already past most laptops. Quantization is what makes local inference practical: store each weight at lower precision. At 8-bit that 7B model shrinks to about 7 GB with quality loss that is barely measurable for most uses; at 4-bit it fits in roughly 4 to 5 GB with a modest, usually acceptable hit. Push much below 4 bits and degradation gets obvious quickly. llama.cpp supports integer quantization from 8-bit all the way down to 1.5-bit; the community default is a 4-bit variant, and for most people that is the right call.

Two caveats before the table. These are approximations — actual footprints vary by architecture and quantization scheme. And weights are not the whole bill: every token of context you keep in play consumes additional memory for the KV cache, so long conversations or big documents can add gigabytes on top. Leave headroom.

Size class4-bit weights (approx.)Runs comfortably on
~4B~2–3 GBAny recent laptop, even CPU-only
7–9B~4–6 GB8 GB GPUs, 16 GB Macs
12–14B~7–9 GB12 GB GPUs, 16–24 GB Macs
24–35B~14–20 GB24 GB GPUs, 32–48 GB Macs
~70B~40 GBMulti-GPU rigs, 64 GB+ Macs

One wrinkle that matters more every year: mixture-of-experts models break the intuition that total parameters equal required speed. A MoE with 35B total but ~3B active parameters still needs memory for all 35B, but generates tokens like a small model — which is why the 2026 crop of MoE releases runs so well on modest hardware.

What your hardware can actually handle

Apple Silicon is quietly one of the best consumer platforms for this, because unified memory lets the GPU address the same pool as the CPU. A 32 or 64 GB Mac runs quantized models in the 27–70B class that would otherwise demand exotic GPU setups. Memory bandwidth scales with chip tier, and bandwidth is what drives tokens per second — a Max or Ultra chip is noticeably faster than a base chip with the same RAM. Budget for the OS: usable model memory is a chunk below total RAM.

Consumer NVIDIA GPUs are the fastest option per dollar when the model fits, and VRAM is a hard wall. As rules of thumb: 8–12 GB cards cover the 7–14B class at 4-bit, 16 GB stretches further, and the 24–32 GB flagship cards handle the 30B class comfortably. When a model does not fit, llama.cpp can offload layers to system RAM — it works, but every offloaded layer costs speed.

CPU-only is the last resort that actually functions. llama.cpp runs on nearly anything, and generation speed is limited mostly by memory bandwidth. A 4B model or a small-activation MoE is fine for background jobs and tolerable for chat; dense models much past 8B will test your patience. Fine for trying things, not a destination.

The stacks: Ollama, llama.cpp, and the GUIs

Ollama is the default on-ramp, and it earns the position: one command installs it, one command pulls and runs a model, and it exposes an OpenAI-compatible API on localhost so your existing tooling mostly just works.

# install on macOS or Linux (Windows has an installer)
curl -fsSL https://ollama.com/install.sh | sh

# download and chat with a model
ollama run gpt-oss:20b

# it also serves an OpenAI-compatible API
# at http://localhost:11434/v1

One thing to watch in 2026: Ollama now also offers a cloud tier that can route larger models to its own datacenter hardware. Convenient — but if privacy is your whole reason for going local, make sure you know which mode a given model runs in.

llama.cpp is the engine under most of this ecosystem, Ollama included: a dependency-free C/C++ inference engine that runs on Metal, CUDA, Vulkan, AMD, and plain CPUs, using the GGUF model format. Use it directly when you want the knobs — quantization choice, context length, layer offloading — or a minimal footprint; its llama-server binary speaks the OpenAI API too. If you prefer clicking to typing, LM Studio wraps model browsing and chat in a polished desktop app, and Open WebUI gives you a self-hosted chat front end over any local API. Nearly all of it pulls models from Hugging Face, which is where the GGUF files live.

Which models are worth downloading in August 2026

Three families cover most needs right now. OpenAI’s gpt-oss models (Apache 2.0, released August 2025) remain the reasoning picks: gpt-oss-20b is built to run in about 16 GB of memory, and gpt-oss-120b — 117B total parameters with ~5.1B active — targets a single 80 GB GPU, which in consumer terms means a high-RAM Mac or serious hardware. Google’s Gemma 4 family (spring 2026) is the practical laptop default: sizes run from phone-class E2B and E4B through a 12B, a 26B mixture-of-experts with about 4B active parameters, and a 31B dense model, with multimodal input and up to 256K context. Alibaba’s Qwen3.6 line (April 2026, Apache 2.0) is the coding and multilingual standout, shipping a 27B-class dense model and a 35B MoE with roughly 3B active parameters that flies on modest hardware.

Worth noting: Qwen’s flagship Plus and Max models stayed proprietary — part of a broader 2026 pattern where labs open the mid-sized weights and keep the frontier closed. Elsewhere, Llama 3.3 70B remains a proven workhorse if you have the memory, Mistral’s Apache-licensed small models stay popular where licensing clarity matters, and DeepSeek’s distilled reasoning models are worth a look if you want visible chain-of-thought locally.

What to expect from local quality

A well-chosen 12–27B model at 4-bit is genuinely good at the bread-and-butter work: summarizing documents, drafting and rewriting, structured extraction, code completion and boilerplate, and question-answering over notes. For a lot of daily usage that is most of what a model does anyway. Where local models fall visibly short is the frontier stuff — long multi-step reasoning, agentic loops that recover from their own mistakes, and low-hallucination factual recall. Local code assist is real, but the agents-grade coding covered in the coding-agents comparison still lives on API-backed frontier models.

A hedged rule of thumb: today’s local models feel roughly like the cloud mid-tiers of a year or more ago. That is a compliment — those were useful — but the gap does not close, because the frontier keeps moving too. Calibrate by task, not by vibes: run your actual workload on both for a week before deciding.

When the API is simply the right answer

Pay for the API when correctness is expensive, when you need concurrency and uptime, or when your volume is low and spiky — amortizing a GPU over a few hundred requests a month never pens out. The cheap API tiers undercut hardware hard: small models like Claude Haiku 4.5 run $1 per million input tokens and $5 out as of August 2026, batch processing halves that, and light workloads land in single-digit dollars a month. The economics are covered in the LLM pricing explainer, and you can put numbers on your own workload with the LLM cost calculator. For choosing among the hosted families, see how to choose an LLM in 2026.

Local wins the opposite cases: sensitive data that cannot leave the building, offline or air-gapped environments, high steady volumes of small mechanical tasks, and learning. Most people who go down this road end up hybrid — a local model for the private and the mechanical, an API key for the hard problems. That is not a compromise; it is the correct architecture.

A sane starting setup