批次處理（把多個請求一起算）

你會在什麼時候遇到它

這是所有生產級推理引擎（vLLM 這類）的核心技巧，也是「為什麼同一台機器服務很多人時，總吞吐量能遠超逐一處理」的答案。你會在建置多人服務時遇到它。不懂批次，你無法理解「提高吞吐量」與「降低單請求延遲」為什麼常常互相衝突 —— 這正是容量規劃最核心的取捨。

最小範例

為什麼批次有效：
  decode 每一步都要把整個模型權重搬進計算單元
  搬一次權重只服務 1 個請求   → 浪費
  搬一次權重同時服務 N 個請求 → 搬運成本被 N 個請求分攤
  → 總吞吐量大幅提升

連續批次（continuous batching）：
  不等整批都做完才換下一批
  哪個請求先生成完就立刻釋放、補進新請求
  → 讓 GPU 盡量不空轉

注意取捨：批次越大，總吞吐量越高，但每個請求要跟更多人共享資源、可能等更久（延遲上升）。引擎裡 max-num-seqs 這類參數，調的就是這個工作點。

最常搞錯的地方

• 以為批次處理會讓「每個請求都更快」。它提高的是總吞吐量；單一請求的延遲反而可能因為共享與排隊而變長。
• 以為批次越大越好。批次大到某個點，KV cache 會把 VRAM 吃光，或單請求延遲超過可接受範圍，反而得不償失。
• 把「靜態批次」（等整批做完）當成現代做法。連續／動態批次才能隨時補進新請求、不讓 GPU 空等，這是生產引擎的標配。