Model finder

Method

How to actually choose an open-weight model

Most model shortlists open with the question of which model is best, and never recover from it, because best is not a property a model has on its own. It is a property of a model, a task, a licence and a specific piece of hardware considered together. The useful move is to order your constraints so the hardest and least negotiable one goes first. Applied to the models in this table, that ordering usually cuts the list to a handful within two steps.

1. Set the memory budget in gigabytes, not in parameters. A parameter count means nothing until you also pick a precision and a context length. Of the 63 models here, 44 fit inside 24 GB at Q4_K_M with a 4K context, 35 fit inside 16 GB, and only 24 fit inside 8 GB. Type your real number into the budget box above and watch the table shrink.
2. Decide your context length before you shortlist, not after. Context is paid for in KV cache, and on some architectures that bill is enormous. Command R 35B costs 27.4 GB at 4K and 194.8 GB at 128K. Qwen3 32B goes from 21.7 GB to 55.2 GB across the same range. Shortlist at 4K, deploy at 128K, and you will find out about the difference on the worst possible day.
3. Filter by licence before you filter by capability. Capability is a matter of degree and you can usually trade a little of it away. A licence that forbids your use case is a wall. 39 of these models are Apache 2.0, MIT or Modified MIT; the other 24 carry conditions ranging from mild attribution to an outright ban on commercial use.
4. Only now filter by what the model is good at. The capability chips above use the tags the labs and the community actually apply: code, reasoning, vision, agents, multilingual, rag, edge, long-context. Pick one or two, not five. Every extra tag you demand pushes you toward a bigger model than the job needs.
5. Shortlist three models rather than one, and test them on your own data. Thirty to fifty real examples from your own workload will separate candidates faster, and far more honestly, than any public leaderboard. Keep the two that lost. Models get replaced every few months and the evaluation harness is the part worth keeping.

One more rule that saves a lot of grief: choose the smallest model that clears your quality bar, then stop. Headroom you do not use is paid for in latency on every single request, in electricity, and in a card that sits mostly idle between requests.

Dense, mixture of experts, and the number that decides your hardware

Every model in this table carries two parameter numbers, and they answer two different questions. Total parameters decide how much memory you need, because every weight has to sit somewhere the GPU can reach on short notice. Active parameters decide how fast it runs, because producing one token only reads the weights that token routes through. On a dense model those two numbers are identical and nobody has to think about it. On a mixture of experts they can differ by a factor of thirty, and the whole design exists to make that gap useful.

Read the table as a trade rather than a ranking. A mixture of experts converts memory into speed. You buy enough VRAM to hold every expert, then use a small slice of them on any given token, so decoding is fast and the model is smarter than its active parameter count suggests. That is a good trade when memory is the resource you have spare and latency is the one you do not.

It is a bad trade in the opposite situation, which is where most people actually stand. If you have one 24GB card, an MoE spends your scarcest resource on weights you barely touch. Qwen3 30B-A3B at 19.7 GB and Qwen3 32B at 21.7 GB occupy almost the same memory, but the dense model puts ten times more computation behind each token. On a single card with no throughput pressure, the dense 32B is usually the better answer; on a machine serving many concurrent users, the MoE wins comfortably.

There is a second effect worth knowing. Because an MoE reads so few weights per token, it is far less sensitive to memory bandwidth, which is exactly the constraint that makes large dense models feel sluggish on consumer hardware and on Apple silicon. That is why gpt-oss 120B, despite needing about 72 GB, generates faster on a large unified-memory machine than a dense 70B needing 45 GB. Capacity and speed are decided by different numbers, and the mixture-of-experts filter above lets you separate the two.

Why two models of the same size can need different machines

The attention column looks like trivia and is not. It decides how expensive your context is, and at long contexts it can matter more than parameter count. Here is what the same 4K to 128K jump does to models across the four attention designs in this catalog.

Phi-3.5 mini is the entry that should change how you shop. It is a 3.8B model, the sort of thing people assume runs anywhere, and at its full advertised 128K context it needs about 55 GB because it caches 32 full key-value heads on every layer. Meanwhile a 671B DeepSeek R1 adds only nine gigabytes going from 4K to 128K, because multi-head latent attention compresses keys and values into a single small vector per token per layer. Size did not decide either outcome; geometry did.

The practical reading is simple. If your workload is short prompts, ignore the attention column entirely and shop on weights. If your workload is long documents, whole repositories or big retrieval payloads, sort by attention design first: sliding-window models such as the Gemma 3 family and gpt-oss stay nearly flat as context grows, grouped-query models grow at a manageable rate, and full multi-head models become unaffordable somewhere between 32K and 128K no matter how small they look on paper.

What the licence column really means

Open weights and open source are not the same thing, and the gap is where most legal surprises live. Anyone can download every model on this page. What you may then do with it varies from genuinely unrestricted to explicitly non-commercial. These are the licence families in this catalog and what each one is actually asking of you.

Three details catch people out. The first is that a licence family is not uniform across a lab: DeepSeek publishes R1 and V3 under MIT but Coder V2 Lite under its own terms, and Alibaba ships almost all of Qwen under Apache 2.0 while Qwen2.5 3B and Qwen2.5 72B carry conditions. Check the specific checkpoint you downloaded rather than the brand.

The second is that several of these licences say something about the model outputs, not just the weights, and in particular about whether you may use generated text to train another model. If your plan involves producing synthetic training data, that clause matters more to you than anything about deployment.

The third is obligations that survive fine-tuning. Gemma prohibited-use terms follow anything derived from the weights. The Llama naming requirement applies to derivative model names. A non-commercial licence stays non-commercial after you train on your own data, because the base weights are still in there. Filtering to Apache and MIT with the checkbox above is the fastest way to make all of this stop being your problem, and it still leaves you 39 models. None of this is legal advice; the licence column is a shorthand for a document worth reading once.

Families worth knowing, grouped by what they are good at

Fourteen labs are represented here, but you only need a working map of about six lines of models to make good decisions. VRAM figures below are Q4_K_M at a 4K context, matching the table default.

Coding

Qwen2.5 Coder 32B at 21.7 GB is still the strongest permissively licensed coding model that fits a single 24GB card, and its 7B sibling at 5.5 GB is the standard choice for inline completion where latency beats depth. Devstral Small 24B at 15.7 GB is tuned for agentic editing across many files rather than filling in one function. DeepSeek Coder V2 Lite is the speed option, activating 2.4B of 15.7B parameters. Codestral 22B is good but carries a non-production licence, which rules it out of most shipping products. Above the workstation tier, DeepSeek V3 and Kimi K2 are the serious open coding models and both need a server.

Reasoning

QwQ 32B at 21.7 GB was the first open model to make long-form deliberation practical on one consumer card, and the DeepSeek R1 distills give you the same style at 7B, 14B, 32B and 70B under MIT, which is unusually generous for this class. The Qwen3 dense line switches deliberation on and off per request, so one download covers both modes. gpt-oss 20B and 120B are reasoning-first and Apache 2.0. Phi-4 14B at 10.5 GB punches above its size on mathematics but is capped at a 16K context, which is short by 2026 standards.

Long context

Llama 4 Scout is the outlier with a 10M token window, and Llama 4 Maverick offers 1M. DeepSeek R1 and V3 accept 163840 tokens, and most of the modern catalog settles at 131072. The important thing is what is not on that list: the whole Gemma 2 generation stops at 8192 tokens, Phi-4 at 16384 and TinyLlama at 2048. If you are feeding in long documents, check the context column before anything else, because no amount of quality makes up for a window that will not hold your input.

Vision

Six models here read images. Qwen2.5-VL 7B at 5.9 GB is the small workhorse for documents, screenshots and charts. Gemma 3 comes in 4B, 12B and 27B vision-capable sizes, all under the Gemma terms, and the 4B at 3.5 GB is remarkable for the memory. Llama 4 Scout and Maverick are natively multimodal but need serious hardware. Remember that image tokens consume the same context budget as text, so a vision workload eats your window faster than the page count suggests.

Multilingual and retrieval

Mistral Nemo 12B at 8.8 GB was built with a tokenizer that treats non-English text more fairly than the Llama line, which shows up as both better quality and fewer tokens per sentence. GLM-4 9B is strong on Chinese and English together. For retrieval-augmented generation with inline citations, Command R and Command R+ remain the reference designs, with the enormous caveat that both are non-commercial and Command R uses full multi-head attention, so it becomes very expensive at exactly the long contexts retrieval workloads produce.

Edge and embedded

Thirteen models carry the edge tag. Qwen2.5 0.5B needs about 1.0 GB, Qwen3 0.6B about 1.6 GB, TinyLlama 1.1B about 1.4 GB and SmolLM2 1.7B about 2.5 GB, which puts all of them inside a phone, a browser tab or a Raspberry Pi with an accelerator. Phi-4 mini 3.8B at 3.5 GB and Llama 3.2 3B at 3.1 GB are the practical ceiling for that category and the point where instruction-following becomes dependable.

How to read a benchmark claim sceptically

Every release post contains a table where the new model wins. That is not dishonesty, it is selection: the table was assembled after the results were known, and any row that did not flatter the model was quietly not included. Here is what to check before a benchmark number changes your decision.

• Contamination. Public benchmarks leak into training corpora over time, and the older the benchmark the more likely it has been memorised. A very high score on a long-standing test set is weaker evidence than a middling score on something released last month.
• Which comparison snapshot. Closed models are moving targets. A claim of beating a frontier model usually refers to one specific version from one specific month, which may have been superseded before the post went up.
• Token budget. Reasoning models can spend thousands of hidden tokens before answering. If one row was allowed to deliberate and another was not, the comparison is measuring spend as much as skill.
• Prompt format and sampling. The same model can move several points on the same benchmark depending on chat template, system prompt, temperature and how the answer is parsed. Reported numbers rarely disclose all four.
• Aggregation. A single headline average hides which categories moved. A model that gains on mathematics and loses on instruction-following can show a flat average while being clearly worse for your use.
• Pass at one versus best of many. Sampling several times and keeping the best answer inflates coding scores substantially, and is not how your application will run.

The replacement for all of this is unglamorous and works: collect thirty to fifty examples of your real task, write down what a good answer looks like, and score the candidates yourself. It takes an afternoon, it survives every model release, and it answers the only question that matters, which is whether this model is good at your job rather than at a public exam.

Match the model to the task, not to the leaderboard

A large share of production language-model work does not need a large model. These tasks are routinely handled well by something in the 3B to 8B range, which means Llama 3.2 3B at 3.1 GB, Gemma 3 4B at 3.5 GB, Qwen3 4B at 3.7 GB or Qwen2.5 7B at 5.5 GB, all of which fit an 8GB card with room for context.

• Classification and routing: deciding which of six queues a support ticket belongs in, or whether a message needs a human.
• Extraction into a fixed schema: pulling dates, amounts, party names and identifiers out of a semi-structured document.
• Reformatting: turning notes into a template, converting between markup formats, normalising addresses.
• Short summarisation: one paragraph from one page, where the source is present and the job is compression rather than judgement.
• Tagging and metadata: titles, keywords, sentiment, language detection, content warnings.
• Query rewriting for search, and reranking a handful of retrieved passages before they reach a bigger model.

The tasks that genuinely reward size look different: multi-file code changes where the model must hold an architecture in mind, ambiguous instructions that require inferring intent, synthesis across long documents that disagree with each other, mathematics with more than a couple of steps, and agent loops where an early mistake compounds over twenty turns. If your workload is not in that second list, the money spent on a bigger model buys latency rather than quality.

The strongest architecture in practice is usually mixed: a small model doing the routine volume, escalating to a large one on the cases where it is unsure. The escalation rate is typically a few percent, which is the difference between a workload that fits on one card and one that does not.

Run it locally, or call a hosted API?

Every model on this page can be downloaded, and quite a few of them are also available as hosted endpoints, including through this gateway. The choice is less about ideology than about which resource you are short of.

Run locally when the data cannot leave the building, when you need the weights pinned so behaviour never changes underneath you, when you are working offline or on an unreliable connection, when you have steady high-volume traffic against a GPU you already own, or when you intend to fine-tune. Local inference also gives you things no API exposes: raw logits, constrained decoding against a grammar, custom sampling and speculative decoding.

Call a hosted endpoint when traffic is bursty, when the model you want needs more memory than you can reasonably buy, when you expect to swap models every few weeks, or when nobody on the team wants to operate an inference server. The catalog makes the memory point vividly: 44 of these 63 models fit a 24GB card, but DeepSeek R1 at 410 GB and Kimi K2 at 611 GB are multi-node deployments, and the gap between those two groups is not something you cross by being clever.

The economics are usually decided by utilisation rather than by rates. A card that runs at ten percent duty cycle is expensive per useful token no matter how cheap the hardware was, because you paid for all of it. A card that runs continuously is very hard to beat on price. Estimate your tokens per day honestly before buying anything, and note that the honest answer for most side projects and internal tools is that a free or cheap hosted endpoint wins easily.

Questions people actually ask

How do I choose an open-weight model?

Order your constraints hardest first. Set a memory budget in gigabytes rather than parameters, decide the context length you actually need before shortlisting, filter by licence, and only then filter by capability. Of the 63 models here, 44 fit inside 24 GB at Q4_K_M with a 4K context and only 24 fit inside 8 GB, so the budget step alone usually cuts the list in half. Finish by testing three candidates on thirty to fifty examples of your own real work.

What do active parameters mean on a mixture-of-experts model?

Total parameters decide how much memory you need, because every weight must be resident. Active parameters decide how fast it runs, because generating one token reads only the experts that token routes through. Qwen3 30B-A3B holds 30.5B parameters but activates 3.3B per token, so it occupies about 19.7 GB at Q4_K_M yet decodes at roughly the speed of a 3B model.

Is a mixture-of-experts model cheaper to run than a dense one?

Cheaper in compute and time, not in memory. If VRAM is your binding constraint an MoE is poor value, because you pay for every expert and use a fraction of them. If you have the memory and want throughput, it is excellent. gpt-oss 120B needs about 72 GB at Q4_K_M but only reads 5.1B parameters per token.

Which open-weight models can I use commercially without asking permission?

The Apache 2.0 and MIT ones. In this catalog that is 39 of 63 models, including the whole Qwen3 line, Qwen2.5 Coder, QwQ 32B, Mistral Small 24B, Devstral, the Mixtral models, gpt-oss 20B and 120B, DeepSeek R1 and V3, the R1 distills, Phi-4 and GLM-4.5 Air. The other 24 carry conditions ranging from attribution to an outright ban on commercial use.

Is the Llama community licence a commercial licence?

It permits commercial use, but it is not an open-source licence. It caps free use at 700 million monthly active users, requires you to display Built with Llama and to carry the Llama name into derivative model names, and attaches an acceptable use policy. For most teams none of that bites, but it is a contract rather than a grant, so read it before you build a product on it.

Can I use Command R or Command R+ in a commercial product?

Not under the released weights. Both Cohere models here are CC-BY-NC, which is non-commercial only. They are excellent retrieval and citation models and perfectly fine for research or evaluation, but shipping them in a paid or revenue-generating product needs a separate agreement with Cohere.

Why does the same model need far more VRAM at a 128K context?

The KV cache grows linearly with context, and how steeply depends on attention geometry. Command R 35B uses full multi-head attention and goes from 27.4 GB at 4K to 194.8 GB at 128K. Qwen3 32B with grouped-query attention goes from 21.7 GB to 55.2 GB. Gemma 3 27B, which uses sliding windows on five of every six layers, only goes from 18.1 GB to 28.6 GB.

What is the smallest open model that is still genuinely useful?

For classification, routing, extraction into a fixed schema and reformatting, models in the 3B to 4B range are already reliable. Llama 3.2 3B needs about 3.1 GB at Q4_K_M, Gemma 3 4B about 3.5 GB and Qwen3 4B about 3.7 GB, so all three run on an 8GB card with room for a real context. Below roughly 2B the models still write fluently but stop following multi-step instructions dependably.

Do I need a reasoning model?

Only for problems with a verifiable chain of steps: mathematics, algorithmic code, constraint puzzles, multi-hop analysis. Reasoning models spend a large number of hidden tokens before answering, which means higher latency and more generated tokens for every request. For extraction, summarisation, rewriting and chat, a non-reasoning model of the same size is usually faster and no worse.

Which open-weight model is best for coding?

For a single 24GB card, Qwen2.5 Coder 32B at about 21.7 GB is the strongest permissively licensed option. Devstral Small 24B at about 15.7 GB is tuned for agentic multi-file editing rather than single completions. For fast inline completion, Qwen2.5 Coder 7B or DeepSeek Coder V2 Lite, which activates only 2.4B of its 15.7B parameters. At the top end DeepSeek V3 and Kimi K2 are stronger but need hundreds of gigabytes.

Does a long advertised context length mean the model uses it well?

No. The context figure is the length the released weights accept, not the length at which quality holds. Llama 4 Scout advertises 10M tokens and most modern models here list 128K, but retrieval accuracy usually degrades well before the stated maximum. Treat the number as a hard ceiling and measure real performance at the length you plan to use.

Should I trust the benchmark table in a model release post?

Treat it as marketing with real numbers in it. Release tables are chosen after the fact, comparison models are often older snapshots, prompt formats and sampling settings differ between rows, and popular benchmarks leak into training data over time. The number that should decide your choice is the score on thirty to fifty examples of your own workload.

How much quality do I lose by quantizing to 4-bit?

Less than most people expect on larger models and more than most expect on small ones. Q8_0 is effectively indistinguishable from the original weights. Q4_K_M costs a small, usually unnoticeable amount on models above roughly 13B, and becomes visible on 1B to 3B models where there is less redundancy to spare. Below 4 bits, at Q3 and Q2, degradation is real. Note that gpt-oss ships natively in MXFP4, so 4-bit is its published precision rather than a compression step.

When should I run a model locally instead of calling a hosted API?

Run locally when data cannot leave your machine, when you need weights pinned so behaviour never changes underneath you, when you are offline, or when you have steady high volume on a GPU you already own. Call a hosted API when traffic is bursty, when the model you want needs more memory than you have, or when you want to switch models often. A 24GB card that sits idle most of the day is more expensive per useful token than any API.