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

この記事では、 を使用した カスタムモデルの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 アプリケーションのサービング基盤モデルもサポートしています 。基盤モデル API およびサポートされているモデルとコンピュート オファリングに関して 外部モデル を参照してください。

important

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

ML モデルのログ記録

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

• オートロギング この方法は、Databricks Runtime for ML を使用すると自動的に有効になります。

  Python

  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 の組み込みフレーバーを使用して記録します 。 この方法は、より詳細な制御のためにモデルを手動で記録する場合に使用できます。

  Python

  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 コード モデルをデプロイしたり、モデルと共に追加のコードをデプロイしたりできます。

  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 に記録するために必要です。

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

Python

from mlflow.models.signature import infer_signature

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

以下は入力例です。

Python

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ギガバイト

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

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

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

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

カスタムライブラリまたはプライベートライブラリをデプロイメントに追加できます。 モデルサービングでカスタムPythonライブラリを使用するを参照してください。

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

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

パッケージの依存関係は、次のようにして追加できます。

• pip_requirements パラメーターは、次のとおりです。

  Python

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

• conda_env パラメーターは、次のとおりです。

  Python

  
  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 を使用してください。

  Python

  mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])

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

Python

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

依存関係の検証

カスタム MLflow モデルをデプロイする前に、モデルが提供できることを確認すると便利です。 MLflow は、デプロイ環境をシミュレートし、変更された依存関係のテストを可能にするモデル アーティファクトの検証を可能にする API を提供します。

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

これらの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です。

• トラブルシューティングまたはデバッグのために、パッケージの依存関係の異なるバージョンを更新してテストするかどうか。 これを文字列の依存関係のオーバーライドまたは追加のリストとして指定するには、override 引数 pip_requirements_overrideを使用します。

例えば：

Python

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.models.model.update_model_requirements()またはMLflow Python API を使用して要件を更新できます。

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

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

Python

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 はモデルを再読み込みし、モデルの再読み込みに失敗した場合はエンドポイントを [失敗] としてマークします。 カスタマイズしたモデルが堅牢で、いつでもリロードできることを確認してください。

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

注記

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

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

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

GPU ワークロードの制限

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

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

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

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

• GPU 容量は、ゼロにスケーリングする場合、保証されません。 GPU エンドポイントでは、ゼロにスケーリングした後の最初の要求に対して、追加の高レイテンシが予想される場合があります。

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

Anacondaのライセンスアップデート

以下のお知らせは、Anacondaをご利用いただいているお客様向けです。

important

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

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

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

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 a scikit-learnなど)を参照してください。

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

追加のリソース

• カスタム モデルサービング エンドポイントの作成
• カスタムモデルのサービングエンドポイントをクエリする
• モデルサービングのデバッグガイド
• モデルサービングでのカスタムPythonライブラリの使用
• Model Servingのカスタムアーティファクトをパッケージ化する
• モデルサービングを使用したPythonコードのデプロイ
• サービングエンドポイントのルート最適化設定
• モデルサービスエンドポイントからリソースへのアクセスの構成
• モデルサービングエンドポイントにインスタンスプロファイルを追加する