モデルサービングエンドポイントの高速展開
このページでは、モデルサービングEndpointでエクスプレスデプロイメントを使用する方法について説明します。エクスプレスデプロイメントは、デプロイメント時間を短縮し、モデルサービング環境をモデルトレーニング環境と同じに保ちます。
Expressデプロイメントは以前は レス最適化デプロイメントと呼ばれていました。
エクスプレスデプロイメントとは何ですか?
エクスプレスデプロイメントは、モデルの登録中に、Serverlessノートブック環境でモデルアーティファクトをパッケージ化してステージングします。これにより、Endpointのデプロイメントが迅速化され、トレーニングおよびサービング環境の一貫性が保たれます。
非エクスプレスデプロイメントでは、モデルアーティファクトと環境はデプロイメント時にコンテナにパッケージ化されるため、サービング環境がモデルトレーニング中に使用されたものと一致しない場合があります。
標準とエクスプレスデプロイメント
次の表は、標準デプロイメントとエクスプレスデプロイメントを比較したものです。
観点 | 標準デプロイメント | エクスプレスデプロイメント |
|---|---|---|
環境が構築されると | コンテナイメージはデプロイ時に構築されます。 | モデルを登録する際に、アーティファクトと環境がパッケージ化されます。 |
トレーニングとサービング環境 | サービング環境がトレーニング環境と一致しない場合があります。 | サービング環境は、登録元のノートブック環境と同じです。 |
デプロイメント速度 | 遅くなります。デプロイメントはコンテナイメージのビルドを待機します。 | より高速です。デプロイメントはコンテナイメージのビルドをスキップします。 |
登録速度 | 標準。 | モデルと環境のサイズに応じて、パッケージ化には数秒から1分かかります。 |
Deployment event log | コンテナイメージ作成イベントを表示します。 | コンテナイメージ作成イベントは表示されません。 |
Expressデプロイメントでは、1回限りのパッケージング作業がモデル登録に移行されます。これにより、モデルと環境のサイズに応じて、register_model呼び出しに数秒から1分追加されます。その代わりに、**デプロイメントが大幅に高速化されます**:コンテナイメージのビルドが完全にスキップされるためです。そのビルドもデプロイメント障害の一般的な原因(依存関係の解決、イメージビルドエラー)となります。そのため、それをスキップすると一連の問題を解消できます。Expressモデルのデプロイメントイベントlogには、コンテナのビルドイベントが含まれていません。
要件
エクスプレスデプロイメントEndpointは、モデルサービングEndpointと同じ要件があります。要件を参照してください。
加えて:
- モデルはカスタム モデルである必要があります。
- モデルは、バージョン3以降の Serverless Notebook で記録および登録されている必要があります。
- モデルは
mlflow>=3.12とともにログに記録され、登録されている必要があります。databricks-sdk>=0.102.0 - モデルはUnity Catalogに登録されている必要があります。サービングコンピュートは、モデルが登録された元のコンピュートと一致している必要があります。通常の Serverless ノートブックから登録して CPU でサービングすることも、Serverless GPU コンピュートから登録して GPU でサービングすることもできます。
- モデルの最大環境サイズは200GBです。
Expressデプロイメントを使用してGPUコンピュートでカスタムLLMを提供するには、カスタムモデルサービングでカスタムLLMをデプロイするを参照してください。
GPUにリランカーをデプロイします。
このチュートリアルでは、BAAI/bge-reranker-base をデプロイします。これは、ドキュメントがクエリーにどれだけ適切に回答するかを評価するクロスエンコーダ・リランカーです。環境をセットアップし、Logsを記録し、エクスプレスパッケージングを使用してモデルを登録し、Endpointをデプロイし、クエリーします。
GPU デプロイは、依存関係のバージョン競合のため、失敗することがよくあります。たとえば、torch と CUDA などです。Express Deployment は、これを解決するために次の2つの方法を提供します。
- 各Serverless GPU環境バージョンにプリインストールされている固定の公開ライブラリセットは、ノートブックと同じようにサービング時に存在します。つまり、環境バージョンもバージョンも同じです。これらのライブラリは再パッケージ化されません。
- ノートブックセッションでインストールする追加の依存関係(たとえば、
%pip installを使用)は、登録時にパッケージ化され、サービング時に復元されます。
これらのことを踏まえると、ノートブックで実行されるモデルは、配信後も動作し続けます。
ステップ1:Serverless GPUノートブックをセットアップします。
A10 GPUを搭載したServerless GPU コンピュート でノートブックを作成し、**環境バージョン 5、AI 環境**を選択します。 AI環境には、PyTorch および一般的な機械学習ライブラリ(torch、transformers など)が含まれています。正確なピン留めされたバージョンについては、Serverless GPU 環境バージョン 5 (プレビュー)を参照してください。
エクスプレス デプロイメントが必要とするパッケージをインストールします。
# Express deployment requires recent MLflow and Databricks SDK versions.
%pip install "mlflow>=3.12" "databricks-sdk>=0.102.0"
# Install the libraries your model needs. transformers is preinstalled in the
# v5 AI environment; install it explicitly because this model depends on it.
%pip install transformers
%restart_python
Serverless 環境を介して依存関係を宣言することもできますが、ノートブックにインストールするのが最も簡単な方法です。環境のピン留めされたバージョンに対して開発することで、ノートブック環境がサービング環境と一致するようにします。
このモデルはGPUで提供されているため、Serverless GPU ランタイムからLogsに記録して登録する必要があります。誤ってServerless CPU コンピュートからLogした場合、モデルはCPUの依存関係とともにパッケージ化され、GPUサービング Endpoint は起動に失敗します。ノートブックがGPUランタイムにない場合は早期に失敗するよう、以下のチェックを追加します。
import os
# This model is intended to be served on GPU, so we must log and register from a Serverless GPU runtime.
if not os.environ.get("DATABRICKS_ACCELERATOR"):
raise RuntimeError(
"This model MUST be logged+registered from a serverless GPU runtime, otherwise the correct dependencies will not be packaged for serving."
)
このチェックが必要なのは、リランカーがGPUで提供されているためです。CPUモデルには必要ありません。
ステップ2:MLflowでモデルをログに記録する
リランカーをtext-classificationパイプラインとしてロードし、ネイティブのmlflow.transformersフレーバーでLogsに記録します。ネイティブフレーバーはモデルのpip依存関係を自動的にキャプチャし、GPUで実行されます。pip_requirements、task、またはエントリポイントを設定する必要はありません。
import mlflow
from transformers import pipeline
# BAAI/bge-reranker-base is a cross-encoder reranker: it scores how well a document answers a query.
pipe = pipeline("text-classification", model="BAAI/bge-reranker-base")
model_info = mlflow.transformers.log_model(
transformers_model=pipe,
name="bge_reranker",
input_example={
"text": "What is Databricks?",
"text_pair": "Databricks is a data and AI company.",
},
)
log_modelのregistered_model_name引数を使用してモデルを登録しないでください。その引数はenv_packを受け入れないため、エクスプレスでないモデルを登録します。エクスプレスデプロイメントを有効にするには、env_packを受け入れるregister_model(ステップ3)を使用して別のステップで登録します。
ステップ3:エクスプレスパッケージングを使用してモデルをUnity Catalogに登録します。
モデルをUnity Catalogに登録し、env_packパラメーターを設定してエクスプレスデプロイメントを有効にします。これにより、モデルアーティファクトと、登録中にノートブックセッションに追加した依存関係がパッケージ化されるため、サービングは環境バージョンのプリインストールされたライブラリに加えてそれらを再利用します。
import mlflow
from mlflow.utils.env_pack import EnvPackConfig
mlflow.set_registry_uri("databricks-uc")
model_version = mlflow.register_model(
model_uri=model_info.model_uri,
name="main.default.bge_reranker",
env_pack=EnvPackConfig(name="databricks_model_serving"),
)
文字列のショートハンドenv_pack="databricks_model_serving"をEnvPackConfig(name="databricks_model_serving")の代わりに使用できます。インターネットアクセスがない、またはカスタムライブラリを持つワークスペースの場合、install_dependencies=Falseを設定します(「env_packパラメーター」を参照してください)。
登録にはdatabricks-sdk>=0.102.0が必要です。大規模なモデルアーティファクトをuploadするときに、以前のバージョンはタイムアウトする可能性があります。
ステップ 4: サービング Endpoint を作成する
Databricks SDK を使用して登録済みモデルをデプロイします。このデプロイステップは、他のカスタムモデルと同じです。ただし、登録ステップ (ステップ 3) のみが Express で異なります。
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import (
EndpointCoreConfigInput,
ServedEntityInput,
ServingModelWorkloadType,
)
ENDPOINT_NAME = "bge-reranker-endpoint"
w = WorkspaceClient()
w.serving_endpoints.create_and_wait(
name=ENDPOINT_NAME,
config=EndpointCoreConfigInput(
name=ENDPOINT_NAME,
served_entities=[
ServedEntityInput(
name="bge-reranker",
entity_name=model_version.name,
entity_version=model_version.version,
workload_type=ServingModelWorkloadType.GPU_SMALL,
workload_size="Small",
scale_to_zero_enabled=False,
)
],
),
)
create_and_wait Endpointの準備が完了するまでブロックします。このリランカーにはGPU_SMALLで十分です。サービングでは同じ環境バージョンが再利用され、ノートブックに追加した依存関係が復元されるため、提供されるモデルは、GPU の種類に関係なく、開発で使用したのと同じライブラリバージョンに対して実行されます。
Endpoint のデプロイ中に、Serving UI で Endpoint の **Events** tab を開きます。 これは Express Deployment であるため、イベント Logs にはコンテナイメージ作成イベントは表示されません (標準のデプロイでは、Container image creation initiated の後に Container image creation finished successfully が表示されます)。Endpoint が完了すると、その状態は **Ready** と表示されます。
ステップ 5: Endpoint をクエリーする
クロスエンコーダーはクエリーとドキュメントのスコアを比較するため、textとtext_pairフィールドを送信します。Databricks SDK または curl を使用して、プログラムでクエリーします。
- Databricks SDK
- curl
w.serving_endpoints.query(
name=ENDPOINT_NAME,
dataframe_records=[
{"text": "What is Databricks?", "text_pair": "Databricks is a data and AI company."},
],
)
curl -X POST \
-u "token:$DATABRICKS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"dataframe_records":[{"text":"What is Databricks?","text_pair":"Databricks is a data and AI company."}]}' \
https://<workspace-url>/serving-endpoints/bge-reranker-endpoint/invocations
Endpointは各クエリーとドキュメントのペアの関連性スコアを返します。スコアが高いほど一致度が高いことを示します。これらのスコアを使用して、候補ドキュメントを再ランク付けします。
ノートブックの例
このウォークスルーをエンドツーエンドで実行するには、次のノートブックをインポートします。
Express リランカースターターノートブック
env_packパラメーター
上記のクイックスタートは、GPUモデルのエクスプレスデプロイメントを示しています。エクスプレスデプロイメントはCPUモデルでも機能します。いずれの場合も、env_pack を register_model に渡すことで Express Deployment を有効にします。
import mlflow
from mlflow.utils.env_pack import EnvPackConfig
mlflow.register_model(
model_info.model_uri,
model_name,
env_pack=EnvPackConfig(name="databricks_model_serving"),
)
env_pack モデルのアーティファクトと、登録時にノートブックセッションに追加した依存関係をパックしてステージングするため、登録にはenv_packを使用しない呼び出しよりも時間がかかります。
EnvPackConfig install_dependenciesパラメーターを受け入れます(defaultでTrue)。Trueの場合、モデルの依存関係は現在の環境にインストールされ、環境が有効であることを確認します。
インターネットアクセスがないワークスペース、またはモデルがカスタムライブラリに依存している場合で、install_dependenciesがTrueの場合、登録に失敗することがあります。このような場合は、install_dependencies を False に設定します。
"databricks_model_serving"という文字列をEnvPackConfig(...)のショートカットとして置き換えることができます。EnvPackConfig(name="databricks_model_serving", install_dependencies=True)と同等です。