Learning to read the Hub

A model page on the Hub looks like a product page. It is not. It is the README of a Git repository, and everything on it was typed in by hand by somebody - including the claims.

This chapter teaches you to read it without signing in. At the end you will have three models for the same task side by side and a decision you can justify.

A repo, not a download

Open any model page, for example Qwen/Qwen2.5-0.5B-InstructExternal - Opens in a new tab. The name always has the same shape:

Qwen  /  Qwen2.5-0.5B-Instruct
 ↑              ↑
 namespace      repo name
 (person        (model family, size, variant)
  or organisation)

That is the same structure as on GitHub, and it is no coincidence: underneath lies a real Git repository. The Files and versions tab shows the file tree, the Commits tab the history. You can clone the repo, see branches, check out an older state. Large files are not transferred through Git itself - more on that in the next chapter.

The landing page is the repo's README.md, here called the model card. At the very top of that file sits a YAML block which you do not see as text on the web page, but as the labels to the left and right: task, language, licence, base model.

The four things to look at first

One: the task tag. Top left, for instance Text Generation or Text Classification. It decides whether the model does what you want at all. The most common beginner mistake is a different and subtler one: base versus instruct. A model name without -Instruct, -Chat or -it is usually a base model - it continues text instead of following instructions. Ask a base model a question and you often get the next plausible question back rather than an answer, and conclude the model is broken.

Two: the licence field. In the sidebar on the right, a single word such as apache-2.0. It decides whether you may use the model commercially.

Three: the file list. Under Files and versions you see what you actually get. Watch the extensions: .safetensors is the good format, .bin and .pt are the old one. Why that is a security topic rather than a matter of taste is covered in chapter 03. .gguf is the quantised variant for llama.cpp and Ollama. If a repo only offers .bin, that is a hint - usually about age, sometimes about more.

Four: numbers and dates. On the right you see downloads over the last month and likes; the commit history tells you how old the repo is. Together these are your measure of trust - and the next section explains why either one alone is worthless.

How to spot a rotten repo

The Hub is open. Anyone can create a repo called meta-llama-3-8b-instruct-fixed in ten seconds. There have been documented incidents: fake repos with artificially inflated numbers, in one reported case around 244,000 downloads within 18 hours.

That is exactly where the test lies. Download counts are a time series, not a number. A repo created three days ago carrying a six-figure download count is claiming something that is physically hard. A high number on a two-year-old repo belonging to a well-known organisation is something entirely different from the same number on a repo that appeared yesterday.

The checklist worth making a habit of:

• Whose namespace is it? Is it the organisation that built the model, or a private account that merely contains the name? meta-llama/… is Meta. superuser42/llama-3-8b-instruct is not.
• How old is the repo compared to its numbers? The commit history answers that in two clicks.
• Is the model card written or generated? Missing statements about training data, limitations and intended use are a warning sign - and since the transparency obligations of the EU AI Act for general-purpose models (in force since 2 August 2025), model cards are precisely the instrument serious providers use to meet them. An empty card is therefore not merely impolite.
• Do the files match the description? A repo that describes itself as a 7B model and has 300 MB of files is not one.

Searching like someone with a requirement

The model search at huggingface.co/modelsExternal - Opens in a new tab can do more than the search box. The filters on the left are the real entrance:

• Tasks - what the model should do (text generation, summarisation, automatic speech recognition …)
• Languages - de for German-language models, for instance
• Licenses - apache-2.0 if you work commercially
• Libraries - transformers, gguf, diffusers …

Those filters are written into the URL, which means a combination you found can be bookmarked and reopened in six months.

You can sort by Trending, Most downloads, Most likes and Recently updated. For production use "most downloads" is the most usable entry point - but only the entry point, see above.

The milestone

Take a real task. If none comes to mind, take this one: a model that sorts German-language customer emails into "complaint" and "not a complaint", on a machine without a GPU, usable commercially.

Filter for it, open three candidates and fill in this table - in a file, not in your head:

| Model | Licence | Format | Repo age | Downloads/month | Base/instruct | Size |
|-------|---------|--------|----------|-----------------|---------------|------|
|       |         |        |          |                 |               |      |

Underneath, write three sentences: which one you choose, why, and what bothered you about the other two.

This is not busywork. It is the exercise that stops you from having a model in production in six months whose licence nobody has read.