# Choosing an open-weight model

> How to shortlist open-weight models by licence, memory, context and serving support, then decide on the client's own test set.

- Web page: https://www.alesanalytics.com/docs/choosing-an-open-weight-model
- Markdown: https://www.alesanalytics.com/docs/choosing-an-open-weight-model.md
- Last updated: 2026-11-08
- Publisher: Ales Analytics

Technical page. Licence, shape and fit before accuracy. Published 2026-11-08. Last reviewed 2026-11-08. Reviewed by Ales Analytics engineering.

## In one paragraph

Choosing an open-weight model is a filter before it is a contest. A candidate must be licensed for the intended use, fit the hardware at the required speed, and handle the client's languages and document types; only then is it scored on the client's own test set. Public leaderboards are a way to build a shortlist, never a way to make the decision.

## How it works

1. **Licence.** Permissive licences such as Apache 2.0 and MIT cover families including Qwen3.5, Gemma 4, Mistral 3, DeepSeek-V4 and gpt-oss at the time of writing. Custom licences such as the Llama 4 Community License add conditions. Check the current licence file for each model and size; this is not legal advice.
2. **Shape and memory.** Dense models use every parameter per token. Mixture-of-experts models activate a few experts per token, so compute follows active parameters but memory follows total parameters.
3. **Context and modality.** Maximum context length, whether it reads images, and how well it handles the client's languages.
4. **Serving support.** Whether the chosen serving engine supports the architecture and the quantisation formats needed.
5. **Scores on the client's test set,** per task, with confidence intervals.

## Design choices and trade-offs

| Choice                                                      | Trade-off                                                                                          |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Larger model vs smaller model plus retrieval or fine-tuning | Larger models generalise better; smaller ones are cheaper, faster and often enough once adapted    |
| One model for everything vs one per task                    | One model is simpler to run; per-task models cost less and can be swapped independently            |
| Newest release vs established release                       | Newer models may score higher; established ones have better engine support and known failure modes |

## When not to use it

When data sensitivity, volume and terms all allow a hosted model, and no task needs to run inside the boundary, self-hosting adds operational work without a matching benefit.

## How we evaluate it

Every shortlisted model runs the same frozen test set under the same prompts, at the quantisation level that would be deployed. Results are reported per task with bootstrap confidence intervals, alongside measured latency and memory on the target hardware.

## Sources

- [Qwen3.5](https://huggingface.co/Qwen/Qwen3.5-9B), [Gemma 4](https://opensource.googleblog.com/2026/03/gemma-4-expanding-the-gemmaverse-with-apache-20.html), [Mistral 3](https://mistral.ai/news/mistral-3), [DeepSeek-V4](https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash), [gpt-oss](https://huggingface.co/openai/gpt-oss-120b), [Llama 4](https://huggingface.co/meta-llama/Llama-4-Maverick-17B-128E-Original)
- Explainer: [Language models and open weights](https://www.alesanalytics.com/explainers/language-models-and-open-weights)

## Contact

solutions@alesanalytics.com, or https://www.alesanalytics.com/contact.

- Every page as Markdown: https://www.alesanalytics.com/llms.txt