beginner~2h

4 Ways to Run LLMs Locally

Ollama, LM Studio, vLLM, and llama.cpp — the four most common ways to run LLMs on your own machine, compared for privacy, ease of use, and performance.

kv cache

KV Parameters:

BATCH SIZE:16
SEQUENCE LEN:512 tokens
KV Cache Memory footprint:
4096.0 MB
Total VRAM Allocation
Attention format:mha
KV Heads per Layer:32 heads
Head dimension:128 dims
MHA allocates unique KV caches per attention query head.
4
Subtopics
1
Exercises
1
Projects
5
Quiz Qs
4
Flashcards
📚 Prerequisites(1)

🎓 Learning objectives

  • Set up and run a model using each of the 4 local LLM tools
  • Explain the privacy and testing benefits of running LLMs locally
  • Choose the right local runtime based on whether you need a GUI, a production-compatible API, or maximum performance
  • Explain why vLLM is described as bridging local and production serving

What is it?

Running LLMs locally means executing model inference entirely on your own machine rather than calling a cloud API. There are 4 popular ways to do this: Ollama (a simple CLI/API tool with one-command model downloads), LM Studio (a desktop app with a ChatGPT-like GUI), vLLM (a fast inference/serving library that also works locally, exposing an OpenAI-compatible API), and llama.cpp (a minimal-setup, high-performance inference engine, especially strong on CPU).

Why it exists

Being able to run LLMs locally has real, practical upsides that a cloud API alone doesn't provide: privacy, since your data never leaves your machine (critical for sensitive documents, regulated industries, or just personal preference), and the ability to test things locally before moving to the cloud (validating a prompt, a fine-tune, or an integration without incurring API costs or committing to a cloud deployment). These 4 tools exist because different users have different priorities — some want the absolute simplest setup, some want a graphical interface, some want production-API compatibility even locally, and some want maximum raw performance with minimal dependencies.

Problem it solves

Ollama solves the 'I want to run a model in under a minute with essentially no configuration' problem — a single install command and a single run command gets you a working local model. LM Studio solves the 'I want a GUI, not a terminal' problem, giving non-technical or GUI-preferring users a ChatGPT-like local chat experience with model loading/ejecting built in. vLLM solves the 'I want my local setup to behave exactly like a production API' problem, since it exposes an OpenAI-compatible interface — code written against vLLM locally can point at a real OpenAI-compatible production endpoint later with minimal changes. llama.cpp solves the 'I want maximum performance with minimal setup overhead, especially on CPU or resource-constrained hardware' problem.

Intuition

Think of these 4 tools like different ways to get a car for a weekend. Ollama is like a car-sharing app — download the app, tap a button, you're driving in a minute, no paperwork. LM Studio is like renting from a full-service rental counter with a friendly desk agent — a proper interface guiding you through picking your car and handing you the keys. vLLM is like renting a car that's contractually and mechanically identical to the fleet vehicles your company will eventually deploy in production, so anything you learn or build now transfers directly. llama.cpp is like a stripped-down, ultra-efficient manual-transmission car built by an enthusiast community specifically to get maximum performance out of minimal hardware, even an old engine.

Analogy

Ollama is like Homebrew or npm for LLMs — one command installs, one command runs, minimal ceremony. LM Studio is like a proper desktop application (think Spotify or VS Code) — polished, visual, approachable for non-command-line users. vLLM is like Docker for LLM serving — it's what you'd actually deploy in production, and running it locally means your local and production environments genuinely match. llama.cpp is like a hand-tuned, highly-optimized C library — minimal dependencies, excellent raw performance, especially valuable when you don't have a beefy GPU.

Technical explanation

(1) Ollama: install with a single command, then download and run any supported model with simple CLI commands (e.g., ollama run llama3). For programmatic usage, Ollama also has a Python package and integrations with orchestration frameworks like LlamaIndex or CrewAI, making it easy to wire into a larger application beyond just interactive chat.

(2) LM Studio: installed as a desktop app; it does not collect data or monitor user actions, keeping all data local to the machine, and is free for personal use. It offers a ChatGPT-like interface allowing users to load and eject different models as they chat, and like Ollama, supports a wide range of LLMs.

(3) vLLM: a fast, easy-to-use library for LLM inference and serving — with just a few lines of code, you can locally run LLMs (like DeepSeek) in an OpenAI-compatible format, meaning the exact same API calls that would hit a production OpenAI-compatible endpoint work identically against your local vLLM instance.

(4) llama.cpp: enables LLM inference with minimal setup and strong performance, particularly well-suited for CPU inference and resource-constrained hardware via its GGUF quantized model format, making it a common choice when GPU access is limited.

Architecture

The 4 tools sit at different points on a simplicity-vs-production-fidelity spectrum. Ollama and LM Studio prioritize ease of use and quick setup, abstracting away most configuration decisions. vLLM prioritizes production-API fidelity, running the same serving architecture (continuous batching, PagedAttention) that would be used in a real deployed production service. llama.cpp prioritizes raw inference performance and minimal dependency footprint, particularly on CPU-only or resource-constrained hardware, via aggressive quantization (GGUF format).

Workflow

  1. If you just want to quickly try a model with minimal setup and don't need a GUI or production-API compatibility, start with Ollama.
  2. If you or your team prefer a visual, ChatGPT-like interface over command-line tools, use LM Studio.
  3. If you're building an application that will eventually call a production OpenAI-compatible endpoint and want your local development environment to match that exactly, use vLLM locally.
  4. If your hardware is resource-constrained (no GPU, or a weak one) and you need maximum inference performance from what you have, use llama.cpp with a quantized GGUF model.
  5. For programmatic integration into a larger application (not just interactive chat), check for Python package support and framework integrations (Ollama offers direct LlamaIndex/CrewAI integrations; vLLM's OpenAI-compatible API works with any OpenAI-client-based tooling).
  6. Validate privacy/data-residency requirements are actually met by confirming no telemetry or data collection is happening for whichever tool you choose, if this matters for your use case.

Example

── Ollama: install + run + Python client ──

$ curl -fsSL https://ollama.com/install.sh | sh

$ ollama run llama3

import ollama response = ollama.chat(model='llama3', messages=[{'role': 'user', 'content': 'Hello!'}]) print(response['message']['content'])

── vLLM: local server + OpenAI-compatible client ──

$ pip install vllm

$ vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B

from openai import OpenAI client = OpenAI(base_url='http://localhost:8000/v1', api_key='not-needed') response = client.chat.completions.create( model='deepseek-ai/DeepSeek-R1-Distill-Qwen-7B', messages=[{'role': 'user', 'content': 'Hello!'}], )

── llama.cpp: minimal CLI invocation with a GGUF model ──

$ ./llama-cli -m model-q4_0.gguf -p "Hello!" -n 128

Real-world usage

Developers testing prompts, fine-tunes, or RAG pipelines before committing to cloud API costs commonly use Ollama or LM Studio for the fast iteration loop, then move to a cloud-hosted vLLM or a proprietary API for production. Privacy-sensitive industries (healthcare, legal, government contractors) that cannot send data to third-party APIs rely on local runtimes like llama.cpp or Ollama to keep sensitive documents entirely on-premises. Teams building applications against the OpenAI API contract specifically use vLLM locally during development so that switching between a local dev environment and a production OpenAI-compatible endpoint requires zero code changes. Resource-constrained deployments (edge devices, older hardware, CI/CD test environments without GPU access) commonly use llama.cpp's quantized GGUF models to get usable LLM inference without requiring expensive GPU infrastructure.

Trade-offs

Ollama and LM Studio trade some configurability and raw performance for dramatically simpler setup and use — ideal for individual developers and quick experimentation, less ideal for fine-grained production-serving control. vLLM requires more setup than Ollama/LM Studio but pays off with genuine production-API fidelity, at the cost of typically needing a real GPU to perform well (unlike llama.cpp's CPU-friendliness). llama.cpp offers the best CPU/low-resource performance of the 4 but has a steeper setup curve than Ollama and lacks vLLM's production-serving features (continuous batching for many concurrent users) or LM Studio's GUI.

Visual explanation

A 4-column comparison chart. Ollama: [Install: 1 command] [Run: 1 command] [Interface: CLI + REST API] [Best for: fastest simplest setup]. LM Studio: [Install: desktop app] [Run: GUI model picker] [Interface: ChatGPT-like GUI] [Best for: non-technical/visual users]. vLLM: [Install: pip install] [Run: a few lines of Python] [Interface: OpenAI-compatible API] [Best for: production-API-compatible local testing]. llama.cpp: [Install: build from source or minimal binary] [Run: CLI] [Interface: CLI + bindings] [Best for: maximum performance, CPU/low-resource hardware].

Advantages

  • Running locally provides genuine data privacy since nothing leaves the local machine, valuable for sensitive or regulated data

  • Local testing avoids API costs during iteration and development, before committing to a cloud deployment

  • 4 distinct tools cover the full spectrum from simplest-possible setup (Ollama) to production-API-identical (vLLM) to maximum CPU performance (llama.cpp)

  • Several of these tools (Ollama, vLLM) offer direct integration paths to production deployment, easing the transition from local development

Disadvantages

  • Local inference is generally slower and less capable than the largest cloud-hosted proprietary models, especially on consumer hardware

  • Running larger models locally requires substantial RAM/VRAM, which not all development machines have

  • Ollama and LM Studio's simplicity comes with less fine-grained control over serving configuration compared to vLLM

  • llama.cpp's performance advantages require understanding quantization tradeoffs (GGUF formats trade some model quality for speed/size)

Common mistakes

  • Choosing Ollama or LM Studio for a project that will eventually need production-API-compatible serving, missing the smoother transition vLLM would have provided

  • Attempting to run large, unquantized models on consumer hardware without GPU acceleration, resulting in unusably slow inference — llama.cpp's quantized GGUF models exist specifically to address this

  • Assuming all 4 tools have identical privacy guarantees without verifying each tool's specific data-handling behavior for sensitive use cases

  • Not considering local testing at all and paying cloud API costs even during early prompt/pipeline iteration, when local tools would have been faster and free

  • Using llama.cpp's raw CLI for a production-style multi-user serving need, when vLLM's continuous batching and concurrent-request handling is the better-suited tool for that specific requirement

📂 Subtopics

📝 Quiz

💬 Deep Dive with AI

Next Step

Continue to Mixture of Experts: Router Training Challenges & Solutions