並發（同時處理多少個請求）

你會在什麼時候遇到它

當你的 AI 從「自己用」變成「給團隊或使用者用」，你會撞上這個詞。單人測試時一切很快，一上線多人同時用就變慢甚至崩潰 —— 因為你一直在測「單串流速度」，卻沒測「並發下的吞吐量與延遲」。不懂這個分別，你的容量規劃會完全失準。

最小範例

正確的容量測試是做「並發掃描」：
  同時 1 個請求   → 記錄：吞吐量、每個請求的延遲
  同時 5 個請求   → 記錄：吞吐量、延遲
  同時 20 個請求  → 記錄：吞吐量、延遲
  …逐步加壓，直到延遲或錯誤率不可接受

你會看到一條取捨曲線：
  並發越高 → 總吞吐量越高，但每個請求的延遲也越高
  「最佳工作點」取決於你的業務能忍受多少延遲

只看「單請求多快」會嚴重高估容量。一定要看延遲的分位數（p95／p99），不要只看平均 —— 並發升高時，受害最重的是尾部那些等最久的請求。

最常搞錯的地方

• 用單使用者速度去估算多人容量。並發下資源被瓜分、還要排隊，實際能服務的人數遠低於「速度 × 人數」的直覺。
• 以為並發越高、總吞吐量就一直越高。到某個點記憶體（KV cache）或算力會被吃光，再加只會讓延遲暴增、甚至開始報錯。
• 只看平均延遲。並發的痛在長尾，平均值會把「少數請求等到天荒地老」這件事完全藏起來。