Improve load_model() by adding param dst_path#4997
Conversation
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
|
|
||
|
|
||
| def load_model(model_uri): | ||
| def load_model(model_uri, artifact_path=None): |
There was a problem hiding this comment.
I think dst_path or path might be better here to distinguish from the artifact_path parameter of log_model(). This will make it clearer that artifact_path is not related to the model_uri / run.
| def load_model(model_uri, artifact_path=None): | |
| def load_model(model_uri, dst_path=None): |
There was a problem hiding this comment.
+1 for this change. download_artifacts also has a dst_path argument:
mlflow/mlflow/tracking/client.py
Lines 1353 to 1365 in 8bd7503
|
After load_model returned, shall we delete the model file on local disk immediately ? |
Signed-off-by: Liang Zhang <liang.zhang@databricks.com>
That's a good point for optimization that could be addressed in a separate PR. We also need to confirm that for all the flavors, the load_model() method is not lazy, and will never refer to the model file after load_model is returned. |
|
It looks like the failure is discussed here keras-team/keras#15579. It's not related to this PR. |
Signed-off-by: Liang Zhang liang.zhang@databricks.com
What changes are proposed in this pull request?
This PR is to resolve issue #4852.
How is this patch tested?
Existing tests.
Release Notes
Is this a user-facing change?
You can specify the directory where model artifacts are downloaded to by using the parameter
dst_pathinload_model().What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/artifacts: Artifact stores and artifact loggingarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesarea/examples: Example codearea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/models: MLmodel format, model serialization/deserialization, flavorsarea/projects: MLproject format, project running backendsarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/server-infra: MLflow Tracking server backendarea/tracking: Tracking Service, tracking client APIs, autologgingInterface
area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Modelsarea/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registryarea/windows: Windows supportLanguage
language/r: R APIs and clientslanguage/java: Java APIs and clientslanguage/new: Proposals for new client languagesIntegrations
integrations/azure: Azure and Azure ML integrationsintegrations/sagemaker: SageMaker integrationsintegrations/databricks: Databricks integrationsHow should the PR be classified in the release notes? Choose one:
rn/breaking-change- The PR will be mentioned in the "Breaking Changes" sectionrn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/feature- A new user-facing feature worth mentioning in the release notesrn/bug-fix- A user-facing bug fix worth mentioning in the release notesrn/documentation- A user-facing documentation change worth mentioning in the release notes