The short answer
Most articles with this title never name a model, because names go stale in weeks. Here are the names anyway, each checked against its own Hugging Face model card in early September 2026: Qwen 3.8 from Alibaba, DeepSeek V4, GLM 5.2 and 5.3 from Z.ai, Gemma 4 from Google, Mistral Small 4 and Large 3, IBM Granite 4.2, OpenAI's gpt-oss, Meta's Llama 4, Kimi K3 from Moonshot AI, NVIDIA Nemotron 3.5, Microsoft Phi-4, and Ai2's OLMo 3.1.
The part that costs money when you get it wrong is not capability. It is the license. Open-weight licenses run from MIT and Apache 2.0, which let you do essentially anything, to custom community licenses carrying revenue thresholds, user-count triggers, mandatory on-screen attribution, and separate-agreement requirements if you let anyone else call the model. Two models from the same publisher, weeks apart, routinely land at opposite ends of that range. GLM-5.2 is MIT. GLM-5.3 is not. Qwen3.8-27B is Apache 2.0. Qwen3.8-Flash-Next is not.
Everything below reflects the cards as they read in early September 2026, and it will age. Before you commit, open the card, read the license field, and open the LICENSE file behind it. That text is the only version that counts, and none of this is legal advice.
Open weights, open source, and a closed API are three different things
An open-weight model is one whose trained parameters are published for download. You can run it on a machine under your desk, in your own cloud account, or through whichever hosting provider you like this quarter. Nobody meters it, deprecates it, or changes it underneath you. That is the entire property that matters.
Open source, in the sense the phrase means for software, implies you can see and rebuild how the thing was made: training data, training code, recipe. Almost none of these models qualify. Ai2's OLMo 3.1 is the exception, publishing code, checkpoints and training details alongside Apache 2.0 weights. A closed API model publishes nothing: you send tokens, you pay per token, you get capability without ownership. That is a legitimate trade and often the right one.
The distinction that matters in practice: open weights tells you that you can run it. It tells you nothing about what you may do with it commercially. Those are independent facts, and the second lives in the license file.
Why a business would run open weights, and what it really costs
Four reasons hold up. Data residency: if your inputs are medical records, legal files or payroll, a model inside your own boundary removes an entire class of contractual question, because there is no model vendor in the request path. This is the most common reason clients end up self-hosting, and our guide to self-hosted AI for business goes deeper. No per-token bill: cost becomes hardware, roughly fixed, rather than usage, which is not. No forced deprecation: a hosted model can be retired or silently re-tuned and your prompts regress overnight, while a downloaded checkpoint behaves in March exactly as it did in September. Offline operation: air-gapped sites, factory floors, field devices.
The costs are equally real and usually missing from the business case. An idle GPU costs the same as a busy one, so a deployment serving twelve requests a day is more expensive per useful answer than an API. Someone must own updates. Evaluation stops being the provider's problem, so you need your own test set of real examples and the habit of running it. So do guardrails: content filtering and prompt-injection defence become things you configure, often with a separate safety model such as IBM's Granite Guardian alongside the main one. And acceptable latency under load means batching and serving-stack work a hosted endpoint hides from you.
The open-weight model families worth knowing, as of September 2026
Grouped by publisher, with what each is good for, the sizes a business could realistically run, the context length, and the license as it reads on the card. There is no ranked score table here on purpose: published benchmark numbers move faster than this page can, and they will not tell you whether a model handles your invoices.
One structural note. Most current frontier open-weight models are mixture-of-experts, so they quote two parameter counts: total parameters determine how much memory holds the model, active parameters determine compute per token. A 284B-total, 13B-active model computes about as fast as a 13B model while still needing memory for all 284B. When a vendor quotes one number, find the other before sizing anything.
Qwen 3.8 (Alibaba) — the broadest range, and a licensing trap
Qwen has the most variants and the widest tooling support, which means the fewest deployment surprises. The generation spans Qwen3.8-27B — roughly 28B, multimodal, 262,144 tokens of native context extensible toward a million — up to Qwen3.8-2.4T-A95B at 2.4 trillion total and 95 billion active, with Qwen3.8-Flash-Next between them at 125B total and about 6B active.
Their licenses differ, and this is the most important thing on the page. Qwen3.8-27B is Apache 2.0, no strings. Qwen3.8-Flash-Next carries the Qwen Community License 1.0: a separate license is required if you offer the model as a service, or if your product is an AI coding or office-productivity assistant, with internal-only use exempt. Qwen3.8-2.4T-A95B carries a qwen3.8-max license with a similar gate above a stated 50 million dollar revenue threshold, plus UI display of the model name above 100 million monthly active users or 20 million dollars monthly revenue. For a product customers log into, the 27B ships without further reading.
DeepSeek V4 — MIT, at frontier scale
Both V4 sizes are MIT licensed, about as permissive as it gets: no revenue thresholds, no user triggers, no naming requirements, no restriction on reselling inference. DeepSeek-V4-Flash is 284B total with 13B active and a one-million-token context; DeepSeek-V4-Pro is 1.6T total with 49B active, also a million tokens. An experimental vision-capable Flash variant sits in the repository. The constraint is memory, not law — neither fits on anything a small business owns, so these are models you rent GPUs for. If your reason for going open-weight is license freedom rather than physical data custody, this is the cleanest answer in the category.
GLM 5.2 and 5.3 (Z.ai) — coding and agents, license varies by release
GLM built its reputation on coding and agentic tool use. GLM-5.2 is 753B parameters with a one-million-token context and is MIT. GLM-5.3 is also 753B but ships under a custom glm-5.3 license, permitting commercial use generally while requiring a Z.ai security review before commercial deployment for model-as-a-service operators whose aggregate revenue exceeds ten billion dollars over any consecutive twelve months. GLM-5.3-Flash, a natively multimodal 320B-total, 18B-active model with a 300,000-token context, is back to MIT. Within one family, weeks apart: MIT, custom, MIT. That threshold will never bind on a normal business, but know it is there rather than discover it.
Gemma 4 (Google) — the best fit for hardware you already own
Gemma is Google's small-and-efficient line, and Gemma 4 is where it becomes easy to recommend. The family runs from E2B and E4B, at roughly 2.3B and 4.5B effective parameters with 128K context, through a 12B unified model and a 26B mixture-of-experts variant at about 25B total and 3.8B active, up to a 31B dense model, with 256K context on the larger sizes. The license field reads apache-2.0, a meaningful change from earlier Gemma generations that shipped under Google's own custom Gemma Terms of Use. The cards still link to a Gemma 4 license page on Google's developer site, so read both.
Mistral — Apache 2.0 all the way up
Mistral's lineup spans small Ministral models through Mistral Small 4, at 119B total and roughly 6.5B active with a 256K context, up to Mistral-Large-3 at 675B, also 256K. Both Small 4 and Large 3 read apache-2.0 on their cards. That matters because Mistral historically split its range, putting some models under research-only or non-production terms while others were Apache. Having the flagship under Apache 2.0 makes Mistral one of the few European-published families you can build a commercial product on without qualification. Smaller and specialist repositories should still be checked individually.
gpt-oss (OpenAI) — clean license, and now visibly aging
OpenAI's open-weight release is two models, gpt-oss-120b at about 117B parameters and gpt-oss-20b at about 21B, both Apache 2.0 and subject to OpenAI's separate gpt-oss usage policy. Both were built for reasoning and tool use, and the 20b was designed to run on hardware a business plausibly owns. The honest caveat: as of September 2026 neither main repository has seen a new generation since 2025. Safeguard variants exist for content classification, but the base models are roughly a year old, which in this field is a long time. Still a clean-licensed choice for local work; no longer the capability answer.
Llama 4 (Meta) — familiar, well-supported, most restrictive license here
Llama 4 comes in Scout, at 109B total with 17B active across 16 experts, and Maverick, at 402B total with 17B active across 128 experts. The ecosystem is still the deepest in the category: more tutorials, more fine-tunes, more tooling that assumes it by default.
The license field reads llama4, the Llama 4 Community License, and it is the most conditional here. You must request a separate license from Meta above 700 million monthly active users. If you distribute the model or a derivative you must display Built with Llama prominently, and any derivative you release must have a name beginning with Llama. Meta's Acceptable Use Policy applies, and the repositories are gated, so you accept terms and identify yourself before downloading weights at all. For internal deployment none of this is onerous; for anyone shipping a fine-tuned model in a product, the naming and attribution rules are product decisions. Note also that the Llama 4 repositories were last updated in May 2025.
IBM Granite 4.2 — the enterprise-shaped choice
Granite 4.2 comes in 3B, 8B and 30B sizes, all Apache 2.0, with 128K native context extensible toward 512K. The 8B is the sweet spot for most business deployments: small enough for modest hardware, large enough for reasoning, code generation, tool calling and multilingual dialogue. What distinguishes Granite is the surrounding apparatus rather than raw capability — IBM ships Granite Guardian as a companion risk-detection model aligned to its published AI Risk Atlas, and documents provenance and intended use in the detail procurement and risk functions ask for.
Kimi K3 (Moonshot AI) — long-context work, community license
Kimi K3 is 2.8T total with 104B active and a 1,048,576-token context, and the family's reputation is document-heavy, long-horizon work. The license field reads kimi-k3. Commercial use is permitted, but organisations whose aggregate revenue exceeds 20 million dollars over twelve consecutive months must enter a separate agreement with Moonshot AI before operating it as a service, and products above 100 million monthly active users or 20 million dollars monthly revenue must display Kimi K3 prominently in the interface. Internal use where outputs are not made available to third parties is exempt, as is access through Moonshot's own products and certified inference partners. That 20 million bar is low enough that a mid-sized software company could hit it.
The small and specialist tier — Nemotron, Phi, OLMo
NVIDIA Nemotron 3.5 Lightning is 30B total with 3B active and up to a million tokens of context, though the card notes 256K is the practical ceiling on a single H100 for memory reasons. It ships under OpenMDW-1.1, an open model license permitting commercial use with no revenue or user restrictions, asking only that you retain notices when redistributing; the card states plainly that the model is ready for commercial use.
Microsoft Phi-4 continues the small-model line, including a reasoning-vision variant at 15B under MIT, aimed at chart, diagram and screen understanding. Its 16,384-token context is far shorter than the rest of this list — fine for focused tasks, disqualifying for document work. Ai2 OLMo 3.1 at 7B and 32B is Apache 2.0 and the closest thing here to genuinely open source. For most businesses that is a research property, but if you must explain to a regulator exactly what went into a model, it is the only family that can answer. For more on fine-tuned open-weight variants, see our write-up on open-weights models for business.
Licenses: the two-minute check that prevents the expensive mistake
The failure mode is assuming a brand has a license. It does not; a repository has a license. Qwen ships Apache 2.0, a community license and a max-tier license simultaneously across one generation. Z.ai shipped MIT, a custom license, then MIT again across three consecutive releases. Mistral historically mixed Apache with research-only terms. Gemma changed license type between generations. So the check is per model, every time: open the Hugging Face card, read the license field in the header, click through to the LICENSE file, and search it for revenue, monthly active, service, and name.
If none of those words appear you are almost certainly in the permissive tier — MIT, Apache 2.0 or OpenMDW-1.1 — which permits commercial use, modification, fine-tuning and reselling inference with no thresholds or naming requirements. If any appear, four patterns recur across publishers and are worth recognising: a model-as-a-service clause requiring a separate agreement before third parties send their own inputs to the model, a revenue or user threshold above which extra obligations apply, a UI attribution requirement to display the model name in your product, and in Meta's case a derivative naming rule.
The thresholds vary by two orders of magnitude, and that variance is the point. Z.ai's GLM-5.3 gate sits at ten billion dollars, which no reader here will touch. Kimi K3's sits at twenty million, which a growing software business genuinely could. Qwen's max-tier gate sits at fifty million with an extra clause specific to coding and office-productivity assistants — a narrow and surprisingly relevant carve-out if that is what you are building. To be explicit: this article is a pointer, not a legal opinion. The repository's license text is the only authoritative version, it can change between releases, and if the decision is commercially significant, have a lawyer read it.
How to actually run one
Downloading weights is the easy part. Three deployment shapes, genuinely different economics.
A hosted inference provider. Several providers host popular open-weight models behind an OpenAI-compatible API and bill per token. Use this first, always, to learn whether a model can do your task before spending on hardware. What you do not get is the reason you wanted open weights: your data goes to a third party, so the residency argument evaporates. What you keep is portability — because the weights are public you can change provider or bring it in-house without changing models.
Your own cloud GPU. Rent instances in your own cloud account and serve the model yourself. Data stays inside your tenancy and under your existing agreements, satisfying most residency requirements that are not strictly on-premises. The economics turn on utilisation, because a rented GPU bills whether or not anyone uses it. Do the arithmetic first: monthly instance cost divided by realistic monthly request count, against the per-token price of the same model hosted.
On-premises. Hardware you own, in a building you control — the only option that fully delivers offline operation and physical data custody. For small models the tooling is undemanding; a runner like Ollama will have a compact model answering requests in minutes, and our guide to Ollama for business covers the setup. At frontier scale it means a serious capital purchase and someone who owns it. On-prem is a compliance and continuity decision, not a cost-saving one.
The hardware reality, briefly
Model size drives memory, memory drives hardware, hardware drives the budget. A 3B to 8B model in a quantised format runs on a decent laptop or a single consumer GPU. A 27B to 31B model wants a serious workstation card or a small cloud instance. A 300B-total mixture-of-experts model needs multiple datacentre GPUs just to hold the weights, even though its low active-parameter count makes each token cheap. Active parameters tell you about speed; total parameters tell you the size of the cheque. Our local LLM cost and hardware guide has the tier-by-tier numbers.
The implication for selection: start from the hardware you have or will buy, filter to models that fit, and only then compare capability. Choosing a model first and discovering the hardware requirement second is how self-hosting projects die.
Most small businesses should just use a hosted API
This is the truthful answer for the majority of readers. With no data-residency requirement, no offline requirement and moderate volumes, a commercial API will cost less in total, take a fraction of the setup time, and give better capability on hard tasks than anything you can comfortably self-host. The arithmetic is not close: typical business AI usage runs roughly 30 to 150 dollars a month in API charges, while a single capable GPU costs more than that per month to rent and considerably more to buy, before anyone's time. Self-hosting starts winning when volume pushes per-token cost above fixed infrastructure cost, or when a non-financial requirement makes the comparison irrelevant.
Insist that the keys are yours regardless. Bring-your-own-key means you hold the provider account, you see real usage, and nobody marks up your model spend, which our BYOK explainer walks through. That is the same ownership principle open weights give you, applied to a hosted model. A sensible stack often uses both: a cheap self-hosted small model for high-volume classification and extraction, a hosted frontier model for the handful of genuinely hard requests. Build so the model is a swappable component rather than hard-coded into your workflows — that decision costs nothing at the start and stops any of these choices becoming permanent.
How to choose, in order
Write down the specific task with ten real examples from your own business, not hypothetical ones. Decide whether you have a hard requirement for data residency or offline operation. If you do not, price a hosted API first and be genuinely willing to stop there.
If you do, filter by hardware before capability, then run the two-minute license check on each survivor and drop anything whose terms conflict with how you plan to ship. Test what remains on your ten examples, starting with the smallest, and pick the smallest that clears your bar rather than the best that exists. Re-run that set every few months: the releases that matter are the ones letting you drop a size tier at the same quality.
Frequently asked questions
What is the best open-source LLM right now?
No single answer, but as of September 2026 there is a defensible shortlist. For hardware you already own, Gemma 4 or Granite 4.2 at 8B to 31B. For frontier capability with a genuinely unrestricted license, DeepSeek V4, which is MIT. For coding and agentic work, GLM-5.3-Flash or Qwen 3.8. For a product you ship to customers, Qwen3.8-27B or Mistral Small 4, both permissively licensed. Verify the current generation and license before acting on this.
Are open-source LLMs free for commercial use?
The weights are free to download; commercial permission depends on the license. MIT, Apache 2.0 and OpenMDW-1.1 models are free for commercial use with essentially no conditions. Custom community licenses — Llama 4, Kimi K3, Qwen's community and max tiers, GLM-5.3 — permit commercial use but attach conditions triggering at defined revenue or user thresholds, or if you offer inference to third parties. Read the repository's LICENSE file rather than trusting any summary, including this one.
What is the difference between open-source and open-weight models?
Open-weight means the trained parameters are published so you can download and run the model. Open source, strictly, means the training data, code and full recipe are published too, so the model could in principle be rebuilt. Almost every model called open source in the AI industry is really open-weight. Ai2's OLMo is the main family meeting the stricter definition. The distinction matters for auditability, not for whether you can run it.
Can I fine-tune an open-weight model and sell the result?
Under MIT, Apache 2.0 and OpenMDW-1.1, yes, without conditions. Under community licenses it depends. A Llama 4 derivative must have a name beginning with Llama and must display Built with Llama. Qwen's community and max licenses require a separate agreement if the product is an AI coding or office-productivity assistant, or if you offer the model as a service. Several licenses also require displaying the model name in your interface above stated scale thresholds.
How much hardware do I need to run an open-source LLM?
For a 3B to 8B model in a quantised format, a modern laptop or single consumer GPU is enough for light use. For 27B to 31B, expect a workstation-class GPU or a cloud instance with 24GB or more of video memory. Frontier models in the hundreds of billions need multiple datacentre GPUs regardless of how few parameters are active per token, because the whole model still has to fit in memory.
Are open-weight models as good as the leading proprietary ones?
For the work most business automation actually consists of, the gap has largely closed. Summarisation, classification, data extraction, routine drafting and question-answering over your own documents are handled well by open-weight models several tiers below the frontier. Where proprietary models still tend to lead is the hardest multi-step reasoning and the most demanding agentic tool use. If your use case sits there, use an API. Pick per workload, not per ideology.
How often will this list go out of date?
Quickly. Across these families new generations arrive every few weeks, and licenses change between generations rather than staying put, as Gemma and Mistral both demonstrate. Treat this page as a starting shortlist and a set of questions to ask, not a current inventory. The durable parts are the framework: check the license per repository, size by total parameters, test on your own examples, keep the model swappable.
Should I self-host or use an API?
Use an API unless you have a specific reason not to. The reasons that justify self-hosting are data residency, offline operation, very high request volumes where fixed infrastructure beats per-token pricing, or a need for a frozen model that will never change. If none apply, hosted is cheaper and faster to stand up. If you are unsure which side you fall on, our free automation audit takes about three minutes, needs no call, and returns a health score with ranked quick wins for your situation.