すべてのプロダクト
Search
ドキュメントセンター

Platform For AI:LLM インテリジェントルーティングワークベンチ

最終更新日:Sep 02, 2026

WebUI ワークベンチは、LLM のインテリジェントルーティングを視覚的に管理するためのインターフェイスです。ロールベースのユーザー管理、独立した API キーの割り当て、リアルタイムモニタリング、設定のホットアップデートを提供します。これにより、ユーザーのアイデンティティ分離とアクセス監査を実現し、運用の複雑さを軽減します。

機能の概要

ワークベンチでは、必要に応じてユーザー管理機能を有効化できます。この機能を無効にすると、ワークベンチには次のモジュールが表示されます。

  • リアルタイムモニタリング:スループット、レイテンシー、TTFT などのほぼリアルタイムのパフォーマンスメトリクスに加え、ステータスコードの分布や、ゲートウェイ、スケジューラ、推論インスタンスの稼働状況を表示します。これにより、異常を素早く検知し、パフォーマンスのボトルネックを特定できます。

  • 設定センター:トラフィック分割プロキシ、スケジューリングポリシー、リクエストレート制限、トラフィックミラーリングなど、コアパラメーターのホットアップデートをサポートします。変更はサービスを再起動することなく即時反映されるため、本番環境での動的なチューニングに適しています。詳細については、「設定センター」をご参照ください。

  • スマートチャット:チャットテスト用の視覚的なインターフェイスを提供します。テキストまたは画像のリクエストを LLM インテリジェントルーティングサービスに直接送信し、HTTP ログを使用してデバッグできます。これにより、トラフィック分割プロキシの動作を迅速に検証できます。

ユーザー管理を有効化すると、包括的なユーザーシステムが作成され、複数のチームで LLM サービスを共有する企業に最適です。この場合、次のモジュールが追加されます。

  • データ概要:ユーザーおよび部門別に、トークン消費量とリクエスト数の分布を表示します。時間範囲とユーザーディメンションでデータをフィルターすることで、管理者が高使用量のユーザーを特定しやすくなります。

  • ユーザー管理:ユーザーの作成、取得、更新、削除に加え、有効化/無効化や API キーの管理ができます。これらの操作は API 経由でも実行できます。詳細については、「ユーザー管理 API リファレンス」をご参照ください。

  • 監査ログ:ログイン/ログアウト、ユーザー変更、API キーのリセット、設定変更などの管理操作を記録します。各操作について、時刻、操作者、リソースオブジェクトをログに記録します。コンプライアンス監査や問題の追跡のために、時刻、操作タイプ、操作者でログをフィルタリングできます。

  • ユーザーセンター:ユーザーはプロフィールの管理、自身の API キーの確認とリセット、個人のリクエスト統計およびトークン消費量の記録の確認ができます。

各ロールで利用可能なモジュールは次のとおりです。

ロール

権限

一般ユーザー

スマートチャット、ユーザーセンター (個人統計の表示)

管理者

一般ユーザーのすべての権限に加え、次の機能も利用できます:データ概要 (すべてのユーザー統計の表示)、リアルタイムモニタリング、設定センター (読み取り専用)

システム管理者

管理者のすべての権限に加え、次の機能も利用できます:ユーザー管理、監査ログ、設定センター (読み取り/書き込み)

ワークベンチへのアクセス

前提条件:LLM インテリジェントルーティングサービス、または LLM インテリジェントルーティングサービスを含む集約サービスをデプロイ済みであること。

手順:

  1. PAI コンソールにログインし、EAS 推論サービスのタブに移動します。

  2. 対象の LLM インテリジェントルーティングサービスを見つけます。

  3. サービスの [Invocation / Logs / Monitoring] 列で、[Web アプリ] アイコンをクリックします。

  4. ポップアップウィンドウで WebUI ワークベンチを見つけ、管理者ワークベンチを開きます。

    管理者が [ユーザー管理] ページでユーザーを作成すると、ユーザーは API キーを使用して [ユーザーログインポータル] から WebUI ワークベンチにログインできます。

設定センター

設定センターは、LLM インテリジェントルーティングのコア設定のホットアップデートをサポートします。変更はサービスを再起動することなく即時反映されます。次の図は、各設定が適用されるステージを示します。

image

設定タイプ

説明

スケジューリングポリシー

推論インスタンスにリクエストをスケジューリングするためのポリシーを設定します。PD 分離モードでは、Prefill フェーズと Decode フェーズに対して個別のポリシーを設定できます。

モデルルーティング

リクエスト内の model フィールドに基づき、対応するインスタンスにリクエストをルーティングします。モデルに一致する設定が見つからない場合、リクエストは設定されたデフォルトモデルで処理されます。

トラフィック分割プロキシ

モデルのプレフィックスまたは重みに基づき、設定された外部アップストリーム API サービスにリクエストを転送します。

リクエストレート制限

バックエンドリクエストの同時実行数を制限します。制限を超過した場合、リクエストを即時に拒否するか、キューに入れるかを選択できます。ライフサイクル全体、Prefill フェーズ、Decode フェーズそれぞれに個別の同時実行数制限を設定できます。

DashScope など、トラフィック分割プロキシで指定した外部サービスには各サービス独自のスロットリングルールが適用され、この設定の影響を受けません。

トラフィックミラーリング

本番トラフィックの一定割合をターゲットアドレスにコピーします。これは、カナリア検証、性能比較、またはデータ収集に使用でき、通常の応答には影響しません。

グローバルスケジューリング

現在のリージョンで推論リソースが不足している場合、スケジューラは他のアイドル状態のリージョンにある推論サービスインスタンスにトラフィックをルーティングします。これにより、グローバルなコンピュートプーリングと効率的なリソース再利用を実現します。

ユーザー管理 API リファレンス

認証:すべての API 呼び出しでは、リクエストヘッダーにシステム管理者の API キーを含める必要があります: Authorization: Bearer <admin_api_key>。

呼び出し時は、例に含まれる https://gateway.example.com を、http://xxx.cn-shanghai.pai-eas.aliyuncs.com/api/predict/ai_assistant.ai_gw などの LLM インテリジェントルーティングのエンドポイントに置き換えてください。

1. ユーザーの確認

従業員 ID に基づき、ユーザーが存在するかどうかを確認します。

リクエスト: GET /api/users/check?employee_id={employee_id}

パラメーター:

パラメーター

タイプ

必須

説明

employee_id

string

はい

従業員 ID。

例:

curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"

2. ユーザーの作成

新しいユーザーを作成し、その API キーを返します。

リクエスト: POST /api/users

パラメーター:

パラメーター

タイプ

必須

説明

name

string

はい

ユーザー名。

email

string

いいえ

メールアドレス。

employee_id

string

いいえ

従業員 ID。

department

string

いいえ

部門。

role

string

いいえ

ユーザーのロール。デフォルト: user。指定可能な値: admin。

metadata

object

いいえ

拡張情報。

例:

curl -X POST "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name":"田中太郎","email":"taro.tanaka@company.com","employee_id":"12345","department":"Engineering"}'

3. ユーザーの取得

すべてのユーザー、または特定の1ユーザーの情報を取得します。

リクエスト:

  • GET /api/users (すべてのユーザーを取得)

  • GET /api/users/{user_id} (特定の1ユーザーを取得)

例:

# すべてのユーザーを取得
curl -X GET "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>"

# 単一のユーザーを取得
curl -X GET "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"

4. API キーのリセット

ユーザーの API キーをリセットし、新しいキーを返します。

リクエスト: POST /api/users/{user_id}/regenerate-key

例:

curl -X POST "https://gateway.example.com/api/users/user_xxx/regenerate-key" \
-H "Authorization: Bearer <admin_api_key>"

5. ユーザーの更新

ユーザー情報を更新します。

リクエスト: PUT /api/users/{user_id}

パラメーター:

パラメーター

タイプ

必須

説明

name

string

はい

ユーザー名。

email

string

いいえ

メールアドレス。

employee_id

string

いいえ

従業員 ID。

department

string

いいえ

部門。

role

string

いいえ

ユーザーのロール。デフォルト: user。指定可能な値: admin。

enabled

boolean

いいえ

ユーザーを有効化するかどうかを指定します。

metadata

object

いいえ

拡張情報。

例:

curl -X PUT "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name": "田中太郎", "department":"New Product","email":"taro.tanaka@newcompany.com"}'

6. ユーザーの削除

指定したユーザーを削除します。

リクエスト: DELETE /api/users/{user_id}

例:

curl -X DELETE "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"

7. ユーザーのプロビジョニング

Provision API は、新しいユーザーを作成するか API キーをリセットしたうえで、ワンタイムプロビジョニングリンクを生成します。ユーザーはこのリンクを使用して自身の API キーを取得できます。ユーザーを直接作成する方法 (POST /api/users) と比べて、プロビジョニング方式の方が安全です。

  • ユーザーは専用リンクから API キーを取得するため、キーがプレーンテキストで送信されることを防ぎます。

  • リンクは 24 時間後に自動的に期限切れになります。

  • リンクは 1 回のみ使用でき、使用後は無効になります。

7.1 新規ユーザーのプロビジョニング

リクエスト: POST /api/provision

例:

curl -X POST "https://gateway.example.com/api/provision" \
  -H "Authorization: Bearer <admin_api_key>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "田中太郎",
    "email": "taro.tanaka@company.com",
    "employee_id": "12345",
    "department": "Engineering"
  }'

7.2 プロビジョニングによるキーのリセット

ユーザーが既に存在するが、新しい API キーが必要な場合にこの方法を使用します。

リクエスト: POST /api/provision/reset

例:

curl -X POST "https://gateway.example.com/api/provision/reset" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"employee_id":"12345"}'

7.3 プロビジョニングリンクの検証

ユーザーが provision_url を開くと、Web ページがこのエンドポイントを呼び出してトークンを検証し、ユーザー情報と API キーを取得します。

リクエスト: GET /api/provision/verify?token={token}

8. 一般的なワークフロー

新規ユーザー登録 (プロビジョニング)

プロビジョニング方式では、API キーをワンタイムリンクで配布できるため、より安全です。

# 1. ユーザーを作成し、プロビジョニングリンクを取得します。
curl -X POST "https://gateway.example.com/api/provision" \
-H "Authorization: Bearer <admin_api_key>" \
 -H "Content-Type: application/json" \
 -d '{"name":"田中太郎","email":"taro.tanaka@company.com","employee_id":"12345","department":"Engineering"}'
# 2. 返された provision_url をユーザーに送信します (例:メールやインスタントメッセージ)。

# 3. ユーザーがリンクを開くと、ページが自動的に /api/provision/verify を呼び出して API キーを取得します。

新規ユーザー登録 (直接作成)

# 1. ユーザーが既に存在するかどうかを確認します。
curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"

# 2. ユーザーが存在しない場合は、ユーザーを作成します。
curl -X POST "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name":"田中太郎","employee_id":"12345","department":"Engineering"}'

# 3. 返された api_key をユーザーに送信します。

ユーザーのオフボーディング (無効化または削除)

# ユーザーを無効化します (推奨)。
curl -X PUT "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"enabled": false}'

# または、ユーザーを削除します。
curl -X DELETE "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"

API キーの復旧 (プロビジョニング)

# 従業員IDでキーをリセットし、新しいプロビジョニングリンクを送信します。
curl -X POST "https://gateway.example.com/api/provision/reset" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"employee_id":"12345"}'

# 返された provision_url をユーザーに送信します。

API キーの復旧 (直接リセット)

# 従業員IDでユーザーを確認します。
curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"

# 返された user_id を使用して API キーをリセットします。
curl -X POST "https://gateway.example.com/api/users/user_xxx/regenerate-key" \
-H "Authorization: Bearer <admin_api_key>"

よくある質問

Q:ワークベンチでキャッシュヒット率が 0% になるのはなぜですか。

A:このメトリクスでは、推論サービスが実行時にキャッシュヒットデータをレポートする必要があります。推論エンジンによって必要な起動パラメーターが異なります。

  • SGLang エンジン:起動コマンドに --enable-cache-report パラメーターを追加します。
  • vLLM エンジン:起動コマンドに --enable-prompt-tokens-details パラメーターを追加します。

対応するパラメーターがない場合、ワークベンチはデータを収集できないため、キャッシュヒットが発生していても、キャッシュヒット率は 0% と表示されます。