跳到主要内容

在 MLflow 模型中管理依赖项

MLflow 模型是一种标准格式，它将机器学习模型及其依赖项和其他元数据打包在一起。构建包含依赖项的模型可以确保在各种平台和工具之间的可重现性和可移植性。

当您使用MLflow Tracking API创建 MLflow 模型时，例如 mlflow.pytorch.log_model()，MLflow 会自动推断您使用的模型风格所需的依赖项，并将它们记录为模型元数据的一部分。然后，当您部署模型进行预测时，MLflow 会自动将依赖项安装到环境中。因此，您通常无需担心在 MLflow 模型中管理依赖项。

但是，在某些情况下，您可能需要添加或修改一些依赖项。本页面提供了 MLflow 如何管理依赖项的高层描述，以及如何根据您的用例自定义依赖项的指导。

提示

一个提高 MLflow 依赖项推断准确性的技巧是在保存模型时添加 input_example。这使得 MLflow 能够在保存模型之前执行模型预测，从而捕获预测期间使用的依赖项。有关此参数的其他详细用法，请参阅模型输入示例。

MLflow 如何记录模型依赖项​

MLflow 模型保存在指定目录中，结构如下

my_model/
├── MLmodel
├── model.pkl
├── conda.yaml
├── python_env.yaml
└── requirements.txt

模型依赖项由以下文件定义（对于其他文件，请参阅讨论存储格式部分的指导）

  • python_env.yaml - 此文件包含使用 virtualenv 恢复模型环境所需的信息 (1) python 版本 (2) 构建工具，如 pip、setuptools 和 wheel (3) 模型的 pip 要求（对 requirements.txt 的引用）
  • requirements.txt - 定义运行模型所需的 pip 依赖项集。
  • conda.yaml - 定义运行模型所需的 conda 环境。当您指定 conda 作为恢复模型环境的环境管理器时，将使用此文件。

请注意，不建议手动编辑这些文件来添加或删除依赖项。它们由 MLflow 自动生成，您进行的任何手动更改在您再次保存模型时都将被覆盖。相反，您应该使用以下部分中描述的推荐方法之一。

示例​

以下是使用 mlflow.sklearn.log_model 记录模型时 MLflow 生成的环境文件示例

  • python_env.yaml
python: 3.9.8
build_dependencies:
  - pip==23.3.2
  - setuptools==69.0.3
  - wheel==0.42.0
dependencies:
  - -r requirements.txt
  • requirements.txt
mlflow==2.9.2
scikit-learn==1.3.2
cloudpickle==3.0.0
  • conda.yaml
name: mlflow-env
channels:
  - conda-forge
dependencies:
  - python=3.9.8
  - pip
  - pip:
      - mlflow==2.9.2
      - scikit-learn==1.3.2
      - cloudpickle==3.0.0

向 MLflow 模型添加额外依赖项​

MLflow 会推断模型风格库所需的依赖项，但您的模型可能依赖于其他库，例如数据预处理。在这种情况下，您可以通过在记录模型时指定 extra_pip_requirements 参数来向模型添加额外依赖项。例如，

import mlflow


class CustomModel(mlflow.pyfunc.PythonModel):
    def predict(self, context, model_input):
        # your model depends on pandas
        import pandas as pd

        ...
        return prediction


# Log the model
with mlflow.start_run() as run:
    mlflow.pyfunc.log_model(
        python_model=CustomModel(),
        artifact_path="model",
        extra_pip_requirements=["pandas==2.0.3"],
        input_example=input_data,
    )

额外依赖项将添加到 requirements.txt 文件中，如下所示（类似地也添加到 conda.yaml 文件中）

mlflow==2.9.2
cloudpickle==3.0.0
pandas==2.0.3 # added

在这种情况下，当部署模型进行预测时，MLflow 除了推断出的依赖项外，还将安装 Pandas 2.0.3。

注意

一旦您记录了带有依赖项的模型，建议在沙箱环境中对其进行测试，以避免在将模型部署到生产环境时出现任何依赖项问题。自 MLflow 2.10.0 版本起，您可以使用 mlflow.models.predict() API 在虚拟环境中快速测试您的模型。有关更多详细信息，请参阅验证预测环境。

自行定义所有依赖项​

或者，您也可以从头开始定义所有依赖项，而不是添加额外依赖项。为此，请在记录模型时指定 pip_requirements。例如，

import mlflow

# Log the model
with mlflow.start_run() as run:
    mlflow.sklearn.log_model(
        sk_model=model,
        artifact_path="model",
        pip_requirements=[
            "mlflow-skinny==2.9.2",
            "cloudpickle==2.5.8",
            "scikit-learn==1.3.1",
        ],
    )

手动定义的依赖项将覆盖 MLflow 从模型风格库中检测到的默认依赖项

mlflow-skinny==2.9.2
cloudpickle==2.5.8
scikit-learn==1.3.1
警告

请注意，声明与训练期间使用的依赖项不同的依赖项可能会带来危险，并且容易导致意外行为。确保一致性的最安全方法是依赖 MLflow 推断出的默认依赖项。

注意

一旦您记录了带有依赖项的模型，建议在沙箱环境中对其进行测试，以避免在将模型部署到生产环境时出现任何依赖项问题。自 MLflow 2.10.0 版本起，您可以使用 mlflow.models.predict() API 在虚拟环境中快速测试您的模型。有关更多详细信息，请参阅验证预测环境。

使用 MLflow 模型保存额外代码依赖项 - 自动推断​

注意

自动代码依赖项推断是 MLflow 2.13.0 中引入的一项功能，并标记为实验性功能。为解决潜在问题和边缘情况，基础实现可能会在不另行通知的情况下进行修改、改进和调整。

注意

自动代码依赖项推断目前仅支持 Python Function 模型。未来版本的 MLflow 将支持更多命名的模型风格。

在 MLflow 2.13.0 版本中，引入了一种包含自定义依赖代码的新方法，该方法扩展了保存或记录模型时声明 code_paths 的现有功能。这项新功能利用导入依赖项分析，通过检查 Python 模型定义引用中导入了哪些模块来自动推断模型所需的代码依赖项。

为了使用这项新功能，您只需在记录时将参数 infer_code_paths（默认 False）设置为 True。使用此依赖项推断方法时，无需像 MLflow 2.13.0 版本之前那样通过声明 code_paths 目录位置来显式定义文件位置。

下面展示了使用此功能的一个示例，其中我们正在记录一个包含外部依赖项的模型。在第一部分中，我们定义了一个名为 custom_code 的外部模块，该模块存在于与我们的模型定义不同的位置。

custom_code.py
from typing import List

iris_types = ["setosa", "versicolor", "viginica"]


def map_iris_types(predictions: int) -> List[str]:
    return [iris_types[pred] for pred in predictions]

定义好这个 custom_code.py 模块后，就可以在我们的 Python 模型中使用了

model.py
from typing import Any, Dict, List, Optional

from custom_code import map_iris_types  # import the external reference

import mlflow


class FlowerMapping(mlflow.pyfunc.PythonModel):
    """Custom model with an external dependency"""

    def predict(
        self, context, model_input, params: Optional[Dict[str, Any]] = None
    ) -> List[str]:
        predictions = [pred % 3 for pred in model_input]

        # Call the external function
        return map_iris_types(predictions)


with mlflow.start_run():
    model_info = mlflow.pyfunc.log_model(
        artifact_path="flowers",
        python_model=FlowerMapping(),
        infer_code_paths=True,  # Enabling automatic code dependency inference
    )

将 infer_code_paths 设置为 True 后，将分析 map_iris_types 的依赖项，检测其源声明源自 custom_code.py 模块，并且 custom_code.py 中的代码引用将与模型制品一起存储。请注意，无需使用 code_paths 参数（在下一节讨论）定义外部代码依赖项。

提示

只有位于当前工作目录中的模块才能访问。依赖项推断无法跨越模块边界或在您的自定义代码定义在完全不同的库中时起作用。如果您的代码库结构使得通用模块完全位于模型记录代码执行路径之外，则需要使用原始的 code_paths 选项来记录这些依赖项，因为 infer_code_paths 依赖项推断无法捕获这些要求。

使用 infer_code_paths 的限制​

警告

在使用通过 infer_code_paths 进行的依赖项推断之前，请确保您的依赖代码模块中没有硬编码敏感数据（例如，密码、访问令牌或密钥）。代码推断不会混淆敏感信息，并且无论模块包含什么，都会捕获并记录（保存）该模块。

使用 infer_code_paths 时，代码结构需要注意的一个重要方面是避免在代码的主入口点内定义依赖项。当 Python 代码文件作为 __main__ 模块加载时，它无法被推断为代码路径文件。这意味着如果您直接运行脚本（例如，使用 python script.py），该脚本中定义的函数和类将成为 __main__ 模块的一部分，而其他模块无法轻易访问它们。

如果您的模型依赖于这些类或函数，这可能会带来问题，因为它们不属于标准模块命名空间，因此不容易序列化。为了处理这种情况，您应该使用 cloudpickle 来序列化您的模型实例。cloudpickle 是 Python 的 pickle 模块的扩展版本，可以序列化更广泛的 Python 对象，包括在 __main__ 模块中定义的函数和类。

为何重要​

  • 代码路径推断：MLflow 使用代码路径来理解和记录与您的模型相关的代码。当脚本作为 __main__ 执行时，无法推断出代码路径，这使得您的 MLflow 实验的跟踪和可重现性变得复杂。
  • 序列化：标准的序列化方法（如 pickle）可能无法处理 __main__ 模块对象，这导致在尝试保存和加载模型时出现问题。cloudpickle 通过启用这些对象的序列化提供了一种解决方法，确保您的模型能够正确保存和恢复。

最佳实践​

  • 避免在 __main__ 模块中定义关键函数和类。相反，将它们放在可以按需导入的单独模块文件中。
  • 如果您必须在 __main__ 模块中定义函数和类，请使用 cloudpickle 来序列化您的模型，以确保正确处理所有依赖项。

使用 MLflow 模型保存额外代码 - 手动声明​

MLflow 还支持将您的自定义 Python 代码作为依赖项保存到模型中。当您想部署模型预测所需的自定义模块时，这特别有用。为此，请在记录模型时指定 code_paths。例如，如果您的项目中有以下文件结构

my_project/
├── utils.py
└── train.py
train.py
import mlflow


class MyModel(mlflow.pyfunc.PythonModel):
    def predict(self, context, model_input):
        from utils import my_func

        x = my_func(model_input)
        # .. your prediction logic
        return prediction


# Log the model
with mlflow.start_run() as run:
    mlflow.pyfunc.log_model(
        python_model=MyModel(),
        artifact_path="model",
        input_example=input_data,
        code_paths=["utils.py"],
    )

然后 MLflow 会将 utils.py 保存在模型目录下的 code/ 目录中

model/
├── MLmodel
├── ...
└── code/
    └── utils.py

当 MLflow 加载模型进行部署时，code 目录将被添加到系统路径中，以便您可以在模型代码中使用该模块，例如 from utils import my_func。您也可以将目录路径指定为 code_paths，以在该目录下保存多个文件

将 code_paths 选项用于自定义库​

在记录模型时，要包含 PyPI 上不可用的自定义库，可以使用 code_paths 参数。此选项允许您将 .whl 文件或其他依赖项与模型一起上传，确保在部署期间所有必需的库都可用。

警告

以下示例演示了一种用于开发目的的快速包含自定义库的方法。不建议在生产环境中使用此方法。对于生产用途，请将库上传到自定义 PyPI 服务器或云存储，以确保可靠且安全的访问。

例如，假设您的项目具有以下文件结构

my_project/
|── train.py
└── custom_package.whl

然后以下代码可以记录包含自定义包的模型

train.py
import mlflow
from custom_package import my_func


class MyModel(mlflow.pyfunc.PythonModel):
    def predict(self, context, model_input):
        x = my_func(model_input)
        # .. your prediction logic
        return prediction


# Log the model
with mlflow.start_run() as run:
    mlflow.pyfunc.log_model(
        python_model=MyModel(),
        artifact_path="model",
        extra_pip_requirements=["code/custom_package.whl"],
        input_example=input_data,
        code_paths=["custom_package.whl"],
    )

code_paths 选项的注意事项​

使用 code_paths 选项时，请注意一个限制，即指定的文件或目录必须与您的模型脚本位于同一目录中。如果指定的文件或目录位于父目录或子目录中，例如 my_project/src/utils.py，则模型部署将失败并显示 ModuleNotFoundError。例如，假设您的项目中有以下文件结构

my_project/
|── train.py
└── src/
    └──  utils.py

那么以下模型代码不起作用

class MyModel(mlflow.pyfunc.PythonModel):
    def predict(self, context, model_input):
        from src.utils import my_func

        # .. your prediction logic
        return prediction


with mlflow.start_run() as run:
    mlflow.pyfunc.log_model(
        python_model=MyModel(),
        artifact_path="model",
        input_example=input_data,
        code_paths=[
            "src/utils.py"
        ],  # the file will be saved at code/utils.py not code/src/utils.py
    )

# => Model serving will fail with ModuleNotFoundError: No module named 'src'

此限制是由于 MLflow 保存和加载指定文件和目录的方式所致。当它将指定的文件或目录复制到目标 code/ 中时，它不会保留它们最初所在的相对路径。例如，在上面的示例中，MLflow 会将 utils.py 复制到 code/utils.py，而不是 code/src/utils.py。因此，必须将其导入为 from utils import my_func，而不是 from src.utils import my_func。然而，这可能不太理想，因为导入路径与原始训练脚本不同。

为了解决这个问题，code_paths 应该指定父目录，在此示例中为 code_paths=[\"src\"]。这样，MLflow 会将整个 src/ 目录复制到 code/ 下，您的模型代码将能够导入 src.utils。

class MyModel(mlflow.pyfunc.PythonModel):
    def predict(self, context, model_input):
        from src.utils import my_func

        # .. your prediction logic
        return prediction


with mlflow.start_run() as run:
    mlflow.pyfunc.log_model(
        python_model=model,
        artifact_path="model",
        input_example=input_data,
        code_paths=["src"],  # the whole /src directory will be saved at code/src
    )
警告

出于同样的原因，code_paths 选项不支持 code_paths=[\"../src\"] 的相对导入。

使用 code_paths 加载具有相同模块名但不同实现的多个模型的限制​

code_paths 选项的当前实现有一个限制，即它不支持在同一个 Python 进程中加载依赖于具有相同名称但不同实现的模块的多个模型，如下例所示

import importlib
import sys
import tempfile
from pathlib import Path

import mlflow

with tempfile.TemporaryDirectory() as tmpdir:
    tmpdir = Path(tmpdir)
    my_model_path = tmpdir / "my_model.py"
    code_template = """
import mlflow

class MyModel(mlflow.pyfunc.PythonModel):
    def predict(self, context, model_input):
        return [{n}] * len(model_input)
"""

    my_model_path.write_text(code_template.format(n=1))

    sys.path.insert(0, str(tmpdir))
    import my_model

    # model 1
    model1 = my_model.MyModel()
    assert model1.predict(context=None, model_input=[0]) == [1]

    with mlflow.start_run():
        info1 = mlflow.pyfunc.log_model(
            artifact_path="model",
            python_model=model1,
            code_paths=[my_model_path],
        )

    # model 2
    my_model_path.write_text(code_template.format(n=2))
    importlib.reload(my_model)
    model2 = my_model.MyModel()
    assert model2.predict(context=None, model_input=[0]) == [2]

    with mlflow.start_run():
        info2 = mlflow.pyfunc.log_model(
            artifact_path="model",
            python_model=model2,
            code_paths=[my_model_path],
        )

# To simulate a fresh Python process, remove the `my_model` module from the cache
sys.modules.pop("my_model")

# Now we have two models that depend on modules with the same name but different implementations.
# Let's load them and check the prediction results.
pred = mlflow.pyfunc.load_model(info1.model_uri).predict([0])
assert pred == [1], pred  # passes

# As the `my_model` module was loaded and cached in the previous `load_model` call,
# the next `load_model` call will reuse it and return the wrong prediction result.
assert "my_model" in sys.modules
pred = mlflow.pyfunc.load_model(info2.model_uri).predict([0])
assert pred == [2], pred  # doesn't pass, `pred` is [1]

为了解决此限制，您可以在加载模型之前从缓存中移除模块。例如

model1 = mlflow.pyfunc.load_model(info1.model_uri)
sys.modules.pop("my_model")
model2 = mlflow.pyfunc.load_model(info2.model_uri)

另一种解决方法是为不同的实现使用不同的模块名称。例如

mlflow.pyfunc.log_model(
    artifact_path="model1",
    python_model=model1,
    code_paths=["my_model1.py"],
)

mlflow.pyfunc.log_model(
    artifact_path="model",
    python_model=model2,
    code_paths=["my_model2.py"],
)

考虑到 code_paths 的此限制，推荐的项目结构如下所示

my_project/
|-- model.py # Defines the custom pyfunc model
|── train.py # Trains and logs the model
|── core/    # Required modules for prediction
|   |── preprocessing.py
|   └── ...
└── helper/  # Other helper modules used for training, evaluation
    |── evaluation.py
    └── ...

这样，您可以使用 code_paths=[\"core\"] 记录模型，以包含预测所需的模块，同时排除仅用于开发的辅助模块。

验证预测环境​

在部署之前验证您的模型是确保生产就绪的关键步骤。MLflow 提供了几种在本地测试模型的方法，可以在虚拟环境或 Docker 容器中进行。如果在验证过程中发现任何依赖项问题，请遵循如何修复部署模型时的依赖项错误？中的指导。

使用虚拟环境测试离线预测​

您可以使用 MLflow Models 的 Python 或 CLI predict API 来对模型进行测试预测。这将从模型 URI 加载您的模型，使用模型依赖项（在 MLflow Model 中定义）创建一个虚拟环境，并使用模型运行离线预测。有关 predict API 的更详细用法，请参阅 mlflow.models.predict() 或 CLI 参考。

注意

Python API 自 MLflow 2.10.0 版本起可用。如果您使用的是旧版本，请使用 CLI 选项。

import mlflow

mlflow.models.predict(
    model_uri="runs:/<run_id>/model",
    input_data="<input_data>",
)

使用 mlflow.models.predict() API 对于快速测试您的模型和推理环境很方便。但是，它可能不是对部署的完美模拟，因为它不会启动在线推理服务器。尽管如此，它是测试您的预测输入格式是否正确的好方法。

格式取决于您的记录模型的 predict() 方法支持的类型。如果模型使用签名记录，则输入数据应可从 MLflow UI 或通过 mlflow.models.get_model_info() 查看，该方法包含字段 signature。

更一般地，MLflow 能够支持各种风格特定的输入类型，例如 tensorflow 张量。
MLflow 还支持不特定于给定风格的类型，例如 pandas DataFrame、numpy ndarray、python Dict、python List、scipy.sparse matrix 和 spark data frame。

使用虚拟环境测试在线推理端点​

如果您想通过实际运行在线推理服务器来测试您的模型，可以使用 MLflow serve API。这会创建一个包含您的模型和依赖项的虚拟环境，类似于 predict API，但会启动推理服务器并暴露 REST 端点。然后您可以发送测试请求并验证响应。有关 serve API 的更详细用法，请参阅 CLI 参考。

mlflow models serve -m runs:/<run_id>/model -p <port>
# In another terminal
curl -X POST -H "Content-Type: application/json" \
    --data '{"inputs": [[1, 2], [3, 4]]}' \
    https://:<port>/invocations

虽然这是在部署前测试模型的可靠方法，但需要注意一点：虚拟环境不会吸收您的机器和生产环境之间的操作系统级别差异。例如，如果您使用 MacOS 作为本地开发机器，而部署目标运行在 Linux 上，您可能会遇到在虚拟环境中无法重现的一些问题。

在这种情况下，您可以使用 Docker 容器来测试您的模型。虽然它不像虚拟机那样提供完整的操作系统级别隔离（例如，我们无法在 Linux 机器上运行 Windows 容器），但 Docker 涵盖了一些流行的测试场景，例如运行不同版本的 Linux 或在 Mac 或 Windows 上模拟 Linux 环境。

使用 Docker 容器测试在线推理端点​

用于 CLI 和 Python 的 MLflow build-docker API 能够构建基于 Ubuntu 的 Docker 镜像来部署您的模型。该镜像将包含您的模型和依赖项，并包含用于启动推理服务器的入口点。与 serve API 类似，您可以发送测试请求并验证响应。有关 build-docker API 的更详细用法，请参阅 CLI 参考。

mlflow models build-docker -m runs:/<run_id>/model -n <image_name>
docker run -p <port>:8080 <image_name>
# In another terminal
curl -X POST -H "Content-Type: application/json" \
    --data '{"inputs": [[1, 2], [3, 4]]}' \
    https://:<port>/invocations

故障排除​

如何修复部署模型时的依赖项错误​

模型部署期间最常见的问题之一是依赖项问题。当记录或保存模型时，MLflow 会尝试推断模型依赖项，并将它们作为 MLflow 模型元数据的一部分进行保存。然而，这可能并不总是完整的，并会遗漏一些依赖项，例如某些库的 [extras] 依赖项。这可能导致在部署模型时出现错误，例如 "ModuleNotFoundError" 或 "ImportError"。以下是一些有助于诊断和修复缺失依赖项错误的步骤。

提示

为了减少依赖项错误的可能性，您可以在保存模型时添加 input_example。这使得 MLflow 能够在保存模型之前执行模型预测，从而捕获预测期间使用的依赖项。有关此参数的其他详细用法，请参阅模型输入示例。

1. 检查缺失的依赖项​

缺失的依赖项列在错误消息中。例如，如果您看到以下错误消息

ModuleNotFoundError: No module named 'cv2'

2. 尝试使用 predict API 添加依赖项​

既然您知道了缺失的依赖项，您可以创建一个包含正确依赖项的新模型版本。然而，为了尝试新的依赖项而创建新模型可能有点繁琐，特别是您可能需要多次迭代才能找到正确的解决方案。相反，您可以使用 mlflow.models.predict() API 来测试您的更改，而无需在排查安装错误时重复重新记录模型。

为此，请使用 pip-requirements-override 选项来指定 pip 依赖项，例如 opencv-python==4.8.0。

import mlflow

mlflow.models.predict(
    model_uri="runs:/<run_id>/<model_path>",
    input_data="<input_data>",
    pip_requirements_override=["opencv-python==4.8.0"],
)

指定的依赖项将安装到虚拟环境中，作为模型元数据中定义的依赖项的补充（或替代）。由于这不会修改模型，您可以快速安全地迭代以找到正确的依赖项。

请注意，对于 python 实现中的 input_data 参数，该函数接受您的模型 predict() 函数支持的 Python 对象。一些示例可能包括特定风格的输入类型，例如 tensorflow 张量，或者更通用的类型，例如 pandas DataFrame、numpy ndarray、python Dict 或 python List。使用 CLI 时，我们无法传递 python 对象，而是需要传递包含输入载荷的 CSV 或 JSON 文件的路径。

注意

pip-requirements-override 选项自 MLflow 2.10.0 版本起可用。

3. 更新模型元数据​

一旦您找到正确的依赖项，您就可以使用 mlflow.models.update_model_requirements() API 来更新已记录模型的依赖项。

import mlflow

mlflow.models.update_model_requirements(
    model_uri="runs:/<run_id>/<model_path>",
    operation="add",
    requirement_list=["opencv-python==4.8.0"],
)

请注意，您也可以利用 CLI 来更新模型要求

mlflow models update-pip-requirements -m runs:/<run_id>/<model_path> add "opencv-python==4.8.0"

或者，您可以在记录模型时通过指定 extra_pip_requirements 选项来记录一个包含更新后依赖项的新模型。

import mlflow

mlflow.pyfunc.log_model(
    artifact_path="model",
    python_model=python_model,
    extra_pip_requirements=["opencv-python==4.8.0"],
    input_example=input_data,
)

如何为许可证变更迁移 Anaconda 依赖项​

Anaconda Inc. 更新了其针对 anaconda.org 渠道的服务条款。根据新的服务条款，如果您依赖 Anaconda 的打包和分发，您可能需要商业许可证。有关更多信息，请参阅Anaconda Commercial Edition 常见问题解答。您对任何 Anaconda 渠道的使用均受其服务条款的约束。

在 v1.18 之前记录的 MLflow 模型默认使用 conda defaults 渠道 (https://repo.anaconda.com/pkgs) 作为依赖项进行记录。由于此许可证变更，MLflow 已停止在 MLflow v1.18 及更高版本中记录的模型中使用 defaults 渠道。现在记录的默认渠道是 conda-forge，它指向社区管理的 https://forge.conda.org.cn。

如果您在 MLflow v1.18 之前记录了一个模型，且没有从模型的 conda 环境中排除 defaults 渠道，该模型可能存在您不期望的对 defaults 渠道的依赖。要手动确认模型是否存在此依赖，您可以检查与记录模型打包在一起的 conda.yaml 文件中的 channel 值。例如，一个带有 defaults 渠道依赖的模型 conda.yaml 可能如下所示

name: mlflow-env
channels:
  - defaults
dependencies:
  - python=3.8.8
  - pip
  - pip:
      - mlflow==2.3
      - scikit-learn==0.23.2
      - cloudpickle==1.6.0

如果您想更改模型环境中使用的渠道，您可以使用新的 conda.yaml 将模型重新注册到模型注册表。您可以通过在 log_model() 的 conda_env 参数中指定渠道来做到这一点。

有关 log_model() API 的更多信息，请参阅您正在使用的模型风格的 MLflow 文档，例如 mlflow.sklearn.log_model()。