請求排程 (Request Scheduling)

3 秒看懂

一句話定義： 請求排程是 LLM 推論服務系統中，決定”哪些使用者請求、以什麼順序、用哪些 GPU 資源、以什麼批處理策略執行”的核心決策引擎。

類比： 它是 LLM 推論叢集的”交通指揮中心”——決定哪輛車先走、走哪條車道、是否讓道，直接決定了吞吐量（每秒處理多少 token）和延遲（使用者多久拿到結果）。

核心矛盾： 吞吐 vs 延遲 vs 資源利用率——三者永遠在博弈。

3 分鐘產業解釋

為什麼請求排程突然成為關鍵？

2023–2024 年 LLM 應用爆發後，推論服務的成本問題急劇凸顯。訓練是一次性的，推論是持續性的——頭部應用（ChatGPT、Claude、Gemini 等）的推論算力消耗已遠超訓練。在此背景下，推論服務的效率最佳化成為產業核心議題，而請求排程正是影響推論效率的第一道關口。

核心邏輯鏈：

使用者請求到達 → [請求排程器] → 決定批次組成 → 分配 GPU 資源 → 執行推論 → 返回結果
                     ↑
          排程策略直接決定：
          - GPU 利用率（空轉 vs 滿載）
          - 請求排隊時間（毫秒 vs 秒級）
          - 系統吞吐量（tokens/s）
          - 使用者體感延遲（TTFT / TPOT / TPS）

產業角色定位

請求排程不是一個獨立產品，而是推論引擎/推論服務平台的核心子系統。它內嵌於：

層級	代表	排程器的角色
開源推論引擎	vLLM、SGLang、TensorRT-LLM、llama.cpp	內建排程器模組
雲端推論服務	AWS Bedrock、Azure AI、Google Vertex AI	平台級排程
專用推論晶片廠商	Groq、Cerebras、SambaNova	排程與硬體強耦合
企業自建推論叢集	各大廠內部 Serving 平台	自研排程系統

一句話：誰控制了排程，誰就控制了推論成本。

---

15 分鐘專家深入

1. 請求排程的核心問題域

LLM 推論的請求排程與傳統分散式系統排程（如 Kubernetes Pod 排程、資料庫查詢最佳化）有本質區別，根源在於 LLM 推論的三個獨特約束：

約束一：自迴歸生成的動態性

• LLM 推論是逐 token 自迴歸生成，每個請求的輸出長度在排程時不可精確預知
• 使用者問”1+1=?”可能只需 1 個輸出 token，問”幫我寫篇文章”可能需要數千個
• 這導致請求的資源消耗（主要是 KV Cache 視訊記憶體佔用）隨時間動態變化

約束二：KV Cache 的視訊記憶體瓶頸

• 每個請求在推論過程中需要維護其所有已生成 token 的 Key/Value 快取
• KV Cache 的視訊記憶體佔用隨序列長度線性增長，是推論視訊記憶體的最大消耗者
• 排程器必須即時感知每個 GPU 的 KV Cache 佔用狀態

約束三：Prefill 與 Decode 的資源特性截然不同

• Prefill 階段（處理輸入 prompt）：計算密集型，GPU 算力是瓶頸
• Decode 階段（逐 token 生成）：訪存密集型，視訊記憶體頻寬是瓶頸
• 兩個階段對硬體資源的需求模式完全不同

2. 排程決策的四個維度

┌─────────────────────────────────────────────────┐
│              請求排程器決策空間                     │
├─────────────┬───────────────┬───────────────────┤
│  ① 誰先做？  │  ② 和誰一起做？ │  ③ 用什麼資源做？   │
│  (優先順序)    │  (批處理策略)   │  (資源分配)        │
├─────────────┼───────────────┼───────────────────┤
│  FCFS       │  靜態 batching │  單 GPU 內排程     │
│  優先順序佇列  │  連續 batching │  跨 GPU 排程       │
│  SRPT       │  Chunked      │  跨節點排程        │
│  公平排程    │  prefill      │  Prefill/Decode   │
│             │               │  分離部署          │
├─────────────┴───────────────┴───────────────────┤
│  ④ 什麼時候讓路？(搶佔與遷移策略)                    │
│  - 搶佔低優先順序請求釋放 KV Cache                     │
│  - KV Cache 解除安裝到 CPU/SSD                        │
└─────────────────────────────────────────────────┘

3. 從靜態 Batching 到連續 Batching：範式躍遷

傳統靜態 Batching（2022 年前主流）：

時間 →
請求A: [==========]
請求B: [======     ]  ← B 先生成完，但必須等 A
請求C: [=========  ]  ← C 也必須等
                ↑
          整個 batch 結束才能釋放資源
          GPU 利用率低，延遲高

問題：短請求被長請求”綁架”，GPU 在短請求完成後處於空轉狀態。

連續 Batching（Continuous Batching / Iteration-level Batching）：

這一範式由 Orca 論文（OSDI 2022）系統性提出。核心思想是將排程粒度從”請求級”降低到”迭代級”（即每次 forward step）。

時間 → (每個 tick = 一次 forward step)
tick1: [A] [B] [C] [D]
tick2: [A] [B] [C] [D]
tick3: [A] [B] [C]     ← D 已完成，slot 空出
tick4: [A] [B] [C] [E] ← 新請求 E 立即填入
tick5: [A] [B]     [E] ← C 完成
...

核心收益：

• 請求完成即釋放資源，新請求可立即加入
• GPU 利用率顯著提升
• 長短請求混合執行，系統吞吐量大幅提升

現狀： 連續 Batching 已成為主流推論引擎的標配基線。

4. Prefill-Decode 分離排程：前沿架構

隨著推論規模增長，一種更激進的排程架構出現：將 Prefill 和 Decode 階段拆分到不同的 GPU 組（或不同型別的硬體）上執行。

                    ┌──────────────┐
使用者請求 ──────────→│  排程路由器    │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ↓                         ↓
    ┌──────────────────┐     ┌──────────────────┐
    │  Prefill 節點組    │     │  Decode 節點組     │
    │  (高算力 GPU)     │     │  (高頻寬 GPU)     │
    │  - 計算密集       │     │  - 訪存密集       │
    │  - 短時佔用       │     │  - 長時佔用       │
    └────────┬─────────┘     └──────────────────┘
             │
             │ KV Cache 傳輸
             ↓
    ┌──────────────────┐
    │  KV Cache 池      │
    │  (高頻寬互聯)     │
    └──────────────────┘

為什麼分離？

• Prefill 是 compute-bound，需要高 FLOPS；Decode 是 memory-bandwidth-bound，需要高 HBM 頻寬
• 兩類負載混合在同一 GPU 上會互相干擾
• 分離後可分別針對各自瓶頸最佳化硬體選型和排程策略

代表性工作/產品方向（定性）：

• DistServe（PD 分離論文，UCSD 等）
• Splitwise（微軟研究院相關工作）
• 多個雲端廠商在生產環境中探索 Prefill-Decode 分離部署

核心挑戰： Prefill 完成後的 KV Cache 需要高速傳輸到 Decode 節點，互聯頻寬成為關鍵瓶頸。

5. Chunked Prefill 排程策略

一個關鍵最佳化：當長 prompt 進入 Prefill 時，它會獨佔 GPU 較長時間，導致正在 Decode 的請求被”餓死”（延遲飆升）。

Chunked Prefill 的核心思想：將長 prompt 的 Prefill 切成多個 chunk，每個 chunk 與 Decode 請求交替執行。

時間 →
未最佳化:  [====長Prefill====] [D1] [D2] [D3] ...
                        ↑ decode 請求被阻塞
Chunked: [P1][D1D2D3][P2][D1D2D3][P3][D1D2D3] ...
         ↑ Prefill chunks 與 decode 交錯執行

效果： Decode 請求的延遲抖動（jitter）顯著降低，長 prompt 不再”堵車”。

vLLM 和 SGLang 等主流引擎已支援 Chunked Prefill，具體引數（chunk 大小等）可配置。

6. 搶佔與 KV Cache 管理

當 GPU 視訊記憶體被 KV Cache 佔滿時，排程器面臨選擇：

搶佔策略（Preemption）：

• Recomputation： 低優先順序請求被驅逐，重新排隊；恢復時從頭計算 Prefill（浪費算力但省視訊記憶體）
• Swapping： 將低優先順序請求的 KV Cache 解除安裝到 CPU 記憶體或 SSD，恢復時載入回來（省算力但需傳輸時間）

排程器需要即時決策：

新請求到達 → KV Cache 容量不足？
  ├─ 是 → 選擇哪些請求搶佔？
  │       ├─ 優先順序低的先搶佔
  │       ├─ 已生成 token 多的（重啟成本高）可能保留
  │       └─ 預估剩餘生成長度短的（快完成了）可能等待
  └─ 否 → 正常加入 batch

---

技術原理（深度機制講解）

1. 請求生命週期與排程器互動

┌─────────────────────────────────────────────────────────────────┐
│                    請求完整生命週期                                │
│                                                                   │
│  使用者請求到達                                                     │
│      │                                                           │
│      ↓                                                           │
│  ┌──────────┐    ┌──────────────┐    ┌────────────┐             │
│  │ 請求解析  │ →  │ 排程器決策    │ →  │ 等待佇列    │             │
│  │ 優先順序分配│    │ - 資源檢查    │    │ (按策略排序) │             │
│  │          │    │ - 批次組成    │    └─────┬──────┘             │
│  └──────────┘    │ - 搶佔決策    │          │                    │
│                  └──────────────┘          ↓                    │
│                                     ┌──────────────┐            │
│                                     │ Prefill 階段  │            │
│                                     │ (計算輸入token│            │
│                                     │  的 KV Cache) │            │
│                                     └──────┬───────┘            │
│                                            │                     │
│                                            ↓                     │
│  ┌──────────────────────────────────────────────────────┐       │
│  │ Decode 階段（逐 token 生成，參與連續 Batching）         │       │
│  │  for each iteration:                                  │       │
│  │    scheduler.select_active_requests()                 │       │
│  │    batch.forward_step()     ← 生成 1 個 token         │       │
│  │    scheduler.check_completion()                       │       │
│  │    scheduler.check_new_requests()  ← 可能有新請求插入  │       │
│  └──────────────────────────────────────────────────────┘       │
│                         │                                        │
│                   請求完成 / 超時 / 被搶佔                         │
│                         ↓                                        │
│                   釋放 KV Cache，返回結果                          │
└─────────────────────────────────────────────────────────────────┘

2. 排程演算法詳解

2.1 FCFS（First-Come-First-Served）

最簡單，按到達順序排程。公平但不高效——一個超長請求可能阻塞後續所有短請求。

2.2 SRPT（Shortest Remaining Processing Time）

優先排程”預估剩餘時間最短”的請求。

優勢：最小化平均完成時間
挑戰：LLM 請求的剩餘長度難以準確預估
實踐：可用 prompt 長度、模型特性、歷史統計做啟發式估計
風險：長請求可能被無限延遲（飢餓問題）

2.3 基於優先順序的排程

優先順序來源：
  - 使用者等級（付費 > 免費）
  - 請求型別（即時對話 > 批次處理）
  - SLA 約束（延遲敏感 > 吞吐敏感）
  - 字首快取命中率（有快取的請求啟動成本低）

實現方式：
  - 多優先順序佇列
  - 加權輪詢
  - 搶佔式 vs 非搶佔式

2.4 字首感知排程（Prefix-Aware Scheduling）

動機： 如果多個請求共享相同字首（system prompt、few-shot examples 等），它們的 KV Cache 可以複用。

請求A: [system prompt | 使用者問題A]
請求B: [system prompt | 使用者問題B]
請求C: [system prompt | 使用者問題C]

→ 三個請求共享 system prompt 的 KV Cache
→ 排程器應將共享字首的請求聚合在一起執行
→ 減少重複計算，降低視訊記憶體佔用

代表實現： SGLang 的 RadixAttention 通過字首樹（Radix Tree）管理共享字首的 KV Cache，排程時優先複用已有快取的請求組合。

3. 排程器的核心資料結構

# 簡化的排程器狀態模型（虛擬碼）

class SchedulerState:
    # 每個 GPU 的狀態
    gpu_slots: List[GpuSlot]

class GpuSlot:
    total_kv_cache_budget: int    # 總 KV Cache 視訊記憶體預算（tokens 數）
    used_kv_cache: int            # 已使用的 KV Cache
    active_requests: List[Request] # 當前正在 decode 的請求
    waiting_queue: PriorityQueue  # 等待佇列
    
class Request:
    request_id: str
    prompt_tokens: int             # 輸入 token 數
    generated_tokens: int          # 已生成 token 數
    max_new_tokens: int            # 最大可生成 token 數
    priority: int                  # 優先順序
    kv_cache_usage: int            # 當前 KV Cache 佔用
    status: Enum(WAITING, PREFILLING, RUNNING, SWAPPED, PREEMPTED)
    
class Scheduler:
    def schedule_step(self):
        """每次 forward step 的排程決策"""
        # 1. 檢查是否有請求完成，釋放資源
        self._handle_completions()
        
        # 2. 嘗試喚醒被搶佔/swap 的請求
        self._try_resume_preempted()
        
        # 3. 從等待佇列取新請求，檢查 KV Cache 容量
        new_batch = self._select_new_requests()
        
        # 4. 如果容量不足，執行搶佔
        if not self._has_capacity(new_batch):
            self._preempt(self._select_victims(new_batch))
        
        # 5. 組裝最終 batch
        return self._assemble_batch(new_batch)

4. 與 KV Cache 管理的深度耦合

請求排程與 KV Cache 管理是一體兩面的關係：

┌─────────────────────────────────────────────┐
│           KV Cache 管理方案演進               │
├─────────────────┬───────────────────────────┤
│ 方案             │ 排程器需要感知的維度        │
├─────────────────┼───────────────────────────┤
│ 樸素連續記憶體      │ 每個請求的 KV Cache       │
│                 │ 獨佔連續視訊記憶體塊              │
│                 │ → 碎片化問題嚴重            │
├─────────────────┼───────────────────────────┤
│ PagedAttention  │ KV Cache 分頁管理          │
│ (vLLM)          │ → 類似 OS 虛擬記憶體         │
│                 │ 排程器按 page 粒度分配      │
│                 │ → 視訊記憶體利用率大幅提升        │
├─────────────────┼───────────────────────────┤
│ Prefix Caching  │ 共享字首的 KV Cache        │
│                 │ 通過引用計數複用            │
│                 │ → 排程器需感知字首親和性    │
├─────────────────┼───────────────────────────┤
│ KV Cache 壓縮   │ 量化、蒸餾、稀疏化          │
│                 │ → 影響每個請求的實際佔用    │
│                 │ 排程器需動態感知壓縮率      │
└─────────────────┴───────────────────────────┘

---

技術演進史

時間	里程碑	核心創新	關鍵論文/專案
~2020	樸素靜態 Batching	請求攢一批再執行	早期 TFServing / Triton
2022	Orca：連續 Batching	迭代級排程，請求級粒度	OSDI 2022 (UC Berkeley 等)
2023	vLLM + PagedAttention	KV Cache 分頁管理	SOSP 2023 (UC Berkeley)
2023	Sarathi / Sarathi-Serve	Chunked Prefill 與 Decode 混合	Microsoft Research
2023–2024	DistServe / Splitwise	Prefill-Decode 分離部署	學術界 + 產業界
2024	SGLang RadixAttention	字首樹管理共享 KV Cache	UC Berkeley
2024	Prefill-Decode 分離成主流方向	多個推論架構支援	vLLM / TensorRT-LLM 等
2024–2025	排程與硬體深度協同	運算元級排程、編譯最佳化融合	各大廠自研平台

關鍵趨勢： 排程器從”軟體層獨立模組”逐步向”軟硬體協同的系統級最佳化”演進。

---

技術路線對比

維度	靜態 Batching	連續 Batching	連續 + Chunked Prefill	PD 分離排程
排程粒度	請求級	迭代級	迭代級 + chunk	階段級（跨節點）
GPU 利用率	低	高	更高	最高（各自最佳化）
長 prompt 對 decode 影響	嚴重阻塞	有阻塞	輕微	無（物理隔離）
短請求延遲	受 batch 最長請求約束	低	低	最低
實現複雜度	低	中	中高	高
基礎設施要求	單 GPU 可用	單 GPU 可用	單 GPU 可用	需要高速互聯
適用場景	簡單批次推論	通用線上推論	混合長度負載	大規模生產環境
生態支援	通用	主流引擎均支援	vLLM/SGLang/TRT-LLM	各廠自研為主
KV Cache 效率	低	中（可配合 PagedAttn）	中高	高（專用池化）

---

上下游

上游（請求排程器的輸入依賴）

┌─────────────────────────────────────────┐
│               上游生態                    │
├──────────────┬──────────────────────────┤
│ 應用層        │ API 閘道器、負載均衡器       │
│              │ 使用者請求佇列              │
├──────────────┼──────────────────────────┤
│ 模型層        │ 模型架構（影響 KV Cache   │
│              │ 大小、Prefill 計算量）     │
│              │ GQA/MQA 影響 KV 維度      │
├──────────────┼──────────────────────────┤
│ Tokenizer    │ 分詞結果影響 Prefill 長度  │
├──────────────┼──────────────────────────┤
│ 硬體層        │ GPU 數量、視訊記憶體大小、       │
│              │ HBM 頻寬、NVLink/互聯拓撲  │
└──────────────┴──────────────────────────┘

下游（請求排程器影響的環節）

┌─────────────────────────────────────────┐
│               下游生態                    │
├──────────────┬──────────────────────────┤
│ 推論引擎      │ 核心執行、運算元排程        │
│              │ KV Cache 管理器           │
├──────────────┼──────────────────────────┤
│ 使用者體驗      │ TTFT（首 token 延遲）     │
│              │ TPOT（每 token 延遲）     │
│              │ 端到端完成時間             │
├──────────────┼──────────────────────────┤
│ 基礎設施成本  │ GPU 利用率 → 單位推論成本  │
│              │ QPS 能力 → 叢集規模規劃    │
├──────────────┼──────────────────────────┤
│ 業務能力      │ 併發使用者數上限            │
│              │ 長上下文支援能力           │
└──────────────┴──────────────────────────┘

---

關鍵指標

系統級指標

指標	定義	業界參考量級
Throughput (tokens/s)	系統每秒處理的總 token 數（輸入+輸出）	高度依賴模型/硬體/併發，不列具體數字
QPS	每秒完成的請求數	高度依賴請求長度分佈
TTFT	Time to First Token，使用者感知首 token 延遲	毫秒到秒級，取決於 prompt 長度和排隊
TPOT	Time Per Output Token，每輸出 token 延遲	通常 10–100ms 量級（估算）
P50 / P99 延遲	中位數和尾部延遲	SLA 核心約束
GPU 利用率	GPU 算力實際使用比例	最佳化前後差異可達數倍（定性）
KV Cache 利用率	已分配 KV Cache / 總可用	受碎片化影響，PagedAttention 改善顯著

排程器效率指標

指標	含義
排程開銷	排程決策本身的 CPU 時間，通常應控制在微秒到毫秒級
搶佔頻率	單位時間內發生搶佔的次數，過高說明容量規劃不足
排隊等待時間	請求從到達到開始 Prefill 的等待時間
字首快取命中率	複用已有 KV Cache 的請求佔比

---

供需與市場資料

需求側

• 推論成本佔比持續上升： 據各廠商財報及行業分析，頭部 AI 應用的推論成本已超過訓練成本，推論最佳化 ROI 極高。
• 長上下文需求增長： 128K–1M+ 上下文視窗的應用越來越普遍，KV Cache 管理壓力倍增。
• 多模態推論複雜化： 圖片/影片/音訊輸入的 Prefill 成本遠高於純文本。
• 混合負載需求： 同一叢集同時服務即時對話（低延遲優先）和批次處理（高吞吐優先），排程複雜度飆升。

供給側

• 開源推論引擎競爭激烈： vLLM、SGLang、TensorRT-LLM 等在排程策略上快速迭代。
• 雲端廠商自建最佳化： 各大雲端廠商（AWS、Azure、GCP 及國內廠商）在推論服務平台上投入大量自研最佳化。
• 專用硬體+排程協同： Groq（LPU）、Cerebras（WSE）等將排程邏輯深度融入硬體設計。
• 排程最佳化成為推論晶片差異化競爭的重要維度。

關鍵資料參考（定性/估算）

• 推論服務中 GPU 的典型利用率在最佳化前可能低至 20%–40%，經排程最佳化後可提升至 60%–80%+（量級估算，高度依賴具體場景）
• PagedAttention 在 vLLM 論文中報告相比樸素實現在吞吐量上有顯著提升（具體倍數取決於基線和工作負載）
• Chunked Prefill 在長 prompt 場景下可有效降低 decode 請求的尾部延遲

---

代表公司與資本對映

層級	公司/專案	與請求排程的關係	關聯標的
開源推論引擎	vLLM (UC Berkeley → 商業化)	PagedAttention + 連續 Batching 的標杆	—
	SGLang (UC Berkeley)	RadixAttention 字首感知排程	—
	TensorRT-LLM (NVIDIA)	NVIDIA 官方推論引擎	NVDA
雲端推論服務	AWS Bedrock	平台級推論排程	AMZN
	Azure AI	平台級推論排程	MSFT
	Google Vertex AI	平台級推論排程	GOOG
專用推論硬體	Groq	排程與 LPU 硬體深度耦合	未上市
	Cerebras	WSE 上的排程邏輯	未上市
	SambaNova	DataScale 排程最佳化	未上市
國內推論平台	百度千帆、阿里 PAI、位元組火山引擎等	各家自研排程最佳化	BABA 等
GPU 廠商	NVIDIA	推論排程生態核心（Triton Server + TRT-LLM）	NVDA
	AMD (ROCm + vLLM 支援)	逐步完善推論排程生態	AMD

投資邏輯對映： 請求排程最佳化 → GPU 利用率提升 → 單位推論成本下降 → 或同等成本下更高吞吐。這個方向利好”賣鏟子”的（GPU/推論硬體廠商，因為高利用率 = 買更少的卡 = 但每張卡的單位價值更高 = 使用者願意為高效硬體付溢價），也利好”最佳化鏟子效率”的推論平台/引擎。

---

投資邏輯

核心推論架構

推論成本 = GPU 數量 × 單卡成本 × 使用時間
         ↓
排程最佳化 → 同等 QPS 下所需 GPU 數量減少 → 直接降本
         → 或同等 GPU 數量下 QPS 提升 → 提升服務能力

四條投資主線

主線一：推論硬體廠商（NVIDIA/AMD 及專用晶片）

• 排程最佳化使 GPU 利用率提升，短期看似”賣更少的卡”
• 但長期效應：推論成本下降 → 更多應用被經濟可行地部署 → 總需求增長
• 高效排程更利好硬體頻寬/算力利用率高的晶片 → 加劇硬體差異化

主線二：雲端推論服務平台

• 排程最佳化是雲端廠商推論服務獲利的核心槓桿
• 排程效率直接轉化為獲利率差異
• 具備自研排程最佳化能力的平台更具競爭力

主線三：推論引擎/中介軟體

• vLLM、SGLang 等開源專案背後的商業化機會
• 類似 Red Hat 模式：開源引擎 + 商業支援/託管
• 但護城河存疑，開源競爭激烈

主線四：應用層

• 推論成本下降使得此前”太貴”的 AI 應用變得可行
• 長上下文、即時多模態、Agent 等重度推論應用受益最大

風險因素

• 硬體迭代可能弱化軟體排程優勢： 如果專用硬體（如 Groq LPU）在架構層面解決了排程問題，軟體層面的最佳化空間可能被壓縮
• 模型架構變革： 如線性注意力等替代 Transformer 的架構如果成熟，KV Cache 管理問題可能消失或大幅變化
• 開源社群競爭： 領先排程技術可能快速被開源社群複製，難以形成持久商業壁壘

---

常見誤讀糾偏

❌ 誤讀一：“連續 Batching 就是請求排程的全部”

糾偏： 連續 Batching 只是排程策略的基線。真正的排程最佳化還包括：

• Chunked Prefill（解決長 prompt 阻塞問題）
• 字首感知排程（最大化 KV Cache 複用）
• 搶佔與遷移策略（解決視訊記憶體不足時的應急）
• Prefill-Decode 分離（架構級最佳化）
• 跨 GPU/節點的負載均衡

連續 Batching 類比於”作業系統有了程序排程”，但排程演算法的質量差異巨大。

❌ 誤讀二：“請求排程只是軟體最佳化，與硬體無關”

糾偏： 排程決策與硬體特性高度耦合：

• NVLink/NVSwitch 互聯拓撲影響跨 GPU 排程策略
• HBM 頻寬 vs 容量的權衡影響 KV Cache 管理策略
• 不同 GPU 的 Prefill/Decode 效能比不同，影響 PD 分離策略
• 專用推論硬體（如 Groq LPU）將排程邏輯固化在晶片架構中

排程效率的上限由硬體決定，軟體排程是在硬體約束下的最優解搜尋。

❌ 誤讀三：“排程器的 CPU 開銷可以忽略”

糾偏： 在高頻排程場景下，排程器本身的 CPU 開銷可能成為瓶頸：

• 每次 forward step 都需要排程決策
• 複雜的搶佔/遷移決策、KV Cache 管理涉及大量指標操作
• 在大叢集、高併發場景下，排程器可能需要獨立的 CPU 資源
• 這也是為什麼生產級系統中排程器實現需要極致最佳化

❌ 誤讀四：“Prefill-Decode 分離一定優於共置”

糾偏： 分離部署引入了額外的 KV Cache 傳輸開銷。如果互聯頻寬不足或請求以短序列為主，分離帶來的收益可能被傳輸開銷抵消。最佳策略取決於具體工作負載和硬體條件，不存在”一招鮮”的方案。

---

學習路徑

入門（建立直覺）

1. 理解 LLM 推論基本流程： Prefill → Decode → 逐 token 自迴歸
2. 閱讀 vLLM 官方部落格/文件： 理解 PagedAttention 的核心思想
3. 動手體驗： 用 vLLM 部署一個小模型，觀察不同 batch size 下的吞吐變化

進階（理解機制）

4. 精讀 Orca 論文： 理解連續 Batching 的設計思想和迭代級排程
5. 精讀 vLLM 論文： 理解 PagedAttention + 排程器的完整設計
6. 閱讀 SGLang 的 RadixAttention： 理解字首感知排程
7. 瞭解 Chunked Prefill： Sarathi / Sarathi-Serve 論文

高階（系統級思考）

8. 閱讀 DistServe / Splitwise 相關工作： 理解 PD 分離的系統架構
9. 研究 vLLM / SGLang 原始碼中的 Scheduler 實現： 理解工程實現細節
10. 關注硬體-排程協同設計： Groq LPU 架構、TPU 的推論排程特性等
11. 思考推論排程的”下一步”： 多模態排程、Agent 場景的多輪排程、跨資料中心排程

推薦閱讀清單

• [論文] Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022)
• [論文] Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023)
• [論文] Sarathi: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills
• [論文] DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving
• [文件] vLLM 官方文件 — 排程相關章節
• [文件] SGLang 官方文件 — RadixAttention 相關章節
• [程式碼] vLLM GitHub 倉庫 vllm/core/scheduler.py
• [程式碼] SGLang GitHub 倉庫中排程器實現

---

一句話總結

請求排程是 LLM 推論效率的”第一性原理”——它不改變模型能力，但直接決定了同樣的 GPU 能產出多少有用 token，是推論成本戰爭中最關鍵的軟體槓桿。

---

延伸閱讀與來源

來源	說明
Orca (OSDI 2022)	連續 Batching 的奠基論文
vLLM (SOSP 2023)	PagedAttention + 完整排程系統設計
SGLang 官方文件	RadixAttention 字首快取排程
Sarathi / Sarathi-Serve	Chunked Prefill 方案
DistServe	Prefill-Decode 分離排程
vLLM / SGLang / TensorRT-LLM GitHub	工程實現參考
各廠商技術部落格	AWS / Azure / GCP 及國內廠商推論最佳化實踐分享

宣告： 本文中的效能資料、最佳化倍數等若無明確來源標註，均為基於公開資訊的定性估計或量級判斷，具體數字因模型、硬體、工作負載不同而差異顯著。建議以廠商官方 benchmark 和論文報告為準。