Learn AI /Training and Model Adaptation /Model version
Model version
- Starter
- Training and Model Adaptation
- Policy officers
- Programme & data teams
Also called: model card, release, model update.
Back to the milestone you came from
In five seconds
What it is
A particular identified state of a model or model-backed system, with documented changes, capabilities and checks for use.
In plain words
Think of it like this: the version is the labelled edition, the update is what changed, the release is when people get it, and the model card is the explanation sheet.
An everyday example
A relief team uses a short field guide translated from Arabic into English for incoming staff. In March, they publish Edition 1 with a cover label and a note on where the translation may be too literal. In June, they issue Edition 2 after correcting terms, improving clarity and making the file smaller for low-bandwidth phones. The new PDF is the release, "Edition 2" is the version, the list of changes is the update note, and the page explaining scope and known limits works like a model card.
A translated guide is written and checked sentence by sentence by people. A model version usually reflects many numerical parameter changes and system changes that cannot be summarised like ordinary edits. Also, a model card is often more structured than a simple note page, and some releases bundle several components, not just one file.
Remember thisRecord the exact version tested, what changed and the documentation attached to it. A product name is not a version, and deploying a version is a separate release event.
Understand it
Understand it
Why it matters
For non-specialists, this term matters because results can change from one version to another even when the product name stays similar. If you compare performance, approve procurement, assess risk or write guidance, you need to know exactly which version was used, what changed and what evidence supports the change. A model card can help, but only if it matches the actual released version. Without that clarity, teams may repeat tests that cannot be reproduced, miss new limitations, or assume an update means improvement in every task when it may only improve speed, cost or a narrow benchmark.
From internal change to public use
Show how internal model changes, version naming, release and documentation relate but are not the same thing.
01
1. Change made
Developers alter something: more training, safety tuning, compression, bug fixing or serving changes.
Draw a rounded box with small icons for data, sliders and tools feeding into a model shape. Caption: 'Internal change'.
02
2. Version named
The changed state gets an identifier such as a date, tag or version number so results can be traced.
Draw an arrow to a second box showing labels like 'v1.0', 'v1.1', '2026-04'. Use a tag icon.
03
3. Released
The organisation makes that version available through a file, API or product update.
Draw an arrow to a third box with icons for download, API and app window. Caption: 'Made available'.
04
4. Described
A model card or release notes explain intended use, tests, limits and important changes for this version.
Draw an arrow to a document panel beside the release box. Add bullet lines: 'uses', 'limits', 'evaluation', 'changes'.
A left-to-right four-step diagram. Read it as a sequence from technical change inside a model system to what users actually receive. Each step has a short label and one sentence. A side note under the last step states that a model card describes a version but is not the model itself.
Hover or tap each step to reveal a short example: training change, version tag, release channel and model card contents.
Describe this without the diagram
The diagram shows four connected stages. First, developers make a change to the model or surrounding system, such as extra training, safety tuning, compression or a bug fix. Second, that changed state receives a version label so people can identify it exactly. Third, the organisation releases that version through a file, application programming interface or product update. Fourth, documentation such as a model card or release notes explains what the version is for, how it was tested and what its limits are. The key message is that the technical change, the version label, the release and the documentation are related but different things.
With reduced motion: A static four-box sequence with arrows: Change made, Version named, Released, Described. A note below says: 'Model card describes a version; it is not the model itself.'
People often use several nearby words loosely here, so it helps to separate them. A model version is a specific named state of a model, such as version 1.2 or a dated release. A model update is the change from one version to another. A release is the act of making that version available to users. A model card is the document that describes the model, its intended uses, limits and testing.
What goes in can vary. A team may start from an existing model, then change it through more training, adjustment or compression. Those changes might include fine-tuning, changing safety behaviour, making it smaller or faster, or fixing a bug in how it is served. What comes out is usually a new version name, the model files or access endpoint, and updated documentation.
The important point is that not every change means the same thing. A new version may reflect new training data or fine-tuning, but it may also reflect quantisation, distillation or other engineering changes that affect speed, cost or quality. A release may happen without changing the underlying model weights, for example if only the interface or access controls changed. A model card describes the version, but it is not the version itself.
This term is often confused with checkpoint and knowledge cutoff. A checkpoint is a saved snapshot during training or adaptation, often for developers, and many checkpoints never become public versions. Knowledge cutoff refers to the latest period reflected in a model's training data, which is only one property of a version. When someone says, "we updated the model," ask what changed, how it was tested, and which version the results refer to.
How “Successive editions of a translated field guide” maps onto the real thing
| In the story | In the AI system |
|---|---|
| Edition 1 and Edition 2 labels | named model versions |
| publishing the new PDF to staff | a release |
| corrections and file-size changes | a model update that may affect quality, speed or usability |
| page explaining scope and known issues | a model card |
A worked example
A reporting officer in a regional bureau is checking whether a newly released language assistant can still produce usable English summaries from public French and Spanish updates before a monitoring report is finalised.
Starting from: The supplier has made two identifiable model versions available. The officer has an approved set of public source paragraphs, a fixed scoring rubric and the documentation supplied for each version.
- The officer records the exact identifier of the version currently deployed, rather than relying on the product name shown on the login page.
- Both versions are tested on the same public source paragraphs with the same settings and rubric.
- The newer version performs better on routine summaries but less reliably on specialised legal wording. Its documentation attributes the changes to additional instruction tuning and quantisation.
- The findings are recorded against each version identifier. The model card is updated with the observed limitation, while deployment of the newer version is treated as a separate release decision.
Result: The monitoring report uses output from the identified, tested version. Colleagues can trace which system produced the summaries, what changed, which limitation remains and whether that exact version was approved for release.
In a United Nations workplace
An information management officer in a Headquarters department is finalising terms of reference for a model-backed drafting tool. The file must clear by the end of the week, but the vendor documentation names the product without identifying the model version tested.
The terms of reference should require the exact version identifier, relevant model card, documented changes and evaluation results. They should also distinguish the version assessed from the release later deployed. Otherwise, the same product name may conceal a materially different system by the time it reaches users.
Before you try thisTesting must use approved, non-sensitive material. Draft terms of reference, procurement-sensitive information, personal data and confidential documents must not be entered into a service that has not been approved for them, since the provider may retain or process the content outside authorised arrangements.
Where you may hear it
- A vendor demo during a procurement unit’s technical evaluation
- An ICT governance board reviewing a deployment change
- Clearance of terms of reference for a model-backed service
- A testing debrief before a pilot release
Avoid confusion
Avoid confusion
Often confused with
Checkpoint
A saved copy of a model’s state at a particular point in training or adaptation, so work can be resumed, compared or released later.
Knowledge cutoff
The approximate point up to which a model’s training-derived background is expected to be current, while newer events and facts may be absent unless added another way.
Common misconceptions
Common misconception: A new version always means the model learned new facts from new data.
Correction: Not necessarily. A new version may come from fine-tuning, compression, safety adjustments, bug fixes or deployment changes. Some updates mainly affect behaviour, speed or cost rather than expanding what period of information the model reflects.
Common misconception: A model card and a model version are the same thing.
Correction: They are different. The version is the actual model state or system package being used. The model card is documentation about that version, ideally covering intended use, limits and evaluation. Good documentation helps, but it does not replace testing.
Common misconception: If a release note says 'updated model', that tells me enough to compare results.
Correction: It usually does not. To compare results, you need the exact version identifier, what changed, how it was evaluated and on which tasks. Otherwise two teams may both say 'the updated model' while referring to different releases or configurations.
Quick check
Which statement best distinguishes these related terms?
This option separates the four ideas correctly. The others mix them up with checkpoint or knowledge cutoff, or wrongly suggest that version details stop mattering after release. In practice, version details matter even more after release because users need traceability.
Go deeper
Go deeper
The simple version
Think of it like this: the version is the labelled edition, the update is what changed, the release is when people get it, and the model card is the explanation sheet.
The technical version
A model version is a uniquely identifiable state of a model or model-backed system at a point in time. It may differ from earlier versions because of fine-tuning, instruction tuning, preference optimisation, quantisation, distillation, pruning, safety layer adjustments or serving changes. A release is the publication or deployment event that exposes that version to users through an API, downloadable artefact or product integration. A model card is structured documentation associated with a version or family of versions, typically covering intended uses, out-of-scope uses, evaluation results, limitations, data and training notes where available, and safety or fairness considerations. These terms overlap in everyday speech, but they refer to different layers: technical state, change event, distribution event and documentation. They are also distinct from checkpoints, which are saved states from particular points in training or adaptation, and from knowledge cutoff, which describes the recency of training data rather than the full set of changes in a version.
Reviewed external resources
EncyclopaediaWikipedia search: Model version (opens in a new tab)Wikipedia
This Wikipedia link is a search results page, so it helps readers quickly see whether there are broad encyclopaedic entries or related terms to compare, and it suits general readers who want a starting point.
search results, not one pagelink checked 2026-07-31
CourseLLM Course (opens in a new tab)Hugging Face
This Hugging Face course gives structured technical learning on how models are trained, adapted and evaluated, so it suits readers who want a more systematic understanding of where versions come from.
Deeperlink checked 2026-07-31
CourseShort Courses (opens in a new tab)DeepLearning.AI
These DeepLearning.AI short courses suit busy learners who want guided introductions to practical AI topics without committing to a long programme.
Intermediatelink checked 2026-07-31
VideoVideo explanations: Model version (opens in a new tab)YouTube search
This YouTube link is a search results page, so it helps visual or auditory learners find multiple video explanations and compare teaching styles before choosing one.
search results, not one pagelink checked 2026-07-31
DiscussionCommunity discussion: Model version (opens in a new tab)Reddit search
This Reddit link is a search results page, so it lets readers see informal questions and practitioner discussions, and it suits people who want to learn how the term is used in everyday conversation.
search results, not one pagelink checked 2026-07-31
Where this came from
Drafted with a language model through an offline pipeline, checked against this site's schema, and every external link above fetched to see whether it answers. Treat it as a starting point and check anything that matters against the primary sources. How this site is built and what that means.
The one thing to remember
Record the exact version tested, what changed and the documentation attached to it. A product name is not a version, and deploying a version is a separate release event.