在大語言模型（LLM）應用中，使用者請求與模型響應的長度差異、模型在Prompt和Generate階段產生的Token數量的隨機性，以及GPU資源佔用的不確定性，使得傳統負載平衡策略難以即時感知後端負載壓力，導致執行個體負載不均，影響系統輸送量和響應效率。EAS推出LLM智能路由群組件，基於LLM特有的Metrics動態分發請求，均衡各推理執行個體的算力與顯存分配，提升叢集資源使用率與系統穩定性。
工作原理
架構概覽
LLM智能路由是由LLM Gateway、LLM Scheduler以及LLM Agent三個核心組件構成，它們協同工作，為後端的大語言模型推理執行個體叢集提供智能的流量分發和管理。
LLM Gateway：作為流量入口，負責接收所有使用者請求，並根據
LLM Scheduler的決策將請求轉寄到指定的後端推理執行個體。它支援HTTP（HTTP_SSE）和WebSocket協議，並在後端推理執行個體高負載時可緩衝請求。LLM Scheduler：作為智能路由的大腦，負責執行調度演算法。它從所有
LLM Agent處彙集即時指標，並根據預設的調度策略（如基於首碼緩衝）為每個到來的請求計算出最優的目標執行個體。LLM Agent：作為Sidecar容器與每個推理執行個體一同部署。它負責採集推理引擎的效能指標，與
LLM Scheduler保持心跳，並上報執行個體的健康情況和負載資料。
實現流程
LLM智能路由本質上是一種特殊的EAS服務，必須和推理服務部署在同一個服務群組下，才能正常工作。部署LLM智能路由和推理服務後，LLM智能路由能夠將請求智能調度給後端推理服務，具體實現流程如下：
執行個體註冊：推理服務啟動後，
LLM Agent等待推理引擎就緒，然後向LLM Scheduler註冊該執行個體，並開始周期性上報健康情況和效能指標。流量接入：使用者的請求首先到達
LLM Gateway。Gateway支援HTTP（SSE）和WebSocket協議。調度決策：
LLM Gateway向LLM Scheduler發起調度請求。智能調度：
LLM Scheduler基於調度策略，根據從各LLM Agent收集的即時指標，選擇一個當前最優的後端執行個體。請求轉寄：
LLM Scheduler將決策結果返回給LLM Gateway，LLM Gateway隨即把使用者的原始請求轉寄到該目標執行個體進行推理。請求緩衝：當所有後端執行個體均處於高負載狀態時，新請求會暫時緩衝在
LLM Gateway的隊列中，等待LLM Scheduler找到合適的轉寄時機，以避免請求失敗。
Failover機制
系統設計了多層容錯機制以保障服務穩定性：
LLM Gateway：作為無狀態的流量接入層，建議部署至少2個執行個體。當某個執行個體故障時，流量會自動切換至其他健康執行個體，保證服務的持續可用性。
LLM Scheduler：作為請求調度組件，單一實例運行以實現全域調度。
LLM Scheduler發生故障時，LLM Gateway會在心跳失敗後自動降級，採用輪詢策略將請求直接轉寄給後端執行個體。這保證了服務的可用性，但會犧牲調度效能。待LLM Scheduler恢複後，LLM Gateway會自動切換回智能調度模式。推理執行個體或LLM Agent：當某個推理執行個體或其伴生的
LLM Agent發生故障時，LLM Agent與LLM Scheduler之間的心跳會中斷。LLM Scheduler會立即將該執行個體從可用服務列表中移除，不再向其分配新流量。待執行個體恢複並重新上報心跳後，它將自動重新加入服務列表。
多推理引擎支援
由於不同LLM推理引擎的/metrics介面返回的指標資訊存在差異，LLM Agent負責對這些指標進行採集並統一格式化處理後上報。LLM Scheduler無需關注具體推理引擎的實現細節，只需基於統一化指標進行調度演算法的編寫。目前支援的LLM推理引擎及其對應的採集指標如下：
LLM推理引擎 | 指標 | 說明 |
Blade_LLM | decode_batch_size_mean | 正在啟動並執行請求數。 |
wait_queue_size_mean | 在排隊等待的請求數。 | |
block_usage_gpu_mean | GPU KV Cache的使用率。 | |
tps_total | 每秒總共處理的Token數。 | |
tps_out | 每秒產生的Token數。 | |
vLLM | vllm:num_requests_running | 正在啟動並執行請求數。 |
vllm:num_requests_waiting | 在排隊等待的請求數。 | |
vllm:gpu_cache_usage_perc | GPU KV Cache的使用率。 | |
vllm:prompt_tokens_total | 總Prompt的Token數。 | |
vllm:generation_tokens_total | 產生的總的Token數。 | |
SGLang | sglang:num_running_reqs | 正在啟動並執行請求數。 |
sglang:num_queue_reqs | 在排隊等待的請求數。 | |
sglang:token_usage | KV Cache的使用率。 | |
sglang:prompt_tokens_total | 總Prompt的Token數。 | |
sglang:gen_throughput | 每秒產生的Token數。 |
使用限制
不支援更新時添加：LLM智能路由功能僅能在建立新服務時配置。對於一個已存在的、未使用智能路由的推理服務，無法通過更新服務操作來為其添加智能路由。
推理引擎節流：目前僅支援 PAI-BladeLLM、vLLM 或 SGLang。
推薦部署多推理執行個體：在部署多個推理執行個體的情境下，LLM智能路由的功能價值才能得以發揮。
部署服務
步驟一：部署LLM智能路由服務
支援以下兩種部署方式：
方式一：通過控制台部署
登入PAI控制台，在頁面上方選擇目標地區，並在右側選擇目標工作空間，然後單擊進入EAS。
在模型在线服务（EAS）頁面，單擊部署服务，選擇场景化模型部署>LLM智能路由部署。
在LLM智能路由部署頁面，配置以下關鍵參數，然後單擊部署。
參數
描述
基本信息
服务名称
自訂服務名稱，例如llm_gateway。
部署资源
LLM Gateway的資源配置。為確保高可用，最小執行個體數預設為2，建議保持。預設 CPU 為4核，記憶體 為8 GB。调度配置
LLM Scheduler調度資源。預設為 CPU 2核，記憶體 4 GB。调度策略
系統基於調度策略選擇後端最佳推理執行個體，支援的調度策略如下：
基于前缀缓存：KV Cache親和性調度，是一種綜合性調度策略，基於多項指標進行決策。將請求轉寄到已緩衝相應KV Cache的執行個體中處理，從而使請求的處理效率最大化。使用時，需將引擎的首碼緩衝（Prefix Caching）功能開啟。
基于LLM指标：基於LLM服務的各項監控指標，智能分配服務流量，保證資源利用效率最大化。
最少请求：優先選擇當前請求數最少的執行個體來分配新請求。
最少token：優先選擇當前處理token數量最少的執行個體來分配新請求。
静态PD分离：在Prefill-Decode分離的LLM部署方案中，選擇該策略可最大化提升調度效率。選擇之後需要分別設定Prefill和Decode的調度策略。
动态PD分离：根據實際服務負載、KVCache緩衝以及GPU利用率等關鍵計量，智能地實現Prefill執行個體與Decode執行個體的自動動態切換。在使用動態PD分離的LLM部署方案中，選擇該策略可最大化提升調度效率。
部署成功後，系統會自動建立一個群組服務，命名格式為group_LLM智能路由服務名稱。您可以前往模型線上服務（EAS）頁面的灰度发布頁簽進行查看。
由於智能路由與服務隊列存在衝突，同一服務群組中兩者不可同時存在。
方式二：通過JSON獨立部署
登入PAI控制台，在頁面上方選擇目標地區，並在右側選擇目標工作空間，然後單擊進入EAS。
在模型線上服務（EAS）頁面，單擊部署服务，然後在自定义模型部署地區，單擊JSON独立部署。
JSON配置樣本和參數說明如下，配置完成後單擊部署。
配置樣本：
基礎配置
使用基礎配置可快速部署LLM智能路由服務，未配置的參數將使用預設值。
LLM Scheduler預設資源配置為4核CPU和4 GB記憶體，調用策略預設為基于前缀缓存。
{ "metadata": { "type": "LLMGatewayService", "cpu": 4, "group": "group_llm_gateway", "instance": 2, "memory": 8000, "name": "llm_gateway" } }高階配置
{ "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" } }參數說明：
參數
說明
metadata
type
配置為LLMGatewayService，即可部署LLM智能路由服務。服務部署成功後，EAS會自動建立一個組合服務，包含
LLM Gateway和LLM Scheduler。instance
LLM Gateway執行個體數，建議至少設定為2，以防止單點故障。cpu
LLM Gateway的CPU。memory
LLM Gateway的Memory。group
LLM智能路由服務歸屬的服務群組。
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秒。
llm_scheduler
cpu
LLM Scheduler的CPU，預設為4核。memory
LLM Scheduler的Memory，預設為4 GB。policy
調度策略（詳見控制台部署說明），預設值為prefix-cache。可取值：
prefix-cache：基于前缀缓存。
llm-metric-based：基于LLM指标。
least-request：最少请求。
least-token：最少token。
pd-split：静态PD分离。
dynamic-pd-split：动态PD分离。
prefill_policy
policy選擇pd-split時，需分別設定Prefill和Decode的調度策略。可取值：prefix-cache、llm-metric-based、least-request、least-token。
decode_policy
步驟二：部署大語言模型（LLM）服務
部署LLM服務時，需將其關聯到已建立的智能路由服務。本文以EAS情境化部署LLM為例，具體操作步驟如下：
登入PAI控制台，在頁面上方選擇目標地區，並在右側選擇目標工作空間，然後單擊進入EAS。
在推理服务頁面，單擊部署服务，選擇LLM大语言模型部署。在服务功能地區找到並開啟LLM智能路由開關，從下拉式清單中選擇在步驟一部署的LLM智能路由服務。其他參數參見LLM大語言模型部署。
說明當使用vLLM加速部署，並且LLM智能路由服務的調度策略選擇基于前缀缓存時，需將引擎的首碼緩衝功能開啟。
參數配置完成後，單擊部署。
調用與測試
所有請求都應發送到LLM智能路由服務的訪問地址，而不是後端的具體推理服務。
擷取訪問憑證
在模型線上服務（EAS）頁面，找到部署的LLM智能路由服務。
單擊服務名稱進入概览頁面，在基本信息地區單擊查看调用信息。
在調用資訊頁面，複製服务独立流量入口下的公網調用地址和Token。
構建與發送請求
最終的請求URL由LLM智能路由的訪問地址和模型服務的API路徑拼接而成。
URL結構:
<LLM智能路由訪問地址>/<LLM服務要求介面>樣本:
http://********.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completions
請求樣本：
# 將 <YOUR_GATEWAY_URL> 和 <YOUR_TOKEN> 替換為您的實際資訊
# <model_name> 替換為實際的模型名稱
curl -X POST "<YOUR_GATEWAY_URL>/v1/chat/completions" \
-H "Authorization: Bearer <YOUR_TOKEN>" \
-H "Content-Type: application/json" \
-N \
-d '{
"model": "<model_name>",
"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]查看服務監控指標
部署服務後，可以在EAS控制台查看服務的核心效能指標，以評估智能路由的效果。
在模型線上服務（EAS）頁面，單擊已部署的LLM智能路由服務進入服務詳情。在监控頁簽，關注以下核心指標：
Token Throughput LLM輸入和輸出Token的輸送量
| GPU Cache Usage LLM Engine GPU KV Cache的使用率
|
Engine Current Requests LLM Engine即時請求並發數
| Gateway Current Requests LLM智能路由即時請求數
|
Time To First Token 請求的首包延時
| Time Per Output Token 請求的每包延時
|
