All Products
Search
Document Center

Platform For AI:Improve inference efficiency with the LLM intelligent router

Last Updated:Aug 05, 2026

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:

  1. Receive request: A user request arrives at the LLM Gateway. If backend inference instances experience high load, the gateway queues the request.

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

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

image

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

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

  2. In the left-side navigation pane, click Elastic Algorithm Service (EAS). On the EAS page, select the target workspace.

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

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

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

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

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

    Note

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

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

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

  1. Get access credentials.

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

    2. On the Endpoint Information page, under Service-specific Traffic Entry, copy the Internet Endpoint and token.

    Important

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

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

  1. Purchase an instance from the Tair purchase page.

    Important

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

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

  3. 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_gateway node of the JSON body, add the following parameters:

    Parameter

    Description

    enable_user_management

    Enables user management. Defaults to true.

    redis_addrs

    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 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 LLMGatewayService, which indicates the deployment of an LLM intelligent router service.

instance

Required. The number of LLM Gateway replicas. We recommend setting this value to 2 or more to prevent a single point of failure.

cpu

The number of vCPUs for each LLM Gateway replica.

memory

The memory (in GB) for the LLM Gateway.

group

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

rpc.disable_auth

Required. Must be set to true.

cloud.computing.instance_type

Specifies the instance type for the LLM Gateway. If this parameter is specified, you do not need to configure metadata.cpu or metadata.memory.

llm_gateway

max_queue_size

The maximum queue depth for the LLM Gateway. Default: 128.

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 LLM Scheduler. The default is 2.

memory

The memory (in GB) for the LLM Scheduler. The default is 4 GB.

policy

The scheduling policy. Default: prefix-cache. For available values and descriptions, see the Scheduling Policy Reference.

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

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

Important

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

-