GitLab Incubation Engineering - Latest, 21 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: GitLab Model Registry July 2023 Development Update

Description

Current status on the development of GitLab Model Registry: where are we and where do we want to go.

- All Updates: https://gitlab.com/groups/gitlab-org/-/epics/9423#note_1437373082
- Epic: https://gitlab.com/groups/gitlab-org/-/epics/9423

A

Hello, everyone, my name, is Eduardo I. Am the incubation engineer for mlops here at gitlab, and today I'm going to be giving an update over the development of the model registry that have been working for the past month. First of all, what is model registry motor registry will be a solution that allows data science and machine learning Engineers to store their models, intricate lab, making it very easy to pass that on uh to the for deployment later on, to share them with their colleagues.

A

Just to make it easier to put your the stuff that you build the models that you build into production and for the users as fast as possible.

A

um What is the experience that we want to give with this? Well, what are we looking at here? What would it mean to have a model relative within the gitlab? First of all, you have models. A model is like a a library that you iterate over time.

A

You have a lot of information about the model itself and a model can have either candidates or versions. A candidate is when you are developing machine learning models. There's a lot of um iterations that are just changing parameters, you're exploring and candidates are. This exploration is when you are uh working. You are not really deploying those but you're, just tracking all the metadata, the artifacts that are created, uh the metrics. You want to share with your colleagues uh the results you want to review. You want to do hyper parameter tuning.

A

This is on candidates, and some of these candidates uh can be promoted into model versions. A version is something that is can be consumed that would be consumed by your application. So there are more serious or there are more, uh they have stronger requirements. uh They are more like they will be more likely to be built through SCI, whereas candidates can be built either locally or CI, but on an early stage but and versions.

A

You would expect more more rigorous training and creation, so there will be users will be able to promote a candidate that they have created into a model version that could mean trigger a pipeline that triggers that creates a new motor version from the parameters that the candidate had or just copying, creating a candidate, a version from the candidate directly um all of these versions, Beyond just the files that they have uh they will contain metadata.

A

You will be able to pass metadata training time, GPU usage, metrics parameters that were used, the tracking to the data that was used on that model um and plenty of other, like code base that you would like you would be able to see the CI pipeline that was used to create that model and so on and so forth, and having this version, uh then the the application can easily pull the correct version uh to serve to the users.

A

So, given this uh ux- or this is user experience, this uh idea- um where, where are we right now so beyond the part of the experiments, the motor experience, which is uh which we have deployed on 16 point two um as well so 16.0? You already can a gitlab track candidates and track metadata and search for for for for for, for all those uh for your for art, facts and so visualize parameters and so on and so forth, but for motor registry. Specifically, what have we built over the past few uh weeks?

A

One users can already upload and download model artifacts, there's a specific package type for machine learning models which allows us to go increase a little bit of the limit uh for for these files to 10 gigabytes, but it doesn't have support for directory structure. So you cannot pass a folder with many things like multiple folders, each folder having a file into the into the package registry.

A

um Only at the root of of the package um you can already create when you upload uh the model up um the the artifact. When you upload a file it will it will, it will create a model version, a model version. uh It needs to be assigned as a version that follows the same version, some verse back, a major minor header patch. This will be really useful down the road, because then we can provide a functionality that picks the the best.

A

The latest version- that is not that, doesn't have breaking changes, so it will allow users to set up automatic deployment of new models. So this is why we chose some semantic versioning. uh You can already track candidates for a specific model. So if you create a model, it will allow you to already use ml flow to track candidates, uh the mlflow client to track candidates for that model, and it also has a simple display for uh the the models and model versions that you created.

A

All of this is behind a feature flag. um It is not enabled on gitlab.com, it is not enabled for self-manned customers; it is very early in development, but what I mean is we already have an API that you can upload uh your files and you will start creating the models and the versions? This is very simplistic, UI, just to see what is going on over here, but this is what we have so far on 16.2 what it works. What do we expect for 16.3?

A

We worked the the heavy work that we did so far was on creating the the data layer, meaning all the the back-end changes that you don't see are happening.

A

That was done uh pretty much and now we're moving on to the Y. So there was a very simplistic UI that I showed before, but we want to iterate on this. We want to add search, paginate uh search, the Model Management delete, create and upload files directly from uh the the UI. We also want to make it easier to manage these models through an API right now. The only apis that we have enabled is to upload and download files, but we want to do better than that.

A

We want to allow you allow users to create uh the models, change them, manage them directly through an API models and model versions and candidates.

A

This is what I expect for 16.3 for 16.4.

A

um We wanna integrate better our model experiments into the model registry, so everything that we have developed for model experiments will become part of model registry uh tracking the metadata displaying the metadata. This will all be part of the of the model of the model registry. We'll start thinking at this level how to promote a candidate to a model through a model version, so what does it mean? Should we trigger a new CI pipeline or just copy the metadata? What does it look like?

A

um We want to also add on 16.4 uh support for different uh for direct 45 directors structure, so you don't need to upload just in the root, but you can pass a folder a lot of the tooling that, like Pi carrot and others, uh they need this folder uh structure, so we will provide those.

A

um We also want to continue what we did with model experiments and provide a compatibility layer to demo flow client, uh so that users that already use demo flow can switch uh to using gitlab model registry uh without changing their code base. Again. All of this is part of the gitlab platform.

A

So you already expect here: user authentication, artifact management, the data scientists don't need to worry about this. This is already available through gitlab. We are just adding uh more on top of we're just making Easier by adding this model registry. We're also want to, for example, integrate with merge requests integrate with the CI. If the the model version is already pulled from, I was already created through a CI. We want to show all of the information from the CI, how much time what are the logs and so on and so forth.

A

um So this is what I had for today. If you are interested in following you up, uh the best way is fall is going to the Epic uh for the the other. The on the development I have a thread there with all of where I will be keeping posting updates.

A