面对大语言模型(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智能路由服务的访问地址,而不是后端的具体推理服务。
群组内若有推理服务的流量分配处于开启状态,通过群组总流量入口发起的请求可能绕过智能路由,导致调度失效。
请确保群组内仅智能路由服务的流量分配为开启状态,并通过智能路由服务的独立流量入口地址发起调用。
获取访问凭证。
单击LLM智能路由服务进入概览页面,在基本信息区域单击查看调用信息。
在调用信息页面,复制服务独立流量入口下的公网调用地址和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) 实例
步骤二:部署时配置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_addrsTair 实例的连接地址,格式为
<专有网络地址>:<端口号>,例如r-uxxx.redis.rds.aliyuncs.com:6379。redis_usernameTair 实例的用户名。
redis_passwordTair 实例的密码。
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 | 必填。固定为 |
instance | 必填。 | |
cpu |
| |
memory |
| |
group | LLM智能路由服务归属的服务群组。 | |
rpc.disable_auth | 必填,设为 | |
cloud.computing.instance_type | 指定 | |
llm_gateway | max_queue_size |
当超过后端推理框架处理能力时,多余的请求会缓存在该队列,等待调度。 |
retry_count | 重试次数,默认是2。当后端推理实例异常时,进行请求重试并转发到新的实例。 | |
wait_schedule_timeout | 当后端引擎处于满负荷时,请求会间隔尝试进行调度。该参数表示尝试调度的时间,默认为10秒。 | |
wait_schedule_try_period | 每次尝试调度的间隔时间,默认为1秒。 | |
llm_scheduler | cpu |
|
memory |
| |
policy | 调度策略,默认值 | |
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"
调度策略详解与选择
选择合适的调度策略是发挥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组,并为两组分别指定调度策略。 | 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智能路由 | 效果提升 |
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 | - |