# The Best Self-Hosted LLMs in 2026 — and How I Deployed Them

> Source: <https://dev.to/mryadavgulshan/the-best-self-hosted-llms-in-2026-and-how-i-deployed-them-24ie>
> Published: 2026-08-28 02:30:00+00:00

*A practical field guide to running open-weight LLMs on your own hardware — which models, which serving stacks, and the cost math nobody puts on a blog post.*

A fintech client called me in January with a problem that is getting more common by the month: their compliance team had banned every external AI API. No data leaves the building, they said. The analyst who wanted to chat with their internal documents would just have to wait. I told them they did not have to wait — they could run the model on hardware they already owned.

Three weeks later we had a 70B-class model serving the entire company on two GPU boxes, handling their document Q&A, their support triage, and a chunk of their internal code review. The cost per million tokens was a fraction of what the hosted API would have billed, the data never left the office, and the compliance team slept better. This article is that deployment, generalized: how I think about open-weight models, which ones I actually reach for, how I serve them, what the hardware math looks like, and the honest list of things that go wrong.

Let me state the case plainly, because there are good reasons and bad reasons to self-host, and you should know which one you have.

**The good reasons:**

**The bad reasons:**

Decide which column you are in before you spend a rupee on silicon.

The open-weight ecosystem moves fast, but the tiers have been stable enough to reason about. Here is how I categorize what is available today, and the hardware each tier realistically needs.

| Tier | Representative models | What it is good at | VRAM you need |
|---|---|---|---|
| Small (1–4B) | Phi-4, Llama 3.2 3B, Qwen 2.5 3B | Classification, extraction, routing, single-purpose tasks | 4–8 GB |
| Mid (7–14B) | Llama 3.1/3.3 8B, Qwen 2.5 14B, Mistral 7B | General chat, summarization, light reasoning on one GPU | 10–24 GB |
| Large (30–40B) | Qwen 2.5 32B, Llama 3.1 70B (quantized) | Strong reasoning, coding, agent loops on a single big GPU or two | 24–48 GB |
| Frontier open (70B+) | Llama 3.3 70B, DeepSeek R1 distill variants, Qwen 3 flagship | Best open quality; needs multi-GPU or heavy quantization | 48 GB+ |

The honest guidance: most production workloads do not need the frontier tier. A routing model that decides which sub-agent gets a task, an extraction model that reads invoices, a summarizer for internal reports — those are 3B to 8B jobs that run on a single GPU and answer in a few hundred milliseconds. Save the big models for the tasks where reasoning quality actually changes the business outcome.

The model file is only half the story. The serving layer decides your throughput, your latency, and how much of your weekend you spend fighting it. My recommendations, in order:

**Ollama — the start-here option.** A single binary, a `pull`

command, and an OpenAI-compatible endpoint out of the box. Perfect for one machine, one developer, or a small team that just needs a local model. It is not a serious production serving layer at scale — it will get you to the demo, then you migrate.

**llama.cpp — the edge and CPU option.** Runs quantized GGUF models on CPU, on Macs, on laptops, and even on Raspberry Pi-class hardware. When a client needs a model in the field with no GPU, llama.cpp is the tool. Expect modest tokens per second — fine for interactive use, wrong for high-throughput serving.

**vLLM — the production choice.** A continuous-batching serving engine that is OpenAI-API-compatible and designed to maximize throughput on GPUs. This is what I reach for the moment an app goes behind an endpoint that real users hit. PagedAttention keeps the GPU busy, and the API surface means your existing OpenAI client code does not change.

**Text Generation Inference (TGI)** — Hugging Face's serving stack. Also excellent, also OpenAI-compatible, a reasonable alternative to vLLM. I choose between them based on which has better support for the specific model and quantization I am running that week; they are close enough that your choice of one over the other rarely determines success.

**TensorRT-LLM / DeepSpeed** — for the teams with the engineering time to squeeze the last bit of performance and the models that benefit from it. If you do not have a full-time inference engineer, you do not need these.

Let me give you the numbers I actually use, because every tutorial says "you need a good GPU" and then stops. The math is simple: a model needs roughly its parameter count multiplied by the bytes per weight, plus the KV cache for concurrency.

So a single 24 GB RTX 4090 comfortably serves a 14B model in FP16 or a 70B model in 4-bit. Two 4090s handle a 70B with room for a real KV cache. One 48 GB workstation card or an A100 80 GB gives you frontier-tier headroom. A Mac with 64–128 GB of unified memory runs 70B-class GGUF models through llama.cpp with surprising grace — slower than a GPU, but silent and quiet in an office in a way two GPUs blasting in a rack never are.

The rule of thumb I give clients: **the KV cache is the part people forget.** Two users asking long questions can double your memory usage. Size your server for your concurrency, not for one benchmark prompt. I have seen a perfectly tuned single-user demo fall over at five concurrent users because the cache had nowhere to go.

Here is the deployment pattern I have shipped most often. On the GPU server, install vLLM and pull the model:

```
pip install vllm

vllm serve Qwen/Qwen2.5-32B-Instruct-AWQ \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 32768 \
  --quantization awq \
  --gpu-memory-utilization 0.92
```

A few choices worth explaining:

`--gpu-memory-utilization 0.92`

.`--max-model-len 32768`

.That command gives you an OpenAI-compatible endpoint at `http://localhost:8000/v1`

. Your application code does not change:

``` python
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed",  # vLLM is unauthenticated by default
)

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-32B-Instruct-AWQ",
    messages=[
        {"role": "system", "content": "You summarize internal support tickets."},
        {"role": "user", "content": "Summarize this ticket: ..."},
    ],
    temperature=0.2,
)
print(resp.choices[0].message.content)
```

The `api_key`

line is the sneaky detail — your existing code that hardcodes `OPENAI_API_KEY`

keeps working against a local server. That compatibility is exactly why vLLM is my default: migration from a hosted API becomes a one-line `base_url`

change.

Self-hosting is not "free AI." It is a new production system with its own failure modes. The list, in order of how much they have cost me:

**The demo dies under concurrency.** Single-user latency looks great; five users queue. The cause is almost always KV-cache memory or the serving engine not batching. Fix: set `--max-model-len`

to what you need, add a second GPU if the cache is the constraint, and load-test with your real prompt lengths before day one.

**Quantization quality is assumed, not measured.** You save 75% of VRAM with Q4 and never check whether the model still does your task. Fix: build a 50-question eval set, run it on FP16 and Q4, and compare. I have shipped models where the answer was identical on 95% of questions — and I have found tasks (exact number extraction is a classic) where quantization quietly breaks them.

**Model changes are not versioned.** Someone runs `ollama pull latest`

and the "same model" suddenly behaves differently in production. Fix: pin exact model and quantization versions, store them in your config, and treat model upgrades like any other breaking deploy.

**The GPU is idle at night and hot at noon.** If your traffic is spiky, you are paying for idle silicon and burning electricity. Fix: size for your 95th percentile, put a load-balancing layer in front, and if your peaks are rare, honestly compare against a hosted option for the overflow.

**Nobody owns the stack.** A self-hosted model is a server. It needs patching, backups, monitoring, and a person on call. The team that says "we self-host to save money" and has no one who understands the box usually ends up paying more in emergency engineering than they saved in API bills.

**Embedding models get forgotten.** Your LLM is self-hosted, but if your RAG pipeline still embeds with an external API, you have not actually achieved data sovereignty. Self-host your embedding model too — the same vLLM server can serve it.

The honest boundary, stated so you can check yourself:

Before you call a self-hosted deployment done:

The compliance-banned fintech client now runs a 32B Qwen model on one 24 GB GPU, serving the whole company, with the data never leaving the building. Their monthly bill for the box is a fixed number they can budget for; the API they replaced would have been metered and unpredictable. That is the real value of self-hosting — not just cheaper tokens, but ownership.

Start where I start: pick the smallest model that does the job, serve it with Ollama to prove the workflow, move to vLLM when real users show up, and write your own cost math before you buy a single GPU. The models will keep improving; the pattern will not.

*Gulshan Yad