vLLM 團隊10月23日發布「GLM-5.3 優化」系列第二部分，講點樣喺16塊 NVIDIA H200 上服務 GLM-5.3，其中一台做預填（prefill，即先處理提示詞建立上下文）、另一台做解碼（decode，即逐字生成回覆），靠三樣嘢：預填上下文並行（Prefill Context Parallelism, PCP）、解碼上下文並行（Decode Context Parallelism, DCP）同混合稀疏 KV 快取（Hybrid HiSparse）。
背景係咁：長篇 agent（代理）工作每輪都會加入更多工具輸出同檔案內容，上下文越嚟越長，同時壓住 H200 嘅兩條線——KV 快取（Key-Value cache，即模型記住之前上下文的記憶）顯存，同 prefill 速度。GLM-5.3 嘅權重本身就佔咗每塊 H200 大部分顯存，畀長上下文的 KV 快取嘅空間冇幾多。
vLLM 講，8× H200 上通常跑 prefill 有兩種做法，各有死穴：
圖片：極客灣Geekerwan／CC BY 3.0／Wikimedia Commons
- 數據並行 DP8：每段提示詞派喺一塊 GPU，注意力（attention）用唔到其他七塊，首字延遲（TTFT，即第一個 token 出現嘅時間）被拖長，KV 快取都要湊喺嗰塊卡入面。
- 張量並行 TP8：按注意力「head」切。因為 GLM-5.3 用 Multi-head Latent Attention（MLA），潛層 KV 係全部 64 個 head 共享，每塊 GPU 都儲住完整快取、只讀嚟服務 8 個 head；而且負責揀出稀疏注意力該讀嘅 2,048 個 token 嘅 indexer（索引器）完全冇被切，二次方計算成本喺每塊卡重複。
兩種都冇法把一條長提示詞嘅注意力工作真正分哂八塊卡，同時又要每塊卡各存一份完整 KV。PCP 解決 query 嗰邊、DCP 解決 KV 嗰邊。
PCP 嘅做法係切 token，唔切 head：每塊 GPU 計算提示詞八分之一的 query，但保留全部 64 個 head。天真切法會 workload 唔平衡——causal attention 下一個 token 要看之前所有 token，攞提示詞尾端嘅 GPU 會做遠多過頭端嘅活。所以 PCP 將提示詞切16段再配對，令每塊卡負責頭尾各一截。效果：每塊卡只索引自己嘅 token，indexer 唔再被複製；每行 KV 由記憶讀出後服務全部 64 個 head 而非 8 個，稀疏 MLA 嘅 FLOPs-per-byte 由約 26 升到約 191。
DCP 再將 prefill 節點嘅 KV 快取按 token 分片，移除 PCP 留下嘅 KV 複製，1M 上下文先會得喺預填節點。解碼節點用 Hybrid HiSparse 將 KV 放喺主機記憶體，1M token 嘅請求先放得落，同時提高長上下文下嘅並發度。
圖片：Coolcaesar／CC BY-SA 4.0／Wikimedia Commons
vLLM 自述用咗新模組化核心 Model Runner V2，方便將以上各組件湊埋。
AgentX 長文基準（vLLM 自測）： PCP8 × DCP8 prefill 配 Hybrid HiSparse decode，喺 AgentX agentic 基準上，相同吞吐量下逐用户速度為數據並行部署嘅 1.7 至 3.2 倍；同時間係佢哋測過嘅唯一能服務 1M token 上下文嘅配置。
模姐驗嚇貨： 呢係廠商自報嘅技術優化，數字全部來自 vLLM 自身測試，冇獨立第三方驗證。對要喺 H200 機群跑長文 agent 嘅讀者，呢篇係實操參考；對一般用户，呢係「後端點樣先撐得住你嗰長 agent」嘅問題，唔係你直接見到嘅功能。
模姐｜深度調教
