次の方法で共有

モザイク AI ベクター検索: コスト管理ガイド

この記事では、モザイク AI ベクター検索を使用するときにコストを効果的に管理する方法について説明します。 次のトピックについて説明します。

  • ベクター検索インデックスとエンドポイントの基本。
  • 課金と使用状況の監視。
  • 同期モード。
  • コストを最適化するためのベスト プラクティス。

モザイク AI ベクター検索の基本

モザイク AI ベクター検索は、次の要素で構成されます。

  • ベクター検索インデックス: インデックスは、検索と取得のためにベクトルを格納します。
  • ベクター検索エンドポイント: 各エンドポイントは、クエリを提供するための 1 つ以上のインデックスをホストします。 1 つのエンドポイントで複数のインデックスを提供でき、1 つのエンドポイントで最大 50 個のインデックスを提供できます。 多くの場合、1 つのエンドポイントで小規模なワークロードを組み合わせて合計コストを削減できます。

ベクター検索の価格の設定

Databricks には、次の 2 つのエンドポイント オプションがあります。

  • 標準エンドポイント。 1 つのベクトル検索ユニットは、次元 768 の最大 200 万のベクトル (またはそれに相当するもの) をカバーします。 たとえば、ディメンション 1536 の 100 万のベクトルがある場合、これは 1 つの単位としてもカウントされます。

  • ストレージ最適化エンドポイント。 1 つのベクトル検索ユニットは、次元 768 の最大 6,400 万ベクトル (またはそれに相当するもの) をカバーします。

どちらのオプションでも、各エンドポイントには基本価格があり、サービスされているインデックスの合計サイズに合わせて自動的にスケールアップされます。

  • 標準エンドポイントは自動的にスケールダウンされません。 ベクターを削除したり、インデックスのサイズを小さくしたりした場合でも、手動で変更を加えるまで、より高い容量に対する支払いを続けます。
  • ストレージ最適化エンドポイントは、インデックスが削除されると自動的にスケールダウンされます。 エンドポイントの最小サイズは、1 つのベクター検索単位です。

重要

標準エンドポイントは自動的にスケールダウンされません。 ベクター数が大幅に減少した場合 (たとえば、400 万から 150 万個のベクター)、エンドポイントを削除して新しいベクターを作成するまで、より高い容量 (この例では 2 つのベクター検索単位) の料金を引き続き支払います。 これは、標準エンドポイントに対してのみ当てはまります。 ストレージ最適化エンドポイントは自動的にスケールダウンされます。

使用状況とコストを監視する方法

Databricks には、ベクター検索の使用状況とコストを監視するのに役立つ課金対象の使用状況テーブル、使用状況ダッシュボード、予算ポリシーが用意されています。

課金対象の使用状況テーブル

課金対象の使用状況テーブルのクエリの例を次に示します。

WITH all_vector_search_usage AS (
  SELECT *,
         CASE WHEN usage_metadata.endpoint_name IS NULL THEN 'ingest'
              WHEN usage_type = "STORAGE_SPACE" THEN 'storage'
              ELSE 'serving'
         END as workload_type
    FROM system.billing.usage
   WHERE billing_origin_product = 'VECTOR_SEARCH'
),

daily_dbus AS (
  SELECT
    workspace_id,
    cloud,
    usage_date,
    workload_type,
    usage_metadata.endpoint_name as vector_search_endpoint,
    CASE WHEN workload_type = 'serving' THEN SUM(usage_quantity)
         WHEN workload_type = 'ingest' THEN SUM(usage_quantity)
         ELSE null
         END as dbus,
    CASE WHEN workload_type = 'storage' THEN SUM(usage_quantity)
         ELSE null
         END as dsus
  FROM all_vector_search_usage
  GROUP BY 1,2,3,4,5
  ORDER BY 1,2,3,4,5 DESC
)
SELECT * FROM daily_dbus;

課金対象の使用状況テーブルの詳細については、 課金対象の使用状況システム テーブルのリファレンスを参照してください。

追加のクエリは、次のノートブック例にあります。

ベクター検索システム テーブルクエリノートブック

ノートブックを入手

使用状況ダッシュボード

ベクター検索の使用状況など、コスト ドライバーに関する分析情報を得るためにインポートできる使用状況ダッシュボードについては、「 使用状況ダッシュボード」を参照してください。

予算ポリシー

予算ポリシーを使用すると、管理者はすべての Azure Databricks サーバーレス製品の課金レコードをグループ化してフィルター処理し、支出を追跡するための専用 UI を提供できます。 ベクター検索エンドポイントに予算ポリシーを適用する方法については、「 モザイク AI ベクター検索: 予算ポリシー」を参照してください。 予算ポリシーを作成および管理する方法に関する一般的な情報と詳細については、「 サーバーレス予算ポリシーを使用した属性の使用」を参照してください。

インデックス同期コストを管理する方法

インデックスを更新するように構成するには、次の 2 つの方法があります。

  • トリガーされた同期: API または Python SDK を呼び出してインデックスの更新をトリガーします。 これは最もコスト効率の高いオプションです。
  • 継続的同期: インデックスは、ほぼリアルタイムの待機時間でソース Delta テーブルからの変更で自動的に更新されます。 同期を処理するためにストリーミング クラスターがプロビジョニングされるため、コストが高くなります。待機時間が数秒のほぼリアルタイムの更新が重要でない場合は、トリガーされた同期を使用してコストを削減することを検討してください。

コスト管理のベスト プラクティス

  • 1 つのエンドポイントでワークロードを結合する: すべてのインデックスで最大 150 QPS 以下が予想される場合は、1 つのエンドポイントでインデックスを組み合わせて、複数のベース エンドポイント コストを回避できます。
  • 使用状況の監視: システム課金テーブルと組み込みの使用状況ダッシュボードを使用して、容量、使用量、コストを追跡します。
  • 手動でスケールダウンする: 上記で説明したように、ベクター数が不要になった以前の容量しきい値を下回った場合は、エンドポイントを削除して再作成する必要があります。
  • 適切な同期モードを選択します。可能な場合は、継続的同期ではなくトリガーされた同期を使用して、ストリーミング コストを削減します。

その他のリソース