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

3秒看懂

TTFT = 從使用者按下”傳送”到螢幕上出現第一個字的等待時間。 它是大型模型”思考”多久才開口回答你的時間，直接決定使用者體感是否”卡”。

3分鐘產業解釋

為什麼TTFT突然成為焦點？

大型模型推論分兩個階段：

Prefill（預填充）：一次性”閱讀”完使用者的全部輸入，計算出所有中間狀態（KV Cache），產出第一個token
Decode（解碼）：逐個生成後續token

TTFT ≈ Prefill階段的計算耗時（加上排隊、網路等開銷）。

當模型從”閒聊”走向”生產工具”——客服系統、程式碼助手、搜尋引擎增強——使用者能容忍的等待閾值從數秒壓縮到亞秒級。TTFT成為產品體驗的生死線。

類比：傳統搜尋引擎的首屏時間（TTFB）決定了使用者是否點選；大型模型的TTFT決定了使用者是否繼續使用。

核心矛盾

維度	趨勢	對TTFT的影響
模型引數量	持續增大（百億→千億→萬億MoE）	Prefill計算量上升
輸入長度	長上下文成為標配（128K+）	Prefill計算量大幅上升
使用者預期	從”能用”到”好用”	可接受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算力，但前提是：

Batch size足夠大（或序列足夠長）
記憶體訪問模式高效（HBM頻寬不成為瓶頸）
Attention計算有演算法最佳化

TTFT與輸入長度的關係

這是最關鍵的產品端約束：

TTFT ∝ L_tokens（近似線性，因為compute-bound）

輸入長度	7B模型（單卡A100級）	70B模型（多卡並行）
~1K tokens	數十ms級 [估算]	數百ms級 [估算]
~8K tokens	數百ms級 [估算]	秒級 [估算]
~128K tokens	秒級 [估算]	十秒級 [估算]

注：以上為量級估算，實際取決於硬體型號、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最佳化思路
2017-2019	Transformer提出，早期BERT/GPT	模型較小，TTFT不是關注點
2020-2021	GPT-3(175B)，模型規模化	算力需求上升，但推論場景有限
2022	ChatGPT爆發，InstructGPT	Prefill最佳化需求湧現，FlashAttention v1釋出
2023	通用大型模型API服務，百模大戰	FlashAttention-2，vLLM引入PagedAttention/Continuous Batching，Prefix Caching成為標配
2024	長上下文成為標配(128K-1M)，MoE普及	稀疏注意力、分塊Prefill、GQA/MQA降低KV Cache開銷、Prefill-Decode分離架構（Splitwise等）
2025+	超長上下文(10M+)、即時互動	推測Prefill、異構排程、編譯最佳化

技術路線對比

TTFT最佳化技術量化對比（架構）

最佳化技術	TTFT改善幅度	實現複雜度	精度影響	適用場景
FlashAttention-2/3	2-4x [文獻引用範圍]	低（架構整合）	無	通用
Continuous Batching	排隊延遲降低顯著	中	無	高併發服務
Prefix Caching	字首命中時TTFT大幅降低	中	無	相同system prompt場景
張量並行(TP=4→8)	TTFT近線性提升(頻寬允許時)	低	無	大型模型多卡推論
GQA/MQA	KV Cache減小，間接改善	低（需模型支援）	微小	KV Cache受限場景
分塊Prefil	TTFT略增，但系統公平性提升	中	無	長prompt+高併發
量化(INT8/INT4)	Prefill計算量降低	中	微小-小	成本敏感
Prefill-Decode分離	獨立最佳化各階段	高	無	大規模服務

注：改善幅度為量級估算，具體取決於工作負載特徵、硬體配置、系統實現。實際基準測試資料多由各推論架構/廠商釋出，條件不完全可比。

上下游

上游（影響TTFT的因素）

┌─────────────────────────────────────────────────────────┐
│                      上游影響因素                         │
├──────────────┬──────────────┬───────────────────────────┤
│   模型側      │   硬體側      │   系統側                  │
├──────────────┼──────────────┼───────────────────────────┤
│ 模型引數量    │ GPU/TPU算力   │ 推論架構最佳化              │
│ 架構(Attention│ HBM容量/頻寬  │ 排程策略                  │
│  型別,層數)   │ 網路互聯頻寬   │ 記憶體管理                  │
│ 上下文長度    │              │ 快取策略                  │
│ 量化方案      │              │ 並行策略                  │
└──────────────┴──────────────┴───────────────────────────┘

下游（TTFT影響的場景）

應用場景	TTFT敏感度	典型要求
即時對話/客服	極高	<1s
程式碼補全	極高	<500ms
搜尋增強（RAG）	高	<2s
文件摘要	中	<5s
離線批處理	低	分鐘級可接受

關鍵指標

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的關聯
vLLM（UC Berkeley）	PagedAttention, Continuous Batching	開源推論引擎標杆，TTFT最佳化的重要參考實現
Anyscale（Ray）	分散式推論排程	通過排程最佳化降低排隊延遲
TensorRT-LLM（NVIDIA）	編譯最佳化, FP8, In-flight Batching	NVIDIA官方推論最佳化棧
SGLang（LMSYS）	RadixAttention（高階prefix caching）	字首快取最佳化，降低重複Prefill TTFT
Triton（OpenAI）	編譯器驅動的核心最佳化	底層計算最佳化

硬體

公司	產品方向	與TTFT的關聯
NVIDIA	GPU（A100→H100→B200）	算力提升直接降低Prefill時間
AMD	MI300系列	競爭性推論算力
Groq	LPU	確定性低延遲架構
Cerebras	晶圓級晶片	大規模片上SRAM，減少HBM瓶頸

資本對映邏輯

TTFT最佳化鏈條：

硬體層 ──── NVIDIA/AMD/自研晶片（算力提升）
    │
編譯層 ──── TensorRT/Triton/XLA（計算圖最佳化）
    │
架構層 ──── vLLM/SGLang/TGI（系統級最佳化）
    │
模型層 ──── GQA/MQA/稀疏Attention（架構最佳化）
    │
應用層 ──── API服務商（快取/排程/定價策略）

投資邏輯

核心判斷架構

TTFT最佳化的投資價值 = f(模型使用規模, 場景延遲敏感度, 最佳化技術壁壘)

模型使用規模增長：推論請求量指數級增長 → TTFT最佳化的邊際價值提升
場景延遲敏感：從”能用”到”好用”→ 低TTFT成為產品差異化要素
技術壁壘：FlashAttention級別最佳化需要深厚的系統+硬體理解

投資方向

方向	邏輯	風險
推論晶片	硬體算力是TTFT的底層約束	NVIDIA壟斷地位穩固
推論架構/引擎	軟體最佳化是”免費午餐”，邊際成本低	開源競爭激烈
長上下文技術	長prompt是TTFT的最大挑戰	技術路線不確定
推測推論（Speculative Decoding）	潛在的TTFT+TPOT雙重最佳化	成熟度待驗證
Prefill-Decode分離架構	獨立最佳化各階段，資源利用率提升	工程複雜度高

關鍵觀測點

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

學習路徑

入門

理解Transformer推論的Prefill vs Decode兩階段
使用vLLM或TGI部署模型，觀察不同輸入長度的TTFT
閱讀NVIDIA TensorRT-LLM文件中的效能調優章節

進階

閱讀FlashAttention論文（Tri Dao et al.），理解IO-aware演算法設計
閱讀vLLM論文（PagedAttention），理解記憶體管理對推論效能的影響
學習SGLang的RadixAttention，理解高階prefix caching
實操：profile一個推論服務，定位TTFT瓶頸（計算 vs 排隊 vs 記憶體）

專家

研究Prefill-Decode分離架構（Splitwise、DistServe等學術論文）
分析MoE模型的Prefill特性（Expert路由的All-to-All通訊）
追蹤FlashAttention-3及後續版本的核心最佳化技術
硬體層面：理解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年