Pick your card or your Mac and get the models that actually run on it, ranked, with an estimated speed beside each one. 92 architectures, every one read from the model's own config rather than a table someone typed.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The most common starting point. Plenty runs, and the ranking puts a mixture of experts near the top because it is resident in full and read in part, which is the answer people miss.
macOS caps what the GPU may wire down, so a machine sold with 192 GiB offers about 144 GiB to a model. Reading the sticker figure as usable memory is the usual way a Mac plan fails.
The cache is what runs this out, not the weights. Even a 1B model caches several gigabytes at 128k tokens, so the answer names the cheapest lever rather than just reporting failure. At 8 GiB the same request succeeds, which is the shape of the problem.
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The KV cache at a long context can exceed the weights, and it is the term nobody budgets for. A 7B at Q4 is about a 4 GB download and will not run in 4 GB of VRAM at any useful context.
Instead:Budget the weights, the cache at the context you actually intend to use, and an overhead allowance. The cache is the one that grows.
Grouped-query attention shares one key and value across several queries, and the two counts differ by up to eight times. The cache then comes out multiples too large, and people buy hardware they never needed.
Instead:Read `num_key_value_heads` from the model config, not `num_attention_heads`. Every architecture on this page carries both.
Memory follows the total parameter count because every expert stays resident. Speed follows the active count because only a few are read per token. Mixing them up is wrong in both directions at once.
Instead:Check the total against your memory and the active count against your bandwidth. A mixture is often the fastest thing that fits.
The default wired limit leaves roughly a quarter to a third unreachable, so a 64 GiB machine offers about 48 GiB before anything else is running.
Instead:Plan against the wired limit, and raise it deliberately with `sudo sysctl iogpu.wired_limit_mb` if you need to. Leave the system its share.
A 70B squeezed onto a small card at 1.5 tokens a second technically fits and is unusable for anything interactive. Fit and speed are separate questions and only one of them is about memory.
Instead:Set a speed floor before you choose. Decode speed is bandwidth divided by the bytes read per token, so a smaller model on the same card is the usual fix.
Most answers to this stop at whether the weights fit in the card. That is the easy half and it is the half that moves least. What decides whether a model is worth running is the cache it builds at your context length, and the bandwidth it has to read itself through for every token it writes.
Grouped-query attention shares one key and value across several queries, so the cache follows the KV head count and not the attention head count. Llama 3.1 70B has 64 attention heads and 8 KV heads, so an estimate built on 64 is eight times too large. That much is well known. What is newer is that a single model no longer has one kind of layer: Qwen3-Next runs standard attention on one layer in four and linear attention on the rest, Nemotron 3 states a Mamba and attention pattern layer by layer, and Gemma 4 gives its global layers a different head count from its sliding ones. Counting every layer the same way is wrong by a different factor for each of them, so this page holds a per-layer-class figure taken from each model's own config.
A mixture of experts keeps every expert in memory and reads only the few selected for each token. Memory follows the total parameter count and speed follows the active one, and swapping those around is wrong in both directions at once. It is also why a mixture is often the right answer on a small card: it will fit the same as a dense model of its size, and decode several times faster. Vendors publish an active count in the model name, and where the number computed from the config disagrees with it, this page uses the computed one and the difference is recorded in NOTES.md.
K-quants are mixed precision by design, keeping the tensors that matter at higher accuracy, so the file is always wider than the name. Rather than quote a number, every width here is measured: the published size of a real GGUF file divided by the parameter count of the model it came from. Q4_K_M lands near 4.84 bits per weight, and it moves by a few percent between models because the high-precision share depends on the vocabulary. The measurement was taken on 2026-08-18.
macOS caps what the GPU may wire down, at roughly two thirds of memory below 36 GiB and three quarters at or above it. A 64 GiB machine therefore offers about 48 GiB to a model before anything else is running, and reading the sticker figure as usable memory is the most common way a Mac plan fails. This page applies the limit and prints the sysctl that raises it.
Generating one token reads every active weight once, plus the cache. That is a memory bound rather than a compute one, which is why a large model is slow on a fast card: the arithmetic is trivial and the traffic is not. The figures here assume a runtime reaches 80% of peak bandwidth, which is in the middle of what gets measured and is an assumption rather than a fact. Prefill is the other half and it is compute bound, so a long prompt on a small card is a different complaint from a slow reply.
This is a memory budget and a bandwidth bound computed from published architecture, not a measurement of your machine. It cannot see allocator behaviour or fragmentation, the savings from Flash Attention or paged attention, speculative decoding or a draft model, batching effects, or thermal and power limits on a laptop. Estimates of this kind usually land within 10 to 15% of measured, and the only authority is running it. 11 of the 103 models here are excluded from the fit entirely, because they cache a compressed latent rather than keys and values per head and the arithmetic on this page would read several times high. They are named in the report rather than dropped silently. Architectures were fetched from each model's config on 2026-08-18, and the 21 devices on 2026-08-18.