連續批次處理：吞吐量提升最大的一個開關

傳統靜態批次要等一批請求都到齊才開始，而且要等最慢的那個生成完才能收工。連續批次（continuous batching）改成以 token 為單位排程：誰生成完就離開，空出的位置立刻讓新請求補進來。

為什麼提升這麼大

• GPU 在逐 token 生成階段其實很閒——瓶頸是記憶體頻寬而非算力，多幾個序列一起算幾乎不增加時間。
• 請求的輸出長度差異很大，靜態批次會被最長的那個綁住。
• 不必等湊滿一批，排隊時間大幅下降。

實務上怎麼開

# vLLM 範例：連續批次是預設行為，主要調這幾個
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-8B-Instruct \
  --max-num-seqs 128 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

三個關鍵參數

• max-num-seqs：同時處理的序列數上限。太大時單一請求的生成速度會下降。
• max-model-len：影響 KV 快取的預留量，設得比實際需求大會浪費記憶體。
• gpu-memory-utilization：留給 KV 快取的比例，太高容易在尖峰時出錯。

吞吐與延遲的取捨

批次越大，總吞吐越高，但單一請求的生成速度會變慢。互動式服務應該設較小的並行上限；離線批次任務則可以拉滿。兩種流量最好分開部署，不要混在同一個服務裡互相干擾。