← AI Hashrate

Running Large Models on Consumer GPUs: Offload, Speed Decay and MoE

Why "it doesn't fit" doesn't mean "it won't run" — and what it costs you · AI Hashrate guide

Every local-LLM user eventually tries to run a model that's bigger than their VRAM. The good news: modern runtimes (llama.cpp, Ollama, LM Studio and friends) will happily offload — splitting the model between GPU and CPU memory — so it still runs. The bad news: speed falls off much faster than intuition suggests. This guide explains the mechanics, the (VRAM ÷ need)² decay we use in our estimates, and why MoE models are the cheat code for big models on small hardware.

What is GPU offload, exactly?

Decode is a memory-bandwidth game: to generate one token, the hardware must read every active weight once. When the whole model sits in VRAM, that read happens at GPU memory speed — 1,000+ GB/s on an RTX 4090. When it doesn't fit, the runtime keeps as many layers as possible in VRAM and leaves the rest in system RAM, shuttling them across PCIe (tens of GB/s) every single token.

So an offloaded model is a hybrid: part of each token's weights arrive at VRAM speed, the rest crawl over PCIe, and the slowest part sets the pace. It runs — but the bottleneck is no longer your GPU.

Why does speed decay with (VRAM ÷ need)²?

Our estimator uses a deliberately conservative rule: when a model doesn't fit, the utilization factor drops from 0.35 (fits) to (VRAM ÷ need)², floored at 0.01. Why squared? Because two penalties compound:

Worked example — Llama-3.1-70B Q4 on a 24 GB RTX 4090: the model needs 53.8 GB at 8K context, so the ratio is 24 ÷ 53.8 = 0.45, squared = 0.20, versus 0.35 if it fit. Estimated speed: ~5 tok/s instead of the ~12 tok/s a linear guess would suggest (est.). Push to a denser case — 70B FP16 on the same card needs 156 GB — and the estimate collapses to ~0.2 tok/s (est.): technically running, practically unusable.

Scenario (RTX 4090 24GB)NeededRatio²Estimated tok/s
8B Q4 (fits)7.0 GB0.35 (fit)~80
32B Q4 (just misses)25.6 GB0.88~49
70B Q453.8 GB0.20~5
70B FP16156.2 GB0.02~0.2

The 32B row is the important lesson: just missing the fit line keeps most of your speed — 0.88 vs 0.35 would actually beat the fit factor in our model, because the formula caps the penalty at the resident fraction. Deep misses are catastrophic; shallow ones are survivable.

Why are MoE models the offload sweet spot?

Mixture-of-Experts models store many expert networks but only activate a few per token. That splits the problem in two:

And when an MoE model does offload, the damage is muted: the PCIe shuttle only moves the active experts, not the whole model. This is why giant MoE flagships are surprisingly usable on unified-memory machines: gpt-oss-120b (8B active) on a 128 GB M4 Max estimates ~43 tok/s at Q4, and Qwen3-235B (22B active) on a 192 GB Mac Studio M2 Ultra estimates ~23 tok/s (est.). A dense model of the same total size would be a slideshow on the same box.

What are your practical options when a model doesn't fit?

How should you read our "fits / doesn't fit" line?

We mark a combination as fitting only when weights + KV(8K) + 1 GB overhead is ≤ 95% of VRAM, and we apply full 0.35 utilization only there. "Doesn't fit" never means "won't run" — it means "runs offloaded, at the decayed estimate shown". The full formula and its limits are documented on the methodology page.