カスタムモデルのデプロイ

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

カスタムモデルとは

モデルサービングは、任意のPythonモデルを本番運用グレードのAPIとしてデプロイできます。 Databricks では、このようなモデルを カスタム モデルと呼びます。 これらの機械学習モデルは、 Scikit-Learn、XGBoost、PyTorch、HuggingFace Transformersなどの標準の機械学習ライブラリを使用してトレーニングでき、任意の Python コードを含めることができます。

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

  1. ネイティブの MLflow 組み込みフレーバー または pyfunc を使用して、モデルまたはコードを MLflow 形式でログに記録します。

  2. モデルがログに記録されたら、Unity Catalog (推奨) またはワークスペース レジストリに登録します。

  3. ここから、モデルをデプロイしてクエリするためのモデルサービング エンドポイントを作成できます。

    1. 「カスタム モデルビング エンドポイントの作成」を参照してください。

    2. 「 カスタムモデルのサービングエンドポイントをクエリする」を参照してください。

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

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

重要

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

機械学習モデルのログ

モデルサービングの機械学習モデルをログに記録するには、さまざまな方法があります。 次の一覧は、サポートされているメソッドと例をまとめたものです。

  • 自動ロギング このメソッドは、Databricks Runtime for Machine を使用すると自動的に有効になります。

    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 上で実行されるようにコードが設定されていることを確認することが重要です。 MLflow は、PyTorch または Transformers フレーバーでログに記録されたモデルに対してこれを自動的に実行します。

ワークロードの種類

GPU インスタンス

メモリ

CPU

コンカレンシーあたり 4GB

GPU_SMALL

1xT4

16ギガバイト

GPU_MEDIUM

1xA10Gの

24ギガバイト

MULTIGPU_MEDIUM

4xA10G

96ギガバイト

GPU_MEDIUM_8

8xA10G

192ギガバイト

GPU_LARGE_8

8xA100-80GB

320ギガバイト

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

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

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

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

カスタム ライブラリまたはプライベート ライブラリをデプロイに追加できます。 「モデルサービングでのカスタム 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 を提供します。

デプロイ前の検証APIsには 、 MLflow Python APIとMLflow CLI 2 つがあります。

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

  • モデルサーバーにデプロイされるモデルの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"],
)

期待と制限

次のセクションでは、モデルサービングを使用してカスタムモデルを提供する際の既知の期待と制限について説明します。

エンドポイントの作成と更新に対する期待値

注：

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

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

Databricksは、新しいエンドポイントの準備ができるまで既存のエンドポイント構成を維持することにより、ダウンタイムなしでエンドポイントの更新を実行します。そうすることで、使用中のエンドポイントが中断されるリスクが軽減されます。

モデルの計算に 120 秒以上かかる場合、要求はタイムアウトします。 モデルの計算に 120 秒以上かかると思われる場合は、Databricks アカウント チームにお問い合わせください。

Databricks既存のモデルサーバー エンドポイントに対して、ダウンタイムなしのシステム更新とメンテナンスを定期的に実行します。 メンテナンス中に、Databricks はモデルをリロードし、モデルのリロードに失敗した場合はエンドポイントを「失敗」としてマークします。 カスタマイズしたモデルが堅牢で、いつでもリロードできることを確認してください。

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

注：

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

サービスエンドポイントは、トラフィックとプロビジョニングされた同時実行ユニットの容量に基づいて自動的にスケーリングされます。

  • プロビジョニングされた同時実行数: システムが処理できる並列要求の最大数。 プロビジョニングされたコンカレンシー = クエリ/秒 (QPS) * モデル実行時間 (秒) という式を使用して、必要なコンカレンシーを見積もります。

  • スケーリング動作: エンドポイントは、トラフィックの増加に合わせてほぼ即座にスケールアップし、トラフィックの減少に合わせて 5 分ごとにスケールダウンします。

  • ゼロにスケーリング: エンドポイントは、非アクティブな状態が 30 分間続いた後にゼロにスケールダウンできます。 ゼロにスケーリングした後の最初の要求では、"コールド スタート" が発生し、待機時間が長くなります。 レイテンシーの影響を受けやすいアプリケーションの場合は、この機能を効果的に管理するための戦略を検討してください。

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

GPU ワークロードでエンドポイントにサービスを提供する場合の制限事項は次のとおりです。

  • GPU サービス用のコンテナー イメージの作成には、モデルのサイズと GPU で提供されるモデルのインストール要件の増加により、CPU サービス用のイメージ作成よりも時間がかかります。

  • 非常に大規模なモデルをデプロイする場合、コンテナーのビルドとモデルのデプロイの期間が 60 分を超えると、デプロイ プロセスがタイムアウトすることがあります。 これが発生した場合は、プロセスの再試行を開始すると、モデルが正常にデプロイされます。

  • GPU サビングのオートスケールは、CPU サービングよりも時間がかかります。

  • GPU 容量は、ゼロにスケーリングする場合には保証されません。 GPU エンドポイントでは、ゼロにスケーリングした後の最初の要求に対して、非常に長い待機時間が予想される場合があります。

  • この機能は ap-southeast-1では使用できません。

Anaconda ライセンスの更新

以下の通知は、Anacondaをご利用のお客様向けです。

重要

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

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

MLflow v1.18 より前のモデルを、モデルの conda 環境から defaults チャネルを除外せずにログに記録した場合、そのモデルには、意図しない defaults チャネルへの依存関係がある可能性があります。 モデルにこの依存関係があるかどうかを手動で確認するには、記録済みモデルにパッケージchannelconda.yaml ファイル内の値を調べます。たとえば、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 の詳細については、使用しているモデル フレーバーの MLflow ドキュメント (log_model for Scikit-Learnなど) を参照してください。

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