doc/user/project/ml/model_registry/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
model_registry. Disabled by default. To enable the feature, an administrator can enable the feature flag named model_registry.{{< /history >}}
A machine learning model registry serves as a centralized repository for managing machine learning models throughout their lifecycle. It functions like a specialized database that stores model versions along with essential metadata including performance metrics, validation results, and data lineage information.
Use GitLab model registries to:
For more information about model registry features and capabilities, see epic 9423.
The model registry is controlled by the package registry setting. Before using the model registry, make sure the package registry is enabled.
To access the model registry, in the left sidebar, select Deploy > Model registry.
If Model registry is not available, ensure that it has been enabled.
To enable the model registry or set the visibility level to public or private:
To create a new machine learning model by using the GitLab UI:
You can now view the newly created model in the model registry.
To create a new model version:
The new model version is now available in the model registry.
To delete a model and all its associated versions:
Alternatively you can delete models from the model details page:
To delete a model version:
Alternatively you can delete models from the model version details page:
To add artifacts to a model version:
config.Alternatively, you can drag and drop files in the drop area. The artifacts are automatically uploaded.
Because each file has a size limit of 5 GB, you must partition larger models.
To delete artifacts of a version:
Models and model versions can be created using the MLflow client compatibility. For more information about how to create and manage models and model versions, see MLflow client compatibility. You can also create models directly on GitLab by selecting Create model on the Model registry page.
Files can either be uploaded to a model version using:
<model_name>/<model_version>.Users can log metrics and a parameters of a model version through the MLflow client compatibility, see details
When creating a model version through a GitLab CI/CD job, you can link the model version to the job, giving convenient access to the job's logs, merge request, and pipeline. This can be done through the MLflow client compatibility. View details.
The version of a model version in GitLab must follow Semantic Version specification. Using semantic versioning facilitates model deployment, by communicating which if a new version can be deployed without changes to the application:
Major (integer): 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.
Minor (integer): A change in the minor component signifies a non-breaking change, and that the consumer can safely use the new version without breaking, although the consumer might need to be updated to use its new functionality. For example, adding a non-mandatory feature column with a default value to the model is a minor bump, because when a value for the added column is not passed, inference still works.
Patch (integer): 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.
Prerelease (text): Represents a version that is not yet ready for production use. Used to identify alpha, beta, or release candidate versions of the model.