See which LLMs your computer can run. One-click GPU detection checks Llama, Gemma, Qwen, DeepSeek and 50+ models against your VRAM, with speed estimates.
This tool starts from the machine you already own and works backwards to a shortlist. You tell it what GPU you have and how much memory it and the system hold; it walks all 55 curated open-weight models — Llama, Qwen3, Gemma, DeepSeek, Mistral, GPT-OSS, GLM, Kimi, Phi 4, Nemotron — and sorts every one into a verdict: runs great, runs with trade-offs, technically runs, or won't fit. It is the inverse of our LLM VRAM calculator, which starts from one model and tells you how much memory that model needs. Use this one when the question is "I have 16 GB, what are my options", and that one when you have already picked the model.
The detect button reads two things from your browser: the WebGL unmasked renderer string and, where available, the WebGPU adapter info. Those give a GPU name — strings like ANGLE Metal Renderer: Apple M3 Max or one containing RTX 4070 Ti Super — which is matched against the built-in hardware table to recover bandwidth and typical memory.
Browsers deliberately do not expose memory sizes. navigator.deviceMemory is bucketed and capped at 8 GB, so it is useful only as a floor, and VRAM is not exposed at all. That is why the tool always asks you to confirm the numbers. On Apple Silicon and other unified-memory hardware it makes one extra inference: the WebGPU adapter's maxBufferSize limit is snapped to the nearest shipping memory configuration to pre-select a sensible default. Treat that as a smart guess, not a reading — change it if it is wrong. Everything runs in your browser; no hardware fingerprint is sent anywhere by this screen.
If detection fails, or if you are planning a purchase rather than testing what you own, use "Pick manually" and choose any card from the list — NVIDIA GeForce and datacentre parts, AMD Radeon and Strix Halo, Intel Arc, every Apple Silicon tier, plus plain CPU + DDR4/DDR5 entries.
A model is not one size. The same weights ship in a range of GGUF quantisation formats, and the tool tries them from best quality downwards until one fits your memory. The bytes-per-parameter figures below are averages that include the embedding and output layers, so they match real GGUF file sizes rather than the naive bit-width arithmetic.
| Format | Bytes per parameter | Quality |
|---|---|---|
| Q8_0 | 1.06 | Practically indistinguishable from FP16 |
| Q6_K | 0.82 | Near-lossless |
| Q5_K_M | 0.71 | Very good, noticeably smaller |
| Q4_K_M | 0.61 | The popular size/quality balance |
| Q3_K_M | 0.50 | Visible quality loss |
| IQ2_M | 0.36 | Significant loss; last resort |
Fit is checked at a realistic everyday setting of 8,192 tokens of context, and the memory it needs is weights plus KV cache plus 0.75 GiB reserved for the CUDA or Metal runtime context and buffers. The KV cache is computed from each model's real architecture — layer count, KV head count, head dimension, and whether the layers use sliding-window attention or DeepSeek-style compressed latent attention — not from a rule of thumb.
| Verdict | What it means |
|---|---|
| Runs great | Fits entirely in GPU or unified memory at Q4_K_M or better, and generates at 15 tokens/sec or more |
| Runs with trade-offs | Fits, but only at a reduced quantisation, or fits well and still generates slowly |
| Technically runs | Heavy CPU offload or 2-bit weights — expect single-digit tokens per second |
| Too slow for you | Fits, but below the minimum speed you set on the slider |
| Won't run | Does not fit in VRAM plus system RAM at any quantisation |
Point it at a 16 GB card with roughly 717 GB/s of bandwidth (an RTX 4080 is the reference used here) and the shortlist looks like this at 8K context. Speeds are the tool's single-stream estimate at 65% of theoretical bandwidth.
| Model | Best fitting quant | Memory needed | Estimated generation |
|---|---|---|---|
| Llama 3.2 3B | Q8_0 | 4.8 GiB | ~107 tok/s |
| Llama 3.1 8B | Q8_0 | 9.7 GiB | ~49 tok/s |
| Gemma 3 12B | Q8_0 | 13.6 GiB | ~34 tok/s |
| Qwen3 14B | Q6_K | 13.3 GiB | ~35 tok/s |
| GPT-OSS 20B | Q5_K_M | 15.2 GiB | ~169 tok/s |
| Mistral Small 3.2 24B | Q4_K_M | 15.6 GiB | ~29 tok/s |
| Qwen3 30B-A3B | Q3_K_M | 15.7 GiB | ~190 tok/s |
| Llama 3.3 70B | — | does not fit in VRAM | offload only |
Two things in that table are worth pausing on. First, an 8B model at Q8_0 is a better use of 16 GB than a 14B model squeezed to Q6_K if you care about output quality — you are not obliged to take the biggest model that fits. Second, the mixture-of-experts entries invert the usual ordering. GPT-OSS 20B holds 21.5 billion parameters but reads only about 3.6 billion of them per token, and Qwen3 30B-A3B reads about 3.3 billion of its 30.5 billion. They are large to store and cheap to generate from, so they land near the top of the speed column despite being near the bottom of the fit column. If your bottleneck is capacity, MoE is expensive; if it is speed, MoE is the bargain of the list.
On Apple Silicon, Strix Halo, and integrated graphics, the model shares one pool with the operating system, so the tool budgets 75% of total memory rather than all of it: a 36 GB Mac is assessed as 27 GiB of usable model space. Unified systems also get no CPU-offload fallback, because there is nowhere to offload to — the memory is already the system memory. A discrete GPU, by contrast, can spill layers into system RAM, so those machines are additionally checked against VRAM plus system RAM minus 4 GB for the OS and the runtime.
When part of a model lives in system RAM, every generated token has to read those bytes over the memory bus instead of the GPU's. The estimate models that split explicitly: GPU-resident bytes at your card's bandwidth and 65% efficiency, CPU-resident bytes against an assumed 80 GB/s of dual-channel DDR5 at 35% efficiency. That second number is much lower for a reason — dequantisation overhead, unsaturated memory channels and laptop thermal limits mean CPU inference does not achieve anything like the bandwidth the DIMM spec suggests. Mixture-of-experts models take a further penalty on CPU, because switching experts every token defeats CPU caches in a way it does not on a GPU. In practice the RAM-resident share dominates the total time, which is why a model that is "90% on the GPU" is nowhere near 90% of the GPU-only speed.
Fitting is not the same as being tolerable. The slider (0–20 tokens/sec) reclassifies anything below your threshold into a separate "too slow for you" group, so it stops competing for attention with the models you would actually use. The reference points on the scale: about 5 tok/s is roughly reading speed, 10 feels like smooth chat, 20 feels snappy. Set it to 10 and a long list of technically-runnable 70B configurations quietly disappears, which is usually the honest outcome.
Each result carries its chosen quantisation, the memory it needs, the estimated speed, and the largest standard context that still fits alongside the weights on your GPU at that quant — useful when you plan to paste in long documents, since context is the variable that quietly eats the headroom. Every row links out to the VRAM breakdown and the speed detail for that exact model and quant, to an Ollama command builder, and offers a one-click copy of the matching LM Studio command. Results also filter by use case (chat, coding, reasoning, vision) and the whole configuration is captured in the URL, so a shareable link reproduces the same report on someone else's screen.
Whether a model runs is a memory question first and a speed question second.
Memory gate: a model needs room for its weights (parameter count x bytes per parameter at the chosen quantization), its KV cache (grows with context length), and runtime overhead. We check this against your GPU memory first, then against GPU + system RAM combined (CPU offloading).
Speed estimate: for models that fit, generation speed is approximately memory bandwidth divided by bytes read per token, derated to 65% for real-world engine efficiency. Models that need CPU offloading are penalized by system RAM bandwidth, which is the actual bottleneck.
Quantization ladder: we test each model from Q8_0 (near-lossless) down to IQ2_M (heavily compressed), and report the best quality level that fits. A model that only fits at 2-bit quantization is ranked lower because the quality loss is significant.
Once you know what runs, here is how to act on it:
For chat and general use: pick the largest model in your "runs great" tier. Larger models are smarter; there is rarely a reason to run a 4B model if a 12B model runs well on your hardware.
For coding: coding-tuned models (Qwen3 Coder, Devstral) outperform general models of the same size at code tasks. A 30B MoE coder that runs great beats a 70B general model that runs slowly — latency matters when you are iterating.
For long documents: check the "max context" figure on each card. A model that runs great at 8K context may not handle a 100K-token document. Models with efficient attention (Gemma sliding-window, DeepSeek MLA) degrade least at long context.
Then download it: use the Ollama Command Builder linked on each model card to get the exact pull command for the quantization that fits your hardware.
Your browser exposes the GPU model name through WebGL and WebGPU APIs (the same way games detect graphics settings). We match that name against our hardware database to get its specs. Everything happens locally in your browser — nothing is sent to a server. Browsers never reveal memory amounts for privacy reasons, which is why we ask you to confirm your VRAM and RAM.
Runs great: the model fits entirely in your GPU memory at good quality (Q4_K_M or better) and generates at comfortable speed. Runs with trade-offs: it works, but needs aggressive quantization (quality loss) or runs slowly. Technically runs: requires CPU offloading or extreme compression — expect single-digit tokens per second. Will not run: the model does not fit in your combined GPU memory and system RAM at any quantization.
When a model does not fit entirely in GPU memory, inference engines like llama.cpp can keep some layers in system RAM and run them on the CPU. It works, but system RAM bandwidth (50-90 GB/s) is 10-40x slower than GPU memory bandwidth, so every offloaded layer drags down generation speed. A model that is 40% offloaded typically runs 3-5x slower than one that fits entirely on the GPU.
Mixture-of-Experts (MoE) models only read a fraction of their parameters for each token. GPT-OSS 120B reads just 5.1B parameters per token, so it generates as fast as a 5B model — but it still needs memory for all 120B parameters. That is why you will sometimes see a 30B MoE model ranked "runs great" while a 32B dense model is marked slow: same memory needs, very different speeds.
For Llama 3.3 70B at Q4_K_M (about 43 GB), you need roughly 48 GB of GPU memory: two 24 GB GPUs (2x RTX 3090 or 4090), one 48 GB workstation card (RTX 6000 Ada), a Mac with 64 GB+ unified memory, or a datacenter GPU. On a 64 GB Mac it runs at about 5-7 tokens/sec; on 2x RTX 4090 with tensor parallelism, around 20-25 tokens/sec.
Safari and some privacy-focused browsers report a generic "Apple GPU" or hide the renderer string entirely. Some Linux setups report the Mesa driver name instead of the GPU model. If detection fails, just pick your hardware manually from the vendor list — the results are identical.
Yes — rankings are computed at 8K tokens of context, a realistic everyday setting. Each model card also shows the maximum context that fits on your hardware. Long contexts need significantly more memory (the KV cache grows linearly), so a model that fits at 8K may not fit at 64K.
The quantization levels we test (Q8_0 down to IQ2_M) correspond to the standard GGUF files you will find on Hugging Face and in Ollama. When a model is ranked "runs great at Q4_K_M", that is exactly the file variant to download. Use our Ollama Command Builder to get the right pull command.
Calculate how much VRAM any LLM needs to run locally. Pick a model, quantization, and context size — see download size, total memory required, and which GPUs it fits on.
Estimate LLM tokens per second from memory bandwidth, model size, quantization, and context window. Compare generation speed across GPUs and understand the memory-bandwidth bottleneck.
Build Ollama commands without memorizing syntax: run, pull, and create commands for any model, complete Modelfiles, and server environment configuration — with built-in VRAM checks.
Count tokens in text for GPT-4, Claude, Llama, and other LLMs. Estimate API costs and optimize prompts for token limits
Speed test your GPU for AI — measure real memory bandwidth and compute with WebGPU, run an actual LLM in your browser, and see predicted speeds for every popular model on your hardware.
Chat with an AI model that runs entirely in your browser — free, no signup, no API key. Pick a model like Llama 3.2 or Qwen 2.5, or load your own GGUF file. Conversations never leave your device and it works offline once the model is downloaded.