每 Token 延遲 (TPOT, Time Per Output Token)

1. 3 秒看懂

TPOT = 大型模型每生成一個輸出 token 所需的時間（毫秒）。 它直接決定使用者”一個字一個字蹦出來”的體感速度。類比打字：TPOT 是每個字的間隔，而 TTFT（首 token 延遲）是按下回車後到第一個字出現的等待。人類閱讀速度約 3–5 token/s，TPOT > 200 ms 使用者即感知明顯示卡頓；< 50 ms 則”流式如飛”。

2. 3 分鐘產業解釋

為什麼 TPOT 是 AI 推論的核心體驗指標？

大語言模型推論分為兩個階段：

階段	操作	主要瓶頸	使用者感知指標
Prefill（預填充）	並行處理全部輸入 prompt	計算密集（矩陣×矩陣）	TTFT（首 token 延遲）
Decode（解碼/生成）	逐 token 自迴歸生成	頻寬密集（讀模型權重）	TPOT

在對話、程式碼補全、Agent 呼叫等場景中，輸出 token 通常遠多於輸入——一次請求可能生成 200–2000 個 token。TPOT 直接決定了這整個生成過程的累積等待時間：TPOT 100 ms 生成 1000 個 token 需 100 秒；TPOT 30 ms 則僅需 30 秒。

產業影響鏈

• 使用者體驗：TPOT < 50 ms ≈ 20 token/s，超過人類閱讀速度，體驗流暢
• 成本結構：TPOT 越低 = 單請求佔用 GPU 時間越短 = 單卡可服務更多請求 → 推論成本下降
• 商業模式：按 token 計費的 API 服務，TPOT 直接影響併發能力與單位成本

3. 15 分鐘專家深入

3.1 精確定義

\text{TPOT} = \frac{\text{Total Decode Latency}}{\text{Num Output Tokens} - 1}

分母減 1 是因為 N 個輸出 token 之間有 N-1 個間隔。也有實現方案將第 1 個輸出 token 的生成歸入 TTFT，此時 TPOT = (Total Generation Latency - TTFT) / (Num Output Tokens - 1)。

3.2 TPOT 在推論服務棧中的位置

請求到達
  │
  ▼
┌──────────────┐     ┌───────────────────┐     ┌─────────────────┐
│  Prefill 階段 │────▶│  Decode 階段(迴圈)  │────▶│  輸出拼接/返回    │
│  處理全部輸入  │     │  每步生成 1 個 token │     │                 │
│  → 決定 TTFT  │     │  → 決定 TPOT       │     │                 │
└──────────────┘     └───────────────────┘     └─────────────────┘

3.3 TPOT 的物理極限：記憶體頻寬牆

Decode 階段的核心操作是矩陣-向量乘（batch_size=1 時權重矩陣 × 單個 token 向量），其算術強度（Arithmetic Intensity）極低：

• 權重引數：每個引數讀入一次（bytes_per_param 取決於量化精度）
• 計算量：2 × d_in × d_out FLOPs/層（一個矩陣-向量乘）
• 算術強度 ≈ 2 / bytes_per_param（FLOPs/byte）

精度	bytes_per_param	算術強度 (FLOPs/byte)
FP16/BF16	2	1
INT8	1	2
INT4	0.5	4

以 H100 SXM 為例 [廠商規格]：

• 峰值 FP16 算力 ≈ 990 TFLOPS（dense）
• HBM3 頻寬 ≈ 3.35 TB/s
• Ridge Point（屋頂拐點）≈ 295 FLOPs/byte

FP16 decode 的算術強度 = 1 FLOP/byte ≪ 295 → 嚴重落在 memory-bound 區域。GPU 計算單元大量空閒，TPOT 幾乎完全由記憶體頻寬決定。

近似下界公式：

TPOT_min ≈ (Model_Weight_Bytes + 2 × n_layers × seq_len × d_model_kv × bytes_per_element) / Memory_Bandwidth

其中 2 × n_layers × seq_len × d_model_kv × bytes_per_element 為每生成一個新 token 時，attention 層需要讀取的 K/V 快取總量。

3.4 量化對 TPOT 的影響

由於 decode 是 memory-bound，減少每次讀入的位元組數直接降低 TPOT：

• FP16 → INT4：權重位元組減少 ~4×，理論上 TPOT 可改善接近 4×
• 實際改善需考慮反量化計算開銷、KV cache 仍為 FP16 等因素，典型改善約 2–3× [行業經驗估算]
• 常見方案：GPTQ、AWQ、GGUF 等權重量化；KV cache 也可量化至 INT8/FP8

3.5 批處理（Batching）對 TPOT 的權衡

策略	TPOT 影響	吞吐影響
增大 batch_size	TPOT 可能上升（KV cache 增長、計算變為矩陣-矩陣）	吞吐上升
Continuous Batching（Orca 思路）	請求完成即時釋放，TPOT 穩定	吞吐提升顯著
PagedAttention（vLLM 思路）	KV cache 分頁管理，減少碎片化浪費，TPOT 略有改善	吞吐提升
Prefill-Decode 分離（Splitwise/DistServe 思路）	各自最佳化硬體選擇，TPOT 可獨立最佳化	整體提升

核心張力：增大 batch_size 後，decode 從 matrix-vector 升級為 matrix-matrix，算術強度提升，GPU 計算利用率上升，整體吞吐增加但單請求 TPOT 可能增加——這是吞吐-延遲的經典 trade-off。

3.6 與 TTFT、吞吐的三角關係

            低 TTFT
           ╱      ╲
          ╱  三者    ╲
         ╱   難以     ╲
        ╱   同時最優    ╲
       ╱                ╲
  低 TPOT ———————————— 高吞吐

• Prefill-heavy 最佳化（大 chunk prefill）→ TTFT 可能上升，但 TPOT 不受影響
• 大 batch → 吞吐上升，TPOT 可能上升
• Speculative decoding → 可同時改善 TPOT 而不犧牲吞吐（見下文）

---

4. 技術原理（最深）

4.1 Decode 單步的完整執行流程

以標準 Transformer decoder layer 為例，每生成一個 token 需要執行：

輸入 token embedding (dim=d_model)
    │
    ▼
┌─────────────────────────────────────────────┐
│ Layer Norm (Pre-Norm)                        │
│   FLOPs: O(d_model)                          │
│   Mem: read d_model 引數                      │
├─────────────────────────────────────────────┤
│ Multi-Head Self-Attention                    │
│   Q_proj: weight (d_model × d_model)         │
│   K_proj: weight (d_model × d_model)         │
│   V_proj: weight (d_model × d_model)         │
│   O_proj: weight (d_model × d_model)         │
│   QK^T: 需讀取全部歷史 KV cache               │
│   → KV cache bytes = 2 × seq_len × d_model_kv │
│     × bytes_per_element                      │
├─────────────────────────────────────────────┤
│ Layer Norm                                    │
├─────────────────────────────────────────────┤
│ Feed-Forward Network (SwiGLU variant)        │
│   Gate_proj: (d_model × d_ffn)               │
│   Up_proj:   (d_model × d_ffn)               │
│   Down_proj: (d_ffn × d_model)               │
│   d_ffn 通常 = 8/3 × d_model (SwiGLU)        │
│     或 = 4 × d_model (傳統 GELU)              │
└─────────────────────────────────────────────┘
    │
    ▼
  LM Head: (d_model × vocab_size) → logits

每層需讀取的權重位元組（FP16）：

Attention weights: 4 × d_model² × 2 bytes
FFN weights:       3 × d_model × d_ffn × 2 bytes  (SwiGLU)
LN params:         略
─────────────────────────────────────────────
每層合計 ≈ (8 × d_model² + 6 × d_model × d_ffn) bytes  [FP16]

還需額外讀取 KV cache（每層）：

KV_cache_per_layer = 2 × seq_len × d_model_kv × bytes_per_element
                   = 2 × seq_len × n_kv_heads × head_dim × bytes_per_element

4.2 Roofline 分析圖（ASCII）

  Achieved
  Performance
  (TFLOPS)
    │
 990├── ── ── ── ── ── ── ── ── ── ── ── ── ── ──  ← H100 compute ceiling
    │                                          ╱
    │                                        ╱
    │                                      ╱
    │                                    ╱  Compute-bound region
    │                                  ╱
    │                                ╱
    │                              ╱
    │                            ╱
    │                          ╱
    │                        ╱
    │          ╱───────────╱── Memory BW ceiling (3.35 TB/s)
    │        ╱           ╱
  ★ ├── ★ ╱           ╱     ★ = FP16 decode (AI≈1)
    │    ╱           ╱       ▲ = INT4 decode (AI≈4)
    │  ╱  ▲        ╱
  ▲ ├╱ ▲         ╱
    │           ╱
    ┼───┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──▶
    0  0.1 1   10  50 100 300 500     Arithmetic Intensity (FLOPs/byte)
              ↑
          Ridge Point ≈ 295

★ FP16 decode at bs=1：算術強度 ≈ 1，遠在左側 memory-bound 區域，實際 TFLOPS 遠低於峰值。

▲ INT4 decode at bs=1：算術強度 ≈ 4，仍為 memory-bound，但利用率提升 ~4×。

隨 batch_size 增大，decode 操作從 matrix-vector 逐步接近 matrix-matrix，算術強度線性增長，向 ridge point 靠近。

4.3 KV Cache 的角色

KV cache 是 decode 階段的關鍵記憶體開銷：

KV_cache_total = 2 × n_layers × n_kv_heads × head_dim × seq_len × bytes_per_element

• GQA/MQA 的影響：n_kv_heads < n_attention_heads，KV cache 按比例縮小（如 Llama 2 70B 使用 GQA，n_kv_heads/n_heads = 8/64 = 1/8），直接降低 decode 時需讀取的 cache 量
• 長上下文場景：seq_len 增長直接擴大 KV cache，成為 TPOT 退化的主要因素之一
• KV cache 量化：將 cache 從 FP16 降至 INT8 可減半 cache 讀取量

4.4 TPOT 的組成部分分解

TPOT = T_weight_read + T_kv_cache_read + T_compute + T_comm + T_overhead

其中：
  T_weight_read    ∝ model_size / HBM_bandwidth    (通常佔主導)
  T_kv_cache_read  ∝ seq_len × batch_size / BW     (隨上下文增長)
  T_compute        ∝ model_size × batch_size / FLOPS (bs=1 時可忽略)
  T_comm           (多卡並行時 AllReduce/ReduceScatter)
  T_overhead       (kernel launch、排程等，通常 < 1ms)

---

5. 技術演進史

時期	關鍵事件	TPOT 水平（估算）
2020	GPT-3 175B 推論於 V100 叢集	數百 ms/token，主要面向研究
2021–2022	A100 + FP16 推論成為主流，Hugging Face Text Generation Inference 上線	大型模型 ~100–200 ms，小模型 ~30–50 ms
2023 Q1–Q2	vLLM（PagedAttention）開源，連續批處理普及	吞吐大幅提升，TPOT 在高負載下仍可控
2023 H2	INT4/INT8 量化推論（GPTQ、AWQ）成熟，H100 大規模部署	大型模型 TPOT 降至 ~30–80 ms（因模型/量化/硬體而異）
2024	H200（HBM3e 頻寬提升）、Speculative Decoding 工程化、Prefill-Decode 分離架構（Splitwise/DistServe）	大型模型 TPOT 可低至 ~20–50 ms（最佳化配置下估算）
2024–2025	B200/GB200 NVL72 部署、Blackwell 架構 HBM3e + 1.8TB/s NVLink	預計進一步壓低 TPOT，但模型規模同步增長

---

6. 技術路線對比（量化表）

6.1 影響 TPOT 的主要技術路徑

技術路徑	TPOT 改善倍數（估算）	吞吐影響	成熟度	代表實現
權重量化 (INT4)	2–3×	正面	高	GPTQ, AWQ, GGUF
KV Cache 量化 (INT8)	1.1–1.3×	正面	高	多推論架構支援
更大 batch_size	TPOT 可能略升	吞吐 ↑↑	高	所有架構
Continuous Batching	高負載下 TPOT 更穩定	↑↑	高	vLLM, TGI, TensorRT-LLM
Speculative Decoding	2–3×	不變或略升	中	Medusa, EAGLE, DeepSeek 等
PagedAttention	略有改善	↑	高	vLLM
Prefill-Decode 分離	TPOT 可獨立最佳化	↑	中	Splitwise, DistServe
模型剪枝/蒸餾	取決於壓縮比	↑	中	依模型而定
硬體升級（更大 HBM BW）	線性改善	↑	—	H100→H200→B200

6.2 不同硬體平台的 TPOT 近似上限（理論記憶體頻寬極限）

以 FP16 推論 70B 引數模型為例，僅讀取模型權重的理論下界：

模型權重 ≈ 70B × 2 bytes = 140 GB (FP16)

TPOT_weight_only ≈ 140 GB / HBM_bandwidth

硬體	HBM 頻寬 [廠商規格]	理論 TPOT 下限（僅權重讀取，FP16）
A100 80GB (HBM2e)	~2.0 TB/s	~70 ms
H100 SXM (HBM3)	~3.35 TB/s	~42 ms
H200 (HBM3e)	~4.8 TB/s	~29 ms
B200 (HBM3e)	~8.0 TB/s [廠商規格]	~18 ms

注：以上為權重讀取理論下限，未計入 KV cache、計算、通訊等開銷，實際 TPOT 通常高於此值 20–50%。使用 INT4 量化後，上述數值可近似除以 4。

---

7. 上下游

7.1 上游（TPOT 的決定因素）

┌─────────────────────────────────────────────────┐
│                 決定 TPOT 的因素                   │
├──────────────┬──────────────┬───────────────────┤
│  模型層       │  系統層       │  硬體層            │
├──────────────┼──────────────┼───────────────────┤
│ 引數量        │ 推論架構最佳化   │ HBM 頻寬          │
│ 精度(FP16/INT4)│ 批處理策略    │ HBM 容量           │
│ 架構(GQA/MoE) │ 排程器       │ GPU 計算能力        │
│ 層數/d_model  │ 量化方案      │ 互聯頻寬(NVLink等)  │
│ 序列長度      │ KV cache管理  │ 晶片數量/並行策略    │
└──────────────┴──────────────┴───────────────────┘

7.2 下游（TPOT 的影響物件）

• 使用者體感：流式輸出的流暢度
• 產品設計：影響是否適合即時互動場景（對話 vs 批次生成）
• 服務成本：TPOT × 輸出 token 數 = 單請求 GPU 佔用時間 → 影響 QPS 和 GPU 利用率
• API 定價：更低 TPOT → 同硬體可服務更多請求 → 每 token 邊際成本下降

---

8. 關鍵指標

指標	定義	與 TPOT 關係
TPOT (本文)	每輸出 token 的 decode 延遲	—
TTFT (Time To First Token)	首個輸出 token 的延遲（prefill）	與 TPOT 正交，可獨立最佳化
Decode Throughput (token/s)	服務端總輸出 token 吞吐	= 1/TPOT × batch_size（簡化）
Per-Request Throughput	單請求的輸出 token/s	= 1/TPOT
Time-to-Serve	單請求總延遲 = TTFT + TPOT × (N-1)	使用者端完整體驗
TPS (Tokens Per Second)	每秒輸出 token 數	= 1000/TPOT（TPOT 單位為 ms 時）
Inter-Token Latency (ITL)	與 TPOT 同義，部分文獻互換使用	—

關鍵效能指標參考區間

場景	目標 TPOT	說明
即時對話（類 ChatGPT 體驗）	< 50 ms（> 20 token/s）	超過人類閱讀速度
程式碼補全	< 30 ms（> 33 token/s）	需跟上編碼節奏
批次文件處理	< 200 ms 可接受	非互動，更關注吞吐
Agent / 工具呼叫	< 80 ms	需快速決策，但非即時對話

---

9. 供需與市場資料

9.1 推論成本中的 TPOT 意義

推論服務的單位成本（每 1000 token 價格）本質上可分解為：

Cost_per_1K_tokens ≈ (GPU_cost_per_hour) / (3600 × 1000 / TPOT_ms × avg_batch_size)

TPOT 降低 2× → 在相同 batch_size 下可服務的 token/s 翻倍 → 每 token 成本近乎減半。

9.2 主流 API 服務的 TPOT 參考（公開/社群測試，非標準化基準）

重要說明：以下資料來源於各廠商公開文件及第三方社群測試，測試條件（模型、prompt 長度、負載、region）各異，僅作量級參考，不宜直接橫比。

服務	模型（參考）	公開宣稱/社群測試的生成速度	估算 TPOT
OpenAI GPT-4o API	GPT-4o	官方宣稱低延遲，社群測試約 50–100+ token/s	~10–20 ms（估算，視負載）
Anthropic Claude API	Claude 3.5 Sonnet	社群測試約 60–90 token/s	~11–17 ms（估算）
Google Gemini API	Gemini 1.5 Pro	視場景，社群報告約 40–80 token/s	~13–25 ms（估算）
DeepSeek API	DeepSeek-V3	社群測試約 30–60 token/s	~17–33 ms（估算）
自建 Llama 3 70B (INT4, H100)	Llama 3 70B	社群基準約 15–30 token/s（單使用者）	~33–67 ms（估算）

注意：上述資料受測試條件影響極大，包括上下文長度、併發負載、是否使用 KV cache 命中、量化方案、batch 策略等。廠商通常在最佳化條件下公佈資料。

9.3 推論晶片 HBM 頻寬競爭格局

TPOT 的物理上限由 HBM 頻寬決定，這驅動了 HBM 的軍備競賽：

廠商/產品	HBM 代際	頻寬 [廠商規格]	狀態
NVIDIA H100	HBM3	~3.35 TB/s	量產中
NVIDIA H200	HBM3e	~4.8 TB/s	量產中
NVIDIA B200	HBM3e	~8.0 TB/s	量產中
AMD MI300X	HBM3	~5.3 TB/s	量產中
AMD MI350X	HBM3e	待公佈	預期中

---

10. 代表公司與資本對映

10.1 推論架構/平台（通過最佳化 TPOT 獲競爭力）

公司/專案	產品	TPOT 最佳化技術	備註
vLLM (UC Berkeley → 商業化)	vLLM	PagedAttention, Continuous Batching	開源影響力最大的推論引擎
NVIDIA	TensorRT-LLM	核心最佳化、量化、In-flight Batching	GPU 上效能標杆
Anyscale (Ray)	Ray Serve	分散式排程	適合大規模部署
SGLang	SGLang	RadixAttention（KV cache 複用）	複雜 Agent 場景優勢
Hugging Face	TGI	Continuous Batching	雲端上廣泛部署

10.2 晶片/硬體（提供 TPOT 的物理基礎）

類別	代表	與 TPOT 的關係
GPU（NVIDIA）	H100, H200, B200	HBM 頻寬直接決定 TPOT 下限
GPU（AMD）	MI300X, MI350X	高 HBM 頻寬競爭
推論 ASIC	Groq LPU, Cerebras WSE	通過 SRAM/片上儲存繞過 HBM 牆
記憶體廠商	SK Hynix, Samsung, Micron	HBM 代際提升直接改善 TPOT

---

11. 投資邏輯

11.1 核心判斷架構

TPOT 最佳化是推論市場的”刀刃”——誰的 TPOT 更低、成本更優，誰就在 API 服務市場有定價權。

11.2 投資對映

投資主題	邏輯	相關標的（舉例）
HBM 記憶體	TPOT 物理瓶頸 = HBM 頻寬，每代升級直接改善 TPOT	SK Hynix, Samsung, Micron
高階 GPU	更高 HBM 頻寬 + 更大容量 = 更低 TPOT + 更大 batch	NVIDIA, AMD
推論最佳化軟體	量化、排程、KV cache 管理可在同硬體上壓低 TPOT	vLLM 生態、NVIDIA TRT-LLM 生態
推論 ASIC	若能在特定場景突破 GPU 的 HBM 瓶頸	Groq, Cerebras, d-Matrix
Prefill-Decode 分離架構	分別最佳化兩個階段，預期成為大規模推論標準	新興架構，當前多為內部方案

11.3 風險

• 模型架構革新（如 Mamba/SSM 類線性注意力模型）可能從根本上改變 decode 的計算模式，TPOT 瓶頸從記憶體頻寬轉向計算
• 推論 ASIC 的適用範圍若受限於模型靈活性，市場空間可能小於預期
• FP4/更激進量化可能進一步削弱對 HBM 頻寬升級的需求

---

12. 常見誤讀糾偏

誤讀 1：「TPOT 就是生成速度（token/s）」

糾偏：TPOT 是每 token 的時間（ms/token），token/s = 1000/TPOT，二者互為倒數。更關鍵的區別：token/s 在含糊使用時可能指單請求速度（= 1/TPOT）或服務端總吞吐（= batch_size/TPOT），差異巨大。討論效能時必須明確語境。

誤讀 2：「TPOT 越低越好，應該不計代價追求最低 TPOT」

糾偏：TPOT 與吞吐存在 trade-off。一個請求的 TPOT 20 ms 但只能同時處理 1 個請求，不如 TPOT 50 ms 但可併發處理 20 個請求——後者的總吞吐和成本效率遠優於前者。最優解取決於場景：即時對話優先低 TPOT，批處理優先高吞吐。部分方案（如 Speculative Decoding）可在不顯著影響吞吐的情況下改善 TPOT。

誤讀 3：「TPOT 只和 GPU 算力有關」

糾偏：decode 階段在典型 batch_size 下是 memory-bandwidth-bound，不是 compute-bound。高 TFLOPS 數字對 TPOT 的改善是間接的（通過更大 batch 提升算術強度）。真正直接改善 TPOT 的是更大的 HBM 頻寬、更小的權重位元組（量化）、更高效的 KV cache