首Token延迟 (TTFT, Time To First Token)

3秒看懂

TTFT = 从用户按下”发送”到屏幕上出现第一个字的等待时间。 它是大模型”思考”多久才开口回答你的时间，直接决定用户体感是否”卡”。

3分钟产业解释

为什么TTFT突然成为焦点？

大模型推理分两个阶段：

1. Prefill（预填充）：一次性”阅读”完用户的全部输入，计算出所有中间状态（KV Cache），产出第一个token
2. Decode（解码）：逐个生成后续token

TTFT ≈ Prefill阶段的计算耗时（加上排队、网络等开销）。

当模型从”闲聊”走向”生产工具”——客服系统、代码助手、搜索引擎增强——用户能容忍的等待阈值从数秒压缩到亚秒级。TTFT成为产品体验的生死线。

类比：传统搜索引擎的首屏时间（TTFB）决定了用户是否点击；大模型的TTFT决定了用户是否继续使用。

核心矛盾

结果：TTFT优化成为推理系统工程的核心战场。

15分钟专家深入

TTFT的完整分解

TTFT = T_queue + T_network + T_prefill + T_sample
         │           │            │            │
         │           │            │            └─ 采样+解码开销（通常可忽略）
         │           │            └─ 核心：Prefill计算（约占90%+）
         │           └─ 请求传输+KV Cache传输（分布式场景显著）
         └─ 等待GPU空闲槽位（batch调度）

关键洞察：在优化良好的系统中，T_prefill是绝对主导项。优化TTFT本质上就是优化Prefill效率。

Prefill的计算本质

Transformer的Prefill阶段，每个attention层需要：

• Q、K、V投影：对prompt中所有token并行计算
• Self-Attention：所有token之间的两两交互（O(n²)）
• FFN：逐token的前馈计算

粗略计算量估算（密集Transformer，推理）：

FLOPs_prefill ≈ 2 × N_params × L_tokens
    │              │            │
    │              │            └─ 输入prompt的token数
    │              └─ 模型总参数量（如7B、70B）
    └─ 每个参数约2次浮点运算（乘+加）

注意：MoE模型的激活参数量远小于总参数量，Prefill FLOPs应按激活参数计算，而非总参。

计算瓶颈分析

Prefill的算术强度（Arithmetic Intensity） 高于Decode：

• Prefill：大矩阵乘法，GPU计算单元利用率高，compute-bound
• Decode：单token生成，矩阵向量乘法，memory-bound

这意味着Prefill理论上能充分利用GPU算力，但前提是：

1. Batch size足够大（或序列足够长）
2. 内存访问模式高效（HBM带宽不成为瓶颈）
3. Attention计算有算法优化

TTFT与输入长度的关系

这是最关键的产品端约束：

TTFT ∝ L_tokens（近似线性，因为compute-bound）

注：以上为量级估算，实际取决于硬件型号、batch大小、优化程度。具体数字因厂商未充分披露基准测试条件，不作定论。

技术原理

1. Prefill阶段的计算图

输入: [token_1, token_2, ..., token_L]
           │
    ┌──────▼──────┐
    │ Token Embedding │
    └──────┬──────┘
           │ (L × d_model)
    ┌──────▼──────────────────────┐
    │         × N_layers          │
    │  ┌────────────────────────┐ │
    │  │ Q = x · W_q            │ │
    │  │ K = x · W_k            │ │
    │  │ V = x · W_v            │ │
    │  │                        │ │
    │  │ A = softmax(Q·K^T/√d)  │ │  ← O(L²·d)，TTFT的主要贡献
    │  │ O = A · V              │ │
    │  │                        │ │
    │  │ FFN: h → up → act → down│ │  ← O(L·d²)
    │  └────────────────────────┘ │
    └─────────────────────────────┘
           │
    ┌──────▼──────┐
    │ LM Head     │ → logits (vocab_size)
    └──────┬──────┘
           │
    ┌──────▼──────┐
    │ Sampling    │ → 第一个token
    └─────────────┘

2. KV Cache的生成与意义

Prefill不仅产出第一个token，还生成完整的KV Cache：

KV Cache结构（每个attention层）：
┌─────────────────────────────────┐
│ K_cache: [L × d_head × n_heads] │
│ V_cache: [L × d_head × n_heads] │
└─────────────────────────────────┘
    │
    └─ 存储在GPU HBM中，供后续Decode阶段复用

KV Cache大小估算（每层）：

Size = 2 × L × n_heads × d_head × dtype_bytes
     = 2 × L × d_model × dtype_bytes  (因为 n_heads × d_head = d_model)

对于128K上下文、80层、d_model=8192、FP16：

Size ≈ 2 × 128K × 8192 × 2B × 80 ≈ 320GB [估算]

这就是为什么长上下文对KV Cache内存需求极大，也是GQA/MQA等技术存在的原因。

3. 关键优化技术原理

FlashAttention

问题：标准attention需要将完整的L×L注意力矩阵写入HBM，内存带宽成为瓶颈。

思路：利用GPU SRAM（片上缓存，带宽>>HBM）做分块计算，避免物化完整注意力矩阵。

标准Attention:
  Q,K,V → HBM读取 → 计算L×L矩阵 → HBM写入 → softmax → HBM读取 → V加权
  
FlashAttention:
  Q,K,V → 分块加载到SRAM → 在SRAM内完成softmax计算（在线softmax技巧）→ 直接输出结果
  [不写入L×L矩阵到HBM]

效果：Prefill速度提升2-4x [常见文献引用范围]，同时内存占用从O(L²)降至O(L)。

Continuous Batching

问题：传统static batching中，batch内所有请求必须同时开始、同时结束，短请求等待长请求，GPU利用率低。

思路：允许不同请求动态加入/退出batch，GPU始终满载。

Static Batching:
  请求A: [████████████]
  请求B: [██░░░░░░░░░░]  ← 等待A完成
  请求C: [███░░░░░░░░░]  ← 等待A完成
  
Continuous Batching:
  请求A: [████████████]
  请求B: [██]→完成→[请求D: ████]
  请求C: [███]→完成→[请求E: ███████]

对TTFT的影响：减少T_queue（排队等待时间）。

Prefix Caching

问题：相同system prompt或前缀的请求重复Prefill，浪费算力。

思路：缓存已计算的KV Cache，命中时跳过对应token的Prefill。

请求1: [System Prompt: 4K tokens] + [用户问题A: 100 tokens]
       ──── 完整Prefill ────

请求2: [System Prompt: 4K tokens] + [用户问题B: 200 tokens]
       ── 命中缓存 ─┘        └─ 仅Prefill新token

效果：对于system prompt较长的场景，TTFT可显著降低（从处理全部token降至仅处理增量token）。

张量并行（Tensor Parallelism）与Prefill

大模型分布到多卡时，Prefill的通信模式：

单层张量并行（TP=4）：

GPU0  GPU1  GPU2  GPU3
  │     │     │     │
  ▼     ▼     ▼     ▼
[W_q/4] [W_q/4] [W_q/4] [W_q/4]  ← 权重切分
  │     │     │     │
  ▼     ▼     ▼     ▼
 AllReduce（同步Q、K、V结果）
  │     │     │     │
  ▼     ▼     ▼     ▼
Attention计算
  │     │     │     │
  ▼     ▼     ▼     ▼
 AllReduce（同步attention输出）

注意：张量并行中的主要通信原语是AllReduce/ReduceScatter，而非All-to-All。All-to-All更多见于MoE的专家路由通信。

分块Prefill（Chunked Prefill）

问题：长prompt的Prefill会独占GPU数秒，阻塞batch中的其他decode请求，导致decode延迟飙升。

思路：将长prompt切分为多个chunk，交错执行prefill chunk和decode步骤。

传统：  [====== Prefill 128K tokens ======] [decode请求A] [decode请求B]...
分块：  [P-chunk1][decodeA][P-chunk2][decodeB][P-chunk3][decodeA]...

效果：TTFT略微增加（Prefill被切分），但decode延迟大幅降低，系统整体更平稳。

技术演进史

技术路线对比

TTFT优化技术量化对比（框架）

注：改善幅度为量级估算，具体取决于工作负载特征、硬件配置、系统实现。实际基准测试数据多由各推理框架/厂商发布，条件不完全可比。

上下游

上游（影响TTFT的因素）

┌─────────────────────────────────────────────────────────┐
│                      上游影响因素                         │
├──────────────┬──────────────┬───────────────────────────┤
│   模型侧      │   硬件侧      │   系统侧                  │
├──────────────┼──────────────┼───────────────────────────┤
│ 模型参数量    │ GPU/TPU算力   │ 推理框架优化              │
│ 架构(Attention│ HBM容量/带宽  │ 调度策略                  │
│  类型,层数)   │ 网络互联带宽   │ 内存管理                  │
│ 上下文长度    │              │ 缓存策略                  │
│ 量化方案      │              │ 并行策略                  │
└──────────────┴──────────────┴───────────────────────────┘

下游（TTFT影响的场景）

关键指标

TTFT相关性能指标体系

用户体感指标
    ├── TTFT（首Token延迟）← 核心指标
    ├── TPOT（Time Per Output Token，每token生成时间）
    ├── TPS（Tokens Per Second，吞吐）
    └── E2E Latency（端到端延迟，= TTFT + TPOT × output_length）

系统效率指标
    ├── GPU利用率（MFU，Model FLOPs Utilization）
    ├── 请求吞吐（requests/s）
    ├── KV Cache命中率（针对prefix caching）
    └── 有效算力占比（= 有效FLOPs / 峰值FLOPs）

指标之间的张力

              TTFT
               ▲
               │
    低并发 ◄────┼────► 高并发
               │
               ▼
              TPOT

低并发时：TTFT低（独占GPU），TPOT低
高并发时：TTFT升高（排队），TPOT升高（GPU争用）
         但系统总吞吐提升

核心trade-off：是优先单用户TTFT，还是系统总吞吐？不同业务有不同选择。

供需与市场数据

需求端

• 用户体验研究 [行业共识]：TTFT超过3-5秒时用户流失率显著上升
• 竞品对标：主流API服务（如Claude、GPT系列、Gemini等）在短输入场景下TTFT多在0.5-2s范围 [公开基准测试估算]
• 长上下文场景：128K输入的TTFT可能达到5-15s [估算]，是优化重点

供给端

• 推理框架：vLLM、TensorRT-LLM、SGLang、DeepSpeed-FastGen等均将TTFT作为核心优化目标
• 硬件厂商：GPU/TPU的算力提升直接降低Prefill时间；专用推理芯片（如Groq LPU）强调低延迟
• 云服务商：各API提供商通过调度优化、缓存策略降低TTFT

市场规模（间接相关）

大模型推理市场 → TTFT优化技术/方案的市场

推理算力市场 [行业报告估算]：
├── 2024年：数百亿美元级
├── 2027年（预测）：千亿美元级
└── TTFT优化技术是该市场的"软件层增值"

注：具体市场数字参考Gartner、IDC等机构报告，此处为量级估算。

代表公司与资本映射

推理框架/引擎

硬件

资本映射逻辑

TTFT优化链条：

硬件层 ──── NVIDIA/AMD/自研芯片（算力提升）
    │
编译层 ──── TensorRT/Triton/XLA（计算图优化）
    │
框架层 ──── vLLM/SGLang/TGI（系统级优化）
    │
模型层 ──── GQA/MQA/稀疏Attention（架构优化）
    │
应用层 ──── API服务商（缓存/调度/定价策略）

投资逻辑

核心判断框架

TTFT优化的投资价值 = f(模型使用规模, 场景延迟敏感度, 优化技术壁垒)

1. 模型使用规模增长：推理请求量指数级增长 → TTFT优化的边际价值提升
2. 场景延迟敏感：从”能用”到”好用”→ 低TTFT成为产品差异化要素
3. 技术壁垒：FlashAttention级别优化需要深厚的系统+硬件理解

投资方向

关键观测点

• FlashAttention的下一代：能否继续带来数量级提升？
• 硬件架构演进：更大SRAM、更高HBM带宽能否跟上模型增长？
• MoE模型的Prefill特性：稀疏激活如何改变TTFT优化策略？

常见误读纠偏

误读1：“TTFT就是Prefill时间”

纠偏：TTFT = T_queue + T_network + T_prefill + T_sample。

在低并发场景下T_prefill确实主导；但在高并发场景下，T_queue（排队等待GPU空闲槽位）可能成为显著部分。Continuous Batching等技术的核心收益往往在降低T_queue，而非T_prefill。

误读2：“降低TTFT就用更多卡做张量并行”

纠偏：张量并行降低TTFT的前提是通信带宽不是瓶颈。当TP从4扩展到8，AllReduce的通信开销可能抵消计算收益。存在最优TP度数，超过后TTFT反而上升。

此外，TP不是唯一选择：

• 序列并行（Sequence Parallelism）：将输入序列切分到不同GPU
• Prefill-Decode分离：用不同集群分别处理Prefill和Decode

误读3：“FlashAttention能无限提升Prefill速度”

纠偏：FlashAttention解决的是HBM带宽瓶颈（memory-bound场景）。当Prefill本身已经是compute-bound时（长prompt + 高算力GPU），FlashAttention的边际收益递减。此时优化方向转向减少计算量本身（如量化、稀疏注意力）或增加算力（更多GPU、更快芯片）。

误读4：“长上下文的TTFT是线性增长的”

纠偏：标准Self-Attention的计算复杂度是O(L²)，所以理论上TTFT应与输入长度的平方成正比。但FlashAttention等优化改变了这个关系——在compute-bound regime下，FlashAttention的有效复杂度接近O(L)（消除了HBM带宽的L²访问）。实际TTFT增长曲线取决于：

• 硬件是compute-bound还是memory-bound
• 是否使用了FlashAttention等优化
• 系统层面是否有分块Prefill

学习路径

入门

1. 理解Transformer推理的Prefill vs Decode两阶段
2. 使用vLLM或TGI部署模型，观察不同输入长度的TTFT
3. 阅读NVIDIA TensorRT-LLM文档中的性能调优章节

进阶

4. 阅读FlashAttention论文（Tri Dao et al.），理解IO-aware算法设计
5. 阅读vLLM论文（PagedAttention），理解内存管理对推理性能的影响
6. 学习SGLang的RadixAttention，理解高级prefix caching
7. 实操：profile一个推理服务，定位TTFT瓶颈（计算 vs 排队 vs 内存）

专家

8. 研究Prefill-Decode分离架构（Splitwise、DistServe等学术论文）
9. 分析MoE模型的Prefill特性（Expert路由的All-to-All通信）
10. 跟踪FlashAttention-3及后续版本的内核优化技术
11. 硬件层面：理解GPU的SRAM/HBM层次结构对attention实现的约束

一句话总结

TTFT是大模型推理体验的第一道门槛，其本质是Prefill阶段的计算效率问题，优化方向横跨硬件算力、算法创新、系统工程三个维度，是推理时代最核心的性能指标之一。

延伸阅读与来源

论文

• Dao, T. et al. “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness” (2022)
• Dao, T. “FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning” (2023)
• Kwon, W. et al. “Efficient Memory Management for Large Language Model Serving with PagedAttention” (SOSP 2023, vLLM)
• Zhong, Y. et al. “SGLang: Efficient Execution of Structured Language Model Programs” (2024)
• Patel, P. et al. “Splitwise: Efficient Generative LLM Inference Using Phase Splitting” (ISCA 2024)
• Zhong, Y. et al. “DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving” (OSDI 2024)

工程资源

• vLLM官方文档：https://docs.vllm.ai/
• NVIDIA TensorRT-LLM文档：https://github.com/NVIDIA/TensorRT-LLM
• SGLang官方文档：https://sgl-project.github.io/
• NVIDIA H100 Transformer Engine技术白皮书

社区讨论

• LMSYS Chatbot Arena基准测试（真实用户TTFT数据参考）
• 各推理框架GitHub Issues中的性能讨论

本文档基于公开技术文献与行业认知编写。具体性能数据因测试条件差异（硬件配置、batch大小、输入长度、优化级别）存在较大变异，建议以各厂商/框架官方基准测试为准。市场数据为量级估算，引用需核实原始报告。

最后更新：2025年