每 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 推理的核心体验指标？

大语言模型推理分为两个阶段：

在对话、代码补全、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）

以 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 的权衡

核心张力：增大 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. 技术演进史

6. 技术路线对比（量化表）

6.1 影响 TPOT 的主要技术路径

6.2 不同硬件平台的 TPOT 近似上限（理论内存带宽极限）

以 FP16 推理 70B 参数模型为例，仅读取模型权重的理论下界：

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

TPOT_weight_only ≈ 140 GB / HBM_bandwidth

注：以上为权重读取理论下限，未计入 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. 关键指标

关键性能指标参考区间

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）各异，仅作量级参考，不宜直接横比。

注意：上述数据受测试条件影响极大，包括上下文长度、并发负载、是否使用 KV cache 命中、量化方案、batch 策略等。厂商通常在优化条件下公布数据。

9.3 推理芯片 HBM 带宽竞争格局

TPOT 的物理上限由 HBM 带宽决定，这驱动了 HBM 的军备竞赛：

10. 代表公司与资本映射

10.1 推理框架/平台（通过优化 TPOT 获竞争力）

10.2 芯片/硬件（提供 TPOT 的物理基础）

11. 投资逻辑

11.1 核心判断框架

TPOT 优化是推理市场的”刀刃”——谁的 TPOT 更低、成本更优，谁就在 API 服务市场有定价权。

11.2 投资映射

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