Model Management Service¶
Idea¶
The Model Management for Analytical solutions helps customers to store single file models, algorithms, scripts, docker images and training or validation data, used for machine learning or AI tasks.
Access¶
The Model Management Service is exposed as a REST API. Storing, retrieving, updating of models and their versions, along with the associated metadata can be done by simple API calls.
For accessing this service you need to have the respective roles listed in Model Management Service roles and scopes.
Basics¶
The Model Management Service stores and serves models for either active users or applications, which require storing of (large) binaries. It supports both versioning and metadata information.
Model Management supports structured information associated with models, such as:
- Model Metadata: Provides general model information
- Version Metadata: Provides traceability of model versions
- Version Payload: Provides traceability of the actual binary content of a model, which is always associated with version information
Model Metadata¶
The model metadata stores general model information like name, author, creation date and its type.
Version Metadata¶
The version metadata stores detailed information regarding the stored version. Those are the version number, the type (like Zeppelin, Jupyter, Protobuff, Docker etc.), in/out parameters, freeform parameters, build and/or run dependencies (libraries and associated version), and dependencies on other models. A dependency on another model is for example given, if the other model produces a payload, which is required as an input. This dependency is defined using the producedBy field.
Version payload¶
The version payload stores the actual model content in a file, which can be of any type, including .json, .pmml, .py, .ipynb, or .pb.
Features¶
The Model Management Service exposes its API for realizing the following tasks:
- Storing analytical model binaries and versioning info
- Managing versions of a model
- Downloading a model for examination or execution
- Defining dependencies needed to execute a model
- Defining parameters required to execute a model
Limitations¶
- Currently, the Model Management Service can only store one version payload (file) for a specific version of a model.
- Model needs to be kept in sync with asset modelling. The user needs to update the model and retain it, if there is any change in asset modelling which is used in the algorithm/model. If this is not done, then jobs using such models will start failing as they would be looking for a variable/aspect/asset by name which does not exists in the system.
- All tenants have 100 GB storage allocated by default irrespective of the offering
API Rate Limits for P&P Tenant¶
Model Management has imposed technical limits for P&P tenant to safeguard the system and to avoid system exploitation on heavy load exceeding system limits.API rate limits for Model Management are applicable as technical rate limits.
Example Scenario¶
A client has their own analytical models for training or forecasting. They use the Model Management Service store these models and retrieve them for training. After the training is finished, the model can output weights or another type of trained model binaries. Additional models or simple inference services can load the weights files to perform predictions.