Databricks AI Gatewayのレート制限を整理してみる

はじめに

この記事は株式会社ナレッジコミュニケーションが運営するチャットボット と AIエージェント Advent Calendar 2025 の8日目にあたる記事になります!

Databricks とは?

Databricks は、データエンジニアリング/データサイエンス/BI/機械学習/生成 AI などを統合的に扱えるレイクハウスプラットフォームです。
Spark ベースの分散処理に加え、Unity Catalog によるデータ・権限管理、MLflow による MLOps、そして最近では各種 LLM を安全かつ一元的に扱うための機能が強化されています。

その「LLM を安全に使うための入り口」の一つが AI ゲートウェイ(AI Gateway) です。


Databricks AI ゲートウェイとは?

Databricks AI ゲートウェイは、以下のような用途のための「LLM 用プロキシ/ゲートウェイ」です。

  • Databricks から外部の LLM(例: OpenAI, Azure OpenAI, Google Gemini など)を一元的に呼び出す
  • モデルごとに API キー・エンドポイント URL を隠蔽し、利用者には統一されたエンドポイントだけを公開する
  • 利用ログの一元管理(監査・モニタリング)
  • レート制限や使用ポリシーの強制

特に、組織内で複数チーム・複数ユースケースが同じモデルを使う場合、

  • 誰がどれだけ使っているのか
  • コストをどう抑制するか
  • 誤った使い方をどう防ぐか

といった課題が出てきます。
AI ゲートウェイの レート制限(Rate Limit) 機能は、その対策として非常に重要です。


AI ゲートウェイのレート制限で何ができるか

AI ゲートウェイでは、エンドポイントごとに以下のようなレート制限を設定できます。

  • エンドポイント全体のレート制限
  • ユーザー(デフォルト)のレート制限
  • 特定ユーザー / グループ / サービスプリンシパルごとのレート制限

画面上では、各エンドポイントに対して「QPM」「TPM」を設定する欄があり、さらにユーザー/グループ単位で例外設定を追加できます。


レート制限の基本パラメータ:QPM と TPM

まずは用語の整理からです。

QPM(Queries Per Minute)

  • 意味:1 分あたりのリクエスト数(クエリ数)の上限
    • QPM = 10
      → そのエンドポイントに対して「1 分間に最大 10 回まで」API を呼び出せる

TPM(Tokens Per Minute)

  • 意味:1 分あたりに利用できるトークン数(入力+出力トークンの合計)の上限
    • TPM = 20,000
      → 1 分間に利用できるトークン数の合計(プロンプトのトークン+モデルからの出力トークン)を 20,000 までに制限

QPM / TPM を 0 にした場合

  • QPM = 0 または TPM = 0 に設定すると、そのエンドポイントは 呼び出し不可 になります。
  • 実質的に「即時停止」「利用禁止」に相当します。
  • 特に、デフォルトで利用可能なモデル(権限設定を細かく制御しづらいもの)に対しては、
    • 誤って組織全体から自由に叩かれる
    • 意図しない高額コストが発生する
      といったリスクを避けるために、QPM/TPM を 0 にして封じておく、という運用が有効です。

レート制限の適用レベル

レート制限は、以下の 3 レベルで設定できます。

  1. エンドポイント単位の制限
  2. ユーザー(デフォルト)の制限
  3. 個別のユーザー / グループ / サービスプリンシパルごとの制限

image.png

それぞれ見ていきます。

1. エンドポイント単位の制限

  • 対象:そのエンドポイントを通過する すべてのトラフィック
  • 機能:
    • QPM / TPM を設定して、エンドポイント全体の利用上限を決める
    • QPM = 0 / TPM = 0 を指定すると、エンドポイント全体を停止 したのと同じ状態になる

ポイント:
あらゆるユーザー/グループ設定よりも 優先される最上位の制限 です。
つまり、どんなユーザーにどんな例外設定を入れていても、エンドポイント単位で 0 を指定すれば全員が利用不可になります。

2. ユーザー(デフォルト)の制限

  • 対象:「そのエンドポイントに対して権限(Can Query / Can Manage)を持つすべてのユーザー」
  • 機能:
    • 個別設定がないユーザーに対して適用される デフォルトのユーザーごとの制限
    • 「特に細かいルールはないけれど、とりあえず全員 1 分あたり n 回まで」といった一律制限をかけたい場合に使う

3. 個別のユーザー / グループ / サービスプリンシパルごとの制限

  • 対象:
    • 特定のユーザー
    • 特定のグループ
    • 特定のサービスプリンシパル(マシンユーザー)
  • 機能:
    • ユーザーやグループ単位で、個別に QPM / TPM を指定できます
    • 「このチームだけ緩める」「このバッチ用のサービスプリンシパルだけ厳しくする」といった粒度で制御が可能

以下、レート制限に引っかかった際の出力

image.png


優先順位(どの設定が効くか)

複数のレベルで設定が重なった場合、どれが適用されるかを整理すると以下の通りです。

  1. エンドポイント単位設定
    • すべてのレベルに対して 上限として強制適用
    • ここでの QPM / TPM を超えて利用することはできない
  2. ユーザー個別設定
    • そのユーザーに対して最優先
    • グループ設定やユーザー(デフォルト)設定よりも優先される
  3. グループ設定
    • ユーザー個別設定がない場合に適用
  4. ユーザー(デフォルト)設定
    • 上記いずれの設定もない場合に適用される、最後のフォールバック

この優先順位があるため、例えば次のような状況が起こります。

  • グループ A に QPM = 100, TPM = 100 を設定
  • そのグループ A に所属するユーザー A に対して 個別設定で QPM = 0, TPM = 0 を設定

この場合:

  • グループ A はエンドポイントを利用可能(QPM=100, TPM=100)
  • しかしユーザー A には「個別設定」があるため、ユーザー A だけエンドポイントを呼び出せない

グループ運用を行う場合、意図せず個別設定を追加すると

「グループでは許可しているはずなのに、このユーザーだけ動かない」

という事象が起こるため、個別設定の扱いには注意が必要です。


ユースケース別:どう設定するか

これまでの内容を踏まえて、「こんな場合はどうする?」を整理しておきます。

1. エンドポイントの使用を完全に禁止したい場合(利用不可にしたい)

  • 対象:全ユーザー/全グループ
  • 設定:
    • エンドポイント単位
      • QPM = 0
      • TPM = 0
  • 効果:
    • 個別ユーザーやグループの設定に関係なく、全員が利用不可になる
  • 代表的な用途:
    • デフォルトで作成されるモデルエンドポイントを「使ってほしくない」状態にしておく
    • 一時的なメンテナンス・トラブル対応で即座に停止したい

2. エンドポイントの使用自体は許可しつつ、利用量を制限したい場合

  • 全員一律で制限したい場合:
    • ユーザー(デフォルト) に QPM / TPM を設定
      例:QPM = 10, TPM = 20,000
  • 特定ユーザー/グループ/サービスプリンシパルだけ制限したい場合:
    • 該当するユーザーやグループをレート制限設定に追加し、個別に QPM / TPM を設定

3. グループ運用を基本としつつ、一部ユーザーだけ例外的に禁止したい場合

  • 基本:
    • グループに対して QPM / TPM を設定して運用(ユーザー個別設定は追加しない)
  • 例外:
    • グループ内の特定ユーザーの利用を禁止したい場合のみ、そのユーザーをレート制限に追加し QPM=0, TPM=0 を設定

ケース別整理(一覧表)

「どの範囲のユーザーに対して」「どのレベルで」「どう制限するか」を表にすると次のようになります。
ここで、QPM/TPM=0 は「利用不可(即時停止)」、0 以外は 「利用量の制限(閾値設定)」 を表します。

# ケース 対象範囲 設定場所(左から優先度高い順)と方針 補足説明
エンドポイント ユーザー個別 グループ ユーザー(デフォルト)
1 全ユーザー共通で利用不可にしたい 全ユーザー / グループ 利用不可 (0) QPM=0 / TPM=0 を設定すると全員のアクセスを即時停止。全設定中で最優先。
2 全ユーザー共通で利用量を制限したい 全ユーザー / グループ 利用量制限 全員に共通の利用上限を設定。個別・グループ・デフォルト設定より優先される。
3 グループ内の特定ユーザーだけ利用不可(例外) グループの一部ユーザー 利用不可 (0) 利用量制限 or 利用可能 グループ設定が利用可能でも、このユーザーはアクセス不可。エンドポイント設定には劣るが、他設定より優先。
4 特定ユーザーだけ利用量を制限したい 特定ユーザー 利用量制限 該当ユーザーにのみトークン数またはリクエスト数上限を設定。グループ・デフォルト設定より優先適用。
5 特定グループのみ制限したい グループ単位 利用不可 or 利用量制限 利用不可 or 利用量制限 or 利用可能 指定したグループにのみ制限を適用。他グループや非所属ユーザーはデフォルト設定が適用される。
6 グループ管理を基本とし、個別設定を避けたい グループ全体 利用量制限 全員をグループに所属させ、グループ単位で制限を管理。ユーザー(デフォルト)は原則使用しない。
7 権限保持者全員を一律制限したい 権限を持つ全ユーザー 利用量制限 個別・グループ設定がない権限保持者全員に制限を適用。最下位優先度のため上位設定に上書きされる。


典型的な運用パターンの例

パターン A:とりあえず全員に緩めの制限をかける

  • ユーザー(デフォルト): QPM = 30, TPM = 50,000
  • グループ/ユーザー個別設定はなし

→ まずは全員にライトな制限をかけて様子を見るパターンです。
過剰利用やコスト増の兆候が見えてきたタイミングで、グループや個別設定を追加していくことができます。

パターン B:グループ単位でしっかり制御する

  • プロダクション向けグループ(例: prod-llm-users):
    • QPM = 60, TPM = 100,000
  • 検証用グループ(例: dev-llm-users):
    • QPM = 10, TPM = 20,000
  • ユーザー(デフォルト)は未設定(または厳しめ)

→ 本番系の利用者にはある程度の上限を与え、検証環境のユーザーには厳しめの上限を設定する構成です。
コスト管理や SLA を意識した運用に向きます。

パターン C:デフォルトモデルを封印しておく

  • デフォルトで作られる汎用エンドポイント:
    • エンドポイント単位で QPM = 0, TPM = 0
  • 実際に利用させたいエンドポイントだけ適切な QPM/TPM を設定し、グループ管理

→ 「デフォルトで誰でも叩けるようなモデル」は基本 OFF にしておき、運用管理者が設計したエンドポイントだけを使わせる構成です。
権限設定が細かくできないモデルの意図しない利用を防ぐ上で有効です。


まとめ

  • Databricks の AI ゲートウェイは、LLM 利用の一元管理・プロキシとして非常に強力な機能を提供します。
  • 特に レート制限(QPM / TPM) によって、
    • 過剰利用
    • コストの急増
    • 他ユーザーへの性能影響
      を予防できます。
  • レート制限は以下のレベルで設定可能で、優先順位があります。
    1. エンドポイント単位(最優先。0 を指定すると全停止)
    2. ユーザー個別
    3. グループ
    4. ユーザー(デフォルト)
  • グループ運用を基本にしつつ、必要な場合のみユーザー単体で例外を追加する、という形が管理しやすい構成です。
  • デフォルトで利用可能なモデルについては、必要に応じて QPM/TPM を 0 にし、「意図しない利用」を防ぐのがおすすめです。

今後、特定の業務やユーザーで過剰利用やコスト増、性能影響の懸念が出てきた際には、ここで整理したレート制限の仕組みを踏まえてポリシーを検討・適用していくとよいと思います。

この記事を書いた人

azure-recipe-user