モデルサービングのデバッグガイド
プレビュー
Mosaic AI Model Serving は パブリック プレビュー 段階にあり、 us-east1
と us-central1
でサポートされています。
この記事では、モデルサービング エンドポイントを操作するときにユーザーが遭遇する可能性のある一般的な問題のデバッグ ステップについて説明します。 一般的な問題には、エンドポイントの初期化または開始に失敗したときにユーザーが遭遇するエラー、コンテナーに関連するビルド エラー、エンドポイントでのモデルの操作または実行中の問題などがあります。
ログへのアクセスとレビュー
Databricks では、モデルサービングワークロードのデバッグとエラーのトラブルシューティングについてビルドログを確認することをお勧めします。 ログとその表示方法については、「 モデルの品質とエンドポイントの正常性の監視 」を参照してください。
注:
モデル コードで MlflowException
エラーが返される場合は、応答コードが 4xx
応答にマップされることを想定してください。 Databricks では、これらのモデル コード エラーは、結果のエラー メッセージに基づいて解決できるため、顧客によるエラーと見なします。 5xx
エラーコードは、Databricks に障害がある場合にエラーを伝達するために予約されています。
ワークスペース UI でモデルのイベント ログを確認し、コンテナーのビルド メッセージが成功したかどうかを確認します。 1 時間経ってもビルド メッセージが表示されない場合は、Databricks サポートにお問い合わせください。
ビルドは成功したが、他のエラーが発生した場合は、「 コンテナのビルドが成功した後のデバッグ」を参照してください。 ビルドが失敗した場合は、「 コンテナのビルド失敗後のデバッグ」を参照してください。
インストールされているライブラリパッケージのバージョン
ビルド ログでは、インストールされているパッケージのバージョンを確認できます。
MLflowバージョンでは、バージョンが指定されていない場合、モデルサービングは最新バージョンを使用します。
flash-attn
が必要な記録済みモデル
flash-attn
が必要なモデルをログに記録する場合、Databricks では のカスタム ホイール バージョンを使用することをお勧めします flash-attn
。そうしないと、 ModuleNotFoundError: No module named 'torch'
などのビルド エラーが発生する可能性があります。
flash-attn
のカスタムホイールバージョンを使用するには、すべての pip 要件をリストとして指定し、それをパラメーターとして mlflow.transformers.log_model
関数に渡します。また、 ホイールで指定されているPyTorch バージョンと互換性のある 、torch、およびtorchvisionのバージョンも指定する必要があります。CUDAflash attn
たとえば、Databricks では、CUDA 11.8 に次のバージョンとホイールを使用することをお勧めします。
logged_model=mlflow.transformers.log_model(
transformers_model=test_pipeline,
artifact_path="artifact_path",
pip_requirements=["--extra-index-url https://download.pytorch.org/whl/cu118", "mlflow==2.13.1", "setuptools<70.0.0", "torch==2.0.1+cu118", "accelerate==0.31.0", "astunparse==1.6.3", "bcrypt==3.2.0", "boto3==1.34.39", "configparser==5.2.0", "defusedxml==0.7.1", "dill==0.3.6", "google-cloud-storage==2.10.0", "ipython==8.15.0", "lz4==4.3.2", "nvidia-ml-py==12.555.43", "optree==0.12.1", "pandas==1.5.3", "pyopenssl==23.2.0", "pytesseract==0.3.10", "scikit-learn==1.3.0", "sentencepiece==0.1.99", "torchvision==0.15.2+cu118", "transformers==4.41.2", "https://github.com/Dao-AILab/flash-attention/releases/download/v2.5.8/flash_attn-2.5.8+cu118torch2.0cxx11abiFALSE-cp311-cp311-linux_x86_64.whl"],
input_example=input_example,
registered_model_name=registered_model_name)
モデルデプロイの検証チェックの前に
Databricks では、モデルを提供する前に、このセクションのガイダンスを適用することをお勧めします。 次のパラメーターは、エンドポイントを待つ前に問題を早期にキャッチできます。 モデルをデプロイする前にモデル入力を検証するには、「 デプロイ前にモデル入力を検証する 」を参照してください。
デプロイ前に予測をテストする
モデルをサービス エンドポイントにデプロイする前に、 mlflow.models.predict
と入力の例を使用して、仮想環境でオフライン予測をテストします。 詳細なガイダンスについては 、予測のテストに関する MLflow のドキュメント を参照してください。
input_example = {
"messages":
[
{"content": "How many categories of products do we have? Name them.", "role": "user"}
]
}
mlflow.models.predict(
model_uri = logged_chain_info.model_uri,
input_data = input_example,
)
デプロイ前にモデルの入力を検証する
モデルサービングエンドポイントは、デプロイ前にモデル入力がサービングエンドポイントで動作することを検証するために、特別な形式の json
入力を想定しています。 MLflow の validate_serving_input
を使用して、このような検証を行うことができます。
以下は、モデルが有効な入力例でログに記録されている場合に、実行の [アーティファクト] タブで自動生成されるコードの例です。
from mlflow.models import validate_serving_input
model_uri = 'runs:/<run_id>/<artifact_path>'
serving_payload = """{
"messages": [
{
"content": "How many product categories are there?",
"role": "user"
}
]
}
"""
# Validate the serving payload works on the model
validate_serving_input(model_uri, serving_payload)
また、convert_input_example_to_serving_input
API を使用して有効な JSON サービング入力を生成することにより、記録済みモデルに対して任意の入力例をテストすることもできます。
from mlflow.models import validate_serving_input
from mlflow.models import convert_input_example_to_serving_input
model_uri = 'runs:/<run_id>/<artifact_path>'
# Define INPUT_EXAMPLE with your own input example to the model
# A valid input example is a data instance suitable for pyfunc prediction
serving_payload = convert_input_example_to_serving_input(INPUT_EXAMPLE)
# Validate the serving payload works on the model
validate_serving_input(model_uri, serving_payload)
コンテナのビルドが成功した後のデバッグ
コンテナが正常にビルドされた場合でも、モデルの実行時やエンドポイント自体の操作中に問題が発生する可能性があります。 次のサブセクションでは、一般的な問題と、トラブルシューティングとデバッグの方法について説明します
依存関係がない
An error occurred while loading the model. No module named <module-name>.
のようなエラーが表示される場合があります。このエラーは、依存関係がコンテナーに存在しないことを示している可能性があります。 コンテナのビルドに含める必要があるすべての依存関係を適切に示していることを確認します。 カスタムライブラリに特に注意を払い、 .whl
ファイルがアーティファクトとして含まれていることを確認してください。
サービスログのループ
コンテナのビルドが失敗した場合は、サービスログをチェックして、エンドポイントがモデルを読み込もうとしたときにループしているかどうかを確認します。 この動作が見られる場合は、次の手順を試してください。
ノートブックを開き、機械学習用のDatabricks Runtimeではなく、Databricks Runtimeバージョンを使用するAll-Purposeクラスターにアタッチします。
MLflow を使用してモデルを読み込み、そこからデバッグを試みます。
また、モデルをPCにローカルに読み込み、そこからデバッグすることもできます。 以下を使用してモデルをローカルに読み込みます。
import os
import mlflow
os.environ["MLFLOW_TRACKING_URI"] = "databricks://PROFILE"
ARTIFACT_URI = "model_uri"
if '.' in ARTIFACT_URI:
mlflow.set_registry_uri('databricks-uc')
local_path = mlflow.artifacts.download_artifacts(ARTIFACT_URI)
print(local_path)
conda env create -f local_path/artifact_path/conda.yaml
conda activate mlflow-env
mlflow.pyfunc.load_model(local_path/artifact_path)
エンドポイントにリクエストが送信されるとモデルが失敗する
モデルで predict()
が呼び出されると、Encountered an unexpected error while evaluating the model. Verify that the input is compatible with the model for inference.
のようなエラーが表示される場合があります。
predict()
関数にコードの問題があります。Databricks では、MLflow からモデルをノートブックに読み込んで呼び出すことをお勧めします。 これにより、 predict()
関数の問題が強調表示され、メソッド内のどこでエラーが発生しているかを確認できます。