@ericrisco/rsc 0.1.39 → 0.1.40
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +8 -2
- package/manifest.json +181 -3
- package/package.json +1 -1
- package/scripts/lib/domains.js +1 -0
- package/scripts/lib/recommend.js +6 -0
- package/skills/deep-learning/SKILL.md +263 -0
- package/skills/deep-learning/evals/README.md +11 -0
- package/skills/deep-learning/evals/cases.yaml +48 -0
- package/skills/deep-learning/references/distributed.md +105 -0
- package/skills/deep-learning/references/training-recipes.md +135 -0
- package/skills/finetuning/SKILL.md +244 -0
- package/skills/finetuning/evals/README.md +13 -0
- package/skills/finetuning/evals/cases.yaml +50 -0
- package/skills/finetuning/references/hyperparameters-and-eval.md +74 -0
- package/skills/finetuning/references/methods.md +189 -0
- package/skills/harness/references/providers.yaml +35 -0
- package/skills/huggingface/SKILL.md +1 -1
- package/skills/machine-learning/SKILL.md +260 -0
- package/skills/machine-learning/evals/README.md +15 -0
- package/skills/machine-learning/evals/cases.yaml +54 -0
- package/skills/machine-learning/references/gbdt-and-tuning.md +83 -0
- package/skills/machine-learning/references/metrics-and-imbalance.md +82 -0
- package/skills/machine-learning/references/pipelines-and-cv.md +135 -0
- package/skills/nlp/SKILL.md +225 -0
- package/skills/nlp/evals/README.md +10 -0
- package/skills/nlp/evals/cases.yaml +45 -0
- package/skills/nlp/references/evaluation.md +107 -0
- package/skills/nlp/references/tokenization.md +95 -0
- package/skills/open-weights/SKILL.md +239 -0
- package/skills/open-weights/evals/README.md +14 -0
- package/skills/open-weights/evals/cases.yaml +42 -0
- package/skills/open-weights/references/licenses.md +123 -0
- package/skills/open-weights/references/model-families.md +83 -0
- package/skills/open-weights/references/sizing-and-quant.md +89 -0
- package/skills/roast-me/tools/adapters/__pycache__/__init__.cpython-312.pyc +0 -0
- package/skills/roast-me/tools/adapters/__pycache__/base.cpython-312.pyc +0 -0
- package/skills/roast-me/tools/adapters/__pycache__/claude.cpython-312.pyc +0 -0
- package/skills/roast-me/tools/adapters/__pycache__/codex.cpython-312.pyc +0 -0
- package/skills/roast-me/tools/adapters/__pycache__/gemini.cpython-312.pyc +0 -0
- package/skills/roast-me/tools/adapters/__pycache__/registry.cpython-312.pyc +0 -0
- package/skills/training-data/SKILL.md +226 -0
- package/skills/training-data/evals/README.md +13 -0
- package/skills/training-data/evals/cases.yaml +41 -0
- package/skills/training-data/references/formats.md +118 -0
- package/skills/training-data/references/synthesis-dedup-quality.md +134 -0
- package/skills/unsloth/SKILL.md +254 -0
- package/skills/unsloth/evals/README.md +10 -0
- package/skills/unsloth/evals/cases.yaml +42 -0
- package/skills/unsloth/references/export.md +75 -0
- package/skills/unsloth/references/grpo.md +91 -0
- package/skills/unsloth/references/masking-and-templates.md +91 -0
- package/skills/vllm/SKILL.md +235 -0
- package/skills/vllm/evals/README.md +9 -0
- package/skills/vllm/evals/cases.yaml +47 -0
- package/skills/vllm/references/flags-and-endpoints.md +105 -0
- package/skills/vllm/references/memory-and-throughput.md +78 -0
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
# Evaluation — runnable metrics and when each one lies
|
|
2
|
+
|
|
3
|
+
Depth overflow for SKILL.md section 3. All snippets use the HF `evaluate` library and
|
|
4
|
+
`sacrebleu`; verify current API/package versions at author time. The governing rule: **pick the
|
|
5
|
+
metric that matches the task, and never let an overlap metric be the final verdict on open-ended
|
|
6
|
+
text.**
|
|
7
|
+
|
|
8
|
+
## Classification — accuracy + macro-F1
|
|
9
|
+
|
|
10
|
+
```python
|
|
11
|
+
import evaluate
|
|
12
|
+
acc = evaluate.load("accuracy")
|
|
13
|
+
f1 = evaluate.load("f1")
|
|
14
|
+
acc.compute(predictions=preds, references=labels)
|
|
15
|
+
f1.compute(predictions=preds, references=labels, average="macro") # macro on imbalance
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
- **accuracy** is honest only on balanced classes. With 95% negatives, "always predict negative"
|
|
19
|
+
scores 0.95 while being useless — **macro-F1** exposes that by averaging per-class F1 equally.
|
|
20
|
+
- Report a confusion matrix too; a single scalar hides *which* class fails.
|
|
21
|
+
|
|
22
|
+
## NER / token classification — entity-level F1 (seqeval)
|
|
23
|
+
|
|
24
|
+
```python
|
|
25
|
+
import evaluate
|
|
26
|
+
seqeval = evaluate.load("seqeval")
|
|
27
|
+
# predictions/references are lists of B-/I-/O tag STRINGS per token, specials already dropped
|
|
28
|
+
seqeval.compute(predictions=[["B-PER","I-PER","O"]],
|
|
29
|
+
references =[["B-PER","I-PER","O"]])
|
|
30
|
+
# -> precision / recall / f1 / accuracy at the ENTITY level, plus per-entity-type breakdown
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
- seqeval scores a **whole entity span** as correct only if every tag in it is right — the metric
|
|
34
|
+
that matches what NER is for. Per-token accuracy is inflated by the flood of `O` tokens and can
|
|
35
|
+
read ~0.97 on a model that misses half the entities.
|
|
36
|
+
- Align labels to subwords first: first subword of a word gets the label; continuation subwords
|
|
37
|
+
and specials get `-100` (ignored by the loss); flip `B-XXX`→`I-XXX` on continuations.
|
|
38
|
+
|
|
39
|
+
## Translation — BLEU / chrF (use sacrebleu for comparable numbers)
|
|
40
|
+
|
|
41
|
+
```python
|
|
42
|
+
import evaluate
|
|
43
|
+
sacrebleu = evaluate.load("sacrebleu")
|
|
44
|
+
sacrebleu.compute(predictions=["the cat sat on the mat"],
|
|
45
|
+
references=[["the cat sat on the mat", "a cat was on the mat"]])
|
|
46
|
+
# {'score': .., ...} chrF: evaluate.load("chrf") — character n-gram F-score
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
- Use **sacrebleu**, not a hand-rolled BLEU — tokenization/normalization differences make raw
|
|
50
|
+
BLEU numbers non-comparable across papers; sacrebleu standardizes them.
|
|
51
|
+
- **chrF** (character n-gram F-score) is often better than BLEU for **morphologically rich** and
|
|
52
|
+
agglutinative languages, because it credits partial-word overlap that word-BLEU misses.
|
|
53
|
+
|
|
54
|
+
## Summarization — ROUGE
|
|
55
|
+
|
|
56
|
+
```python
|
|
57
|
+
import evaluate
|
|
58
|
+
rouge = evaluate.load("rouge")
|
|
59
|
+
rouge.compute(predictions=[summary], references=[reference])
|
|
60
|
+
# rouge1 / rouge2 / rougeL — n-gram and longest-common-subsequence recall overlap
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
- ROUGE rewards overlap with the reference's n-grams, so it **favors extractive/copy-heavy**
|
|
64
|
+
summaries and is **blind to faithfulness** — a fluent summary that invents a fact can outscore a
|
|
65
|
+
faithful paraphrase. Pair it with a faithfulness/NLI check or an LLM judge.
|
|
66
|
+
|
|
67
|
+
## The shared caveat: overlap metrics ≠ quality on open-ended text
|
|
68
|
+
|
|
69
|
+
BLEU, ROUGE, and chrF correlate **weakly with human judgment** on open-ended and creative
|
|
70
|
+
generation (documented across the MT and summarization evaluation literature). They reward
|
|
71
|
+
matching the reference's *exact phrasing*: a correct paraphrase is punished, a wrong-but-fluent
|
|
72
|
+
copy is rewarded. Legitimate use: **tracking regressions against a fixed reference set**, where a
|
|
73
|
+
drop is a real signal. Illegitimate use: declaring model A "better" than B on open-ended output
|
|
74
|
+
from a BLEU delta.
|
|
75
|
+
|
|
76
|
+
## Perplexity (language modeling)
|
|
77
|
+
|
|
78
|
+
```python
|
|
79
|
+
import torch
|
|
80
|
+
def perplexity(model, input_ids):
|
|
81
|
+
with torch.no_grad():
|
|
82
|
+
loss = model(input_ids, labels=input_ids).loss # mean token NLL
|
|
83
|
+
return torch.exp(loss).item()
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
- Lower = the model predicts held-out text better. **Tokenizer-dependent**: PPL is defined over
|
|
87
|
+
the model's own tokens, so two models with different tokenizers/vocab have **non-comparable**
|
|
88
|
+
perplexities. Only compare within one tokenizer, on the same held-out set.
|
|
89
|
+
|
|
90
|
+
## LLM-as-judge (the right tool for open-ended quality)
|
|
91
|
+
|
|
92
|
+
```text
|
|
93
|
+
Judge prompt (pin the rubric; score on fixed axes):
|
|
94
|
+
Rate the SUMMARY on 1–5 for: (a) faithfulness to SOURCE, (b) coverage, (c) fluency.
|
|
95
|
+
Output JSON: {"faithfulness": n, "coverage": n, "fluency": n, "reason": "..."}
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
- Known judge biases: **position** (favors the first candidate — randomize order), **verbosity**
|
|
99
|
+
(favors longer answers), **self-preference** (favors its own family's style). Mitigate: fixed
|
|
100
|
+
rubric, randomized order, and a **human spot-check** on a sample to calibrate the judge.
|
|
101
|
+
- For agent/pipeline-level eval harnesses beyond single outputs, see `agent-eval`.
|
|
102
|
+
|
|
103
|
+
## The one-change loop (applies to every metric above)
|
|
104
|
+
|
|
105
|
+
Establish a baseline number on a **held-out set**, change exactly **one** variable (model OR
|
|
106
|
+
tokenizer OR data OR decoding params), re-measure on the **same** set. Two changes at once and
|
|
107
|
+
the delta is unattributable — and a regression can hide inside an improvement.
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
# Tokenization — mechanics, special tokens, fertility
|
|
2
|
+
|
|
3
|
+
Depth overflow for SKILL.md section 1. Grounded in the HF NLP course (chapters 6.4–6.8) and the
|
|
4
|
+
`tokenizers` library; verify current API at author time (transformers current major ~v5).
|
|
5
|
+
|
|
6
|
+
## The four subword algorithms
|
|
7
|
+
|
|
8
|
+
All three "learned" algorithms share a preprocessing step (normalization + pre-tokenization);
|
|
9
|
+
they differ in how they build and apply the vocabulary.
|
|
10
|
+
|
|
11
|
+
### BPE (Byte-Pair Encoding) — GPT-2, RoBERTa, and many others
|
|
12
|
+
|
|
13
|
+
1. Start from a base vocabulary (characters, or the 256 bytes for byte-level).
|
|
14
|
+
2. Count all adjacent token pairs in the corpus; **merge the single most frequent pair** into a
|
|
15
|
+
new token; record the merge rule.
|
|
16
|
+
3. Repeat until the vocab reaches the target size. The output is an ordered list of merge rules.
|
|
17
|
+
|
|
18
|
+
To tokenize new text: split into base units, then **replay the merge rules in learned order**.
|
|
19
|
+
|
|
20
|
+
**Byte-level BPE** (GPT-2, RoBERTa) runs BPE over raw **bytes** instead of Unicode characters:
|
|
21
|
+
|
|
22
|
+
- Base vocabulary is exactly **256** (every byte value), so it stays tiny.
|
|
23
|
+
- **No `[UNK]` token is ever needed** — every possible character maps to some byte sequence, so
|
|
24
|
+
emoji and unseen scripts are always representable (HF NLP course ch.6.5). This is the key
|
|
25
|
+
robustness win over character/word tokenizers.
|
|
26
|
+
|
|
27
|
+
### WordPiece — BERT, DistilBERT, ELECTRA
|
|
28
|
+
|
|
29
|
+
Similar merge-based training, but instead of picking the most *frequent* pair it picks the pair
|
|
30
|
+
that maximizes a **likelihood score**: `score = freq(pair) / (freq(first) × freq(second))`. This
|
|
31
|
+
favors merging pieces whose parts are individually rare — it prefers to build up rare tokens.
|
|
32
|
+
|
|
33
|
+
To tokenize: **greedy longest-match from the front** of each word. Continuation subwords are
|
|
34
|
+
prefixed with `##` (e.g. `token`, `##izers`). If no subword matches, the whole word becomes
|
|
35
|
+
`[UNK]` — so WordPiece *can* lose OOV content, unlike byte-level BPE.
|
|
36
|
+
|
|
37
|
+
### Unigram — T5, ALBERT, mT5, XLNet (usually via SentencePiece)
|
|
38
|
+
|
|
39
|
+
Works **top-down**: start from a large candidate vocabulary and iteratively **remove** the tokens
|
|
40
|
+
whose removal least increases the total corpus negative-log-likelihood, until the target size is
|
|
41
|
+
reached. Each remaining token keeps a probability/score.
|
|
42
|
+
|
|
43
|
+
To tokenize: choose the **segmentation with the highest product of token probabilities**
|
|
44
|
+
(Viterbi over candidate splits), not a left-to-right greedy pass.
|
|
45
|
+
|
|
46
|
+
### SentencePiece — the wrapper, not a fourth algorithm
|
|
47
|
+
|
|
48
|
+
SentencePiece is a *framework* (usually running Unigram, sometimes BPE) that treats the input as
|
|
49
|
+
a raw stream and encodes spaces as a normal meta-symbol `▁`. Consequences:
|
|
50
|
+
|
|
51
|
+
- **Language-agnostic** — no whitespace pre-tokenizer, so it works on languages that don't
|
|
52
|
+
space-separate words (Chinese, Japanese, Thai).
|
|
53
|
+
- **Reversible** — `decode` is literally "concatenate tokens and swap `▁`→space," so
|
|
54
|
+
`decode(encode(x)) == x` with no detokenization rules. This is why multilingual models favor it.
|
|
55
|
+
|
|
56
|
+
## Special tokens (names differ by family — never hand-roll)
|
|
57
|
+
|
|
58
|
+
| Purpose | BERT/WordPiece | RoBERTa/GPT byte-level | T5/SentencePiece |
|
|
59
|
+
|---|---|---|---|
|
|
60
|
+
| Start / pooled repr | `[CLS]` | `<s>` | (uses `pad` as decoder start) |
|
|
61
|
+
| Separator / end | `[SEP]` | `</s>` | `</s>` |
|
|
62
|
+
| Padding | `[PAD]` | `<pad>` | `<pad>` |
|
|
63
|
+
| Unknown fallback | `[UNK]` | `<unk>` (rare, byte-level) | `<unk>` |
|
|
64
|
+
| Mask (MLM only) | `[MASK]` | `<mask>` | — |
|
|
65
|
+
|
|
66
|
+
- `[CLS]`/`<s>` position holds the sentence-level vector used by a classification head.
|
|
67
|
+
- `[PAD]` tokens must be excluded from attention via the `attention_mask` the tokenizer returns;
|
|
68
|
+
forgetting this lets padding leak into the representation.
|
|
69
|
+
- Add task-specific special tokens with `tokenizer.add_special_tokens(...)` **and** call
|
|
70
|
+
`model.resize_token_embeddings(len(tokenizer))`, or the new ids index past the embedding table.
|
|
71
|
+
|
|
72
|
+
## Offset mapping (needed for NER / span tasks)
|
|
73
|
+
|
|
74
|
+
`return_offsets_mapping=True` returns `(char_start, char_end)` per token so you can map predicted
|
|
75
|
+
token spans back to characters in the original string — essential for entity extraction and for
|
|
76
|
+
aligning B-/I- labels to subwords.
|
|
77
|
+
|
|
78
|
+
```python
|
|
79
|
+
enc = tok("Ada Lovelace", return_offsets_mapping=True)
|
|
80
|
+
# offsets like [(0,0),(0,3),(4,12),(0,0)] — (0,0) marks added special tokens
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Measure fertility before committing (multilingual)
|
|
84
|
+
|
|
85
|
+
Fertility = mean tokens per word. Compare it across your languages on a parallel sample; a large
|
|
86
|
+
gap is the unfairness/cost tax from SKILL.md section 4.
|
|
87
|
+
|
|
88
|
+
```python
|
|
89
|
+
def fertility(texts, tokenizer):
|
|
90
|
+
toks = sum(len(tokenizer.tokenize(t)) for t in texts)
|
|
91
|
+
words = sum(len(t.split()) for t in texts)
|
|
92
|
+
return toks / words # ~1.1–1.4 English on a good tokenizer; much higher off-target
|
|
93
|
+
|
|
94
|
+
# Compare the SAME sentences across languages; a 2–15× gap = over-fragmentation of that script.
|
|
95
|
+
```
|
|
@@ -0,0 +1,239 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: open-weights
|
|
3
|
+
description: "Use when choosing an open-weight LLM and clearing it for use — which family and size fit a task, hardware and budget, and above all whether the license lets you ship (Llama, Qwen, Mistral/Mixtral, Gemma, DeepSeek, Phi, gpt-oss, and others). Owns the license-CLASS map (OSI-open Apache/MIT vs custom-community like Llama/Gemma vs non-commercial/restricted like the original Codestral) and the always-verify-the-model-card rule, plus size-to-VRAM budgeting and quant formats (GGUF/AWQ/GPTQ, what Q4_K_M means). Triggers: 'which open model should I use', 'can I use Llama/Gemma commercially', 'is Qwen Apache-2.0', 'what open LLM fits a 24GB GPU', 'is this license safe to ship in a product', 'quin model obert puc fer servir legalment'. NOT how to download or host on HF (that is huggingface), NOT running it locally (that is ollama), NOT serving at throughput (that is vllm), NOT fine-tuning it (that is finetuning) — this layer only tells you WHICH model and whether the license permits it, then hands off."
|
|
4
|
+
tags: [open-weights, open-source-llm, model-selection, model-licenses, llama-qwen-mistral-gemma]
|
|
5
|
+
recommends: [huggingface, ollama, finetuning, vllm]
|
|
6
|
+
origin: risco
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Open weights — pick the model, then clear the license
|
|
10
|
+
|
|
11
|
+
This is the CHOICE layer. Given a task, a box, and a shipping constraint, it tells you *which*
|
|
12
|
+
open model to reach for and *whether the license lets you ship it*. It does not download, run,
|
|
13
|
+
serve, or fine-tune anything — it feeds the skills that do (see [Related skills](#related-skills)).
|
|
14
|
+
|
|
15
|
+
## The one rule (read before you name a model)
|
|
16
|
+
|
|
17
|
+
**Model names and their licenses change monthly. Never state a license from memory — open the
|
|
18
|
+
model card and confirm it, every time.** This file was authored against cards live in mid-2026;
|
|
19
|
+
by the time you read it, versions have shipped and terms have moved. So:
|
|
20
|
+
|
|
21
|
+
- Treat every specific version/license line below as **[verify the card]**, not as settled fact.
|
|
22
|
+
- State the license **class** (OSI-open vs custom-community vs restricted), then send the reader to
|
|
23
|
+
the actual `LICENSE` / terms page for the exact model + size they intend to ship.
|
|
24
|
+
- The *decision framework* and the *class taxonomy* are the durable parts. The version list is the
|
|
25
|
+
perishable part. Weight your trust accordingly.
|
|
26
|
+
|
|
27
|
+
Real, verified-mid-2026 examples of *why* this rule exists — all confirmed against the source, and
|
|
28
|
+
all things that were different at my Jan-2026 cutoff:
|
|
29
|
+
|
|
30
|
+
- **Gemma 4** moved to **Apache-2.0**, while Gemma 1–3 stay on the custom Gemma Terms of Use
|
|
31
|
+
(confirmed on [ai.google.dev/gemma/terms](https://ai.google.dev/gemma/terms), accessed
|
|
32
|
+
2026-07-18). Same brand, opposite license class depending on version.
|
|
33
|
+
- **Codestral 2** was relicensed **Apache-2.0** (per Mistral, Apr 2026), while the original
|
|
34
|
+
Codestral stays **non-production (MNPL)**. Same name, opposite shippability depending on release.
|
|
35
|
+
- **DeepSeek-R1** is **MIT**, but the original **DeepSeek-V3** weights ship under a **custom
|
|
36
|
+
DeepSeek License Agreement with OpenRAIL-style use restrictions** (confirmed on the
|
|
37
|
+
[V3 LICENSE-MODEL](https://huggingface.co/deepseek-ai/DeepSeek-V3/blob/main/LICENSE-MODEL)),
|
|
38
|
+
not MIT. Same family, different license per model.
|
|
39
|
+
|
|
40
|
+
If three of the load-bearing facts moved in one release cycle, yours have too. Check the card.
|
|
41
|
+
|
|
42
|
+
## 1. How to choose an open model
|
|
43
|
+
|
|
44
|
+
Five gates, in this order. The license gate can veto everything above it, so never fall in love
|
|
45
|
+
with a model before you clear it.
|
|
46
|
+
|
|
47
|
+
1. **Task fit** — match the model's design to the job:
|
|
48
|
+
- General chat / instruct → Llama, Qwen, Mistral, Gemma instruct variants.
|
|
49
|
+
- Coding → Qwen-Coder, Codestral (license!), DeepSeek-Coder, gpt-oss.
|
|
50
|
+
- Reasoning / math → DeepSeek-R1-style reasoning models, gpt-oss, Qwen reasoning variants.
|
|
51
|
+
- Multilingual → Qwen and Gemma tend to lead; check the card's language list.
|
|
52
|
+
- Multimodal (vision) → Llama vision, Qwen-VL, Gemma vision, PaliGemma, Phi multimodal.
|
|
53
|
+
- Embeddings / retrieval → a dedicated embedding model, **not** a chat LLM → `embeddings-search`.
|
|
54
|
+
- Small / edge → 0.5B–4B (Qwen small, Gemma small, Phi-mini, gpt-oss-20b class).
|
|
55
|
+
2. **Size vs your hardware class** — can it even fit? See [§4](#4-size--vram). A 70B at fp16 is
|
|
56
|
+
~140 GB; if you have one 24 GB GPU, that model is off the table unless you quantize *and* accept
|
|
57
|
+
the quality/throughput cost. Pick a size your box can hold before you compare quality.
|
|
58
|
+
3. **License / shippability** — **the gate that matters most** (see [§3](#3-licenses)). Decide up
|
|
59
|
+
front: is this a hobby/internal use, or a commercial product you distribute? "Open weights" does
|
|
60
|
+
**not** mean "open source" and does **not** guarantee commercial rights. Verify the card.
|
|
61
|
+
4. **Hardware target** — consumer GPU (8–24 GB), data-center GPU (A100/H100 80 GB), Apple unified
|
|
62
|
+
memory, or CPU/edge. This narrows both size and quant format (GGUF for CPU/Mac/llama.cpp; AWQ/GPTQ
|
|
63
|
+
for GPU serving).
|
|
64
|
+
5. **Community support** — a proxy for "will this actually work Monday morning": are there
|
|
65
|
+
ready-made GGUF/AWQ quants on the Hub, is it supported by your runtime (llama.cpp/Ollama/vLLM),
|
|
66
|
+
are there fine-tunes and recent downloads? A model with no quants and no runtime support is a
|
|
67
|
+
research artifact, not a shippable choice.
|
|
68
|
+
|
|
69
|
+
Rule of thumb: **smallest model that passes your eval wins.** Don't reach for 70B when a well-chosen
|
|
70
|
+
8B clears the bar — it's cheaper to run, faster, and fits more hardware. Prove it with `agent-eval`.
|
|
71
|
+
|
|
72
|
+
## 2. Model families
|
|
73
|
+
|
|
74
|
+
Families and *typical* size ladders below. Specific version claims are marked — **[verify]** at
|
|
75
|
+
author time; the family and its rough sizing are the durable part. Full per-family notes,
|
|
76
|
+
strengths, and license pointers in [references/model-families.md](references/model-families.md).
|
|
77
|
+
|
|
78
|
+
| Family | Maker | Typical open sizes | Notes / current line [verify] |
|
|
79
|
+
|---|---|---|---|
|
|
80
|
+
| **Llama** | Meta | ~1B–~400B (dense + MoE) | Llama 4 (Scout/Maverick, MoE) current line; custom **Community License**, gated |
|
|
81
|
+
| **Qwen** | Alibaba | 0.5B–235B+ (dense + MoE), strong Coder/VL | mostly Apache-2.0 but **per-size variance** — check each card |
|
|
82
|
+
| **Mistral / Mixtral** | Mistral AI | 7B dense, 8x7B/8x22B MoE, "Small/Large" | open ones Apache-2.0; **Codestral original = MNPL non-production** |
|
|
83
|
+
| **Gemma** | Google | ~1B–~27B, plus PaliGemma/CodeGemma/ShieldGemma | Gemma 1–3 = **custom Gemma Terms**; Gemma 4 = Apache-2.0 [verify] |
|
|
84
|
+
| **DeepSeek** | DeepSeek | V3-class MoE (~600B+), R1 reasoning, distills | **per-model license split** — R1 MIT, original V3 custom; verify |
|
|
85
|
+
| **Phi** | Microsoft | ~3B–15B ("mini", reasoning, multimodal) | **MIT** across the Phi-4 family [verify] |
|
|
86
|
+
| **gpt-oss** | OpenAI | 20B and 120B (MoE, open *weights*) | **Apache-2.0** [verify]; OpenAI's first open-weight LLMs since GPT-2 |
|
|
87
|
+
| Others | various | — | SmolLM, OLMo (fully-open incl. data), Falcon, Yi, Command — check card |
|
|
88
|
+
|
|
89
|
+
## 3. Licenses
|
|
90
|
+
|
|
91
|
+
**This is the load-bearing section. Get it wrong and you ship something you have no right to
|
|
92
|
+
ship.** Every model falls into one of three classes. Identify the class, then open the card.
|
|
93
|
+
|
|
94
|
+
### The three classes
|
|
95
|
+
|
|
96
|
+
| Class | Examples (class, not a promise) | What it means for shipping |
|
|
97
|
+
|---|---|---|
|
|
98
|
+
| **OSI-open** (Apache-2.0, MIT) | Qwen (most), Mistral open, Phi, gpt-oss, DeepSeek-R1, Gemma **4** | Commercial use, modify, redistribute — permissive. Still read the card for attribution/notice. |
|
|
99
|
+
| **Custom / community** | **Llama** (Meta Community), **Gemma 1–3** (Gemma Terms) | Broad free use **but with conditions**: acceptable-use policy, attribution, sometimes a scale cap. NOT OSI-open. |
|
|
100
|
+
| **Non-commercial / restricted** | original **Codestral** (MNPL), any "research-only", some RAIL, some "≥$X revenue → buy a license" | You **cannot** ship it in a commercial product without a separate license. Fatal if missed. |
|
|
101
|
+
|
|
102
|
+
"Open weights" describes availability of the weights file — it says nothing about your legal rights.
|
|
103
|
+
A model can be a free download and still be non-commercial. **The download button is not a license.**
|
|
104
|
+
|
|
105
|
+
### Per-family license notes (state the class, then verify the exact card)
|
|
106
|
+
|
|
107
|
+
- **Llama = Meta Llama Community License — NOT OSI-open.** Carries an Acceptable Use Policy, a
|
|
108
|
+
**"Built with Llama"** attribution requirement on derivatives/products, naming rules, and a
|
|
109
|
+
**>700M-monthly-active-users clause** (above that you must request a separate license from Meta,
|
|
110
|
+
granted at Meta's discretion). Gated on the Hub (accept terms first). Verify the *current* Llama
|
|
111
|
+
version's terms — Meta has revised them across releases.
|
|
112
|
+
- **Gemma = custom Gemma Terms of Use + Prohibited Use Policy** for Gemma 1–3 (not Apache), with a
|
|
113
|
+
duty to pass the restrictions **downstream** to every user and to ship the terms/notice file.
|
|
114
|
+
Gemma **4** reportedly moved to **Apache-2.0** — a textbook reason to check the version's card.
|
|
115
|
+
- **Qwen = mostly Apache-2.0, but with per-size variance.** Historically some sizes (often the very
|
|
116
|
+
largest or a special tier) carried a separate Qwen license instead of Apache. **Check each size's
|
|
117
|
+
card** — do not assume "Qwen = Apache" for the whole family.
|
|
118
|
+
- **Mistral / Mixtral open models = Apache-2.0**, but the **original Codestral is MNPL
|
|
119
|
+
(non-production)** — free for research/eval, **not** for commercial deployment. Codestral **2**
|
|
120
|
+
was relicensed Apache-2.0; verify which Codestral release you actually have. Note some newer
|
|
121
|
+
Mistral models use a "Modified MIT" with a revenue-threshold commercial clause — verify.
|
|
122
|
+
- **DeepSeek = per-model split.** Code repos are MIT; **DeepSeek-R1 weights are MIT**; but the
|
|
123
|
+
original **DeepSeek-V3 weights** ship under a **custom DeepSeek License Agreement with OpenRAIL-
|
|
124
|
+
style use-based restrictions**. "DeepSeek = MIT" is too simple — verify the specific model.
|
|
125
|
+
- **Phi = MIT** across the Phi-4 family [verify] — genuinely permissive, commercial-friendly.
|
|
126
|
+
- **gpt-oss (OpenAI open-weight models, 20B/120B) = Apache-2.0** [verify] — permissive.
|
|
127
|
+
|
|
128
|
+
### Commercial-use checklist (run before you ship)
|
|
129
|
+
|
|
130
|
+
- [ ] Opened the **exact model + size** card and read its `LICENSE` / terms — not a blog, not this file.
|
|
131
|
+
- [ ] Confirmed the **class**: OSI-open, custom-community, or restricted/non-commercial.
|
|
132
|
+
- [ ] If custom/community: identified the **conditions** (attribution string, acceptable-use policy,
|
|
133
|
+
MAU/revenue caps, downstream pass-through duty) and can meet them.
|
|
134
|
+
- [ ] If restricted: confirmed you are **not** deploying commercially, or obtained a separate license.
|
|
135
|
+
- [ ] Checked whether the model is **gated** (accept terms on the Hub before download).
|
|
136
|
+
- [ ] Checked the **base model** license — a fine-tune inherits the base's obligations (a Llama
|
|
137
|
+
fine-tune still owes "Built with Llama"; a distill can inherit the teacher's terms).
|
|
138
|
+
|
|
139
|
+
Deeper class breakdown, gated-model mechanics, and the fine-tune-inheritance trap:
|
|
140
|
+
[references/licenses.md](references/licenses.md).
|
|
141
|
+
|
|
142
|
+
## 4. Size ↔ VRAM
|
|
143
|
+
|
|
144
|
+
A **selection-time** budget: will this size class even fit your hardware? (Operational per-request
|
|
145
|
+
KV-cache math lives in `ollama`/`vllm` — this is the "before I pick it" estimate.)
|
|
146
|
+
|
|
147
|
+
```text
|
|
148
|
+
weights_GB ≈ params(B) × bytes_per_param # then add KV cache + runtime overhead on top
|
|
149
|
+
fp16/bf16 → 2.0 (≈ 2 GB per 1B params)
|
|
150
|
+
8-bit → ~1.0 (≈ 1 GB per 1B params)
|
|
151
|
+
4-bit → ~0.6 (≈ 0.6 GB per 1B + cache + overhead; conservative ~0.5–0.6/param)
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
What that means per hardware class (weights only — leave headroom for context/KV cache):
|
|
155
|
+
|
|
156
|
+
| Hardware | fp16 ceiling | Practical pick (4-bit) |
|
|
157
|
+
|---|---|---|
|
|
158
|
+
| 8 GB consumer GPU | ~3B | 7–8B at 4-bit (~5 GB) |
|
|
159
|
+
| 16 GB | ~7B | 13–14B at 4-bit |
|
|
160
|
+
| 24 GB (e.g. 3090/4090) | ~10B | ~32B at 4-bit (~20 GB) |
|
|
161
|
+
| 80 GB (A100/H100) | ~34B | 70B at 4-bit (~40 GB), or a big-MoE like gpt-oss-120b |
|
|
162
|
+
| Apple unified (e.g. 64 GB) | shares with the OS | budget against **total** unified memory |
|
|
163
|
+
| multi-GPU / 2×80 GB+ | 70B fp16 (~140 GB) via tensor-parallel | full-precision large models |
|
|
164
|
+
|
|
165
|
+
**A 70B at fp16 is ~140 GB — it does not fit one GPU.** You either quantize (4-bit ≈ ~40 GB, fits one
|
|
166
|
+
80 GB card) or split across GPUs with **tensor parallelism** (that's a `vllm` job). Longer context
|
|
167
|
+
grows the KV cache *on top of* weights, so keep a margin. Full derivation + KV math:
|
|
168
|
+
[references/sizing-and-quant.md](references/sizing-and-quant.md).
|
|
169
|
+
|
|
170
|
+
## 5. Quant / formats
|
|
171
|
+
|
|
172
|
+
Quantization shrinks weights (fewer bits/param) to fit smaller hardware, trading a little quality.
|
|
173
|
+
Which **format** you pick is driven by your runtime:
|
|
174
|
+
|
|
175
|
+
| Format | Where it runs | Use it for |
|
|
176
|
+
|---|---|---|
|
|
177
|
+
| **GGUF** | llama.cpp, **Ollama**, LM Studio | CPU, Apple Silicon, single-box local; the everyday local format |
|
|
178
|
+
| **AWQ** | vLLM, TGI, transformers | GPU serving — activation-aware 4-bit, strong quality/latency |
|
|
179
|
+
| **GPTQ** | vLLM, TGI, transformers | GPU serving — older, widely available 4-bit |
|
|
180
|
+
| bitsandbytes (NF4) | transformers | quick load-time 4/8-bit for experiments/fine-tuning |
|
|
181
|
+
| EXL2 | ExLlamaV2 | flexible bit-rates on consumer GPUs |
|
|
182
|
+
|
|
183
|
+
**Decoding a GGUF quant tag like `Q4_K_M`:** `Q4` = ~4-bit weights; `_K` = a k-quant (mixed
|
|
184
|
+
precision — keeps the more sensitive tensors at higher bit-depth); `_M` = the medium size/quality
|
|
185
|
+
tier (`_S` smaller/lower, `_L` larger/higher). **`Q4_K_M` is the standard default** — roughly half
|
|
186
|
+
the memory of fp16 for a few percent quality loss. `Q8_0` is near-lossless (~1 byte/param); below
|
|
187
|
+
`Q4`, quality drops off fast. Don't go sub-Q4 to force a too-big model onto a too-small box — pick a
|
|
188
|
+
smaller model instead. More in [references/sizing-and-quant.md](references/sizing-and-quant.md).
|
|
189
|
+
|
|
190
|
+
## 6. Where to get it + how to run it (routing)
|
|
191
|
+
|
|
192
|
+
You've chosen a model and cleared its license. Now hand off — this skill stops here.
|
|
193
|
+
|
|
194
|
+
- **Get the weights / host on HF** → `huggingface` (Hub download/upload, Inference Providers,
|
|
195
|
+
endpoints). Also where you convert to GGUF.
|
|
196
|
+
- **Run it locally on one box** (laptop/desktop, GGUF via Ollama) → `ollama`.
|
|
197
|
+
- **Serve it at throughput / with tensor-parallel** (production, batching, big models) → `vllm`.
|
|
198
|
+
- **Fine-tune it** (LoRA/QLoRA, SFT, preference tuning) → `finetuning`.
|
|
199
|
+
- **Prove the small model is enough** before committing → `agent-eval`.
|
|
200
|
+
|
|
201
|
+
The Hub filters (task + license + size + recent downloads) and the Ollama library are where you
|
|
202
|
+
actually find candidates — that mechanics lives in `huggingface` / `ollama`, not here.
|
|
203
|
+
|
|
204
|
+
## Guardrails / gotchas
|
|
205
|
+
|
|
206
|
+
- **Never assert a license from memory.** State the class, open the card. Licenses change per
|
|
207
|
+
version, per size, and per release month.
|
|
208
|
+
- **"Open weights" ≠ "open source" ≠ "commercial-use OK".** Three different things.
|
|
209
|
+
- **A fine-tune inherits its base license.** Fine-tuning Llama does not launder away "Built with
|
|
210
|
+
Llama" or the acceptable-use policy; a distill can inherit the teacher model's terms.
|
|
211
|
+
- **Gated ≠ restricted.** Gemma/Llama are gated (accept terms to download) yet usable commercially
|
|
212
|
+
under their conditions; a "research-only" card is restricted regardless of gating.
|
|
213
|
+
- **Don't sub-Q4 a too-big model onto a too-small GPU.** Quality collapses and it still may OOM at
|
|
214
|
+
real context. Choose a size that fits.
|
|
215
|
+
- **Newest ≠ best for you.** The smallest model that passes your eval wins on cost, speed, and fit.
|
|
216
|
+
- **MoE total vs active params.** A "120B" MoE may activate only ~5B/token (fast) but you still need
|
|
217
|
+
VRAM for *all* experts — size against total params, not active.
|
|
218
|
+
|
|
219
|
+
## Related skills
|
|
220
|
+
|
|
221
|
+
- **`huggingface`** — get/host: Hub download/upload, Inference Providers, endpoints, GGUF
|
|
222
|
+
conversion. This skill tells you *which* repo to pull; `huggingface` pulls it.
|
|
223
|
+
- **`ollama`** — run one model locally (GGUF, single box, VRAM sizing at request time). This skill
|
|
224
|
+
says which model + quant *class* fits; `ollama` runs it and does the KV-cache math.
|
|
225
|
+
- **`vllm`** — serve at throughput, batching, tensor-parallel for models too big for one GPU.
|
|
226
|
+
- **`finetuning`** — adapt a chosen base with LoRA/QLoRA/SFT. Choose+clear the base here first.
|
|
227
|
+
- Boundary: this skill is **selection + licensing knowledge only**. It never re-teaches calling,
|
|
228
|
+
running, serving, or training — it feeds those four.
|
|
229
|
+
|
|
230
|
+
## Checklist
|
|
231
|
+
|
|
232
|
+
- [ ] Named the **task** and matched a family designed for it (chat/code/reasoning/vision/embeddings/edge).
|
|
233
|
+
- [ ] Picked the **smallest size** likely to pass the eval, and confirmed it **fits the hardware class**.
|
|
234
|
+
- [ ] Identified the **license class** (OSI-open / custom-community / restricted).
|
|
235
|
+
- [ ] Opened the **exact model + size card** and confirmed the license — not from memory, not from a blog.
|
|
236
|
+
- [ ] For commercial use: met the conditions (attribution, acceptable-use, MAU/revenue caps) or confirmed permissive.
|
|
237
|
+
- [ ] Checked the **base model** license if it's a fine-tune/distill.
|
|
238
|
+
- [ ] Picked a **quant format** matching the runtime (GGUF local / AWQ-GPTQ serving) and a sane tier (`Q4_K_M` default).
|
|
239
|
+
- [ ] Handed off: `huggingface` (get), `ollama` (run local), `vllm` (serve), `finetuning` (adapt).
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# Evals for the `open-weights` skill
|
|
2
|
+
|
|
3
|
+
Routing + capability checks read from `cases.yaml` by the skill eval harness — no network, no
|
|
4
|
+
model downloads, no license fetches. The `should_trigger` prompts must select this skill: they
|
|
5
|
+
cover general model selection, the Llama commercial-license question, Qwen per-size license
|
|
6
|
+
variance, VRAM-fit sizing, the non-commercial (Codestral/MNPL) gate, and a Catalan phrasing.
|
|
7
|
+
The `should_not_trigger` prompts must route to the named real sibling instead — `huggingface`
|
|
8
|
+
(download/host), `ollama` (run local + KV cache), `vllm` (serve/tensor-parallel), `finetuning`
|
|
9
|
+
(adapt), and `rag` (retrieval) — proving the tight "choose only, then hand off" boundary. The
|
|
10
|
+
single `capability` case is a rubric: a good answer to the 24GB commercial-assistant scenario must
|
|
11
|
+
verify the license on the exact card (never from memory), classify the license class, flag Llama as
|
|
12
|
+
custom/non-OSI with its conditions, size the model to fit 24GB, note fine-tune license inheritance,
|
|
13
|
+
and hand off to the four sibling skills. Run with whatever harness loads `evals/cases.yaml`;
|
|
14
|
+
nothing to install or connect.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
skill: open-weights
|
|
2
|
+
|
|
3
|
+
should_trigger:
|
|
4
|
+
- prompt: "Which open-weight model should I pick for a customer-support chatbot I plan to ship commercially?"
|
|
5
|
+
why: "Core selection + license-clearance question across families — the CHOICE layer this skill owns."
|
|
6
|
+
- prompt: "Can I use Llama commercially in my SaaS product, or does its license restrict that?"
|
|
7
|
+
why: "License-class question on Llama (Meta Community License, not OSI-open) — the load-bearing section."
|
|
8
|
+
- prompt: "Is Qwen Apache-2.0 across every size, or do I have to check each model card separately?"
|
|
9
|
+
why: "Per-size license variance — squarely the verify-the-card rule this skill teaches."
|
|
10
|
+
- prompt: "What is the largest open LLM I can realistically run on a single 24GB GPU?"
|
|
11
|
+
why: "Size-to-VRAM budgeting to narrow the model choice before picking — this skill's §4."
|
|
12
|
+
- prompt: "Is the original Codestral safe to use in a commercial product, or is it non-commercial only?"
|
|
13
|
+
why: "Restricted/non-commercial (MNPL) gate — the fatal-if-missed license class."
|
|
14
|
+
- prompt: "Quin model obert puc fer servir legalment en un producte comercial i que càpiga en una GPU de 16GB?"
|
|
15
|
+
why: "Catalan (non-English) phrasing; open-model selection + license + VRAM fit — this skill's whole remit."
|
|
16
|
+
|
|
17
|
+
should_not_trigger:
|
|
18
|
+
- prompt: "Download the Llama weights from the Hub with the hf CLI and push a model card."
|
|
19
|
+
route_to: huggingface
|
|
20
|
+
why: "Getting/hosting weights on HF — huggingface's job; this skill only says WHICH repo, not how to pull it."
|
|
21
|
+
- prompt: "My 70B OOMs in Ollama at 128K context — how do I shrink the KV cache to make it fit?"
|
|
22
|
+
route_to: ollama
|
|
23
|
+
why: "Operational, single-box run + per-request KV-cache math — ollama, not the selection layer."
|
|
24
|
+
- prompt: "Serve a 70B across two 80GB GPUs with tensor parallelism and high request throughput."
|
|
25
|
+
route_to: vllm
|
|
26
|
+
why: "Production serving engine + tensor-parallel flags — vllm owns serving, not model choice."
|
|
27
|
+
- prompt: "Fine-tune Qwen on my instruction dataset with LoRA and export the adapter."
|
|
28
|
+
route_to: finetuning
|
|
29
|
+
why: "Adapting a chosen base with LoRA/SFT — finetuning; this skill only chooses+clears the base first."
|
|
30
|
+
- prompt: "Build a retrieval pipeline over our docs with chunking, an index, and reranking."
|
|
31
|
+
route_to: rag
|
|
32
|
+
why: "Designing a retrieval system, not selecting or licensing an open model."
|
|
33
|
+
|
|
34
|
+
capability:
|
|
35
|
+
- scenario: "Choose an open-weight model for a commercial customer-support assistant that must run on a single 24GB GPU, and confirm its license lets you ship."
|
|
36
|
+
must_include:
|
|
37
|
+
- "verify the license on the EXACT model + size card, never assert it from memory — licenses change per version, size, and month"
|
|
38
|
+
- "classify the license: OSI-open (Apache-2.0/MIT) vs custom-community (Llama Meta Community, Gemma 1-3) vs non-commercial/restricted"
|
|
39
|
+
- "Llama is NOT OSI-open: Meta Community License with an acceptable-use policy, a 'Built with Llama' attribution requirement, and a >700M-monthly-active-users clause"
|
|
40
|
+
- "pick a size that fits 24GB: ~32B at 4-bit (~20GB) or an 8-14B, leaving headroom for KV cache — a 70B at fp16 (~140GB) does not fit one GPU"
|
|
41
|
+
- "a fine-tune or distill inherits its base model's license obligations"
|
|
42
|
+
- "hand off after choosing: huggingface to download/host, ollama to run locally, vllm to serve, finetuning to adapt"
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
# Open-weight LICENSES — the load-bearing reference
|
|
2
|
+
|
|
3
|
+
**Get this wrong and you ship something you have no legal right to ship.** This is the section that
|
|
4
|
+
most often bites teams. The cardinal rule, again: **state the license class, then open the exact
|
|
5
|
+
model + size card and confirm.** Everything below is class guidance + [verify-the-card] pointers,
|
|
6
|
+
authored mid-2026 — licenses move per version, per size, per release month.
|
|
7
|
+
|
|
8
|
+
## The three classes
|
|
9
|
+
|
|
10
|
+
### 1. OSI-open (Apache-2.0, MIT) — permissive
|
|
11
|
+
|
|
12
|
+
Commercial use, modification, and redistribution are allowed. Apache-2.0 adds a patent grant and a
|
|
13
|
+
notice/attribution requirement (keep the `NOTICE`/`LICENSE`); MIT is barely-there attribution. This
|
|
14
|
+
is the class you want for a product you distribute. Still read the card — attribution and notice
|
|
15
|
+
obligations are real even when permissive.
|
|
16
|
+
|
|
17
|
+
Class members (mid-2026, **verify each**): most Qwen sizes, Mistral open models, Phi (MIT), gpt-oss
|
|
18
|
+
(Apache-2.0), DeepSeek-R1 (MIT), Gemma **4** (Apache-2.0), OLMo, SmolLM.
|
|
19
|
+
|
|
20
|
+
### 2. Custom / community — free use *with conditions*
|
|
21
|
+
|
|
22
|
+
Broad, royalty-free rights **but** the vendor keeps strings attached: an acceptable-use policy,
|
|
23
|
+
mandatory attribution, naming rules, sometimes a scale cap, and a duty to pass restrictions
|
|
24
|
+
downstream. **This is NOT OSI-open** even though people loosely call it "open." You can usually ship
|
|
25
|
+
commercially — *if* you meet every condition.
|
|
26
|
+
|
|
27
|
+
Class members (mid-2026, **verify**): **Llama** (Meta Community License), **Gemma 1–3** (Gemma
|
|
28
|
+
Terms of Use).
|
|
29
|
+
|
|
30
|
+
### 3. Non-commercial / restricted — cannot ship without a separate license
|
|
31
|
+
|
|
32
|
+
Free to download and evaluate, but **not** for commercial deployment. Includes "research-only"
|
|
33
|
+
cards, some RAIL variants, revenue-gated licenses ("above $X/month you must buy a commercial
|
|
34
|
+
license"), and non-production licenses. Missing one of these is the expensive mistake.
|
|
35
|
+
|
|
36
|
+
Class members (mid-2026, **verify**): **original Codestral** (MNPL non-production), some Cohere
|
|
37
|
+
Command terms, various research-only community fine-tunes.
|
|
38
|
+
|
|
39
|
+
## Per-family detail
|
|
40
|
+
|
|
41
|
+
### Llama — Meta Llama Community License (custom, NOT OSI-open)
|
|
42
|
+
|
|
43
|
+
- **Acceptable Use Policy** incorporated by reference — prohibited uses bind you and your users.
|
|
44
|
+
- **Attribution:** derivatives/products must **prominently display "Built with Llama"**, and derived
|
|
45
|
+
model names must carry "Llama" per the naming rules.
|
|
46
|
+
- **Redistribution:** include a copy of the Community License with any distribution of the weights.
|
|
47
|
+
- **Scale cap:** if your product (or affiliates') exceeds **700M monthly active users** in the prior
|
|
48
|
+
calendar month, you must **request a license from Meta**, granted at Meta's sole discretion.
|
|
49
|
+
- **Gated** on the Hub — accept terms before you can download.
|
|
50
|
+
- Meta has revised terms across Llama versions — **verify the current version's license page**.
|
|
51
|
+
|
|
52
|
+
### Gemma — custom Gemma Terms of Use + Prohibited Use Policy (Gemma 1–3)
|
|
53
|
+
|
|
54
|
+
- Not Apache. A Google-authored license with a **Prohibited Use Policy** covering sensitive domains.
|
|
55
|
+
- **Downstream pass-through:** if you distribute Gemma or a Gemma-derived model (weights, API, or
|
|
56
|
+
embedded), you must include/reference the Terms, ship the notice file ("Gemma is provided under
|
|
57
|
+
and subject to the Gemma Terms of Use found at ai.google.dev/gemma/terms"), and bind downstream
|
|
58
|
+
users to the Prohibited Use Policy. The restrictions **follow derivatives** — a fine-tune can't be
|
|
59
|
+
used for a purpose that would've been prohibited on the base.
|
|
60
|
+
- **Gemma 4** reportedly switched to **Apache-2.0** (confirmed on ai.google.dev/gemma/terms,
|
|
61
|
+
2026-07-18). Same brand, different class by version — **check which Gemma you have.**
|
|
62
|
+
- Google claims no rights in outputs you generate.
|
|
63
|
+
|
|
64
|
+
### Qwen — mostly Apache-2.0, with per-size variance
|
|
65
|
+
|
|
66
|
+
- Most sizes are Apache-2.0. Historically the very largest (and occasionally a special tier) shipped
|
|
67
|
+
under a separate **Qwen license**. Do not assume the whole family is Apache — **check each size**.
|
|
68
|
+
|
|
69
|
+
### Mistral / Mixtral
|
|
70
|
+
|
|
71
|
+
- Open models (Mistral 7B, Mixtral 8x7B/8x22B, many "Small") = **Apache-2.0**.
|
|
72
|
+
- **Original Codestral = MNPL (Mistral AI Non-Production License)** — research/eval only, **no
|
|
73
|
+
commercial deployment**. **Codestral 2** relicensed **Apache-2.0** (Apr 2026) [verify which one].
|
|
74
|
+
- Some newer models use a **"Modified MIT"** with a revenue-threshold commercial clause (e.g. above
|
|
75
|
+
a monthly-revenue bar you need a commercial license / Mistral platform access). Verify.
|
|
76
|
+
|
|
77
|
+
### DeepSeek — per-model split
|
|
78
|
+
|
|
79
|
+
- **Code** repositories: MIT.
|
|
80
|
+
- **DeepSeek-R1** weights: **MIT**.
|
|
81
|
+
- **Original DeepSeek-V3** weights: **custom DeepSeek License Agreement** (v1.0) with **OpenRAIL-
|
|
82
|
+
style use-based restrictions** (military use, harm to minors, disinformation, PII, discrimination,
|
|
83
|
+
etc.), which you must **pass forward** as an enforceable provision on redistribution.
|
|
84
|
+
- Newer point releases have trended toward MIT [verify]. "DeepSeek = MIT" is an over-simplification.
|
|
85
|
+
|
|
86
|
+
### Phi — MIT
|
|
87
|
+
|
|
88
|
+
- The Phi-4 family (Phi-4, Phi-4-mini, reasoning, multimodal) is **MIT** [verify] — commercial use,
|
|
89
|
+
fine-tuning, redistribution allowed, no royalties.
|
|
90
|
+
|
|
91
|
+
### gpt-oss — Apache-2.0
|
|
92
|
+
|
|
93
|
+
- gpt-oss-20b / gpt-oss-120b = **Apache-2.0** [verify] — permissive commercial use.
|
|
94
|
+
|
|
95
|
+
## Gated models (mechanics)
|
|
96
|
+
|
|
97
|
+
Some models (Llama, Gemma, many others) are **gated**: you must accept terms on the Hub model page,
|
|
98
|
+
then use a read-scoped token. Gating is an access gate, not a use-class — a gated model can be
|
|
99
|
+
commercially usable (under its conditions), and an ungated model can still be non-commercial.
|
|
100
|
+
Downloading without accepting terms returns a 403. The download step itself is a `huggingface` job.
|
|
101
|
+
|
|
102
|
+
## The fine-tune / distill inheritance trap
|
|
103
|
+
|
|
104
|
+
**A derivative inherits the base model's license and obligations.**
|
|
105
|
+
|
|
106
|
+
- Fine-tune Llama → your fine-tune still owes "Built with Llama", the Acceptable-Use Policy, and the
|
|
107
|
+
MAU clause. You cannot re-license it as MIT.
|
|
108
|
+
- Fine-tune Gemma → the Gemma Terms + Prohibited Use Policy follow your model downstream.
|
|
109
|
+
- A **distill** trained on another model's outputs can inherit the **teacher's** terms (this is how
|
|
110
|
+
a restriction can travel into a model whose own card looks permissive). Check the base_model chain.
|
|
111
|
+
- Merging models can compound obligations from **every** parent. Trace the lineage.
|
|
112
|
+
|
|
113
|
+
When in doubt, treat the strictest ancestor's license as governing, and confirm on each card.
|
|
114
|
+
|
|
115
|
+
## Commercial-ship decision flow
|
|
116
|
+
|
|
117
|
+
1. Identify the **exact model + size** (not the family) you'll deploy.
|
|
118
|
+
2. Open its `LICENSE` / terms page on the Hub or the vendor site.
|
|
119
|
+
3. Classify: OSI-open → ship (honor attribution/notice). Custom/community → meet the conditions
|
|
120
|
+
(attribution string, AUP, MAU/revenue caps, pass-through) → ship. Restricted/non-commercial →
|
|
121
|
+
**stop**; get a separate license or pick another model.
|
|
122
|
+
4. If it's a fine-tune/distill/merge, repeat for **every** ancestor and take the strictest.
|
|
123
|
+
5. Record the decision (which model, which license, which conditions) — see `decision-records`.
|