メインコンテンツまでスキップ

カスタムモデルの概要

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

カスタムモデルとは?​

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

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

  1. ネイティブの MLflow 組み込みフレーバー または pyfunc を使用してモデルまたはコードを MLflow 形式でログに記録します。
  2. モデルがログに記録されたら、 Unity Catalogに登録する 。
  3. ここから、モデルをデプロイしてクエリを実行するためのモデルサービングエンドポイントを作成できます。
    1. カスタム モデルサービング エンドポイントを作成するを参照してください。
    2. カスタムモデルのクエリサービングエンドポイントを参照してください。

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

Databricks 、生成AIアプリケーションの基盤モデルの提供もサポートしています。 Mosaic AI Model Servingでサポートされる基盤モデル」を参照してください。

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

シグネチャと入力の例​

シグネチャと入力の例を 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_MEDIUM

1xL4

24ギガバイト

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

デプロイ中に、本番運用グレードのコンテナが構築され、エンドポイントとしてデプロイされます。 このコンテナーには、MLflow モデルで自動的にキャプチャまたは指定されたライブラリが含まれます。基本イメージにはシステム レベルの依存関係がいくつか含まれる場合がありますが、アプリケーション レベルの依存関係は MLflow モデルで明示的に指定する必要があります。

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

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

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

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

カスタムpyfuncモデルの場合、依存関係を明示的に追加できます。ログ記録の要件とベスト プラクティスの詳細については、 MLflowモデルのドキュメントとMLflow Python APIリファレンスを参照してください。

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

  • 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"],)

デプロイ前の依存関係の検証と更新の詳細については、 「モデル デプロイ前の検証チェック」を参照してください。

期待と制限​

注記

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

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

エンドポイントの作成と更新の期待​

  • デプロイ時間 : 新しく登録されたモデル バージョンをデプロイするには、モデルとそのモデル環境をパッケージ化し、モデル エンドポイント自体をプロビジョニングする必要があります。このプロセスには約 10 分かかりますが、モデルの複雑さ、サイズ、依存関係によってはさらに時間がかかる場合があります。
  • ゼロダウンタイム更新 : Databricks は、新しいエンドポイント構成が準備されるまで既存のエンドポイント構成を維持することにより、エンドポイントのゼロダウンタイム更新を実行します。これにより、使用中のエンドポイントの中断のリスクが軽減されます。この更新プロセス中は、移行が完了するまで、古いエンドポイント構成と新しいエンドポイント構成の両方に対して課金されます。
  • リクエストのタイムアウト : モデルの計算に 297 秒以上かかる場合、リクエストはタイムアウトになります。
important

Databricks 、既存のモデルサービング エンドポイントでダウンタイムなしのシステム更新とメンテナンスを不定期に実行します。 メンテナンス中、Databricks はモデルを再読み込みします。モデルの再読み込みに失敗した場合、エンドポイントの更新は失敗としてマークされ、既存のエンドポイント構成が引き続きリクエストを処理します。カスタマイズされたモデルが堅牢であり、いつでもリロードできることを確認してください。

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

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

  • プロビジョニングされた同時実行性: システムが処理できる並列リクエストの最大数。プロビジョニングされた同時実行数 = 1 秒あたりのクエリ数 (QPS) * モデル実行時間 (秒) という式を使用して、必要な同時実行数を見積もります。同時実行構成を検証するには、 「サービス エンドポイントの負荷テスト」を参照してください。
  • スケーリング動作： エンドポイントはトラフィックが増えるとすぐにスケールアップし、トラフィックの減少に合わせて5分ごとにスケールダウンします。
  • ゼロにスケール: ゼロにスケールはエンドポイントのオプション機能であり、30 分間の非アクティブ状態後にゼロにスケールダウンできます。ゼロにスケーリングした後の最初のリクエストでは「コールド スタート」が発生し、レイテンシが高くなります。ゼロからのスケールアップには通常 10 ～ 20 秒かかりますが、場合によっては数分かかることもあります。ゼロレイテンシーからのスケールには SLA はありません。
  • ルート最適化: 高 QPS と低レイテンシのユースケースでは、パフォーマンスを向上させるためにルート最適化が最適かつ推奨されるオプションです。
警告

一貫した稼働時間または保証された応答時間を必要とする本番運用ワークロードには、ゼロへのスケールを使用しないでください。 レイテンシの影響を受けやすいアプリケーションや継続的な可用性を必要とするエンドポイントの場合は、ゼロへのスケールを無効にします。

GPU ワークロードの制限​

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

  • GPU サービング用のコンテナイメージの作成は、モデルサイズと GPU サービングモデルのインストール要件の増加により、CPU サービング用のイメージ作成よりも時間がかかります。
  • 非常に大規模なモデルをデプロイする場合、コンテナのビルドとモデルのデプロイの所要時間が 60 分を超えると、デプロイ プロセスがタイムアウトする可能性があります。
  • GPU サービングのオートスケールは、CPU サービングよりも時間がかかります。
  • GPU 容量は、ゼロにスケーリングする場合、保証されません。 GPU エンドポイントでは、ゼロにスケーリングした後の最初の要求に対して、追加の高レイテンシが予想される場合があります。

レガシーモデルに対するAnacondaライセンス通知​

注記

このセクションは、MLflow v1.17 以前 (Databricks Runtime 8.3 ML 以前) でログに記録されたモデルにのみ適用されます。新しいバージョンを使用している場合は、このセクションをスキップできます。

次の通知は、レガシー モデルで Anaconda に依存している顧客向けです。

important

株式会社Anacondaは、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 のドキュメントを参照してください。

追加のリソース​

に最終更新