1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
---
stage: ModelOps
group: MLOps
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Model registry **(FREE ALL EXPERIMENT)**
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9423) in GitLab 16.8 as an [Experiment](../../../../policy/experiment-beta-support.md#experiment) release [with a flag](../../../../administration/feature_flags.md) named `ml_experiment_tracking`. Disabled by default. To enable the feature, an administrator can [enable the feature flag](../../../../administration/feature_flags.md) named `model_registry`.
NOTE:
Model registry is an [Experiment](../../../../policy/experiment-beta-support.md). [Provide feedback](https://gitlab.com/groups/gitlab-org/-/epics/9423).
Model registry allows data scientists and developers to manage their machine learning
models, along with all metadata associated with their creation: parameters, performance
metrics, artifacts, logs and more. For the full list of currently supported features,
see [epic 9423](https://gitlab.com/groups/gitlab-org/-/epics/9423).
## Access the model registry
To set the model registry [visibility level](../../../public_access.md) to public, private or disabled:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Settings > General**.
1. Expand **Visibility, project features, permissions**.
1. Under **Model registry**, ensure the toggle is on and select who you want to have access.
Users must have
at least the [Reporter role](../../../permissions.md#roles) to modify or delete models and model versions.
## Exploring models, model versions and model candidates
Model registry can be accessed on `https/<your-project>-/ml/models`.
## Creating machine learning models and model versions
Models and model versions can be created using the [MLflow](https://www.mlflow.org/docs/latest/tracking.html) client compatibility.
See [MLflow client compatibility](../experiment_tracking/mlflow_client.md#model-registry) on how to
create and manage models and model versions.
## Upload files, log metrics, log parameters to a model version
Files can either be uploaded to a model version using:
- The package registry, where a model version is associated to a package of name `<model_name>/<model_version>`.
- The MLflow client compatibility. [View details](../experiment_tracking/mlflow_client.md#logging-artifacts-to-a-model-version).
Users can log metrics and a parameters of a model version through the MLflow client compatibility, [see details](../experiment_tracking/mlflow_client.md#logging-metrics-and-parameters-to-a-model-version)
## Link a model version to a CI/CD job
When creating a model version through a GitLab CI/CD job, you can link the model
version to the job, giving easy access to the job's logs, merge request, and pipeline.
This can be done through the MLflow client compatibility. [View details](../experiment_tracking/mlflow_client.md#linking-a-model-version-to-a-cicd-job).
## Model versions and semantic versioning
The version of a model version in GitLab must follow [Semantic Version specification](https://semver.org/).
Using semantic versioning facilitates model deployment, by communicating which
if a new version can be deployed without changes to the application:
- A change in the major component signifies a breaking change in the model, and that the application
that consumes the model must be updated to properly use this new version.
A new algorithm or the addition of a mandatory feature column are examples of breaking
changes that would require a bump at the major component.
- A change in the minor component signifies a non-breaking change, and that the
consumer can safely use the new version without breaking, although it might
need to be updated to use its new functionality. For example, adding a non-mandatory
feature column to the model is a minor bump, because when that feature is not passed,
it will still work.
- A change in the patch component means that a new version is out that does not
require any action by the application. For example, a daily retrain of the
model does not change the feature set or how the application consumes the
model version. Auto updating to a new patch is a safe update.
## Related topics
- Development details, feedback, and feature requests in [epic 9423](https://gitlab.com/groups/gitlab-org/-/epics/9423).
|
