hsml.model #

Name of the tag to be added.

Value of the tag to be added.

If specified, only clear cache for this project. If None, clears all cached models.

If specified (requires project_name), only clear cache for this specific model. If None, clears all models in project.

If specified (requires project_name and model_name), only clear cache for this specific model version. If None, clears all versions.

Name of the feature monitoring configuration.

Description of the feature monitoring configuration.

Start date and time from which to start computing statistics.

End date and time at which to stop computing statistics.

Cron expression scheduling the FM job (UTC, Quartz).

Name of the tag to be removed.

Name of the deployment.

Description of the deployment.

Deprecated. Version number of the model artifact to deploy, CREATE to create a new model artifact or MODEL-ONLY to reuse the shared artifact containing only the model files.

Serving tool used to deploy the model server.

Path to a custom predictor script implementing the Predict class, either local or already uploaded to HopsFS.

Model server configuration file to be passed to the model deployment, either local or already uploaded to HopsFS. It can be accessed via CONFIG_FILE_PATH environment variable from a predictor or transformer script. For LLM deployments without a predictor script, this file is used to configure the vLLM engine.

Resources to be allocated for the predictor.

Inference logger configuration.

Inference batcher configuration.

Scaling configuration for the predictor.

Transformer to be deployed together with the predictor.

API protocol to be enabled in the deployment (i.e., 'REST' or 'GRPC').

The inference environment to use.

Environment variables to set on the predictor.

vLLM image variant for vLLM deployments. One of 'VLLM' or 'VLLM_OMNI'. Ignored for non-vLLM model servers.

vLLM image tag override. If set, it must be one of the tags ModelServing.get_vllm_image_tags returns for the matching vllm_variant; the two variants advertise different tags, and an unqualified call lists the standard vLLM ones. On a new deployment, None selects the newest advertised tag of that variant. On an update, None means "unchanged": the deployment keeps its current tag, so moving it to the cluster default takes naming that tag explicitly. A deployment also keeps its tag after an admin stops advertising it. Ignored for non-vLLM model servers.

Optionally the tags to attach to the deployment when it is created, in the same shapes accepted by feature groups. A single Tag, a {"name": "owner", "value": "team-a"} dict, or a list of either, for example [{"name": "owner", "value": "team-a"}]. The tags ride the create request, so any mandatory deployment tags missing from them cause the backend to reject the creation.

Deployment schema describing the prediction requests. Inferred from the feature view when the default predictor is used; a given schema must then keep the inferred fields and may only refine types and descriptions.

Feature view features whose values clients send with each request instead of the online store providing them. Only with the default predictor.

None selects the default predictor automatically for Python models with a feature view and no script, True requires it (also for sklearn models, and together with a script_file that subclasses it), False never uses it.

Whether to deploy in KServe Knative mode. None (default) lets the backend decide: LLM (vLLM) deployments default to Standard, every other deployment defaults to Knative mode; on an update, None keeps the deployment's current mode. Standard mode does not scale to zero (minimum one instance). It autoscales on a CPU or memory metric between min_instances and max_instances (default: CPU at 80% up to the cluster maximum), and runs a fixed replica count without autoscaler when min_instances == max_instances (the default for LLM deployments).

path where to download the model files in the local filesystem. If None, downloads to cache directory (recommended for idempotent reuse).

By default this is set to True. If you require a more complex initialization of the feature view for online or batch scenarios, you should set init to False to retrieve a non initialized feature view and then call init_batch_scoring() or init_serving() with the required parameters.

By default this is set to False and the initialization for batch scoring is considered the default scenario. If you set online to True, the online scenario is enabled and the init_serving() method is called. When inside a deployment, the only available scenario is the online one, thus the parameter is ignored and init_serving is always called (if init is set to True). If you want to override this behaviour, you should set init to False and proceed with a custom initialization.

Name of the tag to get.

Local or remote (Hopsworks file system) path to the folder where the model files are located, or path to a specific model file.

Awaiting time for the model to be registered in Hopsworks.

If the model files are located in hopsfs, whether to move or copy those files into the Models dataset. Default is False (i.e., model files will be moved)

When saving a model from outside Hopsworks, the model is uploaded to the model registry using the REST APIs. Each model artifact is divided into chunks and each chunk uploaded independently. This parameter can be used to control the upload chunk size, the parallelism and the number of retries. upload_configuration can contain the following keys: * key chunk_size: size of each chunk in megabytes. Default 10. * key simultaneous_uploads: number of chunks to upload in parallel. Default 3. * key max_chunk_retries: number of times to retry the upload of a chunk in case of failure. Default 1.

name of the tag

value of the tag