為什麼吞吐不隨併發線性增長？

視訊記憶體頻寬與算力是共享瓶頸，多請求競爭 KV 快取與計算單元，邊際吞吐遞減；需實測找到拐點再定併發上限。

首 token 延遲和吞吐衝突嗎？

常衝突。大模型首 token 受預填充耗時影響，吞吐受解碼並行影響；最佳化方向相反時按業務(對話要低延遲、批處理要高吞吐)取捨。

🔮 Inference Throughput Estimator

Estimate inference throughput in tokens per second from the generated token count and end-to-end latency, for capacity planning.

📐 計算公式 / 原理

吞吐 = tokens / 秒；單請求吞吐 = tokens / (秒 × 併發批次)

推理服務的核心指標：總吞吐衡量叢集利用率，單請求吞吐才是使用者感知的快慢。batching 能顯著提升總吞吐但會拉長單請求延遲，線上服務通常需要在兩者間按 SLO 折中。

生成 tokens

耗時秒

併發數

單請求吞吐

生成 200 token 耗時 4s → 吞吐=50 tokens/s。若單卡支援 4 併發且各 50 tok/s，總吞吐≈200 tok/s；但實際共享 KV 快取與頻寬，併發增益低於線性。

為什麼吞吐不隨併發線性增長？: 視訊記憶體頻寬與算力是共享瓶頸，多請求競爭 KV 快取與計算單元，邊際吞吐遞減；需實測找到拐點再定併發上限。
首 token 延遲和吞吐衝突嗎？: 常衝突。大模型首 token 受預填充耗時影響，吞吐受解碼並行影響；最佳化方向相反時按業務(對話要低延遲、批處理要高吞吐)取捨。