Glossary
Model card
A model card is a short published summary of one model's intended uses, limitations and how it was built, written by whoever made it and useful mostly for what it declines to say.
In plain terms
A short summary published alongside a model saying what it is for, how it was built and where it falls down. The maker writes it, so it is a statement rather than an audit. The useful way to read one is to notice which of the usual sections is missing, because a maker who has good news generally reports it.
Why it matters
Because it settles cheap questions before an expensive evaluation starts. What the thing is intended for, whether the licence permits your use and which languages are actually claimed can all be read in minutes, and finding a blocker there saves testing something you were never going to be able to deploy.
How it works
It follows a rough convention rather than a standard, which is what makes comparison possible and imperfect. Most cards cover intended use, limitations, an account of training and some evaluation, so two can be read side by side, and nothing obliges a maker to fill any particular section or to define its terms the way another did.
It is self-published, so the reading discipline is about absences. A maker with a good result on a common measure reports it, which means a card silent on something its peers cover is making a choice rather than an omission, and that silence is frequently the most informative part of the document.
The limitations section is written by people who know the thing best, and it is routinely skipped. It tends to be specific, unglamorous and accurate about where the model is weak, which makes it far more useful for a buying decision than the performance claims above it, and it costs a few minutes to read.
Cards accompany open models much more reliably than closed ones. Where weights are published for download the card travels with them as a matter of course, while closed hosted products more often carry marketing pages and a broader system-level document instead. That asymmetry is worth expecting rather than reading as evasion.
How to read a document written by the seller
Seen in the wild
The hub where open models live, where a downloadable model arrives with its card, its licence and the button in the same place.
Hugging FaceAn open image family whose weights are downloaded and modified locally, so what it was built for and what it permits travel with the files.
Stable DiffusionAn open-weight line whose page states plainly which members are downloadable and which are reachable only as a hosted service.
Qwen
Common misconceptions
People assume
It is an independent assessment.
In fact
It is a self-published statement by the maker, closer to a specification sheet than to an audit. That does not make it dishonest, and it does mean the claims are chosen. Read it for what is present, what is absent and what is defined vaguely, rather than as verification by anybody else.
People assume
A missing section means nothing.
In fact
It usually means the answer is unflattering. Makers report good results, so a card that is silent where its peers are specific has made a choice, and noticing that pattern is most of the skill in reading one. The gaps carry more information than the numbers.
Telling them apart
Model card vs System card
Model card
One model: what it is, and what it is not for.
The whole product around it, and how it behaves.
A card describes a component and the other describes what was built from it, which is why a closed product often has the second and no meaningful version of the first.
Questions
- What is worth reading first?
- The limitations and the licence, in that order. Limitations are written by the people who know the model best and are unusually candid, and the licence decides whether your intended use is permitted at all. Both take minutes and both can end an evaluation before it starts, which is the cheapest possible outcome.
- Can I compare two cards directly?
- Roughly, and with care about definitions. The convention is loose enough that two makers can report the same-sounding measure computed differently, so a like-for-like reading needs the definitions checked rather than the figures compared. What compares reliably is the shape: which sections each chose to fill.
- Why do closed products rarely have one?
- Because the format grew up around published weights, where the card travels with the download. Closed hosted products tend to publish a broader system-level account of the product's behaviour instead, which answers different questions. Expect the asymmetry rather than reading it as something being hidden.
Key takeaways
- Self-published, so read it as a specification sheet rather than an audit.
- The omissions carry the information; makers report good news.
- Limitations are the most useful section and the most often skipped.
- Cards travel with open weights; closed products publish something broader.
Tools that use this
- Hugging Face
Card, licence and download button in the same place.
- Stable Diffusion
Open weights where terms and purpose travel with the files.
- Qwen
States plainly which members are downloadable and which are hosted.
Last checked July 2026