カスタム モデルをデプロイする
この記事では、Databricks Model Serving を使用してカスタム モデルをデプロイするためのサポートについて説明します。 また、サポートされているモデル ログのオプション、コンピューティングの種類、提供用にモデルの依存関係をパッケージ化する方法、エンドポイントの作成とスケーリングに関する詳細も提供します。
カスタム モデルとは
Model Serving を使用すると、任意の Python モデルを運用グレードの API としてデプロイできます。 Databricks では、このようなモデルをカスタム モデルと呼びます。 これらの ML モデルは、scikit-learn、XGBoost、PyTorch、HuggingFace トランスフォーマーなどの標準 ML ライブラリを使用してトレーニングでき、任意の Python コードを含めることができます。
カスタム モデルをデプロイするには、
- ネイティブ MLflow の組み込みフレーバー または pyfunc を使用して、モデルまたはコードを MLflow 形式でログします。
- モデルがログされたら、それを Unity カタログ (推奨) またはワークスペース レジストリに登録します。
- ここから、モデルをデプロイしてクエリを実行するためのモデル提供エンドポイントを作成できます。
- 「カスタム モデル提供エンドポイントを作成する」を参照してください
- 「カスタム モデルのエンドポイントを提供するクエリ」をご覧ください。
Databricks でカスタム モデルを提供する方法に関する完全なチュートリアルについては、Model の提供に関するチュートリアルを参照してください。
Databricks では、生成 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())
シグネチャと入力の例
シグネチャと入力の例を 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)
コンピューティングの種類
Note
GPU モデルの提供はパブリック プレビュー段階です。
Databricks 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
。 - 次のいずれかです。
- モデルの
mlflow.pyfunc.PyFuncModel.predict()
呼び出しに想定される形式のinput_data
。 - 読み込まれ、
predict
の呼び出しに使用される入力データが含まれるファイルを定義するinput_path
。
- モデルの
csv
またはjson
形式のcontent_type
。- 予測をファイルに書き込む省略可能な
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
チャネルに依存している可能性があります。
モデルにこの依存関係があるかどうかを手動で確認するには、ログに記録されたモデルと共にパッケージ化された conda.yaml
ファイル内での channel
値を調べることができます。 たとえば、defaults
チャネルの依存関係を持つモデルの conda.yaml
は次のようになります。
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
でモデル レジストリにモデルを再登録できます。 これを行うには、log_model()
の conda_env
パラメーターでチャネルを指定します。
log_model()
API の詳細については、使用しているモデル フレーバー (scikit-learn の log_model など) の MLflow ドキュメントを参照してください。
conda.yaml
ファイルの詳細については、MLflow のドキュメントを参照してください。