Sizing worksheet · language models on bare metal · since 2004

What it takes to run a language model on bare metal.

Filled in from the top, the way the decision goes: the model sets the weights, the precision scales them, the head-room covers the runtime and the conversation, and the total names the card. Nothing else on the order form moves the answer — a card two gigabytes short does not run slower, it fails to load.

Drawn by
Primcast LLC, est. 2004
Checked against
The order catalogue, at serve time
Cards on file · largest
56 · 96 GB GDDR7 ECC
Prices on this sheet
None — see /gpu

Fill in the worksheet Why a fit can still fail What I install on it

Turn your GPUs into passive monthly revenue

Got idle server or desktop GPU setups? List them on the Primcast marketplace today and earn steady monthly rents from AI teams, developers, and enterprises needing production-grade compute.

Go to Marketplace

Worksheet

Four lines, one verdict.

The model
The precision
The duty

70B: 38 GB × 1.5 = 57 GB

Smallest card on the schedule that clears it (3 larger ones also do):

Instinct MI21064 GB HBM2e

The link opens the machine it goes in. What it costs is on /gpu — not on this sheet.

Line 1 × line 2 is the weights; line 3 is the site’s published quarter-to-a-half head-room rule as arithmetic — a quarter again for one user at a time on llama.cpp or Ollama, half again for serving traffic with continuous batching on vLLM or TGI. The verdict names the smallest card in the order catalogue that clears the total, and links to the machine it goes in. What that machine costs is deliberately not on this sheet: every figure is on /gpu, against the exact machine it belongs to.

Fig. 1

What the weights weigh.

Parameters multiplied by bytes per parameter, and that is the whole calculation. Sixteen-bit weights are two bytes each, eight-bit are one, four-bit are a half. Quantising is what turns a machine that cannot hold a model into one that can; it costs quality, and how much depends on the model and the method far more than the bit count alone. If accuracy is the point of the exercise, test both before committing to hardware — the difference is cheaper to discover now than after delivery.

These figures are the weights and nothing else. They are the floor, not the requirement — Fig. 2 is the part that catches people out.

Weights only — the runtime, the activations and the conversation are extra, and are the subject of the next section.
Model16-bit8-bit4-bit
7-8 billion parameters16 GB8 GB5 GB
13-14 billion parameters28 GB14 GB8 GB
30-34 billion parameters68 GB34 GB19 GB
70 billion parameters140 GB70 GB38 GB

Fig. 2 · interactive

One card’s memory, drawn to plan — and why a model that fits can still refuse to serve.

The most common way a GPU purchase goes wrong, every time the same way: the model is thirty-eight gigabytes, the card is forty, it loads — and holds roughly one short conversation. The weights are not alone in there. Slide the workload and watch what the conversation does.

weights · fixed
runtime
key-value cache · grows
free
one card’s memory, 100 %

One user, short context: the tight multiplier (×1.25) covers this.

  • Every token in a conversation leaves an entry in the key-value cache so it is not recomputed. The cache grows with context length, and again with every request served at once.
  • Budget a quarter again over the weights for one user at a time, half again for serving traffic — the two multipliers on the worksheet, and the site’s own published rule.
  • If it is close, ask before you buy: model, quantisation, context, concurrency. We would rather size you up a card now than take an order that comes back as a refund request in week one.

Fig. 3

The fit matrix: which card clears which model.

Read down to your model, across to the precision. Each cell names the smallest card on the parts schedule that holds those weights with room left to serve, and links to the machine it goes in. Where nothing clears it alone, the cell says so rather than leaving a blank.

The smallest card we fit that holds the weights with room left to serve — that is 1.5× the weights, the generous end of the quarter-to-a-half head-room rule below. No prices here on purpose: GPU dedicated servers holds every one.
If you want to runat 16-bitat 8-bitat 4-bit
7-8 billion parametersTESLA P40 / QUADRO P600024 GB16 GB of weightsTITAN V12 GB HBM28 GB of weightsTESLA P48 GB GDDR55 GB of weights
13-14 billion parametersRTX A600048 GB GDDR6 ECC28 GB of weightsTESLA P40 / QUADRO P600024 GB14 GB of weightsTITAN V12 GB HBM28 GB of weights
30-34 billion parametersMore than one cardNothing we fit holds it alone68 GB of weightsInstinct MI21064 GB HBM2e34 GB of weightsTesla V100 32GB32 GB HBM219 GB of weights
70 billion parametersMore than one cardNothing we fit holds it alone140 GB of weightsMore than one cardNothing we fit holds it alone70 GB of weightsInstinct MI21064 GB HBM2e38 GB of weights
  • The smallest card that fits is not always the card you want. Memory decides whether a model runs; everything else about the card decides how fast, and for how many people at once. If throughput matters more than budget, go a step up the schedule.
  • Older cards do not speak the newer number formats. Several parts on the schedule predate FP8 and bfloat16, so a runtime that expects them will fall back to something slower or refuse. Worth asking about a specific card and a specific runtime before ordering.
  • An AMD card runs ROCm, not CUDA. The Instinct parts are excellent value per gigabyte and are the answer in more than one cell, but your stack has to support ROCm. Most current runtimes do; some tooling around them still does not. Check yours, or ask and we will check it with you.
  • “More than one card” is a build we quote, not a checkout option — how many cards fit depends on the width of the specific card and the power budget of the chassis. Multi-GPU and multi-node is that sheet. The other answer at that size is 128 GB of memory the processor and GPU share, in one machine: renting an NVIDIA DGX Spark.

Schedule A

Parts schedule: every card we fit with a published memory figure.

Largest first — this sheet answers “what is the biggest thing I can run”, the reverse of GPU dedicated servers, which sorts the same catalogue by the cheapest complete machine because it is answering “what does this cost”. A card whose memory the manufacturer does not publish is left off rather than guessed at.

Several parts appear on more than one chassis, sometimes at different prices, and the bus generation of the machine underneath changes what a modern card can actually do — both are on GPU dedicated servers. What is standing racked and ready this minute is a different question again, answered by instant servers.

Reference

Named models, mapped to the rows.

The open-weight families people bring here, with the published parameter count that says which row of Fig. 1 applies. Parameter counts are the publishers’ own; nothing else about a model matters to the fit question. A model that is not on this list sizes exactly the same way — parameters × bytes per parameter, plus head-room. New families ship monthly; the arithmetic does not move.

Note 1 · mixture-of-experts

A “30B with 3B active” model needs a 30B model’s memory and runs nearer a 3B model’s speed: every expert must be resident, because different tokens wake different ones. Size from the total parameter count, always.

FamilySizesRow
Llama 3.1 / 3.3 Meta8B · 70B7–8B, and 70B for the 3.3 release
Qwen3 Alibaba8B · 14B · 32BThe first three rows
DeepSeek-R1 distills7B – 70BOne per row — pick the distill your card holds
Mistral Small 3 Mistral AI24BBetween rows 2 and 3; size it from the arithmetic, not the label
Gemma 3 Google12B · 27BRow 2, and just under row 3
Phi-4 Microsoft14BRow 2
gpt-oss OpenAI20B · 120BPublished at 4-bit natively: a 16 GB card, and one 80 GB card

Installation notes

The runtime is yours. That is the point of bare metal.

The machine arrives with a clean operating system and root. No vendor inference service in front of your model, no managed runtime that upgrades itself the week before a deadline. vLLM and Ollama both answer on an OpenAI-compatible endpoint — code written against an API provider points at your own machine by changing one base URL. Pin the driver, the CUDA or ROCm release and the framework to the versions your code was tested against; nothing moves underneath you. If you would rather the driver were installed before handover, say so on the order and name the version.

  1. vLLM — serving real traffic. Continuous batching and paged attention let one card answer many requests at once: the difference between a demo and a service. Wants a reasonably modern card.
  2. llama.cpp — memory tight, or the card older. Its quantised formats are why a large model fits a small card at all; it will use processor and card together when the weights do not quite fit.
  3. TGI · SGLang — production servers in the same family, with different strengths around structured output, prefix reuse and multi-model serving. Run here unchanged.
  4. Ollama — the shortest path from an empty machine to a model answering on a port. Ten minutes tells you whether your sizing was right.

Site conditions

What your own machine does that an API cannot.

The prompts never leave the building

Weights, prompts, retrieved documents and every generated token stay on hardware only you can log into. Amsterdam or Bucharest and the data sits in the EU; New York, Miami or San Francisco and it sits in the US. For workloads answering to a privacy officer, that sentence is the whole business case.

The meter never runs

A per-token API bills every token, and an agent or a batch pipeline generates tokens all day. A dedicated machine is the same figure every month at any volume, with unmetered bandwidth under it — weights in and tokens out cost nothing beyond the port. Which figure it is, is /gpu’s line to fill in, not this sheet’s.

Nobody rate-limits, deprecates or swaps the model underneath you

The model you pin answers unchanged in six months. No requests-per-minute ceiling, no queue at somebody else’s busy hour, no sunset notice. The trade is honest: upgrades are yours, on your schedule.

The work beside the model has a home

Retrieval wants an embedding model, a vector store and fast disk; agents want room to run tools. NVMe for the store, processor cores for the pipeline, the card for the tokens — one machine carries all of it.

Note 2 · ratings

No tokens-per-second figure appears on this sheet.

Deliberately. Every such number depends on the model, the quantisation, the runtime and its version, the batch size, the prompt length, the reply length and the concurrency — change any one and it moves by a multiple. A headline number that does not carry all of that is a number chosen to look good, and we would be quoted on it. What governs it: reading the prompt is compute-bound and happens once per request; generating the reply is memory-bandwidth-bound, because each token requires reading the weights; batching amortises that reading across concurrent requests, until the key-value cache runs out of room. Head-room again.

Ask for a real answer instead

Tell us the model, the quantisation you intend, the context length and roughly how many concurrent requests. If we have run something comparable we will say what we saw and on what. If we have not, we will say that too.

Every hour of every day — telephone, chat and tickets. Support has the response times in writing.

Note 3 · fine-tuning

Training needs considerably more room than serving.

Serving needs the weights. Training needs the weights, the gradients and the optimiser’s state for every parameter it updates, all resident at once, plus the activations kept for the backward pass — a model that serves comfortably on one card can be several times too large to fully fine-tune on it. Parameter-efficient methods update a small fraction of the parameters and need a correspondingly small fraction of the extra memory, which is why most fine-tuning here uses one. The training loop also streams batches across the processor-to-card link continuously, so the PCIe generation of the machine underneath is a real constraint there in a way it is not for serving — which platform gives a card which link is on GPU dedicated servers. Tell us the model, the method, the sequence length and the dataset size and we will size it rather than have you find out after delivery; more than one card is multi-GPU and multi-node’s sheet.

Queries raised

Asked on previous revisions of this sheet.

Taken from what people actually ask us in chat and on tickets, in roughly the order they ask it. The first three are the ones that decide whether a purchase works.

How much GPU memory does a large language model need?
The weights are the parameter count multiplied by the bytes per parameter: two bytes each at 16-bit, one at 8-bit, half at 4-bit. A 7–8 billion parameter model is 16 GB of weights at 16-bit, 8 GB at 8-bit and 5 GB at 4-bit; a 70 billion parameter model is 140 GB, 70 GB and 38 GB. Those figures are the weights alone and are a floor rather than a requirement — budget a quarter to a half again on top for the runtime, the activations and the key-value cache.
What do I need to run a 70B model like Llama 3.3?
At 4-bit the weights are about 38 GB, so with serving head-room the answer is a card of 64 GB or more — one card, one machine. At 8-bit the weights are 70 GB and an 80 GB card clears the bar. At full 16-bit precision no single card we fit holds it, and it becomes a multi-card build we quote. Fig. 3 above names the exact cards; the prices are on GPU dedicated servers.
Why does my model load but fail to serve?
Because the weights are not the only thing in card memory. The runtime and its buffers are resident, and every token in a conversation leaves an entry in the key-value cache so it does not have to be recomputed. That cache grows with the context length and again with each request served concurrently, so a model whose weights only just fit will hold roughly one short conversation. Size the card at one and a quarter to one and a half times the weights.
Which inference runtime can I install?
Any of them. The machine arrives with a clean operating system and root, and there is no vendor inference service in front of it. vLLM is the usual answer for serving real traffic because continuous batching lets one card answer many requests at once. llama.cpp is the usual answer when memory is tight or the card is older. TGI and SGLang run unchanged. Ollama is the shortest path from an empty machine to a model answering on a port — and vLLM and Ollama both answer on an OpenAI-compatible endpoint, so existing client code points at your own machine by changing one base URL. You pin the driver, the CUDA or ROCm release and the framework to the versions your code was tested against.
Is self-hosting an LLM cheaper than a per-token API?
It depends entirely on volume, and the crossover is real: an API bills per token and costs nothing when idle; a dedicated machine is a flat monthly figure and costs nothing more when busy. Steady traffic, agents that run all day, batch pipelines and anything with a privacy requirement tend to come out ahead on their own hardware; a workload that fires ten times a day does not. The monthly figures to do that arithmetic with are on GPU dedicated servers — this sheet deliberately prices nothing.
How many tokens per second will I get?
We do not publish a tokens-per-second figure, because every such number depends on the model, the quantisation, the runtime and its version, the batch size, the prompt length, the reply length and the concurrency, and changing any one moves it by a multiple. What governs it: reading the prompt is compute-bound and happens once per request; generating the reply is memory-bandwidth-bound because each token requires reading the weights; and batching amortises that reading across concurrent requests, which is what makes serving economical until the key-value cache runs out of room. Ask with the model, quantisation and expected concurrency for an answer based on what we have actually observed.
Is the GPU shared with anyone else?
No. One tenant per physical machine, and the card is passed through to your own operating system. There is no hypervisor, no MIG partition, no vGPU profile and no time-slicing scheduler, so nothing else runs on the card and inference latency does not move because of somebody else’s batch job.
What if the model does not fit on one card?
Then it is a multi-card build, which is quoted rather than ordered from a checkout: how many cards fit depends on the physical width of the specific card and the power budget of the chassis. Two cards give you the sum of their memory only if the runtime can split the model across both, which every serious runtime supports at some cost in throughput. More than one card or machine covers what that build looks like.
Does fine-tuning need more memory than serving?
Considerably more. Serving needs the weights; training needs the weights, the gradients and the optimiser state for every parameter being updated, all resident at once, plus the activations kept for the backward pass. A model that serves comfortably on one card can be several times too large to fully fine-tune on it. Parameter-efficient methods update a small fraction of the parameters and need a correspondingly small fraction of the extra memory, which is why most fine-tuning here uses one.
Can I run an AMD card, and does ROCm work?
Yes. The AMD Instinct parts are among the largest-memory cards we fit and are frequently the best value per gigabyte, but your stack has to support ROCm rather than CUDA. Most current inference runtimes do; some surrounding tooling still does not. Ask before ordering and we will check it against your specific runtime rather than answer in general.

For the record

Everything on this sheet, as figures.

Card memory is the manufacturers’ published figure; which cards exist is read from the order catalogue when this page was served. No monthly price appears here on purpose — GPU dedicated servers holds every one, against the exact machine it belongs to.

What decides whether a model runs
Card memory, and almost nothing else on the order form. The weights either fit or they do not — a card a couple of gigabytes short does not run slower, it fails to load. Clock speed and core count decide how fast it is once it fits.
How much memory a model needs
Parameters multiplied by bytes per parameter: two bytes each at 16-bit, one at 8-bit, half at 4-bit. That is the WEIGHTS. The runtime, the activations and the key-value cache for the conversation live in the same memory, so budget a quarter to a half again on top before choosing a card.
Largest model on a single card here
70 billion parameters at 4-bit, with room left to serve. Past that the answer is more than one card in one machine, which is a build we quote rather than a checkout option — multi-GPU and multi-node is the page for it.
Biggest card we fit
RTX PRO 6000 Blackwell 96GB, 96 GB GDDR7 ECC. Card memory figures are the manufacturers' published ones; a card whose figure we could not source is left out of the comparison rather than guessed at.
Which runtime
Yours. The machine arrives with a clean operating system and root, and you install vLLM, llama.cpp, TGI, SGLang, Ollama or anything else, pinned to the version your code was tested against. Nothing upgrades underneath you, and there is no vendor runtime you have to go through.
Throughput
We publish no tokens-per-second figure, deliberately, because we have not measured one under conditions we would be willing to have quoted back at us. What governs it is the card's memory bandwidth while generating, its arithmetic while reading the prompt, and how many requests you batch. Ask with the model, the quantisation and the expected concurrency and we will say what we have actually seen.
Fine-tuning and training
Both are ordinary work here, and both need considerably more memory than serving the same model: gradients and optimiser state sit alongside the weights. A parameter-efficient method needs a fraction of what a full fine-tune does. Tell us the method and the model and we will size it rather than have you find out after delivery.
Tenancy
One tenant per physical machine and the card passed straight through to your operating system. No hypervisor, no MIG partition, no vGPU profile, no time-slicing scheduler, and nobody else's workload on the card. What you measure on the first afternoon is what you keep.
Bandwidth
Unmetered in both directions at every port speed, with no transfer allowance and no egress line on any invoice. Pulling weights down and serving tokens back out costs nothing beyond the port.
What this page does not price
Cards, or anything else. Every card we fit, what each adds per month and what the machine under it costs are on GPU dedicated servers, each figure against the exact machine it belongs to.