メインコンテンツまでスキップ

記録済みモデルの依存関係

この記事では、モデルとその依存関係をモデル アーティファクトとしてログに記録し、モデルサービングのような本番運用タスクに環境内で使用できるようにする方法について説明します。

Python パッケージ モデルの依存関係を記録する​

MLflow は、一部の Python ML ライブラリをネイティブにサポートしており、MLflow はこれらのライブラリを使用するモデルの依存関係を確実にログに記録できます。 組み込みモデルのフレーバーを参照してください。

たとえば、MLflow では mlflow.sklearn モジュールで scikit-learn がサポートされており、コマンド mlflow.sklearn.log_model がサポートされています sklearn のバージョンをログに記録します。 これらの ML ライブラリを使用した 自動ログ 記録についても同じことが言えます。 その他の例については、 MLflow github リポジトリ を参照してください。

注記

生成AI ワークロードのトレースログを有効にするために、 MLflow は OpenAI 自動ログをサポートしています。

pip install PACKAGE_NAME==VERSIONと共にインストールできるが、組み込みの MLflow モデル フレーバーがない ML ライブラリの場合は、mlflow.pyfunc.log_model を使用してそれらのパッケージをログに記録できます 方式。 要件は、nltkではなく f"nltk=={nltk.__version__}" など、正確なライブラリ バージョンでログに記録してください。

mlflow.pyfunc.log_model 次のロギングをサポートします。

  • Python egg または Python wheel ファイルとしてパッケージ化された公開ライブラリとカスタムライブラリ。
  • PyPI 上の公開パッケージと、あなた自身の PyPI サーバ上のプライベートにホストされたパッケージ。

mlflow.pyfunc.log_modelを使用すると、MLflow は、依存関係を自動的に推論しようとします。 MLflow は、 mlflow.models.infer_pip_requirements を使用して依存関係を推論します。 そして、それらをモデルアーティファクトとして requirements.txt ファイルにログに記録します。

以前のバージョンでは、MLflow は、特にライブラリが組み込みのモデル フレーバーでない場合、すべての Python 要件を自動的に識別しないことがあります。 このような場合は、log_model コマンドの extra_pip_requirements パラメーターを使用して、追加の依存関係を指定できます。extra_pip_requirements パラメーターの使用例を参照してください。

important

また、要件のセット全体を conda_env パラメーターと pip_requirements パラメーターで上書きすることもできますが、MLflow が自動的に取得する依存関係がオーバーライドされるため、通常はお勧めしません。 pip_requirements パラメーターを使用して要件を上書きする方法の例を参照してください。

カスタマイズされたモデルのログ記録​

よりカスタマイズされたモデルのログ記録が必要なシナリオでは、次のいずれかを実行できます。

  • カスタム Python モデルを記述します。これにより、 mlflow.pyfunc.PythonModel をサブクラス化して、初期化と予測をカスタマイズできます。 このアプローチは、Python のみのモデルのカスタマイズに適しています。

  • カスタムフレーバーを書きます。このシナリオでは、一般的な pyfunc フレーバーよりもカスタマイズできますが、そのためには実装により多くの作業が必要です。

カスタムPythonコード​

%pip install コマンドを使用してインストールできない Python コードの依存関係 (1 つ以上の .py ファイルなど) がある場合があります。

モデルをログに記録するときに、mlflow.pyfunc.log_model の code_path パラメーターを使用して、指定したパスでモデルがそれらの依存関係を検出できることを MLflow に伝えることができます。MLflowはコードのディレクトリにあるモデルと共にアーティファクトとしてcode_pathを用いて指定されたすべてのファイルとディレクトリを保存します。モデルを読み込むときに、MLflow はこれらのファイルまたはディレクトリを Python パスに追加します。 このルートは、.pyファイルと同様に、code_pathを使用してモデルに含めることができるカスタム Python wheel ファイルでも機能します。

Python
mlflow.pyfunc.log_model( artifact_path=artifact_path,
                         code_path=[filename.py],
                         data_path=data_path,
                         conda_env=conda_env,
                       )

Python 以外のパッケージ モデルの依存関係を記録する​

MLflow では、Java パッケージ、R パッケージ、ネイティブ パッケージ (Linux パッケージなど) など、Python 以外の依存関係は自動的に取得されません。 これらのパッケージでは、追加のデータをログに記録する必要があります。

  • 依存関係リスト: Databricks は、これらの非Python 依存関係を指定するモデルと共にアーティファクトをログに記録することをお勧めします。 これは、単純な .txt ファイルまたは .json ファイルである可能性があります。 mlflow.pyfunc.log_model この追加のアーティファクトを artifacts 引数を使用して指定できます。
  • カスタムパッケージ: 上記のカスタムPython依存関係と同様に、パッケージがデプロイ環境で利用可能であることを確認する必要があります。 Maven Central や独自のリポジトリなどの中央の場所にあるパッケージの場合は、スコアリング時または配信時にその場所が使用可能であることを確認してください。 他の場所でホストされていないプライベートパッケージの場合は、モデルとともにパッケージをアーティファクトとして記録できます。

依存関係のあるモデルをデプロイします​

MLflow トラッキングサーバーまたはモデルレジストリからモデルをデプロイする場合は、デプロイメント環境に適切な依存関係がインストールされていることを確認する必要があります。最も単純なパスは、デプロイ モード (バッチ/ストリーミングまたはオンライン サービス) と、依存関係の種類によって異なる場合があります。

DatabricksすべてのデプロイDatabricks Runtime モードで、モデルを作成した にはさまざまなライブラリが既にインストールされているため 、トレーニング中に使用したのと同じランタイム バージョンで推論を実行することをお勧めします。Databricks の MLflow は、そのランタイム バージョンを MLmodel メタデータ ファイルの databricks_runtime フィールド ( databricks_runtime: 10.2.x-cpu-ml-scala2.12など) に自動的に保存します。

オンラインサービング: Mosaic AI Model Serving​

Databricksでは、MLflow 機械学習モデルがスケーラブルなREST API エンドポイントとして公開されるモデルサービングを提供しています。

requirements.txt ファイル内の Python 依存関係の場合、Databricks と MLflow はパブリック PyPI 依存関係のすべてを処理します。同様に、code_path 引数を使用してモデルをログに記録するときに .py ファイルまたは Python wheel ファイルを指定した場合、MLflow はそれらの依存関係を自動的に読み込みます。

これらのモデルサービングのシナリオについては、以下を参照してください。

requirements.txt ファイル内の Python 依存関係の場合、Databricks と MLflow はパブリック PyPI 依存関係のすべてを処理します。同様に、code_path 引数を使用してモデルをログに記録するときに .py ファイルまたは Python wheel ファイルを指定した場合、MLflow はそれらの依存関係を自動的に読み込みます。

オンラインサービス:サードパーティシステムまたはDockerコンテナ​

シナリオでサードパーティのサービス ソリューションまたは独自の Dockerベースのソリューションにサービスを提供する必要がある場合は、モデルを Docker コンテナーとしてエクスポートできます。

Databricks では、Python の依存関係を自動的に処理するサードパーティのサービスに対して、次のことをお勧めします。 ただし、Python 以外の依存関係の場合は、それらを含めるようにコンテナーを変更する必要があります。

バッチジョブとストリーミングジョブ​

バッチ スコアリングとストリーミング スコアリングは、 Databricks ジョブとして実行する必要があります。 多くの場合、ノートブック ジョブで十分であり、コードを準備する最も簡単な方法は、 Databricks Model Registry を使用してスコアリング ノートブックを生成することです。

以下では、依存関係が適切にインストールされ、適用されるようにするためのプロセスと手順について説明します。

  1. トレーニング中に使用したのと同じ Databricks Runtime バージョンでスコアリングクラスターを開始します。 MLmodel メタデータ ファイルから databricks_runtime フィールドを読み取り、そのランタイム バージョンでクラスターを開始します。

    • これは、クラスター設定で手動で行うことも、カスタムロジックを用いて自動化することもできます。 自動化する場合、Jobs APIおよびCluster APIで、メタデータファイルからランタイムのバージョンを読み込みます。

  2. 次に、Python 以外の依存関係をインストールします。 Python 以外の依存関係をデプロイ環境からアクセスできるようにするには、次のいずれかを行います。

    • 推論を実行する前に、クラスター構成の一部として、DatabricksクラスターにおけるモデルのモデルのPython以外の依存関係を手動でインストールします。
    • または、スコアリング ジョブのデプロイにカスタム ロジックを記述して、クラスターへの依存関係のインストールを自動化することもできます。 非Python依存関係をアーティファクトとして保存したと仮定すると、非Pythonパッケージモデルの依存関係のログ記録で説明されているように、この自動化ではライブラリ APIを使用してライブラリをインストールできます。または、特定のコードを記述して、依存関係をインストールするための クラスター スコープの初期化スクリプト を生成できます。

  3. スコアリング ジョブは、Python の依存関係をジョブ実行環境にインストールします。 Databricksでは、Model Registry を使用して推論用のノートブックを生成できます。これにより、これが自動的に行われます。

    • Databricks Model Registryを使用してスコアリング ノートブックを生成すると、ノートブックには、モデルのrequirements.txt ファイルにPython依存関係をインストールするコードが含まれます。バッチまたはストリーミング スコアリングのノートブック ジョブの場合、このコードはノートブック環境を初期化し、モデルの依存関係がインストールされ、モデルの準備が整うようにします。

  4. MLflow は、log_modelの code_path パラメーターに含まれる任意のカスタム Python コードを処理します。このコードは、モデルの predict() メソッドが呼び出されたときに Python パスに追加されます。 これは、次のいずれかの方法で手動で行うこともできます。

注記

code_path 引数を使用してモデルをログに記録するときに .py ファイルまたは Python wheel ファイルを指定した場合、MLflow はそれらの依存関係を自動的に読み込みます。

に最終更新