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

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

カスタムモデルとは

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

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

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

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

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

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

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

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

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

重要

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())
  

署名と入力の例

署名と入力の例を 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)

コンピュートタイプ

注：

GPU モデルサービングはパブリック プレビュー段階です。

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

ワークロードの種類	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 のドキュメントを参照してください。

関連リソース

• チュートリアル: カスタム モデルのデプロイとクエリ
• カスタムモデルサービングエンドポイントを作成する
• カスタムモデルのサービングエンドポイントをクエリする
• モデルサービングでのカスタムPythonライブラリの使用
• モデルサービングのカスタム成果物をパッケージ化する
• モデルサービングで Python コードをデプロイする
• モデルサービングエンドポイントに対する複数モデルのサービング
• モデルサービングエンドポイントからリソースへのアクセスの構成
• モデルサービングエンドポイントにインスタンスプロファイルを追加する
• サービス提供エンドポイントでのルート最適化の構成