Model Management and Inference
Model Versioning — Stack
Model versioning › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
- Snapshot availability. Does the provider publish immutable dated identifiers alongside its convenience aliases, and does it document what the alias currently resolves to?
- Deprecation notice. The published minimum notice period and whether there is a machine-readable source for retirement dates, or only an announcement page.
- Resolution visibility. Whether the API response reports the concrete version that served the request, so the alias-to-snapshot mapping can be recorded rather than assumed.
- Artefact immutability for self-hosted weights. Content-addressed storage, signed revisions, and a digest you can verify at load time rather than a mutable tag.
- Lineage for derived models. For fine-tunes and adapters: whether the base model version is recorded as part of the derived artefact's identity.
- Retention of evaluation history. Whether your evaluation store can key results by model version, prompt version, and dataset version together, which is the only form in which historical scores stay meaningful.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Dated snapshot identifiers from hosted providers | Production paths that must reproduce an output months later | Snapshots are retired too; pinning only converts a silent change into a dated deadline |
Floating aliases (-latest style) |
Internal tools and exploration where drift is acceptable | Never in an audited path, and never as the identifier recorded against a stored output |
| Hugging Face Hub revisions and model cards | Open-weight models where a commit SHA pins the exact artefact | A tag can move; pin the revision SHA, not the branch name |
| OCI-registry model artefacts and content-addressed object storage | Self-hosted serving where weights ship like any other immutable build artefact | Large artefacts stress registry limits and pull times; plan cache warming |
| Model registries (MLflow Model Registry, Weights & Biases, SageMaker Model Registry, Vertex AI Model Registry) | Organisations already running one for classical ML and wanting one lineage story | Built around training runs; representing a hosted third-party model version in them is a convention you define |
| Git-tracked configuration mapping logical names to pinned versions | Making a version change a reviewable, revertible pull request | Only as good as the enforcement that nothing bypasses the mapping at runtime |