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

この記事では 、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"],)

期待と制限

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

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

注:

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

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

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

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

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

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

注:

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

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

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

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

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

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

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

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

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

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

  • 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 のドキュメントを参照してください。