LOCAL AI
Getting started with local AI
Running a capable language model on hardware you own is no longer a stunt. Here is what it actually takes, what it costs, and where the honest limits are.
There is a version of "running AI locally" that amounts to a party trick: a tiny model dribbling out sentences on a laptop, impressive for roughly ninety seconds. That is not what this is about. On a mid-range gaming GPU bought in the last few years you can now run open-weight models that are genuinely useful for summarising, drafting, classifying, answering questions about your own documents and writing a decent amount of code — entirely on hardware you own, with no API key and no per-token bill.
This is the starting point for our Local AI collection. It covers what local AI actually is, the one number that decides what you can run, which software to install first, and — just as importantly — what local models are still bad at.
What "local AI" actually means
In practice it means downloading an open-weight model, which is a file containing the trained parameters of a neural network, and running it through an inference engine on your own CPU or GPU. Nothing leaves the machine. There is no service to sign up to and nothing to rate-limit you.
Two words there are doing a lot of work. Open-weight means the maker has published the trained parameters for anyone to download. It does not automatically mean open source. Some models ship under Apache 2.0 or MIT; others arrive under bespoke licences with conditions attached, and the difference matters the moment you want to use one commercially. Inference means running a finished model to produce output, as opposed to training it — an enormously more expensive activity that you are not going to be doing at home.
Why bother
The honest answer is that it depends what you want out of it.
Privacy. Nothing you type is sent anywhere. For anything involving client documents, personal notes, internal infrastructure or code you have not published, this is not a small consideration.
A different cost shape. You pay once for hardware and then in electricity. That is worse than an API for occasional use and better for anything that runs constantly — a summariser chewing through RSS feeds, a classifier tagging documents overnight, a voice assistant that answers a hundred times a day.
Availability. No outages, no deprecation notices, no model being retired underneath you. A model you have downloaded keeps working exactly as it did the day you downloaded it, indefinitely.
Control. You choose the system prompt, the sampling parameters, the context length and the model itself, and you can pin all of it. Nothing changes unless you change it.
Because it is interesting. This is a legitimate reason and most of us are not going to pretend otherwise.
What local AI is not is a drop-in replacement for a frontier model. The gap has narrowed a great deal, but a 27B model running on a single consumer card is not going to match the best hosted models on hard reasoning, obscure factual recall or very long, complicated tasks. Going in expecting a free ChatGPT is the fastest route to disappointment. Going in expecting a fast, private, endlessly available workhorse that is genuinely good at a wide range of ordinary tasks is much closer to reality.
Memory is the number that decides everything
Almost every "can I run this?" question reduces to memory. A model has to be held in memory in its entirety while it runs. If it fits in your GPU's VRAM, it runs fast. If it does not, your software will either spill part of it into system RAM — which works, but slows down dramatically — or refuse to load it at all.
Raw parameter counts make this sound worse than it is, because almost nobody runs models at full precision. Quantisation reduces the numerical precision of each weight, most commonly to about four bits, which shrinks the file by roughly three quarters for a quality loss that is small and, for most everyday work, difficult to notice. The near-universal default is a format called Q4_K_M, and unless you have a specific reason to do otherwise it is the right thing to start with.
The practical rule, and it is a good one: the memory you need is roughly the size of the file you downloaded, plus headroom for the conversation itself. Model catalogues publish those file sizes directly, so you can check before you commit to a download.
What that looks like in practice
8 GB of VRAM comfortably runs models in the 3B to 9B range. IBM's Granite 4.2 8B is 5.3 GB at Q4_K_M.
12 to 16 GB opens up the class most people should actually be aiming at. Google's Gemma 4 12B is 7.6 GB; OpenAI's gpt-oss-20b is 14 GB and its own model card puts it inside 16 GB of memory.
24 GB — an RTX 3090, 4090 or a used equivalent — runs the 27B to 35B class that represents the current sweet spot for local work. Qwen3.8 27B is 18 GB at Q4_K_M.
Beyond that you are into unified-memory machines or multiple cards, and into models that are interesting rather than practical for most people.
Memory bandwidth is the second number, and it is the one that sets how fast words come out. We cover both in more detail in How much VRAM do you actually need for local AI?.
Choosing a runtime
The runtime is the software that loads the model file and does the actual work. There are three worth knowing about, and they are less different than they first appear — two of the three are built on the third.
Ollama
Ollama is the default recommendation and the easiest thing to start with. It is MIT-licensed, runs on macOS, Windows, Linux and Docker, and pulls models with a single command. It ships a desktop app if you want a chat window, a command line if you do not, and an HTTP API on port 11434 that is compatible with the OpenAI API — which means an enormous amount of existing software can be pointed at your own machine by changing one base URL. It works out how much of a model fits on your GPU and puts the rest on the CPU automatically.
LM Studio
LM Studio is the GUI-first alternative: a proper desktop application with a model browser, a chat interface and a local server on port 1234. It has been free for commercial use since July 2025, which removed the main reason people used to avoid it, and it ships a command line and a headless server for anyone who wants to run it on a box with no monitor attached.
llama.cpp
llama.cpp is the C++ engine underneath a large fraction of the local AI ecosystem, including LM Studio and — alongside Ollama's own engine — much of Ollama. It is MIT-licensed, it defines the GGUF file format that quantised models are distributed in, and it runs on very nearly everything: CUDA, Metal, Vulkan, ROCm, SYCL, plain CPU. Running it directly gives you the most control and the fewest guard rails. If you are the sort of person who reads the flags, start here; otherwise start with Ollama and come back to it later.
Choosing a first model
The catalogue moves quickly, and chasing the newest release is a good way to spend an afternoon downloading rather than using. A few durable principles instead:
Fit the model to the card, not the other way round. A 12B model that fits entirely in VRAM will feel far better to use than a 27B one that half-fits and grinds.
Start with a well-known general model. Google's Gemma 4 family, Alibaba's Qwen3.8, IBM's Granite 4.2 and OpenAI's gpt-oss-20b are all permissively licensed, all available in sizes that suit consumer hardware, and all good general performers.
Check the licence if it matters to you. Gemma 4 moved to Apache 2.0, and Granite, Qwen3.8 27B and gpt-oss are Apache 2.0 as well. Others are not. Read the model card rather than assuming.
Specialist models earn their place later. Coding models, vision models and embedding models are all worth having, but only once you know what you are actually going to do with them.
Where it starts to get genuinely useful
A chat window is the demo. The interesting part is what you connect it to.
Open WebUI is the usual next step — a self-hosted web front end that talks to Ollama natively and to anything else that speaks the OpenAI API, adding multi-user accounts, document knowledge bases and a much better chat experience. It is worth reading its licence terms before deploying it at any scale: since version 0.6.6 there is a branding clause that applies above fifty users in a rolling thirty-day window, with an exemption below that, which covers essentially every home deployment but not every business one.
Beyond that, the OpenAI-compatible endpoint is the door to everything else: home automation platforms, note-taking tools, IDE plugins, scripts of your own. The model becomes an ordinary local service that other things call, which is a much more useful mental model than "an app I chat to". We look at that properly in Running local AI in a homelab.
What local models are still bad at
Worth being blunt about, because the enthusiast literature tends not to be.
Obscure facts. A quantised 12B model has compressed a great deal of the world into a few gigabytes. It will confidently invent details. Anything that matters needs checking against a source.
Long, multi-step reasoning. This is where the gap to the best hosted models is still most visible.
Very long context. Advertised context windows are not the same as usable ones, because the conversation itself consumes memory as it grows. A model advertising 256,000 tokens will not give you that on a 16 GB card.
Throughput for several users at once. One person chatting is fine. A team hammering the same card is a different engineering problem.
A sensible first afternoon
Install Ollama. Pull one general-purpose model sized to your card. Talk to it for half an hour and get a feel for where it is strong and where it falls over. Then install Open WebUI in a container, point it at Ollama, and see what having a private, always-on model on your own network actually changes about how you work. That is the whole loop, and it takes less time than reading about it does.
From here, the two questions everyone asks next are how much VRAM they really need and which card to buy. Both have their own articles in this collection.
Browse the Local AI collection
Computers
Peripherals
Components
Supplies
Audio Visual
Mobile Tech
Software
Networking
My products
Product guides