Ollama vs vLLM: Local Dev Tool or Production Inference Engine?
Ollama and vLLM both run LLMs locally, but optimize different axes: Ollama trades throughput for simplicity on one laptop; vLLM trades setup complexity for production concurrency. Learn which to use and why they're not competitors.
Ollama and vLLM both let you "run a large language model locally." Ask either one to serve 200 concurrent users on a single GPU, and the resemblance ends.
- Mental model: Ollama is a single-user dev tool that trades throughput for simplicity; vLLM is a production inference server that trades setup complexity for multi-user concurrency.
What Ollama Does
Ollama wraps llama.cpp and quantized GGUF weights into a single command:
ollama run llama3
That's it. No Python environment to configure, no CUDA dependencies to compile, no batch-size tuning. The model downloads, loads, and starts answering you in seconds on your laptop's GPU. Ollama is optimized for developer friction—the fastest possible path from zero to "the model is running and I can ask it a question."
Under the hood, Ollama serves requests largely one at a time. When fifty concurrent API calls arrive, they don't run in parallel. They queue. Latency climbs. The GPU idles waiting for responses. The tool that "just works" for a solo developer becomes a bottleneck the moment real traffic hits.
What vLLM Does
vLLM is built around two architectural ideas that flip Ollama's trade-off:
PagedAttention manages GPU memory like an operating system pages RAM. Instead of allocating one contiguous block per request (wasting memory when sequences are short), vLLM divides the KV cache into fixed-size pages and reuses them across requests. One GPU holds many more concurrent requests.
Continuous batching slots new requests into the running batch mid-flight instead of waiting for a batch to finish. Request A doesn't have to complete before Request B starts generating tokens. They generate in parallel, packed efficiently into the same GPU compute.
The result: one GPU serving hundreds of concurrent requests, exposed through an OpenAI-compatible API:
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="token-unused")
response = client.completions.create(
model="meta-llama/Llama-2-7b",
prompt="Explain inference optimization",
max_tokens=512
)
The cost of that throughput: you must provide a real GPU with real VRAM, install Python and CUDA dependencies, and configure the server deliberately—model path, tensor parallelism, GPU memory fraction, batch size. Even asking one solo question on your laptop means paying the full production setup tax.
They're Not Competitors—Different Axes
| Ollama | vLLM | |
|---|---|---|
| Primary User | One developer, local machine | Production API serving N concurrent users |
| Request Handling | Largely sequential (queue) | Continuous batching (parallel) |
| GPU Memory Model | Fixed allocation per request | PagedAttention (page-based) |
| Setup Friction | One command, zero config | Python, CUDA, deliberate tuning |
| Concurrent Requests per GPU | ~1–5 | ~50–500+ |
| Best For | Local prototyping, tinkering | Production inference APIs |
| If You Pick Wrong | Production traffic queues, GPU underutilized | Local experiments pay ops overhead |
The Inference Lens
In LLM serving, throughput depends on how you handle two latencies:
- TTFT (time to first token): latency before generation starts.
- TPOT (time per output token): latency per token generated.
Ollama's sequential queue inflates both. A second request waits for the first to finish generating all its tokens before the GPU even touches the prompt. vLLM's continuous batching decouples them: Request B's prompt can be processed while Request A is still generating output tokens, and both requests' output generation runs in parallel on the same GPU. One GPU's TPOT is divided among N concurrent requests.
The Verdict
Reach for Ollama when you're prototyping alone—you want model inference in one command with zero fuss. Reach for vLLM when you're serving real traffic—you need the GPU utilization, latency scaling, and concurrency that continuous batching and PagedAttention provide.
Don't use Ollama for production. Don't use vLLM for local tinkering.
Your Turn
You're serving one fine-tuned model to 200 concurrent API users on a single GPU. Ollama or vLLM—and what specifically breaks if you pick wrong?
Watch the 90-second reel for a visual walkthrough of this breakdown.