LLM workloads face inherent challenges: variable request lengths, unpredictable token generation, and fluctuating GPU utilization. Traditional load balancers distribute traffic without visibility into backend pressure, causing uneven instance loads and degraded throughput. EAS addresses this with the LLM intelligent router, which combines intelligent scheduling and visual operations in a single service. It dynamically balances compute and GPU memory based on real-time LLM metrics, sustains high throughput under load, and provides a built-in WebUI workbench for live monitoring, hot configuration updates, and per-user API key management with identity isolation.
How it works
Key concepts
The LLM intelligent router service consists of two core components:
-
LLM Gateway: traffic entry and request processing. Receives user requests and forwards them to the target inference instance based on decisions from
LLM Scheduler.-
Supports HTTP (HTTP_SSE) and WebSocket protocols.
-
Anthropic API protocol conversion is enabled by default. Requests formatted to the Anthropic specification are automatically converted to OpenAI-compatible format, so you can use tools like Claude Code with model services that follow the OpenAI API standard without modifying your code. For details, see Use Claude Code with the router.
-
-
LLM Scheduler: scheduling engine. Selects the optimal target instance for each request based on the configured scheduling policy (for example, prefix-cache routing).
How it works
The request flow proceeds as follows:
-
Receive request. The user request arrives at
LLM Gateway. If all backend inference instances are at high load, the gateway queues the request. -
Intelligent scheduling.
LLM Gatewaysends a scheduling request toLLM Scheduler.LLM Schedulerselects the optimal instance based on the configured policy and real-time metrics from each instance. -
Forward request. After receiving the scheduling result,
LLM Gatewayforwards the user request directly to the selected instance.
Failover mechanism
The service includes multiple layers of fault tolerance to maintain availability:
-
LLM Gateway: Deploy at least two instances. If one instance fails, traffic automatically shifts to healthy instances.
-
LLM Scheduler: If the scheduler fails,
LLM Gatewayautomatically falls back to round-robin routing (scheduling performance is reduced, but availability is maintained). When the scheduler recovers, intelligent scheduling resumes automatically. -
Inference instances: If an instance fails,
LLM Schedulerimmediately removes it from the available pool. No new traffic is routed to that instance until it recovers and is automatically re-added.
Limitations
-
Service group requirements:
-
The LLM intelligent router must be deployed in the same service group as the inference service. The router does not work if deployed in a different service group from the inference service.
-
Within the same service group, an intelligent router service and a queue service cannot coexist.
-
-
Configure the intelligent router only when creating a new inference service. A service's group membership is determined at creation time and cannot be changed afterward. As a result, intelligent routing can only be configured when creating a new inference service. You can't add or modify intelligent routing on an existing service through Update service.
-
Inference engine requirement: Only vLLM and SGLang are supported.
-
Incompatible with NLB and Nacos: Inference services accessed through NLB or Nacos cannot use the LLM intelligent router at the same time.
-
Deploy multiple inference instances: The LLM intelligent router provides benefits only when multiple inference instances are deployed.
Quick start
Step 1: Deploy the LLM intelligent router service
-
Log in to the PAI console and select the target region at the top of the page.
-
In the left navigation pane, click Elastic Algorithm Service (EAS), select the target workspace, and go to EAS.
-
Click Deploy Service, then select Scenario-based Model Deployment>Deploy LLM gateway.
-
Configure the parameters:
Parameter
Description
Basic Information
Service Name
A custom name for the service, for example,
llm_gateway.Resource Information
Deployment Resources
Resource configuration for
LLM Gateway. To ensure high availability, Number of Replicas defaults to 2; keep this default. The default resource allocation is 4 vCPUs and 8 GB of memory.Scheduling configuration
Resource configuration for
LLM Scheduler. The default is 2 vCPUs and 4 GB of memory.Scheduling Policy
The load balancing policy used to select backend inference instances. The default is Prefix cache. For a detailed comparison and selection guidance, see Scheduling policy reference.
Advanced Features
Redis config
Optional. Persists user information and usage statistics. Without Redis, the service uses local memory and 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 complete.
After deployment, the system automatically creates a service group named group_<LLM intelligent router service name>. To view it, go to the Elastic Algorithm Service (EAS) page and click the Canary Release tab.

Step 2: Deploy the LLM service
Configure the intelligent router when creating a new LLM service. You can't add it to an existing service through Update.
The following example uses Qwen3-8B:
-
Click Deploy Service, then select Scenario-based Model Deployment> LLM Deployment.
-
Configure the following parameters:
Parameter
Value
Basic Information
Model Settings
Select Public Model, search for, and select Qwen3-8B.
Inference Engine
Select vLLM (recommended; OpenAI API-compatible).
NoteIf the LLM intelligent router is configured with the Prefix cache scheduling policy and you select vLLM as the inference engine, make sure prefix caching is enabled in vLLM.
Deployment Template
Select Single node. The system automatically populates the recommended instance type, image, and other parameters based on the template.
Features
LLM Intelligent Router
Enable the toggle and select the LLM intelligent router service deployed in Step 1 from the drop-down list.
-
Click Deploy. Deployment takes approximately 5 minutes. When the service status changes to Running, the deployment is complete.
Step 3: Test the service
Send all requests to the LLM intelligent router service's access URL, not to the individual backend inference service URLs.
-
If any inference service in the group has traffic distribution enabled, requests sent through the group's aggregate traffic entry can bypass the intelligent router and cause scheduling to fail.
-
Make sure only the intelligent router service has traffic distribution enabled in the group. Send requests through the intelligent router's dedicated traffic entry URL.
-
Get access credentials.
-
Click the LLM intelligent router service to open the Overview page. In the Basic Information section, click View Endpoint Information.
-
On the Call information page, copy the Service-specific Traffic Entry Internet Endpoint, and copy the Token.

ImportantThe service token shown here is the administrator credential. If an administrator has assigned individual API keys to users through the WebUI workbench, each user should replace
<YOUR_TOKEN>in the examples below with their own API key. -
-
Build the request URL and send a call.
-
URL format:
<LLM intelligent router URL>/<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 the service is deployed, access the WebUI workbench for visual management, including live monitoring and configuration management. For details, see Use the LLM intelligent routing workbench.
Configure Redis persistent storage
The LLM intelligent router includes built-in multi-user management, role-based access control, audit logging, and usage dashboards. An external Redis instance persists user data and usage statistics across service restarts. Without Redis, the service uses local memory and all data is lost when the service stops. For production deployments, configure Redis storage.
Step 1: Provision a Tair (Redis) instance
-
Go to the Tair purchase page and purchase an instance.
ImportantSelect the same virtual private cloud (VPC) and vSwitch as the LLM intelligent router service you plan to deploy. Configure other options as needed; start with the minimum specification.
-
Add the vSwitch CIDR block of the LLM intelligent router service to the instance allowlist. For details, see Configure an allowlist.
-
Click the target instance ID to open the details page and view the connection information. You'll need this information when deploying the LLM intelligent router service.
-
Connection address and port: In Instance information > Connection information, get the VPC connection address and port number.
-
Username and password: On the Account management page, view the default account. If no password was set when the instance was created, set or reset the password there. You can also create a new account instead of using the default.
-
Step 2: Configure Redis during deployment
In addition to the basic configuration, specify the VPC settings and Redis connection parameters to enable persistent storage.
-
Configure the VPC: The VPC and vSwitch must match those of the Tair instance from Step 1, so the LLM intelligent router service can reach the Tair instance.
-
Configure Redis:
Console
In the Advanced Features section, enable Redis config and fill in:
Parameter
Description
Redis Address
Connection address of the Tair instance, in the format
<VPC address>:<port>, for exampler-uxxx.redis.rds.aliyuncs.com:6379.Redis Username
Username for the Tair instance.
Redis Password
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_addrsConnection address of the Tair instance, in the format
<VPC address>:<port>, for exampler-uxxx.redis.rds.aliyuncs.com:6379.redis_usernameUsername for the Tair instance.
redis_passwordPassword 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)
JSON deployment allows you to configure LLM Gateway resource specifications and request handling behavior.
Configuration entry: 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. Fixed value: |
|
instance |
Required. Number of |
|
|
cpu |
vCPU count per |
|
|
memory |
Memory (GB) for |
|
|
group |
The service group that the LLM intelligent router service belongs to. |
|
|
rpc.disable_auth |
Required. Set to |
|
|
cloud.computing.instance_type |
Specifies the resource type for |
|
|
llm_gateway |
max_queue_size |
Maximum queue depth for When requests exceed the backend's processing capacity, the overflow is queued here and dispatched as capacity becomes available. |
|
retry_count |
Number of retries when a backend inference instance fails. Defaults to 2. On failure, the request is retried on a different instance. |
|
|
wait_schedule_timeout |
When all backend instances are at full capacity, the gateway retries scheduling at intervals. This parameter sets the total time the gateway spends attempting to schedule a request. Defaults to 10 seconds. |
|
|
wait_schedule_try_period |
Interval between scheduling retry attempts. Defaults to 1 second. |
|
|
llm_scheduler |
cpu |
vCPU count for |
|
memory |
Memory (GB) for |
|
|
policy |
Scheduling policy. Defaults to |
|
|
prefill_policy |
When policy is set to pd-split, specify the scheduling policy for the Prefill and Decode stages separately. Valid values: prefix-cache, llm-metric-based, least-request, least-token. |
|
|
decode_policy |
||
Appendix
Use Claude Code with the router
-
Set Claude Code to use the base URL and token provided by 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 policy reference
Selecting the right scheduling policy is key to getting the most out of the LLM intelligent router. The following table compares each policy's logic, ideal use cases, advantages, and considerations.
|
Policy name |
JSON value |
How it works |
Best for |
Advantages |
Considerations |
|
Prefix cache |
prefix-cache |
(Recommended) A composite policy. Routes requests with the same conversation history (prompt) to the instance that already has the matching KV cache. |
Multi-turn chatbots and RAG systems with a fixed system prompt. |
Significantly reduces TTFT, improves multi-turn performance and throughput. |
Requires prefix caching to be enabled on the inference engine. |
|
Minimum Requests |
least-request |
Routes new requests to the instance currently processing the fewest requests. |
Workloads with relatively uniform request complexity (similar token lengths and generation lengths). |
Simple and efficient; balances request counts across instances quickly. |
Doesn't account for actual request load; short-request instances can sit idle while long-request instances are overloaded. |
|
Minimum tokens |
least-token |
Routes new requests to the instance currently processing the fewest total tokens (input + output). |
Workloads where token count reliably reflects processing cost. |
Better reflects true instance load than least-request. |
Depends on token count estimates; not all inference engines report this metric. |
|
Static PD Disaggregation |
pd-split |
Requires pre-partitioning instances into Prefill and Decode groups, each with its own scheduling policy. |
Workloads where Prefill and Decode stages have significantly different compute and memory-access characteristics, and disaggregated deployment yields clear gains. |
Maximum hardware utilization through specialized stage optimization. |
Complex to configure. Requires deep understanding of the model and workload, and separate Prefill and Decode service deployments. |
Performance benchmark
Tests on Distill-Qwen-7B, QwQ-32B, and Qwen2.5-72B show improvements in inference speed and throughput when the LLM intelligent router is used. The test environment and results are described below.
Results vary by workload. Run your own benchmarks to validate performance for your use case.
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 LLM router |
With LLM router |
Improvement |
Without LLM router |
With LLM router |
Improvement |
Without LLM router |
With LLM 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 |
+4.4% |
|
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 |
- |