Lesson 11.1 gave you five family names worth evaluating. Now you need a way to check what any single release actually is before you build on it. A viral post, a download count, or a leaderboard rank is not enough evidence.

Hugging Face is your research desk for that job. It hosts model pages, licenses, model cards, downloadable weights, datasets, demo Spaces, and links to inference options. You met it briefly in Class 08. Here you use it properly.

By the end of this lesson, you can research one Qwen, GLM, or DeepSeek release on Hugging Face and write a one-page model brief covering origin, license, size, variants, hardware, and intended use.

Start at the organization page, not a random upload

Anyone can upload files with a familiar-sounding name. Start from the official organization so you know who published the weights.

• Qwen: huggingface.co/Qwen
• DeepSeek: huggingface.co/deepseek-ai
• Zhipu GLM: huggingface.co/zai-org
• MiniMax: huggingface.co/MiniMaxAI
• Moonshot Kimi: huggingface.co/moonshotai

Check three things on the org page: the verified organization name, the list of models it publishes, and links back to the lab's official site or GitHub. If the model you found lives under an unfamiliar username with no link to the lab, treat it as a community re-upload or quantized copy, not the source of truth. Those copies can be useful, but the official page sets the license and intended use.

Read the model card like a builder

Open one model page — for example, a Qwen3, DeepSeek-R1, or GLM-4 release — and read it in this order:

1. Creator and intended task. Who trained it, what it was trained for (chat, code, reasoning, vision), and which languages or domains it targets. A code model and a chat model from the same family are different tools.

2. License. This is the field most builders skip and most regret skipping. Look for the license name on the model page and in the model card. Common patterns:

The license governs the weights. Your API provider has separate terms. If you call the model through an API, you follow both.

3. Parameter size and variant. Look for the parameter count (for example, 7B, 32B, 70B) and the variant name: base, instruct, reasoning, vision, or mixture-of-experts. An instruct-tuned release behaves very differently from a base model. A 7B model may run on a laptop; a 70B model generally needs a server with serious GPU memory. The model card usually states the context length — compare it against the task you have in mind from Lesson 11.1.

4. Quantized variants. Full-precision weights are large. Quantized versions (often labeled GGUF, GPTQ, or AWQ, with names like Q4 or Q8) trade a little accuracy for much smaller size and lower memory. Community uploads often provide the quants; the official page sometimes links to them. Note who made the quant and which base release it was built from. A quant from three versions ago is not the current model.

5. Hardware requirements. The model card, linked README, or community discussions usually state minimum VRAM or RAM. As a rough habit: small 7–8B quants can run on a good laptop, 30B-class models want a workstation or cloud GPU, and 70B-class models belong on a server. If the page does not state requirements, check the file sizes — a 40 GB download will not fit in 16 GB of memory — and plan for the infrastructure lesson later in the course rather than guessing.

6. Community activity and limitations. Check recent commits, open discussions, linked Spaces (live demos), and the stated limitations section. A model with an active demo you can try in the browser, recent maintenance, and honest limitations is easier to trust than a silent upload with a spectacular claim. Download counts help, but they measure popularity, not fitness for your task.

What "not enough evidence" looks like

Each of these is a real trap:

• "It has 2 million downloads, so it must be the best coding model." Popularity is not a task-fit test.
• "A post says it beats everything, so I will switch my default." One benchmark or opinion is not your task on your context.
• "It is open, so it is free and private." Open weights still cost hardware or API fees, and a hosted demo or API still receives your prompt.
• "The name matches, so this upload is official." Only the official org page confirms the source.

Hugging Face gives you facts. Lesson 11.3 gives you the test that turns those facts into a decision.

Exercise: write a one-page model brief

Pick one release from Qwen, GLM, or DeepSeek on Hugging Face. Start from the official org page.

Write a one-page brief with exactly these headings:

# Model Brief: [family + release + variant]

## Source
- Org page URL and model page URL
- Publisher: official lab or community upload?

## Intended use
- What task was this release built for?

## License
- License name and what it permits for your project

## Size and variants
- Parameter size, context length, instruct/base/reasoning variant
- Available quants and who published them

## Hardware or hosting
- Local requirements, or API access paths (official API, OpenRouter route)

## Limitations
- What the card says it is bad at, plus one open question you still have

## Verdict for my work
- Would you short-list it for your task? Why or why not, in two sentences?

Finish line: one page, saved in your project notes, with URLs you could hand to a teammate.

Verify: ask a teammate (or yourself tomorrow): "Could I find this exact release and license from the links alone?" If not, add the missing URL.

Common failure mode: briefing a community quant without noting the base release and its license. Always trace the quant back to the official weights.

Check your understanding

1. Why should you start from the official org page rather than search results? 2. What six things do you read on a model card, and what builder decision does each one answer? 3. What is the difference between the weights license and an API provider's terms? 4. Why is a quantized variant smaller, and what should you check before trusting it? 5. Why are download counts and viral posts insufficient evidence on their own?

You now know what a model is and where its facts live. Next, Lesson 11.3 teaches you to run the same test on every candidate and record the decision — so your default model is chosen by evidence, not enthusiasm.