Most guides to running a model locally end at the same moment: the model answers on your machine, and the guide stops. Putting it in front of a partner, two housemates or four colleagues is where the interesting failures start, and the first has nothing to do with VRAM. None of the mainstream inference servers will ask anyone for a password, and one of the four listens on every network interface before you configure a thing.
The Rule That Breaks on vLLM
Anyone who has run Ollama, llama.cpp or LM Studio absorbs a comfortable rule: the server listens on loopback until you deliberately change it. It holds for three of the four. Ollama’s FAQ states that “Ollama binds 127.0.0.1 port 11434 by default”. llama.cpp’s server README documents --host as “ip address to listen … (default: 127.0.0.1)” on port 8080. LM Studio serves on 127.0.0.1 and port 1234 until “Serve on Local Network” is switched on, and its docs warn that “Any bind other than 127.0.0.1 exposes the server beyond localhost; we recommend enabling authentication.”
vLLM is the exception, and it is the single most useful thing to know before serving anything. In vLLM’s own CLI argument source the frontend field reads host: str | None = None, so --host is unset unless you pass it. The server’s socket code then builds sock_addr = (args.host or "", args.port) and constructs its startup log line with a fallback of "0.0.0.0". An empty-string address is the standard socket spelling for all interfaces. Carrying the Ollama assumption across to vLLM gets it backwards, and that is the difference between a service on one desk and a service on whatever network the machine is plugged into.
Authentication Is Off in All Four
On the second axis the four agree. Ollama’s documentation says “No authentication is required when accessing Ollama’s API locally via http://localhost:11434”; the authentication Ollama does have is documented for ollama.com sign-in and private model pulls, not for the local API. llama.cpp lists --api-key with “(default: none)”. LM Studio’s docs state that “By default, LM Studio does not require authentication for API requests”. vLLM’s api_key field also defaults to None.
Setting vLLM’s key is not the end of the job. Its own security document warns that the flag authenticates “only for OpenAI-compatible API endpoints under the /v1 path prefix, and other similar /v2, /inference path prefix,” and that “Many other sensitive endpoints are exposed on the same HTTP server without any authentication enforcement.” One left outside that boundary is /invocations, which the same document calls “particularly concerning as it provides unauthenticated access to the same inference capabilities as the protected /v1 endpoints”. The document is blunt: “Do not rely exclusively on --api-key for securing access to vLLM.”
Ollama’s position is a stated design choice. A contributor submitted a working basic-auth implementation as PR #6223; on 25 November 2024 the maintainer declined it, writing that “we suggest doing this with a proxy in front of Ollama for the time being.” Authentication belongs to the layer in front of the engine.
| Project | Default bind | Default authentication |
|---|---|---|
| Ollama | 127.0.0.1:11434 | None on the local inference API |
| llama.cpp server | 127.0.0.1, port 8080 | None (--api-key default: none) |
| LM Studio | 127.0.0.1, port 1234 | Off |
| vLLM | --host unset, binds all interfaces | None; when set, covers only /v1, /v2, /inference |
| Open WebUI (front end, not a model server) | Port 8080 | Accounts required; new sign-ups start with zero access |
Three Ollama Scans, Three Different Measurements
Researchers have counted internet-reachable Ollama servers three times, and the three numbers are not points on one line. Cisco Talos ran a single Shodan snapshot and identified 1,139 exposed instances in that one scan, 214 of them (18.8%) with a live model loaded and responding. LeakIX, running a continuous scanning plugin, reported 12,269 instances exposed with zero authentication as its live count in February 2026. SentinelLABS and Censys, in a 293-day longitudinal scan, recorded 175,108 unique hosts cumulatively across that whole window, a total of everything seen at any point, not a census of what was reachable on a given day.
A one-off snapshot, a live count and a nine-month cumulative total answer three different questions, so none of them can be read against the others. They agree on the mechanism: the SentinelLABS write-up notes that “exposing Ollama to the public internet requires only a single configuration change.” All three studies looked for Ollama specifically. No equivalent scanning research for llama.cpp’s server, LM Studio or vLLM surfaced in the sources reviewed here, so these counts say nothing about how often those are reachable.
The Pattern the Projects Recommend for Themselves
None of the four engines has user accounts, roles or per-user history. Open WebUI does: the first account on a fresh install becomes admin, and later sign-ups take the DEFAULT_USER_ROLE, which ships as pending, a role documented with “Zero Access” until an administrator promotes them.
Its hardening guide is the clearest statement of the deployment shape, and it applies to the engine behind it. Open WebUI “is built for private, trusted networks,” and the guide says: “Do not expose it directly to the public internet without an additional access control layer in front of it.” The layers it names are “A VPN (WireGuard, Tailscale),” “A zero-trust access proxy (Cloudflare Access, Pomerium),” or “A reverse proxy with authentication and IP allowlisting.”
For a household or a small team the first of those is usually enough, and it is the honest default. WireGuard describes itself as “an extremely simple yet fast and modern VPN.” Tailscale Serve routes traffic “from other devices on your Tailscale network (known as a tailnet) to a local service running on your device,” with public sharing kept as a separate feature. Every laptop and phone joins the private network, and the model server never appears on the public internet. Where a reverse proxy is the only option, it has to carry the authentication the engine does not, which is what nginx’s ngx_http_auth_basic_module exists for.
Concurrency Is a Separate Ceiling
The second constraint is how many people the engine serves at once. Ollama’s documented default for OLLAMA_NUM_PARALLEL is 1 and OLLAMA_MAX_QUEUE is 512, past which “it will respond with a 503 error indicating the server is overloaded.” The memory cost is documented too: “a 2K context with 4 parallel requests will result in an 8K context and additional memory allocation.” A 2025 Red Hat benchmark of Ollama v0.9.2 recorded a default of four, so check the value on your own build.
llama.cpp’s server lists “Parallel decoding with multi-user support” and continuous batching on by default, with capacity set by -np, --parallel and a /slots endpoint that can return 503 when nothing is free. LM Studio batches through the same engine, with “Max Concurrent Predictions” set to 4 by default. vLLM is built around this case: its AsyncLLMEngine is “designed for online serving, where it can handle multiple concurrent requests and stream outputs to clients”.
The only fully documented head-to-head comes from Red Hat Developer, which measured vLLM at a peak of 793 tokens per second against Ollama’s 41, and P99 latency of 80 ms against 673 ms, on a single datacenter NVIDIA A100-PCIE-40GB running an 8B model at fp16. Red Hat sells an inference product built on vLLM, so it is not a disinterested party, and an A100 is not a consumer card. No sourced figure exists for how many concurrent users a consumer GPU supports.
What This Means
The gap between running a model and serving one is mostly a gap in defaults. Three of the four engines start on loopback and vLLM does not, all four start with no authentication, and vLLM’s --api-key covers only part of its own surface. The exposure counts, all Ollama-specific and each measuring something different, show what happens when that one-variable change gets made with nothing in front of it.
The Bottom Line
Serve to the LAN or to a private overlay such as WireGuard or Tailscale, and treat an authenticated reverse proxy as the exception rather than the plan. Check the bind address first, because vLLM’s default is not the one the other three taught you. Add Open WebUI if the household needs accounts, since no inference engine here provides them. Then size for concurrency, remembering that the published comparison was measured on a datacenter GPU.