面對大語言模型(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"
調度策略詳解與選擇
下表對比了各調度策略的邏輯、適用情境及優缺點,協助您選擇合適的策略。
|
策略名稱稱 |
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 |
- |