For a single-user local chat setup on an RTX 3060 12GB, use llama.cpp — it is dramatically simpler to install, has excellent GGUF quantization support that lets 7B and 14B models fit with room to spare, and its single-stream tok/s on Ampere is competitive with vLLM. Reach for vLLM only when you are serving multiple concurrent users, want continuous batching, or need OpenAI-compatible endpoints for an internal team.
Single-user chat vs served throughput on a 12GB card
Local LLM tooling has consolidated in 2026 around two runtimes for the RTX 3060 12GB class of hardware. llama.cpp is the ubiquitous single-stream chat runtime that ships everywhere — from Ollama to LM Studio to your own build. vLLM is the paged-attention batching runtime that powers most self-hosted inference APIs when the goal is many users hitting one machine.
The choice matters more on a 12GB card than on a 24GB card, because a 12GB card cannot spare much VRAM for vLLM's KV cache overhead. That overhead is what pays off with batching — you need to actually run enough concurrent requests to fill the batch — and if you are one user chatting with one model, you paid the overhead and got no batching benefit.
We walk through what each runtime optimizes for, how they perform in the single-user case on a MSI RTX 3060 Ventus 2X 12G or ZOTAC RTX 3060 Twin Edge, what CPU and storage they demand, and the crossover point where vLLM's batching starts to win. Reference build: 3060 12GB, Ryzen 7 5800X, 32GB DDR4, Crucial BX500 1TB SSD for the model library.
Key takeaways
- llama.cpp is the right pick for one user, one chat window, on a 12GB card.
- vLLM's paged-attention wins when concurrent users >= 4 on a 12GB card.
- Quantization on a 3060 12GB: 7B fits at q6 or q8; 14B fits at q4 or q5; anything larger needs offload.
- vLLM's memory ceiling is lower than llama.cpp on the same card because of KV cache overhead.
- Pair the 3060 12GB with a fast SSD like the Crucial BX500 1TB; model loading is the surprise cost.
What does each runtime optimize for?
llama.cpp was built to run LLMs efficiently on any hardware — CPU-only, GPU-accelerated, or hybrid. Its dominant format is GGUF, a quantization-friendly binary format that supports every precision from Q2_K up through F16. It runs one request at a time, uses a single KV cache, and is optimized for low startup latency and low memory overhead. Its single-user tok/s on a 3060 for a 7B model is competitive with anything on the market. See the llama.cpp GitHub for the current build.
vLLM was built as an inference server, not a chat runtime. Its major innovation is PagedAttention — a way to store the KV cache in fixed-size pages so multiple concurrent requests can share GPU memory efficiently. It excels at continuous batching, where new requests join the batch on the fly rather than waiting for the current one to finish. Its throughput on a many-user workload is dramatically higher than any single-stream runtime. See the vLLM documentation for setup and supported models.
The tension is that PagedAttention is not free. vLLM reserves a chunk of GPU memory for its KV cache pool regardless of how many users you actually have. On a 12GB card that overhead — often 2-3GB — is a real bite from the model's memory budget.
Spec-delta table: llama.cpp vs vLLM on RTX 3060 12GB
| Attribute | llama.cpp | vLLM |
|---|---|---|
| Quantization | GGUF Q2-Q8, F16 | AWQ, GPTQ, FP16, some GGUF via extensions |
| VRAM overhead | Minimal | 2-3 GB for KV cache pool |
| Concurrency | 1 stream (native) | Native continuous batching |
| Setup effort | Easy (Ollama, LM Studio, or build) | Moderate (Python env, CUDA specifics) |
| CPU/GPU hybrid | Excellent CPU offload | Poor; GPU-only best case |
| Format | GGUF | Hugging Face transformer weights |
| Best model size (12GB) | Up to 14B q4/q5 | Up to 7B in FP16 or 13B AWQ |
The clean takeaway: if you are a single user chatting from one client, llama.cpp lets you run bigger models with better quantization. If you are running an internal chat service for a team of 5-10 people, vLLM will serve them more efficiently even accounting for its overhead.
How does llama.cpp perform on an RTX 3060 12GB for one user?
Numbers reported broadly across the community for a single user on a 3060 12GB using llama.cpp with GGUF quantization:
| Model | Quantization | Peak VRAM | Prefill tok/s | Generation tok/s |
|---|---|---|---|---|
| Llama 3.1 8B | Q5_K_M | 5.5 GB | 400 | 42 |
| Llama 3.1 8B | Q6_K | 6.5 GB | 380 | 38 |
| Qwen 2.5 7B | Q5_K_M | 5.3 GB | 410 | 45 |
| Qwen 2.5 14B | Q4_K_M | 8.5 GB | 220 | 22 |
| Qwen 2.5 14B | Q5_K_M | 10.0 GB | 210 | 20 |
| Mistral 7B | Q6_K | 6.2 GB | 400 | 40 |
Prefill tok/s reads the input prompt (batch of N tokens in parallel); generation tok/s produces one output token at a time. For most chat interactions, you feel generation tok/s more — it is what pours words into the window. A steady 40 tok/s on a 7B model reads fluidly; 20 tok/s on a 14B is still faster than you can read comfortably.
The TechPowerUp RTX 3060 spec page confirms the 360 GB/s memory bandwidth that shapes these tok/s numbers — generation is memory-bandwidth-bound, not compute-bound.
When does vLLM's paged-attention batching actually help?
vLLM starts winning when you have enough concurrent requests to fill the batch. On a 3060 12GB with a 7B AWQ quantized model, vLLM can typically batch 6-10 concurrent requests before it runs out of KV cache pool. At full batch, aggregate throughput crosses 200-300 tok/s.
For a single-user session, vLLM is roughly the same speed as llama.cpp on a 3060 12GB for the same model — sometimes a hair faster because of PagedAttention's efficient prefill, sometimes a hair slower because of the KV overhead. The crossover point is roughly 3-4 concurrent users: at that point, vLLM's batched throughput per user beats llama.cpp's serialized throughput even at 30% of vLLM's peak.
If you are hosting a chat endpoint for a team of 5-10 people, vLLM at $0 hardware cost delta wins. If you are a solo user with a chat client, llama.cpp's simpler ergonomics and larger effective model size are the win.
Quantization matrix on an RTX 3060 12GB
Same table as above but framed as "what actually fits":
| Precision | 7B model peak VRAM | 14B model peak VRAM | Quality vs FP16 |
|---|---|---|---|
| Q3_K_M (3.4 bits) | 3.5 GB | 6.5 GB | Noticeable, cheap emergency |
| Q4_K_M (4.5 bits) | 4.6 GB | 8.5 GB | Slight, workable daily driver |
| Q5_K_M (5.5 bits) | 5.5 GB | 10.0 GB | Very close to FP16 |
| Q6_K (6.5 bits) | 6.5 GB | ~11 GB (tight) | Effectively lossless |
| Q8_0 (8 bits) | 8.0 GB | Over 12 GB (won't fit) | Reference for 7B |
| FP16 | 14+ GB (won't fit) | Won't fit | Reference |
For a 3060 12GB, sensible defaults: 7B at Q5_K_M or Q6_K, 14B at Q4_K_M or Q5_K_M. Anything above 14B needs offload, which is a bad experience unless the model is compelling.
Prefill vs generation and context length on a 12GB card
Prefill is compute-bound — it processes N tokens of input in parallel. On a 3060, prefill is roughly 10x the tok/s of generation because it uses the GPU's parallel-compute strength.
Generation is memory-bandwidth-bound — one token at a time reads the whole model weight matrix once per token. The 3060's 360 GB/s bandwidth is your ceiling.
Long-context inputs (32K, 128K) put pressure on the KV cache, which grows linearly with context length. On a 12GB card, an 8B model at 32K context uses noticeably more VRAM than at 4K. Plan headroom.
Verdict matrix
Use llama.cpp if:
- You are one user chatting from one client
- You want the simplest possible setup (Ollama or LM Studio)
- You want to run 14B models at Q4 or Q5 on a 12GB card
- You occasionally need CPU offload for larger models
Use vLLM if:
- You are serving 4+ concurrent users from one endpoint
- You need an OpenAI-compatible API
- You have a stable model choice and need throughput
- You are comfortable managing a Python + CUDA environment
Common pitfalls
- Running FP16 weights on a 3060 12GB. Nothing above 7B fits. Use quantized.
- Assuming vLLM will be faster for one user. It usually is not; the KV overhead eats your advantage.
- Ignoring model-load time. Loading a 6GB quantized model from a slow disk is a minute-long wait. Put your model library on a Crucial BX500 SSD or similar SATA/NVMe.
- Skipping the CPU sizing. Prefill benefits from a capable CPU during warmup; a Ryzen 7 5800X at 8 cores is a comfortable pairing.
- Trying to run two vLLM instances on the same card. They will fight for KV cache. One vLLM per card.
- Confusing GGUF with AWQ. vLLM prefers AWQ/GPTQ; llama.cpp prefers GGUF. Format conversion is a real step.
When NOT to run local at all
If your workload is bursty (a handful of queries per day) or requires the frontier reasoning tier, keep an API subscription. Local wins on always-on, privacy-sensitive workloads and daily developer/writer flows. Local loses on very long context or the highest-quality reasoning.
Recommended pick
For a single user on a 3060 12GB: llama.cpp with a Q5_K_M 7B or 8B model as the daily driver. Ollama is the friendliest wrapper; LM Studio is friendlier still if you want a UI. Pair the MSI RTX 3060 Ventus 2X 12G or ZOTAC RTX 3060 Twin Edge with an AMD Ryzen 7 5800X and a Crucial BX500 1TB SSD for a build that boots into a working chat setup within an afternoon.
For a small team endpoint on the same card: vLLM with a 7B AWQ model. Expect 6-10 concurrent users at usable per-user throughput.
Related guides
- Flux 3 Native-Audio Video: Can a 12GB GPU Run It?
- Anthropic's 2GW AMD Deal: Should You Still Run Local?
- Ryzen 7 5800X vs Ryzen 5 5600G for a Budget Gaming Build
Citations and sources
- llama.cpp GitHub — build instructions, GGUF format, quantization details
- vLLM documentation — PagedAttention, continuous batching, supported models
- TechPowerUp RTX 3060 spec page — memory bandwidth and TDP reference
As of 2026, both runtimes continue rapid development; check the release notes before committing to a specific quantization scheme.
