Large Language Model (LLM) workloads present challenges such as variable request lengths, random token generation, and fluctuating GPU utilization. Traditional load balancers cannot detect backend pressure in real time, leading to uneven instance loads and degraded system performance. To address these issues, EAS provides the LLM intelligent router, a service integrating intelligent scheduling and visualized O&M. It dynamically balances compute power and GPU memory based on real-time LLM metrics to ensure high throughput and stability. The service's built-in WebUI workbench provides live monitoring, dynamic configuration updates, and multi-user API key management with identity isolation to significantly reduce operational complexity.
How it works
Core components
The LLM intelligent router service consists of the following two core components:
-
LLM Gateway: The traffic entry point and request processing center. It receives user requests and forwards them to the target inference instance based on decisions from the
LLM Scheduler.-
Supports the HTTP (HTTP_SSE) and WebSocket protocols.
-
By default, the Anthropic API protocol conversion feature is enabled. This feature automatically converts Anthropic-compliant requests into an OpenAI-compatible format. This allows you to use ecosystem tools, such as Claude Code, to call model services that follow the OpenAI API standard without code modifications. For more information, see Use Claude Code to make calls.
-
-
LLM Scheduler: The intelligent scheduling engine. It selects the optimal target instance for each request based on a scheduling policy, such as prefix-cache routing.
Workflow
The following is the key workflow:
-
Receive request: A user request arrives at the
LLM Gateway. If backend inference instances experience high load, the gateway queues the request. -
Intelligent scheduling: The
LLM Gatewaysends a scheduling request to theLLM Scheduler. TheLLM Schedulerthen selects the optimal instance based on the scheduling policy and real-time metrics from each instance. -
Forward request: After receiving the scheduling decision, the
LLM Gatewayforwards the user request directly to the selected instance.
Failover mechanism
A multi-layered fault tolerance mechanism ensures service stability:
-
LLM Gateway: We recommend deploying at least two instances. If an instance fails, traffic automatically fails over to a healthy one.
-
LLM Scheduler: If the scheduler fails, the
LLM Gatewayautomatically falls back to round-robin routing. This ensures availability at the cost of intelligent scheduling. When the scheduler recovers, it automatically resumes intelligent scheduling. -
Inference instance: If an inference instance fails, the
LLM Schedulerimmediately removes it from the available pool and stops routing new traffic to it. After the instance recovers, the scheduler automatically adds it back to the pool.
Limitations
-
Service group requirements:
-
The LLM intelligent router must be deployed in the same service group as the inference service to function correctly.
-
An intelligent router service and a queue service cannot coexist in the same service group.
-
-
The intelligent router service can only be configured when creating a new inference service: A service's group membership is set at creation and cannot be changed later. Therefore, the intelligent routing feature can only be configured when you create a new inference service. You cannot use Update service to add or modify intelligent routing for an existing inference service.
-
Inference engine limitation: Only vLLM or SGLang are supported.
-
Incompatible with NLB and Nacos: You cannot use the LLM intelligent router with inference services that are exposed via NLB or Nacos.
-
Multiple instances recommended: The LLM intelligent router provides scheduling benefits only when you deploy multiple inference instances.
Quick start: LLM intelligent router
Step 1: Deploy the LLM intelligent router
-
Log on to the PAI console and select the target region at the top of the page.
-
In the left-side navigation pane, click Elastic Algorithm Service (EAS). On the EAS page, select the target workspace.
-
Click Deploy Service, and then select Scenario-based Model Deployment > Deploy LLM gateway.
-
Configure the parameters:
Parameter
Description
Basic Information
Service Name
Enter a custom name for the service, for example,
llm_gateway.Resource Information
Deployment Resources
Specifies the resource configuration for the
LLM Gateway. For high availability, the Number of Replicas is set to 2 by default; we recommend keeping this setting. The default configuration is 4 vCPUs and 8 GB of memory.Scheduling configuration
Specifies the resource configuration for the
LLM Scheduler. The default is 2 vCPUs and 4 GB of memory.Scheduling Policy
The load balancing policy for backend inference instances. The default is Prefix cache. For a detailed comparison to help you choose, see Scheduling policy reference.
Advanced Features
Redis config
Optional. Persists user information and usage statistics. If not configured, the service uses local memory, and the data is lost when the service stops. For details, see Configure Redis persistent storage.
-
Click Deploy. When the service status changes to Running, the deployment is successful.
After deployment, the system automatically creates a service group named group_<LLM intelligent router service name>. To view the group, go to the Elastic Algorithm Service (EAS) page and click the Group Service tab.
Step 2: Deploy an LLM service
You must configure the intelligent router feature when you deploy a new LLM service. You cannot add this feature to an existing service with the Update action.
The following steps use the deployment of Qwen3-8B as an example:
-
Click Deploy Service, and then select Scenario-based Model Deployment > LLM Deployment.
-
Configure the following key parameters:
Parameter
Value
Basic Information
Model Settings
Select Public Model, and then search for and select Qwen3-8B.
Inference Engine
Select vLLM (recommended; compatible with the OpenAI API).
NoteIf the LLM intelligent router service uses the Prefix cache scheduling policy and you select vLLM as the inference engine, ensure the prefix caching feature is enabled for the engine.
Deployment Template
Select Single node. The system then automatically populates the recommended instance specifications, image, and other parameters from the template.
Features
LLM Intelligent Router
Turn on the toggle and select the LLM intelligent router service deployed in Step 1 from the drop-down list.
-
Click Deploy. The deployment takes about 5 minutes. When the service status changes to Running, the deployment is successful.
Step 3: Test the service
All requests must be sent to the access endpoint of the LLM intelligent router service, not to the backend inference services.
-
If any inference service in the service group has traffic distribution enabled, requests sent through the service group's aggregate traffic entry may bypass the intelligent router, causing scheduling failures.
-
Ensure that only the intelligent router service has traffic distribution enabled in the service group. Send requests through the intelligent router service's dedicated traffic entry URL.
-
Get access credentials.
-
Go to the Overview page of the LLM intelligent router service. In the Basic Information section, click View Endpoint Information.
-
On the Endpoint Information page, under Service-specific Traffic Entry, copy the Internet Endpoint and token.
ImportantThe service token here is the administrator API key. If an administrator has assigned you a separate API key through the WebUI workbench, use your own API key to replace
<YOUR_TOKEN>in the example below. -
-
Build the request URL and call the service.
-
URL format:
<LLM intelligent router access endpoint>/<LLM service API path> -
Example:
http://********.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completions
Request example:
# Replace <YOUR_GATEWAY_URL> and <YOUR_TOKEN> with your actual values curl -X POST "<YOUR_GATEWAY_URL>/v1/chat/completions" \ -H "Authorization: Bearer <YOUR_TOKEN>" \ -H "Content-Type: application/json" \ -N \ -d '{ "messages": [{"role": "user", "content": "Hello"}], "stream": true }'Example response:
data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"role":"assistant","content":""},"logprobs":null,"finish_reason":null}]} data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"content":"<think>","tool_calls":[]}}]} ... data: [DONE] -
After you deploy the service, you can use the WebUI workbench for tasks like live monitoring and configuration management. For details, see Use the LLM intelligent router workbench.
Configure Redis for persistent storage
The LLM intelligent router includes a built-in user management feature that supports multi-user management, role-based access control, audit logging, and data overviews. You can use an external Redis instance to persist user information and usage statistics. If Redis is not configured, the service uses local memory and all data is lost when the service stops. For production deployments, configure Redis for persistent storage.
Step 1: Provision a Tair (Redis) instance
-
Purchase an instance from the Tair purchase page.
ImportantWhen you create the instance, select the same VPC and vSwitch as your LLM intelligent router service. For other options, you can start with the minimum specifications.
-
Add the CIDR block of the vSwitch for the LLM intelligent router service to the instance's allowlist. For more information, see Configure an allowlist.
-
Click the target instance ID to open the details page. You will need the connection information when you deploy the LLM intelligent router service.
-
Connection address and port: In the Instance information section, find the VPC connection address and port number under Connection information.
-
Username and password: On the Account management page, find the default account. If you did not set a password when you created the instance, you can set or reset it here. You can also create a new account instead of using the default one.
-
Step 2: Configure Redis
In addition to the basic configuration, you must configure the VPC and add the Redis connection parameters to enable persistent storage.
-
Configure VPC: The VPC and vSwitch must be the same as those of the Tair instance provisioned in Step 1. This ensures that the LLM intelligent router service can connect to the Tair instance.
-
Configure Redis:
Console
In the Advanced Features section, enable Redis config and enter the following parameters:
Parameter
Description
Redis Address
The connection address of the Tair instance, in the format
<VPC address>:<port>. For example,r-uxxx.redis.rds.aliyuncs.com:6379.Redis Username
The username for the Tair instance.
Redis Password
The password for the Tair instance.
JSON
In the
llm_gatewaynode of the JSON body, add the following parameters:Parameter
Description
enable_user_managementEnables user management. Defaults to
true.redis_addrsThe connection address of the Tair instance, in the format
<VPC address>:<port>. For example,r-uxxx.redis.rds.aliyuncs.com:6379.redis_usernameThe username for the Tair instance.
redis_passwordThe password for the Tair instance.
JSON example:
{ "llm_gateway": { "enable_user_management": true, "redis_addrs": "r-uxxx.redis.rds.aliyuncs.com:6379", "redis_username": "xxx", "redis_password": "xxx" } }
Advanced configuration (JSON)
Use JSON Deployment to configure resource specifications for the LLM Gateway and fine-tune its request handling.
On the Inference Service page, click Deploy Service. In the Custom Model Deployment section, click JSON Deployment.
Configuration example
{
"cloud": {
"computing": {
"instance_type": "ecs.c7.large"
}
},
"llm_gateway": {
"max_queue_size": 128,
"retry_count": 2,
"wait_schedule_timeout": 5000,
"wait_schedule_try_period": 500
},
"llm_scheduler": {
"cpu": 2,
"memory": 4000,
"policy": "prefix-cache"
},
"metadata": {
"group": "group_llm_gateway",
"instance": 2,
"name": "llm_gateway",
"type": "LLMGatewayService",
"rpc": {
"disable_auth": true
}
}
}
Parameters
|
Parameter |
Description |
|
|
metadata |
type |
Required. Must be set to |
|
instance |
Required. The number of |
|
|
cpu |
The number of vCPUs for each |
|
|
memory |
The memory (in GB) for the |
|
|
group |
The service group to which the LLM intelligent router service belongs. |
|
|
rpc.disable_auth |
Required. Must be set to |
|
|
cloud.computing.instance_type |
Specifies the instance type for the |
|
|
llm_gateway |
max_queue_size |
The maximum queue depth for the When requests exceed the backend inference framework's capacity, excess requests are held in this queue to await scheduling. |
|
retry_count |
The number of retries. Default: 2. If a backend inference instance fails, the system retries the request and forwards it to a healthy instance. |
|
|
wait_schedule_timeout |
When backend engines are at full capacity, this parameter specifies the total timeout in milliseconds for scheduling a request. The default is 5000 (5 seconds). |
|
|
wait_schedule_try_period |
The interval, in milliseconds, between scheduling attempts. The default is 500 (0.5 seconds). |
|
|
request_stream_prefill_timeout |
The prefill timeout in seconds for streaming requests. This is the maximum time to wait for the first token. Default: 300. |
|
|
request_stream_decode_timeout |
The decode timeout in seconds for streaming requests. This is the maximum idle interval between consecutive chunks. Default: 300. |
|
|
request_stream_total_timeout |
The total timeout in seconds for the entire streaming request. Default: 0, which means no timeout. |
|
|
request_non_stream_timeout |
The timeout in seconds for non-streaming requests. This is the maximum time for a complete response. Default: 900. |
|
|
llm_scheduler |
cpu |
The number of vCPUs for the |
|
memory |
The memory (in GB) for the |
|
|
policy |
The scheduling policy. Default: |
|
|
prefill_policy |
When policy is set to pd-split, you must specify separate scheduling policies for the Prefill and Decode stages. Valid values are: prefix-cache, llm-metric-based, least-request, and least-token. |
|
|
decode_policy |
||
Appendix
Use Claude Code
-
Configure Claude Code to use the BASE URL and TOKEN from the EAS intelligent router service.
# Replace <YOUR_GATEWAY_URL> and <YOUR_TOKEN> with your actual values export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL> export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN> -
Run Claude Code.
claude "Write a Python Hello World program"
Scheduling policies
This table compares the logic, use cases, advantages, and considerations for each scheduling policy.
|
Policy |
JSON value |
Description |
Use cases |
Advantages |
Considerations |
|
Prefix cache |
prefix-cache |
(Recommended) A composite policy that prioritizes routing requests with the same conversation history (prompt) to an instance with a matching KV cache. |
Multi-turn chatbots and RAG systems with a fixed system prompt. |
Significantly reduces Time to First Token (TTFT), and improves performance and throughput for multi-turn conversation. |
Requires the inference engine to have prefix caching enabled. |
|
Minimum Requests |
least-request |
Routes new requests to the instance that is currently processing the fewest requests. |
Workloads with relatively uniform request complexity (similar token lengths and generation lengths). |
Simple and efficient. It quickly balances request counts across instances. |
Does not account for the actual computational cost of requests. Instances handling short requests can become idle while those processing long ones are overloaded. |
|
Minimum tokens |
least-token |
Routes new requests to the instance that is currently processing the fewest total tokens (input + output). |
Workloads where token count reliably reflects processing cost. |
Reflects true instance load more accurately than the Least Request policy. |
Relies on token count estimation, and not all inference engines report this metric. |
|
Static PD Disaggregation |
pd-split |
Instances are pre-partitioned into Prefill and Decode groups, and a separate scheduling policy is set for each group. |
Workloads where the Prefill and Decode stages have significantly different compute and memory-access patterns, and where disaggregation offers distinct advantages. |
Maximizes hardware utilization through stage-specific-tuning. |
Complex to configure. You must understand the model and workload, and deploy separate Prefill and Decode services. |
Performance benchmark
Benchmarks on the Distill-Qwen-7B, QwQ-32B, and Qwen2.5-72B models show that the LLM intelligent router significantly improves inference speed and throughput.
These results are for reference only. Run your own benchmarks to validate performance for your workload.
Test environment
-
Scheduling policy: prefix-cache
-
Test dataset: ShareGPT_V3_unfiltered_cleaned_split.json (multi-turn conversation dataset)
-
Inference engine: vLLM (0.7.3)
-
Backend instances: 5
Test results
|
Test model |
Distill-Qwen-7B |
QwQ-32B |
Qwen2.5-72b |
||||||
|
Instance type |
ml.gu8tf.8.40xlarge |
ml.gu8tf.8.40xlarge |
ml.gu7xf.8xlarge-gu108 |
||||||
|
Concurrency |
500 |
100 |
100 |
||||||
|
Metric |
Without smart router |
With smart router |
Improvement |
Without smart router |
With smart router |
Improvement |
Without smart router |
With smart router |
Improvement |
|
Successful requests |
3698 |
3612 |
- |
1194 |
1194 |
- |
1194 |
1194 |
- |
|
Benchmark duration |
460.79 s |
435.70 s |
- |
1418.54 s |
1339.04 s |
- |
479.53 s |
456.69 s |
- |
|
Total input tokens |
6605953 |
6426637 |
- |
2646701 |
2645010 |
- |
1336301 |
1337015 |
- |
|
Total generated tokens |
4898730 |
4750113 |
- |
1908956 |
1902894 |
- |
924856 |
925208 |
- |
|
Request throughput |
8.03 req/s |
8.29 req/s |
+3.2% |
0.84 req/s |
0.89 req/s |
+5.95% |
2.49 req/s |
2.61 req/s |
+4.8% |
|
Output token throughput |
10631.17 tok/s |
10902.30 tok/s |
+2.5% |
1345.72 tok/s |
1421.08 tok/s |
+5.6% |
1928.66 tok/s |
2025.92 tok/s |
+5.0% |
|
Total token throughput |
24967.33 tok/s |
25652.51 tok/s |
+2.7% |
3211.52 tok/s |
3396.38 tok/s |
+5.8% |
4715.34 tok/s |
4953.56 tok/s |
+5.0% |
|
Mean TTFT |
532.79 ms |
508.90 ms |
+4.5% |
1144.62 ms |
859.42 ms |
+25.0% |
508.55 ms |
389.66 ms |
+23.4% |
|
Median TTFT |
274.23 ms |
246.30 ms |
- |
749.39 ms |
565.61 ms |
- |
325.33 ms |
190.04 ms |
- |
|
P99 TTFT |
3841.49 ms |
3526.62 ms |
- |
5339.61 ms |
5027.39 ms |
- |
2802.26 ms |
2678.70 ms |
- |
|
Mean TPOT |
40.65 ms |
39.20 ms |
+3.5% |
68.78 ms |
65.73 ms |
+4.4% |
46.83 ms |
43.97 ms |
+6.1% |
|
Median TPOT |
41.14 ms |
39.61 ms |
- |
69.19 ms |
66.33 ms |
- |
45.37 ms |
43.30 ms |
- |
|
P99 TPOT |
62.57 ms |
58.71 ms |
- |
100.35 ms |
95.55 ms |
- |
62.29 ms |
54.79 ms |
- |