Qwen is now the open-model default. When an open model beats an API for your workload

Hugging Face published its State of Open Models report for summer 2026 on 14 August, and three of its findings should change how a buyer thinks about the open-weight option.

First, Qwen has become the base the community builds on. Qwen-derived models number 151,448 on the Hub, 2.6 times Meta's total footprint and 4.7 times the Llama repositories specifically, growing at 180 to 210 new repositories a day through the first seven months of the year. Second, the frontier of open weights is mostly Chinese. In almost every month of 2026 the largest open model from a Chinese lab was bigger than anything an American lab released, with Chinese monthly ceilings between 754 billion and 2.78 trillion parameters while US releases stayed under 130 billion in five of seven months, NVIDIA's Nemotron 3 Ultra and Thinking Machines' Inkling being the exceptions. Third, small models remain what people actually run. Qwen's breadth across sizes, with a 27B variant alongside a 2.4 trillion parameter one, is a large part of why it won.

The report also notes a licence shift that arrived in the last few weeks: Kimi K3 and the largest Qwen 3.8 release have added non-commercial restrictions and revenue-share terms, after a year in which 59 per cent of large Chinese releases carried Apache 2.0 and 22 per cent MIT. That detail matters more to a buyer than the parameter counts.

None of this answers the question a company running AI in production needs answered, which is simpler: for this workload, is an open model I host better than an API call I make. Here is the honest answer, workload by workload.

Five cases where open weights win

The data cannot leave. Regulated data, government data, anything where you have promised a customer or a regulator that processing happens inside a boundary you control. An API call crosses the boundary by definition. A model on your own hardware, or in a sovereign cloud, does not. This is the case most Indian public-sector and financial clients start from, and it is a sufficient reason on its own.

The volume is high and steady. API pricing is a good deal for spiky, unpredictable use because you pay only for what you use. It is a poor deal for a pipeline that runs a predictable million documents a month, because the GPU you would need to run that yourself is busy enough to be cheaper than the per-token bill, once you count operations honestly. The crossover depends on the model size and your utilisation, and the calculation is worth doing once per workload rather than assuming.

The task is narrow and the model is small. A 7B to 30B model fine-tuned on your own data will beat a frontier API on a narrow classification, extraction or routing task, at a fraction of the latency and cost. This is the "practical layer" the Hugging Face report describes, and it is where open weights are strongest. The frontier API stays for the steps that need general reasoning.

Latency or locality is the product. On-device, at the edge, in a factory with unreliable connectivity, in a voice agent where every round trip to a distant API is audible. A small open model next to the user is the only architecture that works.

You need to own the behaviour. If a model change by a vendor would break your product, and you have read our migration playbook and decided you would rather control that calendar yourself, open weights let you pin a version indefinitely. You take on the cost of running it and the responsibility for patching what sits around it.

Where the API still wins

Everything else, which for most companies is most things.

The frontier is still closed. On the hardest reasoning, agentic and coding tasks, the top proprietary models lead the top open ones, and the gap re-opens with every flagship release. If the workload needs the best model available, that is an API.

Low or spiky volume makes self-hosting a hobby. A GPU that is idle 90 per cent of the time is the most expensive way to serve the other 10 per cent.

Small teams should not run inference infrastructure. Serving, scaling, patching, monitoring and securing a model endpoint is a job. If nobody on the team has done it, the API's operational simplicity is worth its premium.

And per-step routing changes the arithmetic. Most agent workloads are a mix of easy steps and hard steps. Sending the easy ones to a cheap API model and the hard ones to a frontier model, with caching and batching, often lands within reach of self-hosting cost without any of the operations.

The licence check that matters now

For a year the practical rule was that large open models from Chinese labs came with the most permissive licences available, MIT or Apache 2.0, while American labs were more likely to use custom terms or none. The report's data confirms it: on the US side of the same size band, 29 per cent is Apache or MIT, 41 per cent custom, 30 per cent undeclared.

That is changing at the top. The revenue-share and non-commercial clauses appearing on the largest new releases mean a company cannot assume the licence from the lab's reputation. Read it. Check whether commercial use is permitted, whether there is a revenue threshold, whether derivatives must carry the same terms, and whether the licence can change for versions you have already downloaded. A model on disk under a licence you have read is an asset; one deployed on the assumption it was Apache is a liability waiting for a due-diligence question.

How to decide, in an afternoon

Take one workload. Run your evaluation set against the API model you use today, against the best open model in the size class that fits your hardware, and against a small open model fine-tuned on a few hundred of your examples if the task is narrow. Record accuracy, latency and cost per task for each, with the self-hosted cost including the GPU at realistic utilisation and a share of an engineer's time.

Then apply the five cases. If the workload hits one of them and the open model passes the evaluation, host it. If it hits none, the API is almost always the better answer, and the money saved on infrastructure goes on the evaluation set that lets you switch later.

This is the assessment inside every data platforms engagement we run for clients who arrive convinced they need to self-host everything or nothing. The answer is nearly always a short list of workloads for each.

Frequently asked

Which open-weight model should a company start with in 2026? The Qwen family is the most widely built-on open model, with 151,448 derivative models on the Hugging Face Hub as of August 2026 and variants from 27B to 2.4 trillion parameters. For narrow tasks, a small model in the 7B to 30B range fine-tuned on your own data is usually the right starting point. Always run your own evaluation set and read the specific licence, because the largest recent releases have added commercial restrictions.

When is self-hosting an open model cheaper than an API? When volume is high and steady enough that the GPU you need is well utilised, when the task is narrow enough for a small model, or when data residency, latency or control requirements make an API unsuitable regardless of price. For spiky or low volume, small teams, or tasks that need frontier capability, an API is usually cheaper once operations are counted.

Are open models catching up with proprietary ones? On many everyday tasks, yes, especially in the small and mid sizes where fine-tuned open models can beat general-purpose APIs on narrow work. At the frontier of reasoning, coding and agentic tasks, the leading proprietary models still lead, and each flagship release re-opens the gap for a period.

Related reading

• On-premise, sovereign cloud, or public cloud for AI: how to choose
• Your vendor will retire the model you built on
• Opus 5 arrived at half Fable's price

Open weights are a tool for five kinds of workload and a distraction for the rest. Know which of your workloads are which before the hardware quote arrives.