WebUI ワークベンチは、LLM のインテリジェントルーティングを視覚的に管理するためのインターフェイスです。ロールベースのユーザー管理、独立した API キーの割り当て、リアルタイムモニタリング、設定のホットアップデートを提供します。これにより、ユーザーのアイデンティティ分離とアクセス監査を実現し、運用の複雑さを軽減します。
機能の概要
ワークベンチでは、必要に応じてユーザー管理機能を有効化できます。この機能を無効にすると、ワークベンチには次のモジュールが表示されます。
-
リアルタイムモニタリング:スループット、レイテンシー、TTFT などのほぼリアルタイムのパフォーマンスメトリクスに加え、ステータスコードの分布や、ゲートウェイ、スケジューラ、推論インスタンスの稼働状況を表示します。これにより、異常を素早く検知し、パフォーマンスのボトルネックを特定できます。
-
設定センター:トラフィック分割プロキシ、スケジューリングポリシー、リクエストレート制限、トラフィックミラーリングなど、コアパラメーターのホットアップデートをサポートします。変更はサービスを再起動することなく即時反映されるため、本番環境での動的なチューニングに適しています。詳細については、「設定センター」をご参照ください。
-
スマートチャット:チャットテスト用の視覚的なインターフェイスを提供します。テキストまたは画像のリクエストを LLM インテリジェントルーティングサービスに直接送信し、HTTP ログを使用してデバッグできます。これにより、トラフィック分割プロキシの動作を迅速に検証できます。
ユーザー管理を有効化すると、包括的なユーザーシステムが作成され、複数のチームで LLM サービスを共有する企業に最適です。この場合、次のモジュールが追加されます。
-
データ概要:ユーザーおよび部門別に、トークン消費量とリクエスト数の分布を表示します。時間範囲とユーザーディメンションでデータをフィルターすることで、管理者が高使用量のユーザーを特定しやすくなります。
-
ユーザー管理:ユーザーの作成、取得、更新、削除に加え、有効化/無効化や API キーの管理ができます。これらの操作は API 経由でも実行できます。詳細については、「ユーザー管理 API リファレンス」をご参照ください。
-
監査ログ:ログイン/ログアウト、ユーザー変更、API キーのリセット、設定変更などの管理操作を記録します。各操作について、時刻、操作者、リソースオブジェクトをログに記録します。コンプライアンス監査や問題の追跡のために、時刻、操作タイプ、操作者でログをフィルタリングできます。
-
ユーザーセンター:ユーザーはプロフィールの管理、自身の API キーの確認とリセット、個人のリクエスト統計およびトークン消費量の記録の確認ができます。
各ロールで利用可能なモジュールは次のとおりです。
|
ロール |
権限 |
|
一般ユーザー |
スマートチャット、ユーザーセンター (個人統計の表示) |
|
管理者 |
一般ユーザーのすべての権限に加え、次の機能も利用できます:データ概要 (すべてのユーザー統計の表示)、リアルタイムモニタリング、設定センター (読み取り専用) |
|
システム管理者 |
管理者のすべての権限に加え、次の機能も利用できます:ユーザー管理、監査ログ、設定センター (読み取り/書き込み) |
ワークベンチへのアクセス
前提条件:LLM インテリジェントルーティングサービス、または LLM インテリジェントルーティングサービスを含む集約サービスをデプロイ済みであること。
手順:
-
PAI コンソールにログインし、EAS 推論サービスのタブに移動します。
-
対象の LLM インテリジェントルーティングサービスを見つけます。
-
サービスの [Invocation / Logs / Monitoring] 列で、[Web アプリ] アイコンをクリックします。
-
ポップアップウィンドウで WebUI ワークベンチを見つけ、管理者ワークベンチを開きます。
管理者が [ユーザー管理] ページでユーザーを作成すると、ユーザーは API キーを使用して [ユーザーログインポータル] から WebUI ワークベンチにログインできます。
設定センター
設定センターは、LLM インテリジェントルーティングのコア設定のホットアップデートをサポートします。変更はサービスを再起動することなく即時反映されます。次の図は、各設定が適用されるステージを示します。
|
設定タイプ |
説明 |
|
スケジューリングポリシー |
推論インスタンスにリクエストをスケジューリングするためのポリシーを設定します。PD 分離モードでは、Prefill フェーズと Decode フェーズに対して個別のポリシーを設定できます。 |
|
モデルルーティング |
リクエスト内の |
|
トラフィック分割プロキシ |
モデルのプレフィックスまたは重みに基づき、設定された外部アップストリーム 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 |
はい |
ユーザー名。 |
|
|
string |
いいえ |
メールアドレス。 |
|
employee_id |
string |
いいえ |
従業員 ID。 |
|
department |
string |
いいえ |
部門。 |
|
role |
string |
いいえ |
ユーザーのロール。デフォルト: |
|
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 |
はい |
ユーザー名。 |
|
|
string |
いいえ |
メールアドレス。 |
|
employee_id |
string |
いいえ |
従業員 ID。 |
|
department |
string |
いいえ |
部門。 |
|
role |
string |
いいえ |
ユーザーのロール。デフォルト: |
|
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% と表示されます。