使用LLM智能路由提升推理效率

更新时间:
复制为 MD 格式

面对大语言模型(LLM)场景中请求长度多变、Token 生成随机及 GPU 资源波动等挑战,传统负载均衡因无法实时感知后端压力而导致实例负载不均,严重影响系统性能。为此,EAS 推出了集智能调度可视化运维于一体的 LLM 智能路由服务,基于 LLM 实时指标动态均衡算力与显存,保障高吞吐与稳定性,并通过内置的 WebUI 工作台,提供实时监控、配置热更新及多用户 API Key 独立管控能力,在实现用户身份隔离的同时大幅降低运维复杂度。

工作原理

核心组件

LLM智能路由服务主要由以下两个核心组件构成:

  • LLM Gateway:流量入口与请求处理中心。接收用户请求并根据LLM Scheduler的决策转发到目标推理实例。

    • 支持HTTP(HTTP_SSE)和 WebSocket 协议。

    • 默认开启 Anthropic API 协议转换功能,能够将符合 Anthropic 规范的请求自动转换为 OpenAI 兼容格式。用户无需修改代码,即可直接使用 Claude Code 等生态工具调用遵循 OpenAI 接口标准的模型服务。详见使用Claude Code调用

  • LLM Scheduler:智能调度的大脑。根据调度策略(如基于前缀缓存)为每个请求选择最优目标实例。

工作流程

关键流程如下:

  1. 接收请求:用户请求到达 LLM Gateway,后端推理实例高负载时缓存请求。

  2. 智能调度LLM GatewayLLM Scheduler发起调度请求,LLM Scheduler基于调度策略和各实例的实时指标选择最优实例。

  3. 请求转发LLM Gateway收到调度结果后,将用户请求直接转发至目标实例。

image

Failover机制

系统设计了多层容错机制以保障服务稳定性:

  • LLM Gateway:建议部署至少2个实例。某个实例故障时,流量自动切换至健康实例。

  • LLM Scheduler:故障时LLM Gateway自动降级为轮询策略转发请求(牺牲调度性能但保证可用),恢复后自动切回智能调度。

  • 推理实例:故障时 LLM Scheduler立即从可用服务列表移除该实例,不再分配新流量,恢复后自动重新加入。

使用限制

  • 服务群组要求

    • LLM智能路由必须与推理服务部署在同一个服务群组下,否则无法正常工作。

    • 同一服务群组中,智能路由服务与队列服务不可同时存在。

  • 仅可在新建推理服务时配置智能路由服务:服务所属的服务群组在创建时确定,创建后不可修改。因此,智能路由功能仅能在新建推理服务时配置,无法通过更新服务为已有推理服务添加或修改智能路由。

  • 推理引擎限制:目前仅支持 vLLM 或 SGLang

  • 不兼容NLBNacos:通过关联 NLB 或 Nacos 调用的推理服务无法同时使用 LLM 智能路由。

  • 推荐部署多推理实例:在部署多个推理实例的场景下,LLM智能路由的功能价值才能得以发挥。

快速开始:使用LLM智能路由

步骤一:部署LLM智能路由服务

  1. 登录PAI控制台,在页面上方选择目标地域。

  2. 在左侧导航栏单击模型在线服务(EAS),选择目标工作空间后进入EAS。

  3. 单击部署服务,选择场景化模型部署>LLM智能路由部署

  4. 配置参数:

    参数

    描述

    基本信息

    服务名称

    自定义服务名称,例如llm_gateway

    资源信息

    部署资源

    LLM Gateway的资源配置。为确保高可用,副本数默认为2,建议保持。默认 CPU 为4核,内存 为8 GB。

    调度配置

    LLM Scheduler的资源配置。默认 CPU 为2核,内存为 4 GB。

    调度策略

    选择后端推理实例的负载均衡策略,默认基于前缀缓存。详细对比和选择建议请参见调度策略详解与选择

    高级功能

    Redis配置

    可选。用来持久化存储用户信息与使用统计数据。未配置时使用本地内存,服务停止时数据将丢失。详情请参见配置 Redis 持久化存储

  5. 单击部署。当服务状态变为运行中,表示部署成功。

    部署成功后,系统会自动创建一个群组服务,命名格式为group_<LLM智能路由服务名称>。您可以前往模型在线服务(EAS)页面的灰度发布页签进行查看。image

步骤二:部署LLM服务

必须在部署新LLM服务时配置智能路由功能,无法通过更新已有LLM服务来添加。

以部署 Qwen3-8B 为例,步骤如下:

  1. 单击部署服务,选择场景化模型部署> LLM大语言模型部署

  2. 配置以下关键参数:

    参数

    基本信息

    模型配置

    选择公共模型,搜索并选择Qwen3-8B

    推理引擎

    选择vLLM(推荐,兼容 OpenAI API)。

    说明

    如果LLM智能路由服务选择基于前缀缓存调度策略,部署LLM服务时若推理引擎选择vLLM,请确保开启引擎的前缀缓存功能。

    部署模板

    选择单机。系统将根据模板自动填充推荐的实例规格、镜像等参数。

    服务功能

    LLM智能路由

    打开开关,从下拉列表中选择步骤一部署的LLM智能路由服务。

  3. 单击部署,服务部署耗时约5分钟。当服务状态变为运行中,表示部署成功。

步骤三:调用测试

所有请求都应发送到LLM智能路由服务的访问地址,而不是后端的具体推理服务。

说明
  • 群组内若有推理服务的流量分配处于开启状态,通过群组总流量入口发起的请求可能绕过智能路由,导致调度失效。

  • 请确保群组内仅智能路由服务的流量分配为开启状态,并通过智能路由服务的独立流量入口地址发起调用。

  1. 获取访问凭证

    1. 单击LLM智能路由服务进入概览页面,在基本信息区域单击查看调用信息

    2. 调用信息页面,复制服务独立流量入口下的公网调用地址Tokenimage

    重要

    此处的服务 Token 即管理员API Key。如果管理员已通过 WebUI 工作台为用户分配了独立 API Key,各用户应使用自己的 API Key 替换下方示例中的 <YOUR_TOKEN>

  2. 构建请求URL并发起调用。

    • URL结构<LLM智能路由访问地址>/<LLM服务API路径>

    • 示例http://********.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completions

    请求示例:

    # 将 <YOUR_GATEWAY_URL> 和 <YOUR_TOKEN> 替换为您的实际信息
    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": "你好"}],
               "stream": true
             }'

    返回结果示例如下:

    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]

服务部署成功后,您可以访问 WebUI 工作台进行可视化管理,包括实时监控、配置中心等功能。详情请参见使用LLM智能路由工作台

配置 Redis 持久化存储

LLM 智能路由默认内置用户管理功能,支持多用户管理、角色权限控制、审计日志和数据概览等能力。使用外部 Redis 可持久化存储用户信息与使用统计数据;未配置 Redis 则使用本地内存,服务停止时数据将丢失,建议在生产场景配置 Redis 存储。

步骤一:准备 Tair (Redis) 实例

  1. 访问Tair售卖页购买实例。

    重要

    专有网络(VPC)和交换机需要选择和待部署的 LLM 智能路由服务相同,其他选项按需配置,建议先选择最低规格。

  2. LLM智能路由服务的交换机网段添加到实例的白名单中,参见设置白名单

  3. 单击目标实例ID进入详情页查看实例连接信息,在部署 LLM 智能路由服务时需要使用。

    • 连接地址+端口号:在实例信息连接信息区域获取专有网络的连接地址和端口号。

    • 用户名+密码:在账号管理页面查看默认账号。若创建实例时未设置密码,可在此修改或重置密码。若不使用默认账号,也可创建新的账号。

步骤二:部署时配置Redis

在基础配置的基础上,配置专有网络并补充 Redis 连接参数,以实现数据持久化存储。

  • 配置专有网络专有网络交换机必须选择与步骤一中 Tair 实例相同的 VPC 和交换机,以确保 LLM 智能路由服务可以访问 Tair 实例。

  • 配置Redis

    控制台配置

    高级功能区域,打开Redis配置功能,并填写:

    参数

    说明

    Redis 地址

    Tair 实例的连接地址,格式为 <专有网络地址>:<端口号>,例如 r-uxxx.redis.rds.aliyuncs.com:6379

    Redis 用户名

    Tair 实例的用户名。

    Redis 密码

    Tair 实例的密码。

    JSON配置

    在 JSON body 的 llm_gateway 节点中,补充以下参数:

    参数

    说明

    enable_user_management

    用户管理功能,默认为 true

    redis_addrs

    Tair 实例的连接地址,格式为 <专有网络地址>:<端口号>,例如 r-uxxx.redis.rds.aliyuncs.com:6379

    redis_username

    Tair 实例的用户名。

    redis_password

    Tair 实例的密码。

    JSON 示例:

    {
        "llm_gateway": {
            "enable_user_management": true,
            "redis_addrs": "r-uxxx.redis.rds.aliyuncs.com:6379",
            "redis_username": "xxx",
            "redis_password": "xxx"
        }
    }

高阶配置(JSON)

JSON独立部署提供了更灵活的配置选项,可以对LLM Gateway 指定资源规格,对请求处理行为进行精细化配置。

配置入口:在推理服务页面,单击部署服务,然后在自定义模型部署区域,单击JSON独立部署

配置示例

{
    "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
        }
    }
}

参数说明

参数

说明

metadata

type

必填。固定为LLMGatewayService,表示部署一个LLM智能路由服务。

instance

必填。LLM Gateway的副本数。建议至少设置为2,以防止单点故障。

cpu

LLM Gateway每个副本的CPU(核数)。

memory

LLM Gateway的内存(GB)。

group

LLM智能路由服务归属的服务群组。

rpc.disable_auth

必填,设为true

cloud.computing.instance_type

指定LLM Gateway使用的资源规格。此时无需配置metadata.cpumetadata.memory

llm_gateway

max_queue_size

LLM Gateway缓存队列的最大长度,默认是512。

当超过后端推理框架处理能力时,多余的请求会缓存在该队列,等待调度。

retry_count

重试次数,默认是2。当后端推理实例异常时,进行请求重试并转发到新的实例。

wait_schedule_timeout

当后端引擎处于满负荷时,请求会间隔尝试进行调度。该参数表示尝试调度的时间,默认为10秒。

wait_schedule_try_period

每次尝试调度的间隔时间,默认为1秒。

llm_scheduler

cpu

LLM SchedulerCPU(核数),默认为4核。

memory

LLM Scheduler的内存(GB),默认为4 GB。

policy

调度策略,默认值prefix-cache。可选值及说明请参见调度策略详解与选择

prefill_policy

policy选择pd-split时,需分别指定PrefillDecode阶段的调度策略。可取值:prefix-cache、llm-metric-based、least-request、least-token。

decode_policy

附录

使用Claude Code调用

  1. 设置 Claude Code 使用EAS智能路由服务提供的 BASE URL 与 TOKEN。

    # 将 <YOUR_GATEWAY_URL> 和 <YOUR_TOKEN> 替换为您的实际信息
    export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL>
    export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN>
  2. 直接运行 Claude Code 工具。

    claude "写一个 Python 的 Hello World"

调度策略详解与选择

选择合适的调度策略是发挥LLM智能路由价值的关键。下表详细对比了各种策略的逻辑、适用场景及优缺点,帮助您做出最佳决策。

策略名称

JSON

核心逻辑

适用场景

优点

注意事项

基于前缀缓存

prefix-cache

(推荐) 综合性策略。优先将具有相同历史上下文(Prompt)的请求发往已缓存其KV Cache的实例。

多轮对话机器人、RAG系统中System Prompt固定的场景。

显著降低TTFT,提升多轮对话性能和吞吐量。

需推理引擎开启Prefix Caching功能。

最少请求

least-request

将新请求发送到当前正在处理的请求数量最少的实例。

请求的计算复杂度(Token长度、生成长度)相对均匀的场景。

简单高效,能快速均衡实例间的请求数量。

无法感知请求的实际负载,可能导致短请求实例空闲,长请求实例过载。

最少token

least-token

将新请求发送到当前正在处理的Token总数(输入+输出)最少的实例。

Token数量能较好地反映请求处理成本的场景。

比“最少请求”更能反映实例的真实负载。

依赖对Token数量的预估,且并非所有引擎都上报此指标。

静态PD分离

pd-split

需预先将实例划分为Prefill组和Decode组,并为两组分别指定调度策略。

PrefillDecode阶段的计算/访存特性差异巨大,且分离部署能带来显著收益的场景。

极致优化,最大化硬件利用率。

配置复杂,需要对模型和业务有深入理解,并独立部署PrefillDecode服务。

性能测试对比

通过对Distill-Qwen-7B、QwQ-32BQwen2.5-72B三个模型进行测试,发现LLM智能路由在推理服务的速度和吞吐上有显著的性能提升,具体的测试环境和测试结果如下。

重要

以下测试结果仅供参考,实际表现请以您的实际测试结果为准。

测试环境

  • 调动策略:prefix-cache

  • 测试数据: ShareGPT_V3_unfiltered_cleaned_split.json (多轮对话数据集)

  • 推理引擎: vLLM (0.7.3)

  • 后端实例数: 5

测试结果

测试模型

Distill-Qwen-7B

QwQ-32B

Qwen2.5-72b

卡型

ml.gu8tf.8.40xlarge

ml.gu8tf.8.40xlarge

ml.gu7xf.8xlarge-gu108

并发数

500

100

100

指标

LLM智能路由

使用LLM智能路由

效果提升

LLM智能路由

使用LLM智能路由

效果提升

LLM智能路由

使用LLM智能路由

效果提升

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

-