モデルサービングエンドポイントでの AI Gateway の構成
この記事では、モデルサービングエンドポイントで Mosaic AI Gateway を設定する方法について説明します。
必要条件
- 外部モデルがサポートするリージョンまたはプロビジョニングされたスループットをサポートするリージョンの Databricks ワークスペース。
- A モデルサービング エンドポイント.
- 外部モデルのエンドポイントを作成するには、 外部モデルサービングエンドポイントの作成のステップ 1 と 2 を実行します。
- プロビジョニング スループットのエンドポイントを作成するには、「プロビジョニング スループット 基盤モデル APIsを参照してください。
UI を使用した AI Gateway の構成
このセクションでは、エンドポイントの作成時に Serving UI を使用して AI Gateway を設定する方法について説明します。 これをプログラムで行う場合は、 ノートブックの例を参照してください。
エンドポイント作成ページの [AI Gateway ] セクションでは、AI Gateway の機能を個別に構成できます。 外部モデルサービングエンドポイントで使用可能な機能のサポート対象およびプロビジョニング スループットエンドポイントを参照してください。
| 機能 | 有効にする方法 | 詳細 |
|---|---|---|
| 使用状況の追跡 | [ 使用状況の追跡を有効にする ] を選択して、データ使用量メトリクスの追跡と監視を有効にします。 | - Unity Catalog が有効になっている必要があります。 - アカウント 管理者は、エンドポイントへの各リクエストのトークン数をキャプチャするシステムテーブル: system.serving.endpoint_usage と、各基盤モデルのメタデータを格納する system.serving.served_entities を使用する前に、サービング システムテーブル スキーマを有効にする必要があります。 - 「使用状況追跡テーブルのスキーマ」を参照してください。 - エンドポイントを管理するユーザーが使用状況の追跡を有効にする必要がある場合でも、 served_entities テーブルまたは endpoint_usage テーブルを表示またはクエリするアクセス許可を持っているのはアカウント管理者のみです。 システムテーブルへのアクセス権限の付与を参照してください。 - 入力トークン数と出力トークン数は、モデルによってトークン数が返されない場合、(text_length+1)/4 として推定されます。 |
| ペイロードのロギング | [ 推論テーブルを有効にする ] を選択すると、エンドポイントからの要求と応答が Unity Catalog によって管理される Delta テーブルに自動的に記録されます。 | - Unity Catalog が有効になっていて、指定したカタログスキーマでアクセスCREATE_TABLE必要があります。 - AI Gateway によって有効化される推論テーブルは、カスタムモデルを提供するモデルサービングエンドポイント用に作成された推論テーブルとは異なるスキーマを持ちます。AI Gateway 対応推論テーブル スキーマをご覧ください。 - ペイロードのログデータは、エンドポイントにクエリを実行してから 1 時間以内にこれらのテーブルに入力されます。 - 1 MB を超えるペイロードはログに記録されません。 - 応答ペイロードは、返されたすべてのチャンクの応答を集約します。 - ストリーミングがサポートされています。 ストリーミング シナリオでは、応答ペイロードは返されたチャンクの応答を集計します。 |
| AIガードレール | 「UI での AI ガードレールの設定」を参照してください。 | - ガードレールは、モデルの入力および出力で検出された安全でない有害なコンテンツとモデルが相互作用するのを防ぎます。 - 出力ガードレールは、埋め込みモデルやストリーミングではサポートされていません。 |
| レート制限 | リクエスト レート制限 を適用して、エンドポイントのトラフィックをユーザーごとおよびエンドポイントごとに管理できます | - レート制限は、1 分あたりのクエリ数 (QPM) で定義されます。 - デフォルトは、ユーザーごとエンドポイントごとに 制限なし です。 |
| トラフィック ルーティング | エンドポイントでトラフィックルーティングを設定するには、「 エンドポイントに複数の外部モデルを提供する」を参照してください。 |
UI での AI ガードレールの構成
次の表は、 サポートされているガードレールを構成する方法を示しています。
| ガードレール | 有効にする方法 | 詳細 |
|---|---|---|
| 安全性 | [ 安全性 ] を選択すると、モデルが安全でない有害なコンテンツと相互作用するのを防ぐための保護機能が有効になります。 | |
| 個人を特定できる情報 (PII) の検出 | 名前、住所、クレジットカード番号などのPIIデータを検出するには、[ PII検出 ]を選択します。 | |
| 有効なトピック | このフィールドにトピックを直接入力できます。 複数のエントリがある場合は、各トピックの後に必ず Enter キーを押してください。 または、 .csv ファイルまたは .txt ファイルをアップロードすることもできます。 | 最大 50 個の有効なトピックを指定できます。 各トピックは 100 文字を超えることはできません |
| 無効なキーワード | このフィールドにトピックを直接入力できます。 複数のエントリがある場合は、各トピックの後に必ず Enter キーを押してください。 または、 .csv ファイルまたは .txt ファイルをアップロードすることもできます。 | 無効なキーワードは最大 50 個まで指定できます。 各キーワードは 100 文字を超えることはできません。 |
使用状況追跡テーブルのスキーマ
system.serving.served_entities使用状況追跡システムテーブルには、次のスキーマがあります。
| 列名 | 説明 | タイプ |
|---|---|---|
served_entity_id | 提供されたエンティティの一意の ID。 | 文字列 |
account_id | Delta Sharingの顧客 アカウント ID。 | 文字列 |
workspace_id | サービスエンドポイントの顧客ワークスペース ID。 | 文字列 |
created_by | 作成者の ID。 | 文字列 |
endpoint_name | 配信エンドポイントの名前。 | 文字列 |
endpoint_id | 配信エンドポイントの一意の ID。 | 文字列 |
served_entity_name | 提供されるエンティティの名前。 | 文字列 |
entity_type | 提供されるエンティティのタイプ。 FEATURE_SPEC、 EXTERNAL_MODEL、 FOUNDATION_MODEL、または CUSTOM_MODEL | 文字列 |
entity_name | エンティティの基になる名前。 ユーザーが指定した名前である served_entity_name とは異なります。 たとえば、 entity_name は Unity Catalog モデルの名前です。 | 文字列 |
entity_version | 提供されたエンティティのバージョン。 | 文字列 |
endpoint_config_version | エンドポイント設定のバージョン。 | INT |
task | タスクの種類。 llm/v1/chat、 llm/v1/completions、または llm/v1/embeddingsを指定できます。 | 文字列 |
external_model_config | 外部モデルの構成。 例えば {Provider: OpenAI} | 構造体 |
foundation_model_config | 基盤モデルの構成。 例えば{min_provisioned_throughput: 2200, max_provisioned_throughput: 4400} | 構造体 |
custom_model_config | カスタムモデルの設定。 例えば{ min_concurrency: 0, max_concurrency: 4, compute_type: CPU } | 構造体 |
feature_spec_config | 機能仕様の構成。 例えば { min_concurrency: 0, max_concurrency: 4, compute_type: CPU } | 構造体 |
change_time | 提供されたエンティティの変更のタイムスタンプ。 | Timestamp |
endpoint_delete_time | エンティティ削除のタイムスタンプ。 エンドポイントは、提供されるエンティティのコンテナです。 エンドポイントが削除されると、提供されたエンティティも削除されます。 | Timestamp |
system.serving.endpoint_usage使用状況追跡システムテーブルには、次のスキーマがあります。
| 列名 | 説明 | タイプ |
|---|---|---|
account_id | 顧客アカウント ID。 | 文字列 |
workspace_id | サービスエンドポイントの顧客ワークスペース ID。 | 文字列 |
client_request_id | モデルサービング要求本文で指定できるユーザー指定の要求識別子。 | 文字列 |
databricks_request_id | すべてのモデルサービング要求にアタッチされた Databricks 生成要求識別子。 | 文字列 |
requester | サービスエンドポイントの呼び出しリクエストにアクセス許可が使用されるユーザーまたはサービスプリンシパルの ID。 | 文字列 |
status_code | モデルから返された HTTP 状態コード。 | Integer |
request_time | 要求が受信されたタイムスタンプ。 | Timestamp |
input_token_count | 入力のトークン数。 | ロング |
output_token_count | 出力のトークン数。 | ロング |
input_character_count | 入力文字列またはプロンプトの文字数。 | ロング |
output_character_count | 応答の出力文字列の文字数。 | ロング |
usage_context | ユーザーは、エンドポイントへの呼び出しを行うエンド ユーザーまたは顧客アプリケーションの識別子を含むマップを提供しました。 usage_contextを使用した使用法の詳細な定義を参照してください。 | マップ |
request_streaming | 要求がストリーム・モードであるかどうか。 | ブール値 |
served_entity_id | エンドポイントと提供されるエンティティに関する情報を検索するために system.serving.served_entities ディメンション テーブルと結合するために使用される一意の ID。 | 文字列 |
使用法をさらに定義する usage_context
使用状況の追跡が有効になっている外部モデルに対してクエリを実行する場合は、 usage_context パラメーターに Map[String, String]型を指定できます。 使用状況コンテキスト マッピングは、使用状況追跡テーブルの usage_context 列に表示されます。 usage_contextマップサイズは 10 KiB を超えることはできません。
アカウント 管理者は、使用状況のコンテキストに基づいて異なる行を集計して知見を得ることができ、この情報をペイロードログテーブルの情報と結合することができます。 たとえば、エンドユーザーのコスト属性を追跡するための end_user_to_charge を usage_context に追加できます。
{
"messages": [
{
"role": "user",
"content": "What is Databricks?"
}
],
"max_tokens": 128,
"usage_context":
{
"use_case": "external",
"project": "project1",
"priority": "high",
"end_user_to_charge": "abcde12345",
"a_b_test_group": "group_a"
}
}
エンドポイントの AI Gateway 機能を更新する
AI Gateway の機能は、以前に有効になっていたモデルサービングエンドポイントと有効にしていなかったエンドポイントで更新できます。AI Gateway 構成の更新が適用されるまでに約 20 秒から 40 秒かかりますが、レート制限の更新には最大 60 秒かかる場合があります。
以下は、Serving UIを使用してモデルサービングエンドポイントの AI Gateway機能を更新する方法を示しています。
エンドポイント ページの [ゲートウェイ ] セクションでは、有効になっている機能を確認できます。 これらの機能を更新するには、[ AI Gateway の編集 ] をクリックします。
ノートブックの例
次のノートブックは、Databricks Mosaic AI Gateway 機能をプログラムで有効にして使用し、プロバイダーからのモデルを管理および制御する方法を示しています。 REST API の詳細については、以下を参照してください。