Open-Weight Models

Open weights now ship under three licence regimes, and only one of them is actually open

"Open-weight model" is a marketing phrase, not a licence class, and the gap between the two is where most bad procurement decisions in this field start. Reading the actual licence files — not the model cards, the licence files — the field divides into three regimes. First, genuinely permissive: Apache-2.0 or MIT, where the weights arrive with the same rights as an open-source library — Qwen3 (Apache-2.0 per its model card), gpt-oss (Apache-2.0, stated in bold on the model card), GLM-4.5 through 4.7 (MIT, stated explicitly in the repository README with the words "can be used commercially and for secondary development"). Second, bespoke community licences with real strings: Meta's Llama Community License and Google's Gemma Terms of Use — downloadable, usable, but contracts rather than open-source licences, with attribution duties, use policies, and termination clauses. Third, custom model agreements: DeepSeek ships its code under MIT and its weights under a separate "DeepSeek Model Agreement" — two licence badges on one repository, a distinction most coverage flattens — and Moonshot's Kimi K3 ships under a purpose-built "kimi-k3" licence classified as "other" on its Hugging Face model card.

The regime determines what your lawyers do. Under Apache-2.0 or MIT, legal review is a five-minute confirmation. Under the Llama or Gemma terms, someone must actually read clauses about naming, monthly-active-user thresholds, prohibited-use flow-down, and — in Gemma's case — whether your fine-tune counts as a derivative of the weights or of the outputs. Under a custom agreement, the review is bespoke every time. Every regime in this dossier is commercially usable today; the differences are in what obligations attach and who can take them on. This dossier reads the primary documents for the seven families that matter most and takes positions: DeepSeek-V3, Qwen3, Kimi K3, GLM-4.5 through 4.7, gpt-oss, Llama, and Gemma.

The frontier is measured in activated parameters, and that changes what open can be

The defining architectural fact of the current open-weight generation is sparsity. Nearly every frontier-class open release is now a Mixture-of-Experts model whose total parameter count is a storage problem and whose activated parameter count is the actual compute cost per token: DeepSeek-V3 is 671 billion parameters with 37 billion active; Kimi K3 is 2.8 trillion total with 104 billion active across 896 experts, 16 selected per token; GLM-4.5 is 355 billion total with 32 billion active; Qwen3-235B-A22B is 235 billion total with 22 billion active; gpt-oss-120b is 117 billion total with 5.1 billion active. Five years ago "open weights" meant dense seven-billion-parameter models that ran on a gaming GPU; today an organization can download weights whose flagship competitor is a closed model behind an API, and pay only for the slice of the network each token touches.

The second structural fact is quantization at training time. DeepSeek-V3 was trained natively in FP8 — its README documents the first large-scale validation of FP8 training, at a total cost of 2.788 million H800 GPU-hours across 14.8 trillion tokens — and ships FP8 weights only, with a conversion script for BF16. Kimi K3 ships MXFP4 weights with MXFP8 activations under quantization-aware training. gpt-oss was post-trained with MXFP4 quantization on its MoE weights, which is precisely why the 120-billion-parameter model fits on a single 80GB GPU and the 20-billion sibling fits in 16GB of memory. The weights are no longer an idealized full-precision artifact you downscale later; the release format is the trained format, which improves quality-per-gigabyte and moves the quantization decision from your toolchain to the vendor's training run.

flowchart TD
    NEED["Workload needs open weights"] --> LIC{"Which licence regime works"}
    LIC -->|"Apache or MIT"| BUD{"Serving budget"}
    LIC -->|"bespoke terms acceptable"| BESPOKE["Llama or Gemma terms review<br/>naming, usage thresholds, derivative clauses"]
    BUD -->|"one 80GB GPU"| OSS["gpt-oss-120b<br/>117B total, 5.1B active, MXFP4"]
    BUD -->|"8 to 16 datacenter GPUs"| MID["GLM-4.5 or Qwen3-235B-A22B<br/>355B total, 22 to 32B active"]
    BUD -->|"multi-node rack"| FRONT["DeepSeek-V3 or Kimi K3<br/>671B to 2.8T total"]
    BESPOKE --> REVIEW["Read derivative and use clauses<br/>before the download finishes"]
    OSS --> SERVE["Serve on vLLM or SGLang<br/>day-zero support is the norm"]
    MID --> SERVE
    FRONT --> SERVE
    REVIEW --> SERVE

The fastest-moving open models come out of China, and their own benchmarks say so

Read the model cards in sequence and a pattern is unmistakable: the aggressive frontier of open weights is DeepSeek, Qwen, Kimi, and GLM, and each publishes benchmark tables that include closed flagships as comparators. DeepSeek-V3's README benchmarks it against GPT-4o and Claude 3.5 Sonnet and claims the best open-source performance with competitive results against closed models. Kimi K3's card runs a table against Claude Fable 5, GPT-5.6, and Claude Opus 4.8, showing it ahead on several rows — BrowseComp at 91.2, SWE-Marathon at 42.0 — and behind on others, which is more credible than a clean sweep would be. GLM-4.7's README claims 73.8 percent on SWE-bench, a 5.8-point gain over its predecessor, plus gains on Terminal Bench and HLE.

My positions on each. DeepSeek-V3 is the field's efficiency landmark: the FP8 training result and the auxiliary-loss-free load-balancing strategy are documented engineering, and the 128K-context MoE at 37 billion active parameters remains the reference point for capability per activated parameter. Its weight licence is the split MIT-code-plus-model-agreement arrangement, and its README's local-deployment section is a tour of the serving ecosystem. Qwen3 is the breadth play: sizes from 0.6B to 235B-A22B, a 2507 refresh that split into separate Instruct and Thinking variants, 256K context extendable toward a million tokens, and the deepest runtime coverage in the field — its README documents llama.cpp, Ollama, LM Studio, MLX, ExecuTorch, MNN, OpenVINO, SGLang, vLLM, and TensorRT-LLM recipes. Kimi K3 is the scale statement: the first open 3T-class model, native vision through a MoonViT-V2 encoder, a 1,048,576-token context window, and quantization-aware training in the release weights. GLM-4.5 through 4.7 is the agent-workflow specialist — interleaved, preserved, and turn-level thinking modes designed around coding agents like Claude Code and Cline — under the cleanest licence in the Chinese cohort.

The Western open-weight strategy is permissive licences at deliberately chosen scales

gpt-oss is the Western exception that proves the strategy: OpenAI released two MoE models under Apache-2.0 — 117 billion parameters with 5.1 billion active for a single 80GB GPU, and 21 billion with 3.6 billion active for 16GB of memory — with full chain-of-thought exposed, configurable reasoning effort, native function calling and browsing, and fine-tuning support. The model card's licensing paragraph sells the licence as a feature: "build freely without copyleft restrictions or patent risk." One hard constraint is documented without apology: both models were trained on the harmony response format and "should only be used with the harmony format as it will not work correctly otherwise." My position: gpt-oss is the most operationally thoughtful Western release — the MXFP4 quantization target and single-GPU envelope were design goals, not afterthoughts — and the format coupling is the tax.

Gemma and Llama are the licence-led counterweights. Gemma's Terms of Use were, per the page's own last-modified date, revised this April — and the headline change is that the terms page now points Gemma 4 at a separate Apache-2.0 licence, while every earlier Gemma generation remains under the bespoke terms. Those earlier terms contain the most aggressive derivative definition in mainstream use: a Model Derivative includes "any other machine learning model which is created by transfer of the patterns of the weights, parameters, operations, or Output of Gemma" — explicitly naming distillation methods and synthetic-data training — so a model distilled from Gemma outputs is a Gemma derivative carrying the use restrictions forward. The terms also preserve Google's right to restrict usage "remotely or otherwise," and require the restrictions to flow down as an enforceable provision in any downstream agreement. Llama 3.1's Community License requires "Built with Llama" attribution, forces the "Llama" name onto any model fine-tuned from it, incorporates an acceptable-use policy, and carries the famous clause: above 700 million monthly active users, you must request a licence Meta may grant "in its sole discretion." My positions: Llama's restrictions are the reason its ecosystem spawned a thousand "uncensored Llama" derivatives that are technically non-compliant — the clause set is widely ignored at scale, which is a governance failure nobody has litigated; Gemma's terms are the most lawyer-dense in the field and the April move to Apache for Gemma 4 reads as an admission that the density was costing adoption; gpt-oss is what a Western lab releases when it decides openness itself is the competitive act.

The seven families on the axes that decide adoption:

Family	Licence	Total / active params	Context	Release quantization	Hardware envelope	My one-line position
DeepSeek-V3	MIT code + custom model agreement	671B / 37B	128K	FP8 (BF16 via script)	Multi-node; SGLang, vLLM, TensorRT-LLM, Ascend, AMD	Efficiency landmark; licence citation requires care
Qwen3 (2507)	Apache-2.0	0.6B up to 235B / 22B	256K, to ~1M	BF16 plus community quants	Desktop to 8-GPU nodes	Breadth king; read the per-runtime notes
Kimi K3	Custom kimi-k3	2.8T / 104B	1,048,576	MXFP4 weights, MXFP8 activations (QAT)	Rack-class; day-zero SGLang support	Scale statement; verify the custom licence for your use
GLM-4.5 to 4.7	MIT	355B / 32B (Air 106B / 12B; Flash 30B / 3B)	128K to 200K	BF16 and FP8	8 to 16 H100s; Flash on one H100	Agent-workflow specialist, cleanest Chinese-cohort licence
gpt-oss	Apache-2.0	117B / 5.1B and 21B / 3.6B	Documented per card	MXFP4 post-trained	Single 80GB GPU; 16GB for the small model	Best-documented small-footprint MoE; harmony format is mandatory
Llama 3.1	Community License (bespoke)	Dense family	128K class	BF16	Broad	Governance minefield: naming, MAU clause, flow-down
Gemma (1 to 3n)	Gemma Terms of Use (bespoke); Gemma 4 Apache-2.0	Small-to-mid dense	Varies by generation	BF16	Laptop to single GPU	Read the distillation clause; the v4 licence break is real

One serving-tier observation ties the MoE economics together: sparsity is what makes the day-zero support race possible at all. An engine that has implemented general MoE kernels plus one model-specific attention path can adopt a new 671-billion or 2.8-trillion-parameter release in days, because the compute per token is bounded by the activated slice — 37 billion here, 104 billion there — not by the download size. The cost you are optimizing when you choose among these models is not tokens-per-second alone but tokens-per-second per activated parameter per GPU-hour, and the activated-parameter column above is the closest thing the field has to a price tag.

The licence fine print does real work: read the derivative clause before you distill

The compliance failure modes in this field are all fine-print failures, and the review flow is the same regardless of vendor:

sequenceDiagram
    participant You as Your team
    participant Card as Model card and licence file
    participant Legal as Licence review
    participant Run as Serving runtime

    You->>Card: Shortlist model by benchmarks
    Card->>You: Weights, licence name, use policy
    You->>Legal: Derivative, attribution, threshold clauses
    alt permissive licence
        Legal-->>You: Apache or MIT - no flow-down duties
    else bespoke terms
        Legal-->>You: Naming, attribution, flow-down, restrictions
        You->>You: Propagate clauses into downstream agreements
    end
    You->>Run: Serve on vLLM or SGLang
    Run-->>You: Weights load, prompt format applied
    Note over You,Run: Licence review must finish before deployment, not after the fine-tune has shipped

Three clauses I would flag in any review. The Llama naming requirement — any model fine-tuned from Llama materials must carry "Llama" at the start of its name — is a branding obligation that outlives the fine-tune and attaches to products built on it. The Gemma distillation clause reaches outputs used as training data, which means your Gemma-generated synthetic dataset is a provenance question, not just a data-quality question. And DeepSeek's split licensing means the phrase "DeepSeek is MIT" is half true in a way that matters: the inference code is MIT, the weights are governed by the separate model agreement, and citing the wrong half in a procurement memo is exactly the kind of error the two-badge README layout invites.

The real specification is the hardware table, not the parameter count

Model cards sell capabilities; the deployment tables state costs. GLM's README is the most honest artefact here: GLM-4.5 in BF16 requires 16 H100s, the FP8 build needs 8, full 128K-context BF16 serving wants 32, and the hosting server needs more than a terabyte of system memory. Qwen's own documentation for million-token context on the 235B model states the requirement flatly: approximately 1000 GB of total GPU memory for weights, KV cache, and activations, with max-num-seqs 1 recommended at that length. Against that, gpt-oss-120b on one 80GB GPU and gpt-oss-20b in 16GB are the calibrated low end, and Qwen3's 30B-A3B and 4B models are the desktop tier.

The serving ecosystem closes the gap between release and deployment. vLLM's README claims support for 200-plus Hugging Face architectures, and SGLang's news log documents day-zero support for DeepSeek-V4, Kimi K3, and Nemotron releases within days of their weight drops — for the Chinese MoE frontier, the runtime support is effectively part of the release. The DeepSeek-V3 README reads as evidence: its local-deployment section is a directory of SGLang, LMDeploy, TensorRT-LLM, vLLM, LightLLM, AMD, and Ascend paths, with the note that Hugging Face Transformers was "not directly supported yet" at publication. My position: treat the runtime support matrix as part of the model's spec sheet. A frontier weight without a serving path on your hardware is a benchmark result, not a deployment option.

Where open weights break

The prompt-format coupling trap. Trigger: running a model whose output format is load-bearing without applying its required template. gpt-oss "will not work correctly" outside the harmony format, per its own card. Qwen3-2507 split into Instruct and Thinking variants where the Instruct build no longer emits think blocks and the Thinking build ships a template that auto-opens a think tag — code written against the 2504 hybrid behavior breaks silently on the 2507 builds. The failure looks like a model regression and is a template mismatch.

The convenience-layer default trap. Trigger: serving recent MoE models through desktop tooling at default settings. Qwen's README warns specifically that Ollama's defaults — a 2048-token context with unbounded generation — "could lead to trouble for Qwen3 models," and that Ollama's model naming may not match the official names at all (qwen3:30b-a3b resolved to a Thinking-2507 quantization as of its documentation). The failure is a model that seems to forget everything after two paragraphs; the fix is reading the model card's parameter notes before, not after, the demo.

The activated-parameter hardware floor. Trigger: sizing a deployment from the total parameter count, or from a colleague's experience with a different model. The GLM table and Qwen's 1000GB-for-1M-context figure show how nonlinear the jump is; the failure is a mid-project discovery that your cluster is one tensor-parallel tier short. Size from the card's own deployment table or a benchmark on your hardware, and treat FP8 or MXFP4 release formats as the intended operating point rather than a degradation to reverse.

Self-reported benchmarks against stale comparators. Trigger: adopting a model on the strength of its card's table. DeepSeek-V3's headline comparisons include GPT-4o from May 2024 and Claude 3.5 Sonnet from October — accurate at publication, stale now — and every vendor table has the same half-life. Kimi K3's against-current-flagships table is the better pattern, but it is still vendor-run. The mitigations are boring and mandatory: independent leaderboards where they exist, your own eval set always, and the assumption that every published number is a best case.

Licence drift between generations. Trigger: standardizing on a family's terms and assuming the next generation keeps them. Gemma's terms page moved Gemma 4 to Apache-2.0 while leaving every prior generation under the bespoke terms — the same brand name now means two different legal regimes depending on the version number. Any licence review must name the exact model version, and any compliance document that says "Gemma" without a version is unfinished.

"Open source" as a category error. Trigger: procurement documents that treat an open-weight release as open-source software. The weights are most often governed by a bespoke agreement (Llama, Gemma, DeepSeek's model licence, Kimi's kimi-k3), and only some families ship under genuinely open licences. The failure surfaces when a compliance team discovers, post-adoption, that the model on the approved list has a 700-million-user clause or a remotely restrictable use grant. Put the licence file in the procurement packet, not the marketing page.

Weight-format standards, licence uniformity, and the synthetic-data boundary stay unresolved

Three questions have no settled answer. First, will the licence regimes converge? Gemma 4's move to Apache-2.0 and GLM's MIT are pull factors, while Kimi K3's custom licence and Llama's persistence push the other way; if the permissive regime keeps winning, the field's compliance overhead collapses to nothing, and if it does not, bespoke licences remain a real tax on the entire downstream ecosystem. Second, where does the derivative boundary sit for outputs? Gemma's terms treat Gemma-generated synthetic training data as creating a derivative model — if that interpretation spreads to other licences, every model trained partly on open-model outputs inherits a provenance obligation, which would reach deep into fine-tuning pipelines that nobody currently audits. Third, how long does the day-zero runtime race stay winnable? Frontier releases keep getting larger — Kimi K3's 2.8 trillion parameters is a new order of magnitude — and the gap between "weights are public" and "weights are servable on hardware you can afford" is the real openness metric; it is measured in GPU memory tables, and nobody publishes its trend line.

Resources

Model repositories, cards, and licences

• DeepSeek-V3 README — 671B/37B MoE architecture, FP8 training cost figures, split code-MIT and model-agreement licence badges, local-deployment directory.
• Qwen3 README — Qwen3-2507 Instruct and Thinking variants, size range, 256K-to-1M context, per-runtime recipes, Ollama naming and context warnings.
• Qwen3-235B-A22B-Instruct-2507 model card — Apache-2.0 licence, 1M-context memory requirement of roughly 1000GB, benchmark tables.
• gpt-oss-120b model card — Apache-2.0, 117B/5.1B active, MXFP4 on a single 80GB GPU, harmony-format requirement, reasoning levels.
• Kimi K3 README — 2.8T total and 104B active parameters, KDA and Gated MLA architecture, MXFP4 quantization-aware training, benchmark tables against closed flagships.
• Kimi K3 Hugging Face model card — kimi-k3 custom licence classification, download and engagement counts.
• GLM-4.5 / 4.6 / 4.7 README — MIT licence statement, 355B-A32B and 106B-A12B tiers, hardware requirement tables, thinking-mode variants.
• Llama 3.1 Community License — full licence text: attribution and naming duties, 700M MAU clause, acceptable-use policy incorporation.
• Gemma Terms of Use — derivative definition covering distillation and synthetic outputs, use-restriction flow-down, remote-restriction right, Gemma 4 Apache-2.0 pointer.

Serving-layer context

• vLLM README — 200-plus supported architectures, quantization coverage including GGUF, parallelism strategies, hardware plugins.
• SGLang README — day-zero support history for DeepSeek, Kimi, and Nemotron releases; deployment scale claims.