カスタムモデルをデプロイする

[アーティクル]
12/18/2024

この記事では、Mosaic AI Model Serving を使用してカスタムモデルをデプロイするためのサポートについて説明します。また、サポートされているモデルログのオプション、コンピューティングの種類、提供用にモデルの依存関係をパッケージ化する方法、エンドポイントの作成とスケーリングに関する詳細も提供します。

カスタムモデルとは

Model Serving を使用すると、任意の Python モデルを運用グレードの API としてデプロイできます。 Databricks では、このようなモデルをカスタムモデルと呼びます。これらの ML モデルは、scikit-learn、XGBoost、PyTorch、HuggingFace トランスフォーマーなどの標準 ML ライブラリを使用してトレーニングでき、任意の Python コードを含めることができます。

カスタムモデルをデプロイするには、

ネイティブ MLflow の組み込みフレーバーまたは pyfunc を使用して、モデルまたはコードを MLflow 形式でログします。
モデルがログされたら、それを Unity カタログ (推奨) またはワークスペースレジストリに登録します。
ここから、モデルをデプロイしてクエリを実行するためのモデルサービングエンドポイントを作成できます。
1. 「カスタムモデルサービングエンドポイントを作成する」を参照してください
2. 「カスタムモデルのエンドポイントを提供するクエリ」をご覧ください。

Databricks でカスタムモデルを提供する方法に関する完全なチュートリアルについては、Model の提供に関するチュートリアルを参照してください。

Databricks では、生成 AI アプリケーションの生成 AI モデルの提供もサポートされています。サポートされているモデルとコンピューティングオファリングについては、Foundation Model API と外部モデルに関するページを参照してください。

重要

Anaconda に依存している場合は、サービス使用条件の通知で追加情報を確認してください。

ML モデルをログする

モデルの提供のために ML モデルをログするには、さまざまな方法があります。次のリストは、サポートされている方法と例をまとめたものです。

自動ログ この方法は、Databricks Runtime for ML を使用する場合に自動的に有効になります。

import mlflow
from sklearn.ensemble import RandomForestRegressor
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestRegressor()
model.fit(iris.data, iris.target)

MLflow の組み込みフレーバーを使用してログする。より詳細な制御のためにモデルを手動でログする場合は、この方法を使用できます。

import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestClassifier()
model.fit(iris.data, iris.target)

with mlflow.start_run():
    mlflow.sklearn.log_model(model, "random_forest_classifier")

pyfunc を使用したカスタムログ。この方法を使用すると、任意の Python コードモデルをデプロイしたり、モデルと共に追加のコードをデプロイしたりできます。

  import mlflow
  import mlflow.pyfunc

  class Model(mlflow.pyfunc.PythonModel):
      def predict(self, context, model_input):
          return model_input * 2

  with mlflow.start_run():
      mlflow.pyfunc.log_model("custom_model", python_model=Model())

HuggingFace からダウンロード. Hugging Face からモデルを直接ダウンロードし、そのモデルをログに記録してサービスを提供できます。例については、「ノートブックの例」を参照してください。

シグネチャと入力の例

シグネチャと入力の例を MLflow に追加することをお勧めします。シグネチャは、モデルを Unity Catalog にログするために必要です。

シグネチャの例を次に示します。

from mlflow.models.signature import infer_signature

signature = infer_signature(training_data, model.predict(training_data))
mlflow.sklearn.log_model(model, "model", signature=signature)

入力の例を次に示します。


input_example = {"feature1": 0.5, "feature2": 3}
mlflow.sklearn.log_model(model, "model", input_example=input_example)

コンピューティングの種類

Mosaic AI Model Serving には、モデルをデプロイするための CPU と GPU のさまざまなオプションが用意されています。 GPU を使用してデプロイする場合は、フレームワークによって提供されるメソッドを使用して、GPU で予測が実行されるようにコードが設定されていることを確認する必要があります。これは、PyTorch または Transformers フレーバーでログに記録されたモデルに対して、MLflow によって自動的に行われます。

ワークロードの種類	GPU インスタンス	memory
`CPU`		コンカレンシーあたり 4 GB
`GPU_SMALL`	1xT4	16GB
`GPU_LARGE`	1xA100	80GB
`GPU_LARGE_2`	2xA100	160GB

デプロイコンテナーと依存関係

デプロイ時に、運用グレードのコンテナーがビルドされ、エンドポイントとしてデプロイされます。このコンテナーには、MLflow モデルで自動的にキャプチャまたは指定されたライブラリが含まれます。

モデルを提供するコンテナーには事前にインストールされた依存関係が含まれていないため、必要な依存関係がすべてモデルに含まれていない場合、依存関係エラーが発生する可能性があります。モデルデプロイの問題が発生する場合、Databricks ではモデルをローカルでテストすることをお勧めしています。

パッケージとコードの依存関係

デプロイにカスタムまたはプライベートのライブラリを追加できます。「Model Serving でのカスタム Python ライブラリの使用」を参照してください。

MLflow ネイティブフレーバーモデルの場合、必要なパッケージの依存関係が自動的にキャプチャされます。

カスタム pyfunc モデルの場合、依存関係を明示的に追加できます。

パッケージの依存関係は、次を使用して追加できます。

pip_requirements パラメータ:

mlflow.sklearn.log_model(model, "sklearn-model", pip_requirements = ["scikit-learn", "numpy"])

conda_env パラメータ:


conda_env = {
    'channels': ['defaults'],
    'dependencies': [
        'python=3.7.0',
        'scikit-learn=0.21.3'
    ],
    'name': 'mlflow-env'
}

mlflow.sklearn.log_model(model, "sklearn-model", conda_env = conda_env)

自動的にキャプチャされる要件の他に追加の要件を含めるには、extra_pip_requirements を使用します。
```
mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])
```

コードの依存関係がある場合は、code_path を使用してそれらを指定できます。

  mlflow.sklearn.log_model(model, "sklearn-model", code_path=["path/to/helper_functions.py"],)

依存関係の検証

カスタム MLflow モデルをデプロイする前に、モデルが提供可能であることを確認することをお勧めします。 MLflow からは、デプロイ環境をシミュレートし、変更された依存関係のテストを可能にするモデル成果物を検証できる API が提供されます。

デプロイ前検証 API が 2 つあります。MLflow Python API と MLflow CLI です。

これらの API のいずれかを使用して次を指定できます。

モデル提供にデプロイされるモデルの model_uri。
次のいずれかです。
- モデルの input_data 呼び出しに想定される形式の mlflow.pyfunc.PyFuncModel.predict()。
- 読み込まれ、input_path の呼び出しに使用される入力データが含まれるファイルを定義する predict。
content_type または csv 形式の json。
予測をファイルに書き込む省略可能な output_path。このパラメーターを省略すると、予測が stdout に出力されます。
サービス提供の環境を構築するために使用される環境マネージャー (env_manager):
- 既定値は、virtualenv です。検証の提供に推奨されます。
- local は使用できますが、検証を提供する際にエラーが発生する可能性があります。一般的に、迅速なデバッグにのみ使用されます。
install_mlflow を使用し、環境内にある現在のバージョンの MLflow を仮想環境でインストールするかどうか。この設定の既定値は False です。
トラブルシューティングやデバッグのために、さまざまなバージョンのパッケージ依存関係を更新してテストするかどうか。これは、オーバーライド引数 pip_requirements_override を使用し、文字列の依存関係のオーバーライドまたは追加の一覧として指定できます。

次に例を示します。

import mlflow

run_id = "..."
model_uri = f"runs:/{run_id}/model"

mlflow.models.predict(
  model_uri=model_uri,
  input_data={"col1": 34.2, "col2": 11.2, "col3": "green"},
  content_type="json",
  env_manager="virtualenv",
  install_mlflow=False,
  pip_requirements_override=["pillow==10.3.0", "scipy==1.13.0"],
)

依存関係の更新

ログに記録されているモデルで指定された依存関係に問題がある場合、MLflow CLI または MLflow Python API の mlflow.models.model.update_model_requirements() を使用し、別のモデルをログに記録することなく、要件を更新できます。

次の例は、ログに記録されたモデルの pip_requirements.txt をインプレースで更新する方法を示しています。

指定したパッケージバージョンで既存の定義を更新したり、存在しない要件を pip_requirements.txt ファイルに追加したりできます。このファイルは、指定した model_uri の場所にある MLflow モデル成果物内にあります。

from mlflow.models.model import update_model_requirements

update_model_requirements(
  model_uri=model_uri,
  operation="add",
  requirement_list=["pillow==10.2.0", "scipy==1.12.0"],
)

想定と制限事項

以降のセクションでは、Model Serving を使用してカスタムモデルを提供するための既知の期待と制限事項について説明します。

エンドポイントの作成と更新での考慮事項

Note

このセクションの情報は、基盤モデルまたは外部モデルを提供するエンドポイントには適用されません。

新しく登録されたモデルバージョンをデプロイするには、モデルとそのモデル環境をパッケージ化し、モデルエンドポイント自体をプロビジョニングする必要があります。このプロセスには約 10 分かかる可能性があります。

Azure Databricks では、エンドポイントの更新がゼロダウンタイムで実行されます。これは、新しいエンドポイント構成の準備が完了するまで既存のものを維持することによって実現されます。これにより、使用中のエンドポイントの中断のリスクが軽減されます。

モデルの計算に 120 秒を超える時間がかかる場合、要求はタイムアウトになります。モデルの計算に 120 秒を超える時間がかかると思われる場合は、Azure Databricks アカウントチームにお問い合わせください。

Databricks は、既存の Model Serving エンドポイントで、ダウンタイムなしのシステム更新とメンテナンスを時折実行します。メンテナンス中、Databricks はモデルを再度読み込み、モデルの再読み込みに失敗した場合にエンドポイントを失敗としてマークします。カスタマイズしたモデルが堅牢であり、いつでも再読み込みできることを確認します。

エンドポイントのスケーリングの期待

Note

このセクションの情報は、基盤モデルまたは外部モデルを提供するエンドポイントには適用されません。

提供エンドポイントは、トラフィックとプロビジョニングされたコンカレンシーユニットの容量に基づいて自動的にスケーリングされます。

プロビジョニング済みコンカレンシー: システムが処理できる並列要求の最大数。プロビジョニング済みコンカレンシー = 1 秒あたりのクエリ数 (QPS) * モデルの実行時間 (秒) の式を使用して、必要なコンカレンシーを見積もります。
スケーリング動作: エンドポイントは、トラフィックが増加するとすぐにスケールアップし、トラフィックの減少に合わせて 5 分ごとにスケールダウンします。
ゼロへのスケール: エンドポイントは、非アクティブ状態が 30 分間続くとゼロにスケールダウンする場合があります。ゼロにスケーリングした後の最初の要求では "コールドスタート" が発生し、待機時間が長くなります。待機時間の影響を受けやすいアプリケーションの場合は、この機能を効果的に管理するための戦略を検討してください。

GPU ワークロードの制限事項

GPU ワークロードでエンドポイントを提供する場合の制限事項を次に示します:

GPU サービス提供用のコンテナーイメージの作成は、モデルサイズと GPU で提供されるモデルのインストール要件の増加により、CPU サービスのイメージ作成よりも時間がかかります。
非常に大規模なモデルをデプロイする場合、コンテナーのビルドとモデルデプロイが 60 分の期間を超えると、デプロイプロセスがタイムアウトする可能性があります。これが発生した場合は、プロセスの再試行を開始します。再試行によってモデルが正常にデプロイされます。
GPU サービスの自動スケールには、CPU サービスの場合よりも時間がかかります。
ゼロにスケーリングする際の GPU 容量は保証されません。 GPU エンドポイントでは、ゼロへのスケーリング後の最初の要求の待機時間が長くなることが予想されます。
この機能は、northcentralus では使用できません。

Anaconda ライセンスの更新

以下の通知は、Anaconda に依存しているお客様向けです。

重要

Anaconda Inc. は、anaconda.org チャネルのサービス利用規約を更新しました。 Anaconda のパッケージ化と配布に依存している場合は、新しいサービス利用規約に基づいて商用ライセンスが必要になることがあります。詳細については、「Anaconda Commercial Edition の FAQ」を参照してください。 Anaconda チャネルの使用には、同社のサービス使用条件が適用されます。

v1.18 (Databricks Runtime 8.3 ML 以前) より前にログに記録された MLflow モデルは既定で、conda defaults チャネル (https://repo.anaconda.com/pkgs/) を依存関係としてログに記録されていました。このライセンスの変更により、Databricks は MLflow v1.18 以降を使用してログに記録されたモデルの defaults チャネルの使用を停止しました。ログに記録された既定のチャネルは現在、conda-forge であり、これはコミュニティで管理されている https://conda-forge.org/ を指しています。

モデルの conda 環境から defaults チャネルを除外せずに MLflow v1.18 より前にモデルをログに記録した場合、そのモデルは意図していない defaults チャネルに依存している可能性があります。モデルにこの依存関係があるかどうかを手動で確認するには、ログに記録されたモデルと共にパッケージ化された channel ファイル内での conda.yaml 値を調べることができます。たとえば、conda.yaml チャネルの依存関係を持つモデルの defaults は次のようになります。

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

Databricks では、Anaconda リポジトリを使用してモデルを操作することが、Anaconda との関係の下で許可されているかどうか判断できないため、Databricks のお客様に変更を強制していません。 Databricks の使用を通じた Anaconda.com リポジトリの使用が、Anaconda の条件下で許可されている場合は、何も行う必要はありません。

モデルの環境で使用されるチャネルを変更する場合は、新しい conda.yaml でモデルレジストリにモデルを再登録できます。これを行うには、conda_env の log_model() パラメーターでチャネルを指定します。

log_model() API の詳細については、使用しているモデルフレーバー (scikit-learn の log_model など) の MLflow ドキュメントを参照してください。

conda.yaml ファイルの詳細については、MLflow のドキュメントを参照してください。

次の方法で共有

カスタムモデルをデプロイする

カスタムモデルとは

ML モデルをログする

シグネチャと入力の例

コンピューティングの種類

デプロイコンテナーと依存関係

パッケージとコードの依存関係

依存関係の検証

依存関係の更新

想定と制限事項

エンドポイントの作成と更新での考慮事項

エンドポイントのスケーリングの期待

GPU ワークロードの制限事項

Anaconda ライセンスの更新

その他のリソース

フィードバック

その他のリソース

次の方法で共有

カスタム モデルをデプロイする

カスタム モデルとは

ML モデルをログする

シグネチャと入力の例

コンピューティングの種類

デプロイ コンテナーと依存関係

パッケージとコードの依存関係

依存関係の検証

依存関係の更新

想定と制限事項

エンドポイントの作成と更新での考慮事項

エンドポイントのスケーリングの期待

GPU ワークロードの制限事項

Anaconda ライセンスの更新

その他のリソース

フィードバック

その他のリソース

カスタムモデルをデプロイする

カスタムモデルとは

デプロイコンテナーと依存関係