阿里云国际代理商：人工智能平台PAI-使用LLM智能路由提升推理效率

面对大语言模型（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：智能调度的大脑。根据调度策略（如基于前缀缓存）为每个请求选择最优目标实例。

工作流程

关键流程如下：

接收请求：用户请求到达 LLM Gateway，后端推理实例高负载时缓存请求。
智能调度：LLM Gateway向LLM Scheduler发起调度请求，LLM Scheduler基于调度策略和各实例的实时指标选择最优实例。
请求转发：LLM Gateway收到调度结果后，将用户请求直接转发至目标实例。

Failover机制

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

LLM Gateway：建议部署至少2个实例。某个实例故障时，流量自动切换至健康实例。
LLM Scheduler：故障时LLM Gateway自动降级为轮询策略转发请求（牺牲调度性能但保证可用），恢复后自动切回智能调度。
推理实例：故障时 LLM Scheduler立即从可用服务列表移除该实例，不再分配新流量，恢复后自动重新加入。

使用限制

服务群组要求：
- LLM智能路由必须与推理服务部署在同一个服务群组下，否则无法正常工作。
- 同一服务群组中，智能路由服务与队列服务不可同时存在。
仅可在新建推理服务时配置智能路由服务：服务所属的服务群组在创建时确定，创建后不可修改。因此，智能路由功能仅能在新建推理服务时配置，无法通过更新服务为已有推理服务添加或修改智能路由。
推理引擎限制：目前仅支持 vLLM 或 SGLang。
不兼容NLB和Nacos：通过关联 NLB 或 Nacos 调用的推理服务无法同时使用 LLM 智能路由。
推荐部署多推理实例：部署多个推理实例时，LLM智能路由才能发挥调度优势。

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

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

登录PAI控制台，在页面上方选择目标地域。
在左侧导航栏单击模型在线服务（EAS），选择目标工作空间后进入EAS。
单击部署服务，选择场景化模型部署>LLM智能路由部署。

配置参数：

参数		描述
基本信息	服务名称	自定义服务名称，例如`llm_gateway`。
资源信息	部署资源	`LLM Gateway`的资源配置。为确保高可用，副本数默认为2，建议保持。默认 CPU 为4核，内存为8 GB。
	调度配置	`LLM Scheduler`的资源配置。默认 CPU 为2核，内存为 4 GB。
	调度策略	选择后端推理实例的负载均衡策略，默认基于前缀缓存。详细对比和选择建议请参见调度策略详解与选择。
高级功能	Redis配置	可选。用来持久化存储用户信息与使用统计数据。未配置时使用本地内存，服务停止时数据将丢失。详情请参见配置 Redis 持久化存储。

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

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

步骤二：部署LLM服务

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

以部署 Qwen3-8B 为例，步骤如下：

单击部署服务，选择场景化模型部署> LLM大语言模型部署。

配置以下关键参数：

参数		值
基本信息	模型配置	选择公共模型，搜索并选择Qwen3-8B。
	推理引擎	选择vLLM（推荐，兼容 OpenAI API）。说明如果LLM智能路由服务选择基于前缀缓存的调度策略，部署LLM服务时若推理引擎选择vLLM，请确保开启引擎的前缀缓存功能。
	部署模板	选择单机。系统将根据模板自动填充推荐的实例规格、镜像等参数。
服务功能	LLM智能路由	打开开关，从下拉列表中选择步骤一部署的LLM智能路由服务。

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

步骤三：调用测试

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

说明

群组内若有推理服务的流量分配处于开启状态，通过群组总流量入口发起的请求可能绕过智能路由，导致调度失效。
请确保群组内仅智能路由服务的流量分配为开启状态，并通过智能路由服务的独立流量入口地址发起调用。

获取访问凭证。
1. 单击LLM智能路由服务进入概览页面，在基本信息区域单击查看调用信息。
2. 在调用信息页面，复制服务独立流量入口下的公网调用地址和Token。
重要

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

构建请求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) 实例

访问Tair售卖页购买实例。

重要

专有网络（VPC）和交换机需要选择和待部署的 LLM 智能路由服务相同，其他选项按需配置，建议先选择最低规格。
将LLM智能路由服务的交换机网段添加到实例的白名单中，参见设置白名单。
单击目标实例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.cpu`与`metadata.memory`。
llm_gateway	max_queue_size	`LLM Gateway`缓存队列的最大长度，默认是512。当超过后端推理框架处理能力时，多余的请求会缓存在该队列，等待调度。
	retry_count	重试次数，默认是2。当后端推理实例异常时，进行请求重试并转发到新的实例。
	wait_schedule_timeout	当后端引擎处于满负荷时，请求会间隔尝试进行调度。该参数表示尝试调度的时间，默认为10秒。
	wait_schedule_try_period	每次尝试调度的间隔时间，默认为1秒。
	request_stream_prefill_timeout	Prefill 超时（秒），流式请求等待首包的截止时间，默认值300。
	request_stream_decode_timeout	Decode 超时（秒），流式请求 chunk 间最大空闲间隔，默认值300。
	request_stream_total_timeout	Stream 总超时（秒），整个流式请求的最大时长，默认值0，表示无超时限制。
	request_non_stream_timeout	非流式超时（秒），非流式请求的完整响应超时，默认值900。
llm_scheduler	cpu	`LLM Scheduler`的CPU（核数），默认为4核。
	memory	`LLM Scheduler`的内存（GB），默认为4 GB。
	policy	调度策略，默认值`prefix-cache`。可选值及说明请参见调度策略详解与选择。
	prefill_policy	policy选择pd-split时，需分别指定Prefill和Decode阶段的调度策略。可取值：prefix-cache、llm-metric-based、least-request、least-token。
	decode_policy

附录

使用Claude Code调用

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

# 将 <YOUR_GATEWAY_URL> 和 <YOUR_TOKEN> 替换为您的实际信息
export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL>
export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN>

直接运行 Claude Code 工具。

claude "写一个 Python 的 Hello World"

调度策略详解与选择

下表对比了各调度策略的逻辑、适用场景及优缺点，帮助您选择合适的策略。

策略名称	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组，并为两组分别指定调度策略。	Prefill和Decode阶段的计算/访存特性差异巨大，且分离部署能带来显著收益的场景。	极致优化，最大化硬件利用率。	配置复杂，需要对模型和业务有深入理解，并独立部署Prefill和Decode服务。

性能测试对比

对Distill-Qwen-7B、QwQ-32B和Qwen2.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智能路由	效果提升

测试模型	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	–