AI Answer Library

What server specs do you need to self-host a large language model?

Short answer

Size everything backwards from VRAM; the rest is secondary. The rule of thumb is: weight memory ≈ parameter count × bytes per parameter × 1.2, where FP16 is about 2 bytes per parameter and INT4 about 0.5 — then add KV cache on top, which grows linearly with concurrency and context length. A 70B dense model therefore needs roughly 150 GB of VRAM at FP16 (multi-GPU, unavoidably) and can be squeezed to roughly 40 GB at INT4. CPU-only inference works, but only for one user at low frequency.

Key points

  • 01VRAM is the only hard gate. Core count, system RAM and disk are almost never the inference bottleneck: if the weights fit you can serve, and if they do not, no CPU saves you.
  • 02Quantisation is the highest-leverage cost lever. INT8/INT4 cuts memory to a half or a quarter at a manageable accuracy cost — but validate it on your own evaluation set, not on public leaderboards.
  • 03MoE models (the MoE lines of Qwen 3.x, DeepSeek V4 and GLM-5.x) activate only a fraction of their parameters per token, so they compute fast — but you must provision VRAM for the full parameter count, not the active subset.
  • 04Concurrency drives KV cache, which drives the real machine. Ten internal testers and five hundred live users are two different boxes, even for the same model.
  • 05Budget for everything around the model too: the vector store, the embedding and reranking models, and at least one rollback-ready previous checkpoint — together often several hundred gigabytes of storage.

Sizing hardware backwards from model scale

The table uses empirical values from common open-source serving stacks as of August 2026 and counts weight memory only, excluding KV cache. Use it for a first pass; real selection requires load testing at your target concurrency and context length, because at 128K context under high concurrency the KV cache can exceed the weights themselves.

Model scaleFP16 weight memory (approx.)After INT4 quantisation (approx.)Typical single-machine setupFits
7B–8B (small tiers of Llama 4 and Qwen 3.x)About 16 GBAbout 6 GBA single 24 GB consumer or workstation cardDepartmental pilots, summarisation, lightweight RAG
14B–32B (mid tiers of Qwen 3.x, distilled GLM-5.x)About 32–70 GBAbout 10–20 GBOne or two 48 GB workstation cardsEnterprise RAG, agent assist, structured extraction
70B dense (the Llama 4 dense line and peers)About 150 GBAbout 40 GBA 4–8 GPU chassis with 48–80 GB per cardCompany-wide primary inference, coding assistants, harder reasoning tasks
Trillion-parameter MoE (full DeepSeek V4, full GLM-5.x)Hundreds of gigabytes up to terabyte scaleStill hundreds of gigabytesA multi-node, multi-GPU cluster with high-speed interconnectCustomer-facing high-concurrency workloads, shared multi-team platforms

How to actually compute the memory requirement

Two parts. Weights: parameter count × bytes per parameter, times roughly 1.2 of headroom for activations and framework overhead. FP16 is 2 bytes per parameter, INT8 about 1, INT4 about 0.5. For example a 32B model needs about 32 × 2 × 1.2 ≈ 77 GB at FP16 and about 32 × 0.5 × 1.2 ≈ 19 GB at INT4. KV cache: it grows linearly with concurrent requests × context tokens, and under long context or heavy concurrency it easily exceeds the weights. In practice, pick cards from the weight figure, then treat leftover memory as the dial that sets your concurrency ceiling — when memory runs short, cut concurrency or context length before you downgrade the model.

What else matters besides the GPUs

System RAM should be at least as large as total VRAM, since weights pass through it on load. Use NVMe storage: a single model file runs from tens to hundreds of gigabytes, and once you add the vector store, embedding models and a rollback checkpoint, 1–2 TB is the starting point. On multi-GPU boxes, inter-card bandwidth matters — the same eight cards behave very differently over PCIe versus a high-speed fabric, especially at long context. Power and cooling are routinely underestimated: a loaded multi-GPU chassis draws kilowatts and a standard office rack usually cannot take it, so schedule facility work early. Finally, the network: in a RAG deployment the model is one component among several, and the vector store, document service and auth gateway need planning too — do not discover after delivery that there is nowhere to put the database.

Where this applies

When this answer does not hold

  • The table gives weight memory only, excluding KV cache. Under long context (128K, say) and high concurrency the KV cache can exceed the weights, so real selection requires load testing at your target concurrency and context length rather than copying the table.
  • These numbers shift with the serving framework, the quantisation scheme and whether paged-attention-style optimisations are enabled. They are empirical values from common open-source stacks as of August 2026, intended for first-pass sizing only.
  • Quantisation always costs some accuracy, and how much depends on the task: structured extraction tends to hold up, while long-chain reasoning and maths are more sensitive. Validate on your own evaluation set; leaderboard scores do not transfer.
  • Domestic accelerators and the mainstream NVIDIA ecosystem still differ in operator coverage, serving-framework support and long-context optimisation. Equal nominal VRAM does not mean equal usable throughput — insist on a benchmark on the actual hardware before buying.

People also ask

  • How much VRAM does a 70B model need?
  • How do you choose GPUs for on-premise LLM inference?
  • What does a self-hosted LLM server bill of materials look like?
  • Can you run a large language model without a GPU?
  • How many GPUs does LLM inference actually take?
Written by: YGG Solutions TeamPublished: 2026-08-01Last reviewed: 2026-08-01