All Products
Search
Document Center

Platform For AI:Deploy the LLM intelligent router to improve inference efficiency

Last Updated:Jun 17, 2026

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:

  1. Receive request. The user request arrives at LLM Gateway. If all backend inference instances are at high load, the gateway queues the request.

  2. Intelligent scheduling. LLM Gateway sends a scheduling request to LLM Scheduler. LLM Scheduler selects the optimal instance based on the configured policy and real-time metrics from each instance.

  3. Forward request. After receiving the scheduling result, LLM Gateway forwards the user request directly to the selected instance.

image

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 Gateway automatically 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 Scheduler immediately 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

  1. Log in to the PAI console and select the target region at the top of the page.

  2. In the left navigation pane, click Elastic Algorithm Service (EAS), select the target workspace, and go to EAS.

  3. Click Deploy Service, then select Scenario-based Model Deployment>Deploy LLM gateway.

  4. 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.

  5. 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.image

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:

  1. Click Deploy Service, then select Scenario-based Model Deployment> LLM Deployment.

  2. 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).

    Note

    If 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.

  3. 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.

Note
  • 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.

  1. Get access credentials.

    1. Click the LLM intelligent router service to open the Overview page. In the Basic Information section, click View Endpoint Information.

    2. On the Call information page, copy the Service-specific Traffic Entry Internet Endpoint, and copy the Token.image

    Important

    The 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.

  2. 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

  1. Go to the Tair purchase page and purchase an instance.

    Important

    Select 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.

  2. Add the vSwitch CIDR block of the LLM intelligent router service to the instance allowlist. For details, see Configure an allowlist.

  3. 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 example r-uxxx.redis.rds.aliyuncs.com:6379.

    Redis Username

    Username for the Tair instance.

    Redis Password

    Password for the Tair instance.

    JSON

    In the llm_gateway node of the JSON body, add the following parameters:

    Parameter

    Description

    enable_user_management

    Enables user management. Defaults to true.

    redis_addrs

    Connection address of the Tair instance, in the format <VPC address>:<port>, for example r-uxxx.redis.rds.aliyuncs.com:6379.

    redis_username

    Username for the Tair instance.

    redis_password

    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)

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: LLMGatewayService. Identifies this deployment as an LLM intelligent router service.

instance

Required. Number of LLM Gateway replicas. Set to at least 2 to avoid a single point of failure.

cpu

vCPU count per LLM Gateway replica.

memory

Memory (GB) for LLM Gateway.

group

The service group that the LLM intelligent router service belongs to.

rpc.disable_auth

Required. Set to true.

cloud.computing.instance_type

Specifies the resource type for LLM Gateway. When set, metadata.cpu and metadata.memory are not required.

llm_gateway

max_queue_size

Maximum queue depth for LLM Gateway. Defaults to 512.

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 LLM Scheduler. Defaults to 4.

memory

Memory (GB) for LLM Scheduler. Defaults to 4 GB.

policy

Scheduling policy. Defaults to prefix-cache. For available values and descriptions, see Scheduling policy reference.

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

  1. 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>
  2. 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.

Important

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

-