Which Open AI Model Should You Use? A Practical Guide to Qwen, DeepSeek, Llama, Gemma, Mistral, gpt-oss and OLMo

There is no single “best open-source model.” There are model families built for different constraints: a laptop versus a rack of GPUs, a customer-support assistant versus a coding agent, image and audio input versus text alone, a permissive commercial license versus a research project that needs reproducible training artifacts. The useful question is narrower: what must the model do, where will it run, and what rights do you need over its weights and outputs?

This guide covers the general-purpose language and multimodal model families most often considered for self-hosting and customization: Qwen, DeepSeek, gpt-oss, Mistral Small, Gemma, Llama and OLMo. It does not attempt to catalog every fine-tune, image generator, speech recognizer, embedding model or benchmark release. Those are separate choices: an embedding model, for example, turns text into vectors for search and retrieval; it is not a replacement for the chat model that writes the final answer.

First, separate “open source” from “open weight”

The common misconception is that a downloadable model is automatically open source. A language model has several components: the trained weights, the code used to run it, the training code, the training data, and the license. “Open weight” means the numerical parameters can be downloaded and run elsewhere. It does not necessarily mean the publisher released the training data or the recipe needed to reproduce the model.

For a commercial deployment, read the model license rather than relying on the label. Apache 2.0 is broadly permissive and explicitly addresses patents. Community licenses and acceptable-use terms can impose additional conditions. Meta’s Llama and Google’s Gemma are best described as open-weight families, while Qwen, gpt-oss, Mistral Small and the OLMo project make major releases under Apache 2.0. DeepSeek publishes weights and code, but its model weights have a separate model license from the repository’s MIT code license.

A second distinction matters for cost. A dense model uses its full parameter count for every generated token. A mixture-of-experts, or MoE, model stores many specialist subnetworks but activates only some of them per token. MoE can reduce compute during generation, but the full weight set still has to fit in memory. A model advertised as “4B active” can therefore need much more memory than a four-billion-parameter dense model.

The short version

• Choose Qwen3 when you need the broadest practical range of sizes, strong multilingual support, tool use and a permissive license.
• Choose gpt-oss when text-only reasoning, tool use and an Apache 2.0 license matter, especially if 20B fits your local or edge budget or 120B fits an 80 GB-class GPU.
• Choose DeepSeek-V3 for a high-capacity general model in a serious server deployment; choose DeepSeek-R1 or its distilled variants when deliberate mathematical, coding or analytical reasoning is worth added latency.
• Choose Mistral Small 3.1 for a compact, fast multimodal assistant that can run on a single high-end consumer GPU or a 32 GB-memory Mac.
• Choose Gemma 4 for edge, browser, mobile and local multimodal work, particularly when its small effective-parameter variants fit the hardware plan.
• Choose Llama 4 Scout or Maverick when their large ecosystem, image understanding and long-context design outweigh their non-Apache license terms and substantial serving requirements.
• Choose OLMo when transparency and research reproducibility matter as much as end-task performance.

Qwen3: the broad default for builders

Qwen3 is a large family rather than one model. It includes dense models from 0.6B to 32B parameters and MoE variants including 30B-A3B and 235B-A22B. The notation after the dash identifies the active portion of an MoE model: 30B-A3B stores roughly 30 billion parameters but activates about three billion for a token. Qwen also separates its instruction-oriented and thinking-oriented releases, letting an application choose between faster ordinary responses and more deliberate reasoning.

What it is good at: Qwen3 is a practical generalist for multilingual chat, structured output, tool calling, code, retrieval-augmented generation and agent workflows. The family supports more than 100 languages and dialects, and its many sizes make it easier to match a model to the hardware than with a family that begins at dozens of billions of parameters.

When to use it: start with a Qwen3 4B, 8B or 14B model for a local prototype; move to a 30B-A3B or larger release when quality justifies server deployment. Use the thinking version for tasks with checkable intermediate work, such as code repair, mathematics, planning and data analysis. Do not enable thinking mode merely because it exists: it increases response time and output-token cost, and it rarely improves a straightforward classification or extraction task.

What to watch: Qwen’s model cards and prompt formats vary across generations and specialized branches. Pin a specific checkpoint, tokenizer and chat template in production. “Qwen” is not a sufficient deployment specification.

gpt-oss: text reasoning and tools under Apache 2.0

OpenAI’s gpt-oss family has two text-only MoE reasoning models: gpt-oss-20b and gpt-oss-120b. The names describe total parameters, while only a smaller subset is active for each token. The 20B model has 21B total and 3.6B active parameters; the 120B model has 117B total and 5.1B active parameters. Both support a 128,000-token context window and are released under Apache 2.0 alongside a usage policy.

What it is good at: the models are designed for reasoning, function calling, structured outputs and tool-using agents. The smaller model is aimed at constrained deployments, while the 120B model is the higher-capacity choice for a single 80 GB GPU-class server. They are particularly attractive when a team needs to run a capable text model on infrastructure it controls and wants a permissive license for fine-tuning or redistribution.

When to use it: choose gpt-oss-20b for local development, privacy-sensitive internal tools and latency-conscious reasoning tasks where 16 GB of model memory is realistic. Choose gpt-oss-120b when the task benefits from stronger reasoning and the operations team can support a larger GPU deployment. Use another family if image, audio or video input is a core requirement: gpt-oss is text-only.

What to watch: self-hosting eliminates API rate limits, not operating costs. You still pay for GPU memory, throughput capacity, observability, software updates and evaluation. A local model can keep prompts within your environment, but plugins, web search tools and logging systems can still send data elsewhere if you configure them to do so.

DeepSeek-V3 and DeepSeek-R1: capacity first, then a choice between speed and deliberation

DeepSeek-V3 is a 671B-parameter MoE model that activates 37B parameters per token. DeepSeek-R1 uses a similar large-scale MoE profile but is post-trained to spend more effort on reasoning. The difference is operational as well as stylistic. V3 is the better fit for broad chat, writing, coding and tool workflows that need reasonably direct answers. R1 is for problems where spending extra generated tokens on reasoning can improve the result.

What they are good at: DeepSeek-V3 is a high-capacity general model, while DeepSeek-R1 is aimed at math, code and multi-step reasoning. The R1 release also includes smaller distilled models based on Qwen and Llama architectures. Those distills are often more realistic than the flagship for teams without multi-GPU infrastructure.

When to use them: use V3 in a data-center deployment when you need a very capable generalist and can operate an MoE model at scale. Use R1 for offline analysis, complex programming tasks and other work where latency is less important than a second pass of reasoning. Consider an R1 distill when the relevant task is reasoning-heavy but the available hardware is closer to a workstation than a cluster.

What to watch: active parameters are not the same as memory requirements. DeepSeek’s 671B weights are far beyond what a typical desktop can serve at useful quality and speed. Quantization can reduce memory use, but it changes accuracy, throughput and sometimes tool-calling reliability. Test the exact quantization and runtime you intend to ship.

Mistral Small 3.1: a compact multimodal workhorse

Mistral Small 3.1 is an Apache 2.0-licensed model aimed at the useful middle ground between tiny on-device models and large server models. It accepts text and images, supports function calling and has a 128,000-token context window. Mistral says it can run on one RTX 4090 or a Mac with 32 GB of memory.

What it is good at: fast conversational assistants, document and image understanding, low-latency tool use, and domain fine-tuning where a compact model is easier to operate than a frontier-scale MoE. It is a sensible candidate for a product that needs visual input but cannot justify a large GPU fleet.

When to use it: choose it for a private support copilot that reads screenshots, a quality-control interface that reviews images, or an internal assistant that must call business software quickly. Its size is also useful when model startup time and concurrent-user capacity matter as much as benchmark scores.

What to watch: image understanding does not turn the model into a deterministic OCR or computer-vision system. For invoices, serial numbers, regulated records or measurements, pair it with dedicated extraction and validation steps rather than trusting a prose response as the system of record.

Gemma 4: the strongest case for edge and device deployment

Gemma 4 is Google’s current open-weight Gemma family. It spans small effective-parameter models for mobile, edge and browser use; a 12B unified multimodal model; a 31B dense model; and a 26B MoE model with about four billion active parameters per token. The family supports text, image, video and, in selected variants, audio input. Small models support 128,000 tokens of context and larger models support 256,000.

What it is good at: Gemma 4 offers unusually explicit deployment paths for constrained hardware, including official low-bit quantized variants. Its E2B and E4B releases are suited to devices and browsers; the 12B model is a practical multimodal local option; and the 26B-A4B model targets higher-throughput reasoning without using all 26B parameters for each token.

When to use it: choose Gemma when on-device operation, mobile memory budgets or Google’s edge tooling are central to the product. It is also a reasonable choice for applications that need text, visual and audio inputs in one model family.

What to watch: “effective parameters” are a performance measure, not the number of bytes that must be loaded. Google’s own memory estimates show that the small models still have larger static-weight footprints than their effective counts suggest. Also, Gemma is open weight under Google’s license, not an Apache 2.0 model release; have counsel review the terms for a commercial distribution plan.

Llama 4 Scout and Maverick: ecosystem scale and extreme context, with licensing caveats

Llama remains one of the most widely supported families across runtimes, fine-tunes and deployment tools. Llama 4 Scout and Llama 4 Maverick are Meta’s natively multimodal MoE releases. Scout has 109B total parameters with 17B active and is designed to fit on a single H100 when quantized to Int4. Maverick has 400B total parameters with 17B active and targets larger H100-based deployments.

What they are good at: both accept images as well as text and are designed for multilingual, general-assistant and visual-understanding work. Scout’s headline feature is a claimed 10-million-token context capability, making it relevant to experiments involving very large document collections or codebases. Maverick is the higher-capacity option for general chat and image understanding.

When to use them: choose Llama 4 when compatibility with the Llama ecosystem is a strategic advantage, when a team already has serving infrastructure for large models, or when long-context multimodal work is central. Scout is the more plausible of the two for a single-node high-end deployment; Maverick is an infrastructure commitment.

What to watch: long context is not a guarantee of perfect recall or sound reasoning across millions of tokens. Retrieval, chunking and task-specific evaluation still matter. More importantly, Llama is open weight under the Llama community license rather than a standard permissive open-source license. License compliance must be a design requirement, not paperwork added after an application has shipped.

OLMo 2: use it when reproducibility is part of the work

OLMo is Allen Institute for AI’s open language-model project. OLMo 2 releases include 1B, 7B, 13B and 32B checkpoints, instruction-tuned variants, training configurations and intermediate checkpoints. That combination makes it different from a weights-only release: researchers can inspect training decisions, compare checkpoints and reproduce more of the pipeline.

What it is good at: research, evaluation, interpretability work, model-behavior studies and organizations that need a clearer audit trail from data mixture and configuration to trained checkpoint. The project is also useful for teams that expect to modify training rather than only fine-tune an existing chat model.

When to use it: choose OLMo when the ability to inspect and reproduce the model’s development is a first-order requirement. A research lab building a benchmark, a team studying data contamination, or a company developing a custom training stack will get more value from those artifacts than a team that simply needs the strongest chatbot on a deadline.

What to watch: transparency does not eliminate the need for a use-case evaluation. It gives you more information about what you are evaluating and more control over how you adapt the model.

How to make the choice without chasing a leaderboard

1. Write the task in measurable terms. “Help with support” is too broad; “extract product, quantity and delivery date from 2,000 historical email threads, with fields validated against an order system” is testable.
2. Choose the input modes first. A text-only model cannot reliably replace a model that needs to inspect diagrams, screenshots or recorded calls.
3. Set the hardware ceiling before comparing benchmarks. Include model weights, the key-value cache used for long prompts, concurrent requests and the serving runtime’s overhead.
4. Decide whether the task needs reasoning mode. Evaluate it against a direct instruct model on accuracy, latency and cost; do not assume longer answers are better answers.
5. Check the exact model license, including the weights, before fine-tuning or distributing a derivative. Repository-code licenses are frequently different from model-weight licenses.
6. Build a held-out evaluation set from your real work. Include easy cases, ambiguous cases, adversarial inputs and examples where a wrong confident answer would cause harm.
7. Use deterministic systems for deterministic requirements. A model can draft an SQL query or extract an invoice field; a validator, database constraint or human review should decide whether the result is accepted.

A sensible starting set

For most teams, a small, controlled trial is more informative than a universal recommendation. Run Qwen3 8B or 14B as the permissive general-purpose baseline; add Mistral Small 3.1 or Gemma 4 if images and local deployment matter; compare gpt-oss-20b or a DeepSeek-R1 distill for reasoning-heavy tasks; and reserve DeepSeek-V3, gpt-oss-120b, Llama 4 Maverick and other large releases for cases where a measured gain justifies the infrastructure. If the project is research rather than product delivery, add OLMo 2 to the comparison because the training artifacts are part of its value.