Video memory behaves differently depending on what you ask of it, and the difference is not a matter of degree — it is a difference in kind.

Games degrade. Models refuse.

In a game, running short of video memory is a performance problem. The system spills data across to system memory, which is dramatically slower, and you feel it as stutter and sudden frame drops rather than a crash. Turn the textures down and the problem goes away. It is unpleasant, but it is a dial you can turn.

Running a language model locally is binary. The weights either fit in video memory or they do not. If they do not, you either offload layers to system memory and watch throughput collapse by an order of magnitude, or the load fails outright. There is no equivalent of turning down the textures.

This is why buying advice written for gaming translates so badly to AI work, and why a card that is comfortable at high resolution can be useless for a model that a much cheaper card with more memory handles fine.

For games

Texture resolution dominates, and it scales with output resolution — the same settings cost substantially more at 4K than at 1080p. Ray tracing adds its own structures on top. Frame generation techniques hold additional buffers. None of these are optional extras in the budget sense; they are the budget.

For language models

Three things compete for the space:

• The weights. The bulk of it, and a direct function of parameter count and quantization.
• The context window. Grows with how much conversation or document you keep in play, and it grows faster than people expect on long contexts.
• Working overhead. The runtime's own scratch space, which is small but not nothing.

Quantization is the lever that matters most. Storing weights at lower precision shrinks the model substantially, at some cost in output quality — and it is frequently the difference between a model running on your card and not running at all.

The VRAM calculator works this out for a given model, quantization and context rather than leaving you to estimate it.

Two cards with identical memory capacity can perform very differently, because capacity answers whether something fits while bandwidth answers how fast it runs once it does.

Generating text is overwhelmingly memory-bandwidth bound. The hardware reads through the model's weights for every token it produces, so the speed you experience tracks how fast the card can stream memory far more closely than it tracks raw compute. A card with generous capacity but modest bandwidth will load a large model happily and then produce text slowly.

The practical consequence

Buy capacity for the models you intend to run, then bandwidth for how fast you want them. Getting the order wrong in either direction is expensive: too little capacity and the model will not load at all; plenty of capacity on a slow bus and you have bought the ability to run something at a speed you will not tolerate.

The inference speed estimator turns bandwidth and model size into an expected tokens-per-second figure, which is a more useful thing to compare than either specification on its own.

The figures below are what the VRAM calculator returns at Q4_K_M, the usual starting format: weights at 4.5 bits each, the KV cache for the stated context, and half a gigabyte of runtime overhead.

• Llama 3.1 8B: 5.7 GB at an 8K context, 8.7 GB at 32K. Comfortable on an 8 GB card for chat, but a long document pushes it over.
• Qwen3 14B: 9.5 GB at 8K, 13.3 GB at 32K. A 12 GB card for short contexts, 16 GB once you feed it long files.
• Qwen 2.5 32B: 19.5 GB at 8K, 25.5 GB at 32K. Fits a 24 GB card at a normal context and stops fitting at a long one — the same model, the same card.
• Llama 3.3 70B: 39.7 GB at 8K. Beyond any single consumer card, including a 32 GB one; it takes two 24 GB cards or a lower format.

Context is the number that catches people out

For Qwen 2.5 32B the cache grows from 2 GB at 8K to 8 GB at 32K — a quarter of a gigabyte for every thousand tokens. The weights never change; the conversation does. If you plan to paste in long documents or keep a long chat going, size for the context you will actually use, not the one in a quick test.

Leave a margin

Runtimes reserve their own buffers, the desktop itself uses some video memory, and multimodal models add an image encoder on top. Aim for a gigabyte or two of free memory over the calculator's total. If a model only fits with nothing to spare, the next format down is usually the better trade.