Start with a model card
Read how model cards describe intended uses, limitations, evaluation information, and metadata.
Start with: Model Cards
RedLectern topic
Providers and model families · release lineage · capabilities · model documentation.
For: AI users · builders
After this page you can: Identify a model's origin and read its release evidence.
Page reviewed
Part of: Artificial Intelligence › Foundation models
The AI model landscape is easier to navigate as a set of release records than as a league table. Providers may group related releases into families, offer variants for general or narrower tasks, and update which versions they document. A family name is a useful starting point; the specific release identity and its documentation tell you what is actually being described.
When you inspect a release, trace its stated base model and version links, then read its model card for intended uses, limitations, evaluation information, and license metadata. Treat capability claims as scoped to the release and the evidence provided. Evaluation results are easier to interpret when you can identify their task, dataset, metric, and source. For builders, use this landscape to form a shortlist, then check the specific candidates against your own tasks and deployment constraints.
Read how model cards describe intended uses, limitations, evaluation information, and metadata.
Start with: Model Cards
Learn how model documentation can identify a base model, a new version, or a derived release.
Start with: Model Cards
A model family groups related releases by lineage, design, or release identity. Providers may describe a family as having multiple variants for general or specific use cases, so a family name alone does not tell you which release or capability claim applies. Find the exact release page and check how the provider describes its relationship to other releases.
The term frontier model also needs a stated frame: the Frontier Model Forum uses a membership definition based on performance against models widely deployed for at least 12 months, assessed with conventional benchmarks or high-risk capability assessments. That is one organization’s definition, not a universal label. Treat both family and frontier labels as pointers to investigate, then read the release evidence.
The Forum states its membership-related definition of a frontier AI model.
Model family
Related models sharing a lineage, design, or release identity.
Frontier model
For the Frontier Model Forum’s membership definition, a general-purpose model that outperforms models widely deployed for at least 12 months, based on a range of conventional performance benchmarks or high-risk capability assessments.
Open a provider’s page for a model family. Identify one family name, one specific release or variant, and one sentence that explains their relationship.
Google calls Gemma a family; Gemma 4 is one of its variations for a wide range of generative AI tasks, and Google says Gemma draws technological lineage from Gemini.
A release record can show whether a model is linked to a base model, a newer version, or a relationship such as fine-tuning, an adapter, quantization, or a merge. Follow those links instead of assuming two similar names refer to the same release. Record the exact identifier shown on the release page so you can return to the evidence you checked.
Model cards may also include a license field. Read the linked license itself when deciding what the release permits; a metadata label is a pointer, not a substitute for the terms. For any candidate, note its stated lineage, version, and license source together. This makes it easier to compare releases without carrying claims from one variant over to another.
Use the metadata guidance to identify links between a release and its base model or newer version.
On a model release page, find its stated base model or version link and its license link. Write down what each link establishes.
A base-model or version link records a stated relationship between releases; the license link is where to read the terms for that release.
A model card is documentation about a release. It can describe intended uses and limitations, training and experimental information, datasets, and evaluation results. Check which release the card covers, then separate the maker’s description of intended use from evidence about measured performance.
When a card reports an evaluation, look for the task, dataset, metric, and source. A capability statement may apply to a particular modality or task, while another variant in the same family may have a different stated role. Read limitations alongside capability claims, and note what the documentation leaves unspecified. Use the linked How to read a model card workflow to organize those checks.
An official family overview with examples of general-use and task-specific variants.
Model card
Documentation describing a model’s intended uses, evaluation, and limitations.
Choose a model card. Find its intended uses, one limitation, and one evaluation result. For the result, note the task, dataset, metric, and cited source if provided.
For Gemma 4, the card lists text generation as an intended use and says training-data biases or gaps can limit responses. It reports automated and human safety evaluations conducted without safety filters; that passage does not specify a task, dataset, metric, or source.
No recent updates are available.
Jay Alammar and Maarten Grootendorst · 2024
Builds a practical picture of language models, from Transformer architecture and text representation to pretrained-model uses such as search, classification, and generation.
Chip Huyen · 2024
Offers a framework for developing applications with foundation models, including model evaluation, capability assessment, and public benchmarks.