Local AI infrastructure
Model memory and GPU fit
How much memory does this model need, and does it fit on these GPUs?
Size a model, a context and a GPU setup before you download or buy anything.
1 · Model
Qwen3-8B
Qwen
Model card on Hugging Face(opens in a new tab)config.json(opens in a new tab)
- Parameters
- 8.19B
- Layers
- 36
- Heads
- 32 query, 8 KV
- Head dimension
- 128
- Maximum context
- 40,960 tokens
- KV cache per token, 16 bit
- 144 KiB/token
- Hidden size
- 4,096
- Vocabulary
- 151,936
Values read from the config.json on Hugging Face on October 30, 2026.
These values come from Hugging Face and cannot be edited. Customize to change them.
2 · Precision
How many bits store each parameter.
›Published quantizations
Applies to quantized formats only.
Set apart from the weights. FP8 halves the cache.
3 · Workload
Tokens per sequence, prompt and generated text together.
Requests processed at the same time, the batch.
4 · Hardware
RTX PRO 6000 Blackwell Server Edition
NVIDIA · Blackwell
Memory
96 GB
GDDR7 · counted as 96 GiB
Bandwidth
1,597 GB/s
Max power
300 to 600 W
Configurable.
Bars compare each figure with the largest GPU in the catalogue.
- NVLink
- None
- MIG instances
- 4
- NVLink group
- None, PCIe only
- GPUs per server
- up to 8
How it is built into servers
- The Server Edition lists no NVLink. NVIDIA-Certified RTX PRO servers hold up to 8 GPUs. NVIDIA RTX PRO 6000 Blackwell Server Edition(opens in a new tab)
Dividing this GPU
MIG
Divides into 4 memory slices and 4 compute slices, up to 4 instances on one GPU. The profiles:
- 1g.24gb
- 2g.48gb
- 4g.96gb
Where an instance may start:Derived
vGPU for Compute
10 types with 8 to 96 GB of framebuffer, up to 12 vGPUs on one GPU. It needs an NVIDIA AI Enterprise licence and a hypervisor.
Sharing without dividing
Time-slicing works on any GPU, with no memory or fault isolation between the replicas. MPS shares a whole GPU, not a MIG instance.
Number formats
Documents at NVIDIA
›Specifications and sources
- Memory
- 96 GB[1]
- Type
- GDDR7[1]
- Bandwidth
- 1,597 GB/s[1]
- Max power
- 300 to 600 W[2]Configurable.
- NVLink
- 0[3]Not supported.
- MIG instances
- 4[4]
- FP4
- 4,000 TFLOPS[1]NVIDIA does not say dense or sparse.
- FP8
- 2,000 TFLOPS[1]NVIDIA does not say dense or sparse.
- FP16 / BF16
- 1,000 TFLOPS[1]NVIDIA does not say dense or sparse.
- TF32
- 234 TFLOPS[1]NVIDIA does not say dense or sparse.
Number formats: FP4, FP8, FP16, BF16, TF32, FP32
Tensor figures are peak values from datasheets. They are not application performance.
Sources
Loading sources
GPUs in all. They share the model by tensor parallelism, pipeline stages and replicas, as the layout below sets.
1 server of 8 GPUs, the last one with 1
How the GPU is used
Divide each GPU into slices or share it between replicas instead of using more GPUs. Slices and shares run replicas of the model: they cannot be joined into a tensor-parallel group.
›Deployment layout
How the GPUs share the model. The memory per GPU, the KV cache room and the GPU counts follow from it, the way vLLM divides them.
Pipeline stages
Splits the layers into runs on different GPUs. Little data crosses between stages, so it suits GPUs without a fast link and servers joined by a network.
Replicas
Independent copies of the model, each with its own KV cache. They share the sequences. A mixture-of-experts model spreads its experts over all of them.
Tensor parallel size: 1, the GPUs divided by the stages and the replicas.
GPUs per server
Tensor parallelism stays inside a server. Beyond it the GPUs become pipeline stages.
Decode context parallel size
Splits the KV cache of every sequence by token over the tensor-parallel GPUs. It adds no GPUs and slows decoding.
Only for mixture-of-experts models.
Runtime assumptions›3 GiB overhead per GPU, 90 % usable, 10 % headroom
Memory for the CUDA context, activations and graphs, in the unit of the page. A heuristic.
Share of the GPU memory the serving engine may use. vLLM's default is 92 percent.
Share of the usable memory that should stay free for a comfortable fit.
This model has no sliding window layers.
Fits with headroom
Needs 22.76 GiB per GPU. 63.64 GiB of the 86.4 GiB usable stay free, more than the 10 % margin you asked for.
Required memory per GPU
22.76 GiB
of 86.4 GiB usable
Remaining memory per GPU
63.64 GiB
73.66 % of the usable memory is free
Raw weight size
15.26 GiB
Parameters × nominal bits
Total estimated memory
22.76 GiB
Total GPU memory
96 GiB
Memory of one GPU
Memory on each GPU
GPU memory 96 GiB
- Weights in memory15.26 GiB67.04 %
- KV cache4.5 GiB19.77 %
- Runtime overhead3 GiB13.18 %
Memory budget
| Part | Memory |
|---|---|
| Raw weight sizeParameters × nominal bits | 15.26 GiB |
| Weights in memory | 15.26 GiB |
| Runtime overhead | 3 GiB |
| Model with runtime overhead | 18.26 GiB |
| KV cache | 4.5 GiB |
| Total | 22.76 GiB |
KV cache room
The engine could hold 496,206 tokens of KV cache in what is left after the weights and the overhead, enough for 60.57 sequences of 8,192 tokens.
vLLM prints this as its KV cache capacity at startup. The real capacity is a little lower: the cache is stored in blocks.
GPU count
Memory minimum
1
TP 1
26.34 % of usable memory, 63.64 GiB free per GPU
The fewest GPUs whose memory holds the model in any division. The layout may not be one vLLM accepts.
Smallest valid split
1
TP 1
26.34 % of usable memory, 63.64 GiB free per GPU
The fewest GPUs in a layout vLLM accepts: tensor parallelism inside a server, pipeline stages beyond it.
Recommended
1
TP 1
26.34 % of usable memory, 63.64 GiB free per GPU
A valid split that also keeps your headroom.
Each GPU must hold its own share, so the memory of several GPUs is not one pool. More than eight GPUs usually means several servers.
Memory per GPU by GPU count
Each bar is one GPU count, with the layout vLLM's guidance prefers for it. The line is the usable memory. Choose a bar to use that count.
- Usable 86.4 GiB
- Headroom limit
- Weights in memory
- KV cache
- Runtime overhead
- Star: recommended
- Diamond: smallest valid split
- Circle: memory minimum
- Outlined: in use
- Faded, dashed: vLLM would not start this layout
›Show as a table
| GPUs | Layout | Per GPU | Fit |
|---|---|---|---|
| 1 | TP 1 | 22.76 GiB | Fits with headroommemory minimum, smallest valid split, recommended, in use |
| 2 | TP 2 | 12.88 GiB | Fits with headroom |
| 3 | TP 3vLLM would not start this layout | 9.77 GiB | Fits with headroom |
| 4 | TP 4 | 7.94 GiB | Fits with headroom |
| 5 | TP 5vLLM would not start this layout | 7.18 GiB | Fits with headroom |
| 6 | TP 3 × PP 2vLLM would not start this layout | 6.39 GiB | Fits with headroom |
| 7 | TP 7vLLM would not start this layout | 6.3 GiB | Fits with headroom |
| 8 | TP 8 | 5.47 GiB | Fits with headroom |
| 9 | TP 1 × PP 9 | 6.1 GiB | Fits with headroom |
| 10 | TP 2 × PP 5 | 5.27 GiB | Fits with headroom |
| 11 | TP 1 × PP 11 | 5.61 GiB | Fits with headroom |
| 12 | TP 4 × PP 3 | 4.74 GiB | Fits with headroom |
| 13 | TP 1 × PP 13 | 5.13 GiB | Fits with headroom |
| 14 | TP 2 × PP 7 | 4.79 GiB | Fits with headroom |
| 15 | TP 1 × PP 15 | 5.13 GiB | Fits with headroom |
| 16 | TP 8 × PP 2 | 4.23 GiB | Fits with headroom |
What fits at other contexts and concurrency
Each cell is the memory one GPU needs at that context and number of sequences, on the GPUs and layout you have set. Choose a cell to use it.
Sequences ↓Context, in tokens →
| 2K | 4K | 8K | 16K | 32K | 40Kmodel max | |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 4 | ||||||
| 16 | ||||||
| 64 | ||||||
| 128 | ||||||
| 256 | ||||||
| 512 | ||||||
| 1024 |
- Check: fits with headroom
- Triangle: fits, without the headroom you asked for
- Cross: does not fit
- Outlined: in use
Ways to change the setup
Room to grow
This setup fits with headroom. This is how far it could be pushed.
The context could grow to 40,960 tokens at 4 sequences
Then: fits with headroom, 47.17 % of usable memory
Up to 52 concurrent sequences fit at 8,192 tokens
Then: fits with headroom, 88.84 % of usable memory
Deploy this setup
These commands are written for the setup you sized above and the choices you make here, and change with either. Nothing is changed for you: a choice that stops working is kept and marked, with ways to fix it.
The server
Run it with
Runtime
The server that loads the model.
GPUs
The indices of the GPUs on the machine, as nvidia-smi lists them, separated by commas. The setup uses 1 GPU.
Identify the GPUs by
An index depends on the order the driver finds the GPUs. A UUID is tied to the card.
Endpoint
The port the endpoint answers on. 8000 (default)
Listen on
The default keeps the endpoint on this machine.
The endpoint answers only to requests that carry a key. The key is made on your machine and is never written in a command or a link.
More options
Where the downloaded weights are kept. A directory that exists already saves the download.
The default is the release these commands were written for. latest follows the newest.
What will run
vLLM · Docker · 1 GPU, RTX PRO 6000 Blackwell
- Repository
- Qwen/Qwen3-8BFrom the calculator
- Runtime
- vLLMDefault
- Run with
- DockerDefault
- GPUs
- 1 GPU, RTX PRO 6000 BlackwellFrom the calculator
- index 0Default
- Context
- 8,192 tokensFrom the calculator
- Sequences per replica
- 4Worked out
- Memory per GPU
- 22.76 GiB needed of 86.40 GiB usable
- Share of each GPU for the engine
- 90 percentWorked out
- Access
- OpenFrom the calculator
- Endpoint
- 127.0.0.1:8000Default
Worth a look
You sized a fp16 KV cache for bf16 weights. A 16 bit cache takes the same room in either type, and vLLM stores it in the model's own type unless told otherwise, so the commands do not force fp16.
16 steps in 5 phases. Open one at a time, or all of them.
1Check the hardware
Look at what the machine or cluster offers before you change anything.3 steps
- Step 1
Check the driver
Confirm that the NVIDIA driver is installed and new enough for the software below.
nvidia-smiWhat you should see
- A table with the driver version and a CUDA version of at least 13.0, which the image needs.
Help and sources
If it does not work
- If the CUDA version is lower than the software needs, update the driver and check again.
Where the values come from
- The GPU you chose: RTX PRO 6000 Blackwell.
- Step 2
Check the GPUs
Confirm that the machine lists the GPU at index 0.
nvidia-smi -LWhat you should see
- One line for each GPU, each naming RTX PRO 6000 Blackwell the way the machine spells it.
Help and sources
If it does not work
- If a GPU you chose is missing, it is not in this machine or the driver cannot see it.
- If the names do not match what you expect, the indices are not what you think. Identify the GPUs by UUID, which does not depend on the order.
Where the values come from
- The calculator uses 1 GPU.
- The GPU you chose: RTX PRO 6000 Blackwell.
- Step 3
Check that the memory is free
The calculator expects 22.76 GiB on each GPU, of the 86.40 GiB the engine may use. Check that the memory of the GPU at index 0 is free.
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv -i 0What you should see
- Nearly all the memory of the GPU is free, at least 22.76 GiB on each.
Keep in mind
- Other work may already use these GPUs. If their memory is not free, stop that work or choose other GPUs before you start.
Help and sources
Where the values come from
- The calculator: 22.76 GiB needed of 86.40 GiB usable on each GPU.
2Prepare
Get access to the model, install what the server needs and fetch it. A divided GPU is made here too.2 need administrator rights5 steps
Install the tools
- Step 4
Check Docker
Confirm that Docker Engine is installed.
docker --versionWhat you should see
- A Docker version.
Help and sources
- Step 5
Install the NVIDIA Container Toolkit
Needs administrator rightsIt lets containers use the GPUs. These commands are for Ubuntu and Debian, and the page linked below has the other distributions.
Comes after step 1
sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \ && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update export NVIDIA_CONTAINER_TOOLKIT_VERSION=1.20.1-1 sudo apt-get install -y \ nvidia-container-toolkit=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ nvidia-container-toolkit-base=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container-tools=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container1=${NVIDIA_CONTAINER_TOOLKIT_VERSION}What you should see
- The packages install without errors.
Help and sources
- Step 6
Connect Docker to the GPUs
Needs administrator rightsRegister the NVIDIA runtime with Docker and restart it.
sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart dockerWhat you should see
- No errors, and Docker comes back up.
Keep in mind
- Restarting Docker stops the containers that are running.
Help and sources
- Step 7
Check that a container sees the GPUs
Run nvidia-smi in a container that is given the GPU at index 0. Only that GPU should appear.
docker run --rm --runtime=nvidia --gpus '"device=0"' \ ubuntu nvidia-smiWhat you should see
- A table with one GPU, the ones you chose.
Help and sources
If it does not work
- If Docker cannot start with the GPUs, the toolkit is not configured or the indices do not exist on this machine.
- If the names do not match what you expect, the indices are not what you think. Identify the GPUs by UUID, which does not depend on the order.
- NVIDIA Container Toolkit: sample workload(opens in a new tab)
- NVIDIA Container Toolkit: Specialized configurations with Docker(opens in a new tab)
Where the values come from
--gpus '"device=0"'Default The first GPUs, counted from 0.
Get the server
- Step 8
Download the image
Download vllm/vllm-openai:v0.32.0 before the first start, so that the start only has to load the model.
docker pull vllm/vllm-openai:v0.32.0What you should see
- The download completes and the last line names the image.
Keep in mind
- The image is several gigabytes.
3Start the server
Start it with the setup you sized.1 step
- Step 9
Start the server
Start vllm-qwen3-8b with the setup you sized: the model Qwen/Qwen3-8B, the parallelism, the context and the memory it was given. The first start downloads the model and takes a few minutes.
Comes after step 3
# config YSTVGT docker run -d --name vllm-qwen3-8b \ --runtime nvidia --gpus '"device=0"' \ --ipc=host \ -v "$HOME/.cache/huggingface":/root/.cache/huggingface \ -p 127.0.0.1:8000:8000 \ vllm/vllm-openai:v0.32.0 \ --model Qwen/Qwen3-8B \ --max-model-len 8192 --max-num-seqs 4 \ --gpu-memory-utilization 0.90What you should see
- A container id.
Keep in mind
- The first start downloads the model and prepares the kernels, which takes minutes. The server is not ready before that.
Help and sources
If it does not work
- If it stops with an out of memory message, the setup needs more than the GPU holds. Lower the context or the sequences, give the engine more of the GPU, or use more GPUs. The calculator shows by how much.
- If vLLM says the context is longer than the KV cache can hold, lower the context or the number of sequences.
- If vLLM says the attention heads cannot be divided by the tensor parallel size, use a size that divides them.
- If the port is taken, choose another one in your choices.
- If Docker cannot start with the GPUs, the toolkit is not configured or the indices do not exist on this machine.
Where the values come from
-dDefault How you chose to run it.
--name vllm-qwen3-8bFrom the calculator The repository of the model you chose.
--runtime nvidiaDefault How you chose to run it.
--gpus '"device=0"'Default The first GPUs, counted from 0.
--ipc=hostDefault How you chose to run it.
-v "$HOME/.cache/huggingface":/root/.cache/huggingfaceDefault Where the downloaded weights are kept.
-p 127.0.0.1:8000:8000Default The port the endpoint answers on.
--model Qwen/Qwen3-8BFrom the calculator The repository of the model you chose.
--max-model-len 8192From the calculator The context length you set: 8,192 tokens.
--max-num-seqs 4Worked out 4 sequences shared by 1 replica.
--gpu-memory-utilization 0.90Worked out The usable share you set, 90 percent, divided between 1 replica on the device, rounded down so the shares never add up to more than the device.
- The repository of the model you chose.
- The context length you set: 8,192 tokens.
- The usable share you set, 90 percent, divided between 1 replica on the device, rounded down so the shares never add up to more than the device.
4Check that it works
Wait until it answers, ask it something, and compare the memory with the calculator.6 steps
Check the endpoint
- Step 10
Wait until it is ready
The server answers /health once the model is loaded.
timeout 900 bash -c 'until curl -fs http://127.0.0.1:8000/health >/dev/null; do sleep 5; done' && echo readyWhat you should see
- The word ready, after a minute or more while the model loads.
Help and sources
If it does not work
- If it does not become ready, read the last log lines: the model is still loading, or the server stopped with an error.
- If it stops with an out of memory message, the setup needs more than the GPU holds. Lower the context or the sequences, give the engine more of the GPU, or use more GPUs. The calculator shows by how much.
- Step 11
Check that the model is served
Ask the server which models it serves.
curl -sS http://127.0.0.1:8000/v1/modelsWhat you should see
- A list with Qwen/Qwen3-8B in it.
Help and sources
If it does not work
- If the answer is 401, the key in this shell is not the one the server was started with.
- Step 12
Ask it something
One request through the endpoint your applications will use.
curl -sS http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Say hello in five words."}], "max_tokens": 32}'What you should see
- A JSON answer with a message from the model.
Help and sources
If it does not work
- If the answer is 401, the key in this shell is not the one the server was started with.
- If it does not become ready, read the last log lines: the model is still loading, or the server stopped with an error.
Look at the machine
- Step 13
Look at the GPUs
See the memory in use and the work on the GPU at index 0 while the server runs.
nvidia-smi --query-gpu=index,name,memory.used,memory.total,utilization.gpu --format=csv -i 0What you should see
- Memory in use close to what the engine was given.
Help and sources
- Step 14
Look at the server
See that vllm-qwen3-8b is running, and what it last said.
Comes after step 12
docker ps --filter name=vllm-qwen3-8b --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' docker logs --tail 20 vllm-qwen3-8bWhat you should see
- The server is running, and its last log lines show no errors.
Help and sources
Compare with the calculator
- Step 15
Compare with the calculator
The calculator expected 22.76 GiB on each GPU, with 90 percent of the GPU given to the engine. The server's own log says what it took for the weights and what is left for the KV cache.
Comes after step 12
docker logs vllm-qwen3-8b 2>&1 | grep -E 'Model loading took|Available KV cache memory|GPU KV cache size'What you should see
- Lines with the memory the weights took, the memory left for the KV cache and how many tokens it holds.
Help and sources
Where the values come from
- The calculator: 22.76 GiB needed of 86.40 GiB usable on each GPU.
5Clean up
Stop the server and remove what these steps made.1 step
- Step 16
Stop it
Can stop or remove thingsStop vllm-qwen3-8b and free the GPUs.
Comes after step 9
docker stop vllm-qwen3-8b && docker rm vllm-qwen3-8bWhat you should see
- No output, and the GPUs are free.
Keep in mind
- The endpoint stops answering.
Help and sources
Calculation
- Your input
- Official specification
- Calculated result
- Estimate
- Heuristic
- Assumption
›Weights
Raw weight size
Calculated resultRaw weight size = parameters × nominal bits per parameter ÷ 8
= Your input: 8.19B parameters × Official specification: 16 bit/param ÷ 8
= 15.26 GiB
Weights in memory
Calculated resultWeights in memory = parameters × effective bits per parameter ÷ 8
= Your input: 8.19B parameters × Official specification: 16 bit/param ÷ 8
= 15.26 GiB
›KV cache
KV cache per token
Calculated resultKV cache per token = 2 × layers with a KV cache × KV heads × head dimension × KV cache bits per value ÷ 8
= 2 × Your input: 36 × Your input: 8 × Your input: 128 × Your input: 16 bit ÷ 8
= 144 KiB/token
KV cache per sequence
Calculated resultKV cache per sequence = KV cache per token × context length
= Calculated result: 144 KiB/token × Your input: 8,192 tokens
= 1.13 GiB
KV cache
Calculated resultKV cache = KV cache per sequence × concurrent sequences
= Calculated result: 1.13 GiB × Your input: 4
= 4.5 GiB
›Memory per GPU and in total
Required memory per GPU
EstimateRequired memory per GPU = Weights in memory + KV cache + Runtime overhead
= Calculated result: 15.26 GiB + Calculated result: 4.5 GiB + Heuristic: 3 GiB
= 22.76 GiB
Model with runtime overhead
EstimateModel with runtime overhead = Weights in memory + Runtime overhead
= Calculated result: 15.26 GiB + Heuristic: 3 GiB
= 18.26 GiB
›Fit on the GPU
Usable memory per GPU
EstimateUsable memory per GPU = GPU memory × usable share ÷ 100
= Official specification: 96 GiB × Assumption: 90 % ÷ 100
= 86.4 GiB
Comfortable limit per GPU
EstimateComfortable limit per GPU = Usable memory per GPU × (100 − required headroom) ÷ 100
= Estimate: 86.4 GiB × (100 − Assumption: 10 %) ÷ 100
= 77.76 GiB
Remaining memory per GPU
EstimateRemaining memory per GPU = Usable memory per GPU − Required memory per GPU
= Estimate: 86.4 GiB − Estimate: 22.76 GiB
= 63.64 GiB
Utilization of usable memory
EstimateUtilization of usable memory = Required memory per GPU ÷ Usable memory per GPU × 100
= Estimate: 22.76 GiB ÷ Estimate: 86.4 GiB × 100
= 26.34 %
›KV cache room
Memory left for the KV cache per GPU
EstimateMemory left for the KV cache per GPU = max(0, Usable memory per GPU − Weights in memory − Runtime overhead)
= max(0, Estimate: 86.4 GiB − Calculated result: 15.26 GiB − Heuristic: 3 GiB)
= 68.14 GiB
KV cache capacity
EstimateKV cache capacity = floor(Memory left for the KV cache per GPU ÷ KV cache per token)
= floor(Estimate: 68.14 GiB ÷ Calculated result: 144 KiB/token)
= 496,206 tokens
Sequences of this context that fit
EstimateSequences of this context that fit = KV cache capacity ÷ context length
= Estimate: 496,206 tokens ÷ Your input: 8,192 tokens
= 60.57 ×
›At 1 GPU memory minimum, smallest valid split, recommended
Required memory per GPU
EstimateRequired memory per GPU = Weights in memory + KV cache + Runtime overhead
= Calculated result: 15.26 GiB + Calculated result: 4.5 GiB + Heuristic: 3 GiB
= 22.76 GiB
Usable memory per GPU
EstimateUsable memory per GPU = GPU memory × usable share ÷ 100
= Official specification: 96 GiB × Assumption: 90 % ÷ 100
= 86.4 GiB
Comfortable limit per GPU
EstimateComfortable limit per GPU = Usable memory per GPU × (100 − required headroom) ÷ 100
= Estimate: 86.4 GiB × (100 − Assumption: 10 %) ÷ 100
= 77.76 GiB
Remaining memory per GPU
EstimateRemaining memory per GPU = Usable memory per GPU − Required memory per GPU
= Estimate: 86.4 GiB − Estimate: 22.76 GiB
= 63.64 GiB
Utilization of usable memory
EstimateUtilization of usable memory = Required memory per GPU ÷ Usable memory per GPU × 100
= Estimate: 22.76 GiB ÷ Estimate: 86.4 GiB × 100
= 26.34 %
Assumptions
- Assumption: The KV cache is stored in blocks (16 tokens in vLLM), so the real capacity is slightly below the number shown.
- Heuristic: Runtime overhead is 3 GiB per GPU for the CUDA context, activations and graphs. It is a heuristic: vLLM measured 2.57 GiB for an 8B model, and it varies with engine and settings. Change
- Assumption: Only 90 % of the GPU memory is given to the model. Serving engines reserve the rest: vLLM's default is 92 percent (documentation of version 0.32). Change
- Assumption: A fit counts as comfortable when at least 10 % of the usable memory stays free. Change
- Assumption: NVIDIA prints GPU memory in GB, and the hardware holds that many GiB: an H100 80 GB has 80 GiB, and nvidia-smi shows 79.6. The few percent that ECC and the driver keep back are covered by the usable share.
- Assumption: The KV cache precision is set apart from the weight precision. Quantizing the weights does not shrink the KV cache or the overhead. Change
- Assumption: Every sequence is assumed to use the full context at the same time, the worst case. Real traffic is usually shorter. Change
- Assumption: Several GPUs are assumed to share the model with tensor parallelism, as vLLM does: weights and KV heads are split, and every GPU pays the runtime overhead.
Fits with headroom22.76 GiB / 86.4 GiBrequired / usable
Why it matters
The number on a model card is the weights. A running model also holds a KV cache that grows with context and concurrency, plus runtime overhead, and every GPU must hold its own share: the memory of several GPUs is not one pool. Planning with the weights alone is the most common sizing mistake.
How to read the result
Fits with headroom leaves your safety margin free on every GPU. Fits in theory is below the usable memory with less margin than you asked for. Does not fit means a GPU would run out. The memory budget shows each part for all GPUs and for one. The GPU counts follow vLLM's guidance: tensor parallelism inside a server, pipeline stages beyond it. The deployment layout lets you divide the GPUs another way and see what each way holds.
Local AI and sovereignty
Running a model on hardware you control is one input to a sovereignty decision. It does not by itself make a deployment sovereign, GDPR compliant or EU AI Act compliant.
These tools come from the AI Without the Cloud workshop.