The WebUI workbench is a visual management interface for LLM intelligent routing. It provides role-based user management, independent API Key allocation, real-time monitoring, and hot configuration updates. This enables user identity isolation and access auditing, reducing operational complexity.
Feature overview
You can enable the user management feature in the workbench as needed. When this feature is disabled, the workbench provides the following modules:
-
Real-time monitoring: Displays near-real-time performance metrics such as throughput, latency, and TTFT, along with status code distribution and the operational status of the gateway, scheduler, and inference instances, helping you quickly detect anomalies and identify performance bottlenecks.
-
Configuration center: Supports hot updates for core parameters, including traffic splitting proxy, scheduling policy, request throttling, and traffic mirroring. Changes take effect immediately without a service restart, making it ideal for dynamic tuning in production environments. For more information, see configuration center.
-
Smart chat: Provides a visual interface for chat testing. You can send text or image requests directly to the LLM intelligent routing service and use HTTP logs for debugging, allowing you to quickly validate the behavior of the traffic splitting proxy.
Enabling user management creates a comprehensive user system, ideal for enterprises where multiple teams share an LLM service. This adds the following modules:
-
Data overview: Displays token consumption and request volume distribution by user and department. You can filter the data by time range and user dimension to help admins identify high-usage users.
-
User management: You can create, retrieve, update, and delete users, as well as enable or disable them and manage their API Keys. You can also perform these operations through an API. For more information, see user management API reference.
-
Audit log: Records management operations such as logins and logouts, user modifications, API Key resets, and configuration changes. It logs the time, operator, and resource object for each action. You can filter logs by time, operation type, and operator for compliance audits and issue tracing.
-
User center: Users can manage their profiles, view and reset their own API Key, and review their personal request statistics and token consumption records.
The modules available to each role are as follows:
|
Role |
Permissions |
|
regular user |
smart chat, user center (view personal statistics) |
|
admin |
All permissions of a regular user, plus: data overview (view all user statistics), Real-time monitoring, configuration center (read-only) |
|
system admin |
All permissions of an admin, plus: user management, audit log, configuration center (read and write) |
Access the workbench
Prerequisites: You have deployed an LLM intelligent routing service, or an aggregated service that includes an LLM intelligent routing service.
Procedure:
-
Log on to the PAI console and go to the EAS inference services tab.
-
Find the target LLM intelligent routing service.
-
In the Invocation / Logs / Monitoring column of the service, click the web app icon.
-
In the pop-up window, find the WebUI workbench and open the admin workbench.
After an admin creates a user on the user management page, the user can log on to the WebUI workbench through the User Login portal with their API Key.
Configuration center
The configuration center supports hot updates for the core configurations of LLM intelligent routing, which take effect immediately without a service restart. The following diagram shows the stages where each configuration is applied.
|
Configuration type |
Description |
|
scheduling policy |
Configures the policy for scheduling requests to an inference instance. In PD separation mode, you can configure separate policies for the Prefill phase and Decode phase. |
|
model routing |
Routes requests to the corresponding instance based on the |
|
traffic splitting proxy |
Forwards requests to configured external upstream API services based on a model prefix or weight. |
|
request throttling |
Limits the concurrency of backend requests. When the limit is exceeded, you can choose to either reject the requests immediately or queue them. You can set separate concurrency limits for the overall lifecycle, the Prefill phase, and the Decode phase. External services specified in the traffic splitting proxy, such as DashScope, are subject to their own throttling rules and are not affected by this configuration. |
|
traffic mirroring |
Copies a percentage of production traffic to a target address. This is used for canary validation, performance comparison, or data collection, without affecting the normal response. |
|
global scheduling |
When inference resources in the current region are insufficient, the scheduler routes traffic to inference service instances in other idle regions. This enables global compute pooling and efficient resource reuse. |
User management API reference
Authentication: All API calls must include the system admin API Key in the request header: Authorization: Bearer <admin_api_key>.
When making calls, replace https://gateway.example.com in the examples with your LLM intelligent routing endpoint, such as http://xxx.cn-shanghai.pai-eas.aliyuncs.com/api/predict/ai_assistant.ai_gw.
1. Check user
Checks if a user exists, based on the employee ID.
Request: GET /api/users/check?employee_id={employee_id}
Parameters:
|
Parameter |
Type |
Required |
Description |
|
employee_id |
string |
Yes |
Employee ID. |
Example:
curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"
2. Create user
Creates a new user and returns their API Key.
Request: POST /api/users
Parameters:
|
Parameter |
Type |
Required |
Description |
|
name |
string |
Yes |
The user's name. |
|
|
string |
No |
Email address. |
|
employee_id |
string |
No |
Employee ID. |
|
department |
string |
No |
Department. |
|
role |
string |
No |
The role of the user. Default: |
|
metadata |
object |
No |
Extended information. |
Example:
curl -X POST "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name":"John Doe","email":"john.doe@company.com","employee_id":"12345","department":"Engineering"}'
3. Retrieve users
Retrieves information about all users or a single user.
Request:
-
GET /api/users(retrieves all users) -
GET /api/users/{user_id}(retrieves a single user)
Example:
# Retrieve all users
curl -X GET "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>"
# Retrieve a single user
curl -X GET "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"
4. Reset API key
Resets a user's API Key and returns the new key.
Request: POST /api/users/{user_id}/regenerate-key
Example:
curl -X POST "https://gateway.example.com/api/users/user_xxx/regenerate-key" \
-H "Authorization: Bearer <admin_api_key>"
5. Update user
Updates a user's information.
Request: PUT /api/users/{user_id}
Parameters:
|
Parameter |
Type |
Required |
Description |
|
name |
string |
Yes |
The user's name. |
|
|
string |
No |
Email address. |
|
employee_id |
string |
No |
Employee ID. |
|
department |
string |
No |
Department. |
|
role |
string |
No |
The role of the user. Default: |
|
enabled |
boolean |
No |
Specifies whether the user is enabled. |
|
metadata |
object |
No |
Extended information. |
Example:
curl -X PUT "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"department":"New Product","email":"john.doe@newcompany.com"}'
6. Delete user
Deletes a specified user.
Request: DELETE /api/users/{user_id}
Example:
curl -X DELETE "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"
7. User provisioning
The Provision API creates a new user or resets an API Key and then generates a one-time provisioning link. The user can use this link to retrieve their API Key. Compared to direct user creation (POST /api/users), the provisioning method is more secure:
-
Users retrieve their API Key through a dedicated link, preventing the key from being transmitted in plaintext.
-
The link automatically expires after 24 hours.
-
The link can be used only once and becomes invalid after use.
7.1 Provision a new user
Request: POST /api/provision
Example:
curl -X POST "https://gateway.example.com/api/provision" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{
"name": "John Doe",
"email": "john.doe@company.com",
"employee_id": "12345",
"department": "Engineering"
}'
7.2 Reset key via provisioning
Use this method when a user already exists but needs a new API Key.
Request: POST /api/provision/reset
Example:
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 Verify provisioning link
After the user opens the provision_url, the web page calls this endpoint to verify the token and retrieve the user information and API Key.
Request: GET /api/provision/verify?token={token}
8. Typical workflows
New user registration (provisioning)
The provisioning method delivers the API Key through a one-time link, which is more secure.
# 1. Create a user and get the provisioning link.
curl -X POST "https://gateway.example.com/api/provision" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name":"John Doe","email":"john.doe@company.com","employee_id":"12345","department":"Engineering"}'
# 2. Send the returned provision_url to the user (for example, by email or instant message).
# 3. The user opens the link, and the page automatically calls /api/provision/verify to retrieve the API Key.
New user registration (direct creation)
# 1. Check if the user already exists.
curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"
# 2. If the user does not exist, create the user.
curl -X POST "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name":"John Doe","employee_id":"12345","department":"Engineering"}'
# 3. Send the returned api_key to the user.
User offboarding (disable or delete)
# Disable the user (recommended).
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}'
# Alternatively, delete the user.
curl -X DELETE "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"
Recover API key (provisioning)
# Reset the key by employee ID and send a new provisioning link.
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"}'
# Send the returned provision_url to the user.
Recover API key (direct reset)
# Check for the user by employee ID.
curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"
# Use the returned user_id to reset the API Key.
curl -X POST "https://gateway.example.com/api/users/user_xxx/regenerate-key" \
-H "Authorization: Bearer <admin_api_key>"
FAQ
Q: Why is the cache hit rate 0% in the workbench?
A: This metric requires the inference service to report cache hit data during runtime. Check whether the startup command for the target EAS service includes the --enable-cache-report parameter. Without this parameter, the workbench cannot collect the data, causing the cache hit rate to display as 0% even if cache hits occur.