vLLM vs Ollama: 1 user or 256 at once, and which doors each one opens

Pick Ollama if one person uses it, on a Mac, a Windows PC or almost any graphics card, with GGUF models and one command. Pick vLLM if several people or programs hit the same model at once from a Linux machine with an NVIDIA card, with safetensors models. At home, for one user, Ollama.

The two are not rivals so much as tools for different jobs. Ollama 0.40.10, the stable release since 23 October 2026, is built to put a model on your own computer. vLLM 0.32.0, stable since 18 October 2026, is built to serve a model to many users at once. We have not raced them with a stopwatch, so you will not find a speed winner here. What we have done is read the code of both versions wherever it touches memory, the network and your privacy, and that is where they differ most.

vLLMRuntime sheet→ OllamaRuntime sheet→

	vLLM	Ollama
Built for	Serving a model to many users at once	Running models on your own computer
Version on 24 October 2026	0.32.0	0.40.10
Code and licence	Open source, Apache 2.0	Open source, MIT
Runs on	Linux with an NVIDIA card (compute capability 7.5+), AMD with ROCm on a narrow set of versions; Windows only through WSL; Mac experimental, processor only	Windows 10 22H2+, macOS 14+, Linux; NVIDIA, AMD, Apple Silicon and Vulkan
Model files	safetensors, plus AWQ, GPTQ, FP8 and more; GGUF only through an experimental add-on	GGUF and safetensors; on Apple Silicon, MLX by default
Requests at once, by default	Up to 256 on a home graphics card, batched together	1 per model; the rest wait in a queue of up to 512
Graphics memory	Reserves 92% of the card when it starts	Takes what the model and its context need
Install and first answer	Python package, vllm download-kernels, then vllm serve	Installer or one-line script, then ollama run
Window	None: it is an API server	Desktop app on macOS and Windows
Listens on	0.0.0.0:8000, every network interface	127.0.0.1:11434, your machine only
Key on the API	None by default; --api-key covers 4 route prefixes only	None, and the local server has no key to check
CORS out of the box	Closed since 0.32.0 (no origin allowed)	Open to pages on localhost, 127.0.0.1 and 0.0.0.0 on any port
Sends on its own	Usage statistics to stats.vllm.ai at start and every 10 minutes	2 kinds of cloud call with ollama serve, 4 kinds with the desktop app
Switch it off	VLLM_NO_USAGE_STATS=1 (or 3 other ways)	OLLAMA_NO_CLOUD=1 cuts the 2 cloud kinds; the app’s hourly update check and its account query stay

One person at home, or a dozen at once

This is the question that decides it. Ollama answers 1 request per model at a time out of the box: in the 0.40.7 code, OLLAMA_NUM_PARALLEL defaults to 1, and every other request waits its turn in a queue of up to 512. For one person chatting, coding or running a script, that is exactly what you want: the whole card works on your answer. You can raise OLLAMA_NUM_PARALLEL, but each extra slot multiplies the context memory, so 4 parallel requests on a 4,096-token context reserve memory for 16,384 tokens.

vLLM starts from the other end. On a graphics card with less than 70 GB of memory, which covers every GeForce card, the 0.32.0 code lets vllm serve work on up to 256 requests at once, and it slips new requests into the running batch as they arrive instead of making them queue for the previous one to finish. That is what it was born for. If your family, your team or a dozen agents in a pipeline all hit the same model, vLLM keeps the card busy where Ollama would serve them one by one.

How much faster does that make vLLM? We have not measured it, and it depends on the model, the card and how many requests arrive together. With a single user there is no batch to fill, so vLLM’s main advantage has nothing to work with.

NVIDIA, Mac or just a processor

Here the choice often makes itself. vLLM is a Linux program, and its first-class case is an NVIDIA card with compute capability 7.5 or higher: that leaves out the GTX 10 series and older. AMD cards work through ROCm, but for 0.32.0 the published package needs Python 3.12, ROCm 7.2.3 and glibc 2.39 or newer. On Windows there is no native version, only WSL. On a Mac with Apple Silicon, vLLM’s own support is experimental and on the processor only; the graphics chip needs a separate plugin maintained by its community.

Ollama runs almost anywhere: Windows 10 22H2 or newer, macOS 14 or newer and Linux, on NVIDIA cards from compute capability 5.0, AMD with ROCm v7, and Vulkan, which is on by default on Windows and Linux and is its recommended route for Radeon cards without ROCm. On a Mac with Apple Silicon it uses the graphics chip, and since 0.40.0 it runs a model on MLX by default whenever the model has an MLX version.

If your computer is a Mac or a Windows laptop, the comparison ends here: Ollama. To see which models fit your machine, our Model Finder does the maths.

GGUF or safetensors: the files each one reads

The format your models come in is the second filter. vLLM’s native format is safetensors, the one most models are published in, plus more than 20 quantisation schemes such as AWQ, GPTQ and FP8. GGUF, the format of most quantised models for home use, is no longer built in: since 0.27 it lives in a separate add-on that vLLM’s own documentation calls highly experimental. Models come from Hugging Face by default.

Ollama speaks GGUF through llama.cpp, and it can also import a folder of safetensors or a GGUF file with a Modelfile, quantising on the way if you ask. Most people never see the files: ollama pull downloads from Ollama’s own library, and on Apple Silicon a tag can carry an MLX version that the Mac picks over the GGUF one.

So if you already have a collection of GGUF files, Ollama reads them as they are. If you want to run a model exactly as its maker published it, in full precision or FP8 on an NVIDIA card, that is vLLM’s ground.

Memory: 92% of the card up front, or only what the model needs

The first time you start vllm serve, look at the graphics memory: 92% of it is gone. That is by design. In the 0.32.0 code, gpu_memory_utilization defaults to 0.92, and vLLM reserves that share as soon as it starts, for the weights and a cache big enough to hold many conversations at once. It is reserved, not used on demand, so anything else that needs the card has to fit in the remaining 8%. If you share it, lower that value by hand.

Ollama loads the weights and the cache the context needs, and it picks that context from the graphics memory it finds: 4,096, 32,768 or 262,144 tokens. When the model has been idle for a while, it unloads it and gives the memory back.

Installing them, and the first answer

Ollama is 2 steps: install it with the installer or a one-line script, then ollama run followed by a model name. It downloads the model and starts a chat in the terminal. On macOS and Windows there is also a desktop app with a chat window.

vLLM is a Python package with no window. With 0.32.0 you need Python 3.11 to 3.14; you install it with uv pip install vllm --torch-backend=auto (or the official Docker image), run vllm download-kernels once after every install or upgrade, and start it with vllm serve followed by a model from Hugging Face. From there you talk to it through its OpenAI-compatible API, from code or from a chat interface you put in front. It is not hard for someone at home in a terminal, but there are more pieces, and the memory settings above are part of the job.

Our step-by-step guides take you through each one: run Ollama locally and run vLLM locally.

Which doors are open: 0.0.0.0:8000 against 127.0.0.1:11434

Out of the box, vllm serve listens on 0.0.0.0:8000: every network interface of the machine, with no key. On a laptop in a hotel, anyone on that wifi may be able to use your model. Ollama listens on 127.0.0.1:11434, your own machine only, and to reach it from another device you have to open it on purpose with OLLAMA_HOST=0.0.0.0.

Neither checks a password by default. vLLM can: start it with --api-key, or the VLLM_API_KEY variable, and clients have to send the key. But the key only covers routes under 4 prefixes, /v1, /v2, /inference and /cohere; other routes on the same port answer without it, and vLLM’s security page itself advises not to rely on the key alone. Ollama’s local server has no key at all: its defences are listening only on your machine, CORS and a check on the Host header of each request, which only applies while it listens on your own machine.

CORS decides which web pages may use the server from inside your browser, and here vLLM is now the stricter one. Since 0.32.0 its list of allowed origins is empty: no page from another site can read its answers until you add it with --allowed-origins. Ollama accepts pages served from localhost, 127.0.0.1 and 0.0.0.0 on any port, plus a few app schemes, and answers 403 to any other origin; browser extensions have to be added with OLLAMA_ORIGINS. Keep in mind that CORS only binds browsers: any program on your network reaches vLLM all the same.

One more thing we checked in vLLM’s code, because its security page warns that PyTorch’s internal communication can listen on every interface. On 1 machine, by default, the 0.32.0 code sets that communication up through a file in the temporary folder, not a network port; it only uses TCP on AMD cards with AITER’s all-reduce, with data parallelism (--data-parallel-size above 1), and across several machines. Those internal ports should never be reachable from outside.

What each one sends out on its own

This is where a privacy-minded user should look twice, and it is not the answer you might expect. vLLM sends usage statistics to stats.vllm.ai by default: 1 full report when the engine starts (graphics card, processor, memory, operating system, vLLM version, the model’s architecture but not its name, and startup settings), then a heartbeat every 10 minutes for as long as the server runs. That is 144 heartbeats a day. In its favour, it keeps a copy of everything it sends in ~/.config/vllm/usage_stats.json, and any of 4 switches turns it off: VLLM_NO_USAGE_STATS=1, DO_NOT_TRACK=1, VLLM_DO_NOT_TRACK=1 or an empty file at ~/.config/vllm/do_not_track. The value has to be exactly 1.

vLLM also downloads, when you ask for a model that is not cached, from Hugging Face (HF_HUB_OFFLINE=1 stops it once your models are on disk). And if FlashInfer’s precompiled kernels are missing, FlashInfer fetches them from NVIDIA’s servers when vLLM starts; vllm download-kernels does it once at install, and FLASHINFER_NO_DOWNLOAD=1 forbids it. It has no update check and no account. Before FlashInfer downloads those kernels, vLLM usually checks whether NVIDIA’s server, edge.urm.nvidia.com, answers (1 request, 5-second limit), and FLASHINFER_NO_DOWNLOAD=1 does not stop that check. Installed with pip, this happens on its own on B200 and B300 cards with almost any model and can happen on an H100 or an RTX 50 with models such as gpt-oss. The Docker image already brings the kernels, and with them on disk after vllm download-kernels, normally neither request goes out.

Ollama has no analytics library anywhere in its code. With only ollama serve, as on Linux, it makes 2 kinds of call to ollama.com by itself: a catalogue of recommended models every 4 hours and the cards of its cloud models when the server starts. OLLAMA_NO_CLOUD=1 switches both off. With the desktop app on macOS or Windows, 2 more kinds join them: an update check every hour, which no setting stops, and an account query when the app opens.

So the quietest setup of all is either one with its switch on: vLLM with VLLM_NO_USAGE_STATS=1, HF_HUB_OFFLINE=1 and FLASHINFER_NO_DOWNLOAD=1 once vllm download-kernels has run, or ollama serve without the app and with OLLAMA_NO_CLOUD=1. Every destination, with its source and date, is on our vLLM page and our Ollama page.

Which one we would install, by profile

• One person, any computer: Ollama. One command, a model that loads and unloads by itself and nothing open to the network.
• A Mac or a Windows laptop: Ollama. vLLM has no native Windows version, and on a Mac it runs only on the processor.
• A shelf of GGUF files: Ollama, which imports them without converting (one Modelfile and ollama create per model).
• A Linux box with an NVIDIA card serving the whole household, a team or a fleet of agents: vLLM, with --host, an API key and its statistics switched off.
• A model exactly as its maker published it, in safetensors or FP8: vLLM.
• A card you also use for games or other programs: Ollama, or vLLM with gpu_memory_utilization lowered by hand.

Still weighing a desktop app as well? Our LM Studio vs Ollama comparison covers that one.