Models on Hugging Face

A model card is a data structure, not an essay

A model card is the README.md of a model repository, with a YAML block at the top carrying structured metadata.

That framing changes how you read one. The prose section is the author telling you about the model. The YAML is the part the Hub parses, renders and filters on, and most of what decides whether you can use a model lives there.

Read the metadata first.

Read the license before anything else

The license renders on the page and you can filter models by it. Check it before you evaluate quality, because a model you cannot use commercially is not a candidate however good it is.

The case to watch for is license: other, which appears alongside license_name and license_link fields pointing at a bespoke document. That is the card telling you the terms are not a standard license you already understand, and that you have to go read something. Custom terms can restrict commercial use, cap user counts, or forbid training other models on the outputs.

"Open weights" and "open license" are separate questions. Weights you can download under terms you cannot accept are still weights you cannot use.

What a model was derived from, and how

The base_model field names what a model came from, and base_model_relation records how, as one of adapter, merge, quantized or finetune.

This answers a question people usually guess at from filenames. A repository whose name ends in a quantization suffix might be a quantized copy of somebody else's work, or a fine-tune of a quantized copy, or a merge of two models. The metadata says which, and base_model can be a list when the model is a merge.

Why it matters in practice: a quantized copy inherits the base model's license and its behavior, minus whatever precision cost the quantization carried. A merge inherits from several places, and its license position is the intersection of all of them.

Working out what it costs to run

Parameter count and precision set memory. The card's prose usually states the parameter count, and the files tell you the precision the weights are stored at.

Many popular models have quantized variants published alongside the originals, often by third parties, and base_model_relation: quantized is how you identify them. A smaller variant is the difference between a model that fits your hardware and one that does not.

The arithmetic and the part people forget, which is that concurrent requests consume memory beyond the weights, are covered in self-hosted models.

Reading benchmark claims

Evaluation results can appear as structured metadata under model-index, with each result carrying a task, a dataset, a metric value, and an optional source naming where it came from.

That source field is the most useful thing on the card for judging a number. A result sourced to an independent leaderboard was produced by somebody other than the uploader. A result with no source was typed in by whoever published the model.

Neither is necessarily wrong, and they deserve different levels of trust. When you see a benchmark score in the prose with no corresponding structured entry, you are reading a claim with no provenance at all.

Two further cautions. Contamination is real: a model trained on data that included a benchmark scores well on it without being better at the underlying task. And a benchmark measures its own task, which is unlikely to be yours. The only number that settles it is your own evaluation set on your own inputs.

Telling the variants apart

The same model is often published in several forms, and they are not interchangeable.

A base model continues text. Prompt it with a question and you may get more questions, because completing a list of questions is a reasonable continuation.

An instruction-tuned or chat model has been trained to follow instructions and hold a conversation, and it expects a particular chat format.

Pick the base model by accident and the model is not broken; it is doing the job it was trained for, which is not the one you wanted. pipeline_tag in the metadata tells you the intended task, and it also drives which widget and API the Hub offers.

Further reading

• Hugging Face, Model cards: the metadata fields, license handling, base model relations, and evaluation results.
• Hugging Face Inference SDK: calling a model once you have chosen one.
• Self-hosted models: what running it costs.