自架推理服務的完整調校：從裝好到跑滿

第一步：建立壓測基準

# 壓測必須模擬真實的長度分布，不要用固定長度
# 從線上日誌抽出輸入輸出長度，重播相同分布
lengths = sample_from_prod_logs(n=2000)

results = bench(
    concurrency=[1, 4, 8, 16, 32, 64],
    length_dist=lengths,
    duration_s=120,
)
# 記錄：吞吐(tok/s)、TTFT p50/p95、端到端 p95、GPU 使用率、顯示記憶體峰值

第二步：記憶體配置

• gpu-memory-utilization 從 0.85 起，逐步往上加到 0.92–0.94。
• 太高會在流量尖峰時發生記憶體不足；太低則浪費 KV 快取空間。
• 調完要跑一次「超過預期負載 1.5 倍」的壓測，確認不會崩。

第三步：上下文長度

max-model-len 直接決定 KV 快取的預留量。設成 32768 但實際請求都在 4000 以內，等於白白減少能同時處理的序列數。

# 從實際分布決定，取 p99 再加一點餘裕
p99_len = percentile(prod_input_lengths, 99)
max_model_len = int((p99_len + max_output) * 1.2)

第四步：並行序列數

max-num-seqs 提高會增加吞吐，但單一請求的生成速度下降。這是吞吐與延遲的直接取捨，要依服務型態決定。

• 互動式服務：以 TTFT p95 與生成速度為準，並行數通常設在 32–64。
• 批次任務：以總吞吐為準，可以拉到 128 以上。
• 兩種流量分開部署，混在一起時互相干擾，兩邊都不好。

第五步：前綴快取與分塊預填充

• 系統提示長時，開前綴快取，TTFT 通常有顯著改善。
• 輸入長度差異大時，開啟分塊預填充（chunked prefill），避免長輸入的預填充阻塞其他請求的生成。

第六步：量化（最後才動）

量化會改變輸出品質，所以放在最後。前面的調校都是純粹的效能改善，不影響結果；量化則需要重跑完整評測。

找出真正的瓶頸

# GPU 使用率高、吞吐低   → 計算受限，考慮量化或換卡
# GPU 使用率低、佇列很長 → 記憶體受限（KV 快取不夠），調 max-model-len
# GPU 使用率低、佇列也短 → 上游瓶頸（網路、前處理、資料庫）
# 顯示記憶體滿、吞吐低   → 並行數過高造成頻繁換出

調校的紀錄

每次調整都記錄：改了什麼、壓測結果、GPU 使用率。三個月後有人問「為什麼這個參數是 0.92」，你要拿得出當時的數據。