Anatomy of a Model Card
Lesson 1 of 3 in In Production: Reading a Model Card and Choosing a Model.
This is the last module of the academy, and it teaches the site’s closing skill: choosing a model in a landscape that will look different next quarter. The skill has one load-bearing interface — the Model card.
The idea has a definite origin: Mitchell et al. proposed model cards in 2018 (arXiv:1810.03993) as short standardized documents accompanying trained models — disclosing what a model is for, how it was evaluated and under which conditions, and where it fails. The proposal stuck. Today the card is the closest thing the landscape has to a datasheet: on open-weights catalogs it is literally the page the weights ship with, and for Closed weights API models the vendor’s model-documentation page plays the same role. When this site’s fact tables quote a parameter count, a Context window, or a license name, a card or an official docs page is what was read.
A card is the developer describing their own work, so it is not neutral — but it is specific, and specificity is what a decision needs. The marketing page says “best in class”. The card says what the intended uses are, what data went in, which benchmarks were run under which settings, what the known failure modes are, and which license you are agreeing to. Every one of those is a claim you can check, compare, or hold against your own measurements. Learn the sections and the questions they answer, and every card in the landscape — and every catalog entry modeled on one — becomes legible.
| Card section | The question it answers | Red flag when missing or vague |
|---|---|---|
Intended use | What was this built and tested for — and which uses does the developer disclaim? | You inherit every fitness-for-purpose judgment yourself, with no stated envelope to point to |
Specs: sizes, context, modalities | What are the load-bearing numbers — parameters, context in and out, modalities in and out? | A developer unwilling to commit to numbers is a developer whose numbers may move under you |
Training data disclosure | What went in — can you reason about Knowledge cutoff, language and domain gaps, and Contamination risk? | No data story means no way to judge what the eval scores were not contaminated by |
Evaluation tables | How did the developer measure it — which benchmarks, which settings, compared against what? | Scores without conditions (harness, shots, sampling) cannot be compared to anything, including themselves |
Limitations and risks | What does the developer already know goes wrong? | Every model has failure modes; a card listing none is a marketing page in card formatting |
License and distribution | What may you build, under which obligations — and is access gated behind accepting terms? | A “custom” license without linked text is a legal blocker wearing a footnote’s clothing |
What separates a good card from a decorated one is disclosure you could not have guessed. The SmolLM3-3B card advertises exactly that: “Fully open model: open weights + full training details including public data mixture and training configs” — the data story is part of the release. The gemma-3-4b-it card discloses training scale per size (“4B model was trained with 4 trillion tokens and 1B with 2 trillion tokens”) and — a detail most marketing copy flattens — documents context in two directions: “Total input context of 128K tokens for the 4B, 12B, and 27B sizes, and 32K tokens for the 1B size” alongside “Total output context of 8192 tokens”. One family, one card, and already two numbers where a headline would print one.
Precision shows up in parameter counts too. The Llama 3.2 Vision collection is marketed “in 11B and 90B sizes”, and its card then notes the actual counts: 10.6B and 88.8B. The gpt-oss-120b card draws the distinction that matters for serving Mixture of experts (MoE) models: “117B parameters with 5.1B active parameters”. And the Phi-4-reasoning-vision-15B card even discloses training compute — SFT on curated data using 240 B200 GPUs over 4 days. None of these numbers are ones you should memorize; the point is the genre. Cards written this way give you real levers: total vs active parameters predict serving cost, input vs output context predicts whether your workload fits, data disclosure predicts where the model is blind.
For API families the reading skill is identical, aimed at vendor docs pages instead: Anthropic’s model overview and OpenAI’s model docs state per-model context windows, maximum outputs, and supported modalities, and Google’s Gemini model page catalogs its lineup the same way — the card’s spec section, maintained live. What those pages state, treat as the current claim; what they omit, do not assume.
Key terms: Model card, Benchmark, Community license, Gated distribution, Knowledge cutoff
In production
Model cards are not just a Hugging Face habit — every managed platform reproduces the card pattern in its catalog, and the reading skill transfers directly.
AWS
Amazon Bedrock’s model catalog gives each hosted model an entry with provider documentation: supported modalities, context limits, regions, and links to the provider’s own card or docs. Model access is itself an explicit grant per provider — an echo of gated distribution — and the provider’s use terms travel with the model. The discipline: read the underlying card before enabling access, and record what you read, because the catalog entry is your card-of-record for that deployment.
Azure
The Azure AI Foundry model catalog spans first-party, open-weights, and partner models, each with a card-style page: description, capabilities, deployment options, and the license or terms for that entry. Because the catalog aggregates many providers, the license column changes entry by entry — the same Apache-2.0-next-to-community-license spread you see on Hugging Face, reproduced inside one enterprise catalog. Never assume catalog admission normalized the legal terms.
Google Cloud
Vertex AI Model Garden presents first-party, open, and partner models through card-shaped entries — intended uses, versions, limitations, deployment paths. Open-weights models deployed from Model Garden to managed endpoints keep their upstream licenses and obligations; the platform hosts the weights, it does not relicense them. The card anatomy you learned here is exactly how you audit an entry before standing up an endpoint.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.