全部產品
Search
文件中心

Platform For AI:使用LLM智能路由提升推理效率

更新時間:Jun 26, 2026

面對大語言模型(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收到調度結果後,將使用者請求直接轉寄至目標執行個體。

Failover機制

系統設計了多層容錯機制以保障服務穩定性:

  • LLM Gateway:建議部署至少2個執行個體。某個執行個體故障時,流量自動切換至健康執行個體。

  • LLM Scheduler:故障時LLM Gateway自動降級為輪詢策略轉寄請求(犧牲調度效能但保證可用),恢複後自動切回智能調度。

  • 推理執行個體:故障時 LLM Scheduler立即從可用服務列表移除該執行個體,不再分配新流量,恢複後自動重新加入。

使用限制

  • 服務群組要求

    • LLM智能路由必須與推理服務部署在同一個服務群組下,否則無法正常工作。

    • 同一服務群組中,智能路由服務與佇列服務不可同時存在。

  • 僅可在建立推理服務時配置智能路由服務:服務所屬的服務群組在建立時確定,建立後不可修改。因此,智能路由功能僅能在建立推理服務時配置,無法通過更新服務為已有推理服務添加或修改智能路由。

  • 推理引擎節流:目前僅支援 vLLM 或 SGLang

  • 不相容NLB和Nacos:通過關聯 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售賣頁購買執行個體。

    重要

    Virtual Private Cloud和交換器需要選擇和待部署的 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 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調用

  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"

調度策略詳解與選擇

下表對比了各調度策略的邏輯、適用情境及優缺點,協助您選擇合適的策略。

策略名稱稱

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

-