AI 大模型的「快」怎麼量？Prefill、Decode、TTFT 推理效能術語完全指南

📅 2026-10-27 · 🏷️ 數位科技 · 📂 本地 AI 系列｜從「讀題目」與「寫答案」講起，看懂所有跑分報告

先給答案：是的，prefill（前置處理／提示詞處理）和 decode（解碼生成）就是業界標準術語，vLLM、TensorRT-LLM、llama.cpp、Strata 的原始碼與效能報告都用這組名字。但它們只是「兩個階段」的名稱；真正衡量快慢還有一整套指標：TTFT、TPOT、tokens/s、throughput⋯⋯這篇全部講完。

目錄

  1. 大模型生成只有兩個階段：Prefill 與 Decode
  2. 為什麼兩個階段瓶頸完全不同：算力型 vs 頻寬型
  3. 六個核心指標：TTFT、TPOT、速度、吞吐量
  4. KV Cache：decode 的「工作記憶」
  5. Batching：為什麼雲端服務比你快 10 倍
  6. MoE 專屬術語：active params、expert cache、layer split
  7. 跑分報告怎麼看才不被騙
  8. 在自己機器上實測這些數字
  9. 術語速查表
  10. 延伸閱讀與參考資料

一、大模型生成只有兩個階段：Prefill 與 Decode

你送一段提示詞給 AI，AI 的回覆過程在引擎內部永遠分成兩段，沒有第三種：

Prefill（前置處理）＝讀題目。模型把你的整段 prompt（可能幾百到幾萬個 token）一次全部餵進去平行計算。因為每個輸入 token 在讀題時就已知，不需要等任何人，GPU 的數萬個核心可以同時開工。讀完的副產品是每個 token 在每一層的「筆記」（K/V 向量，存進 KV Cache，第 4 節會講）。

Decode（解碼生成）＝寫答案。從這裡開始一次只生出一個 token，而且第 N 個 token 的生成必須等第 N−1 個出來才能開始——這是自迴歸（autoregressive）架構的天性，寫下一句話之前你不可能已經知道它。想生 500 字就要走 500 步，一步一步來。

兩段加起來的用戶感受就是：

回覆總時間 ≈ TTFT（讀題時間）＋ 輸出長度 × TPOT（每字寫作時間）

所以「AI 回應慢」其實是兩種完全不同的病：開頭卡很久才吐第一個字，是 prefill 的問題；開始吐字後一個字一個字卡，是 decode 的問題。兩者的處方幾乎相反，這就是為什麼專業報告永遠把它們分開列。

二、為什麼兩個階段瓶頸完全不同：算力型 vs 頻寬型

同樣是「跑矩陣乘法」，兩位的姿勢差了十萬八千里：

這個分野有正式的理論框架：Roofline 模型（Berkeley 的 Williams、Waterman、Patterson 提出的效能分析圖），核心變數叫算術強度（arithmetic intensity）＝每搬 1 byte 資料能做幾次運算。算術強度低於某個門檻，再強的晶片也只能等快取送貨。

💡 白話結論：同一張卡，prefill 可以跑到每小時幾十萬字的速度，decode 可能只有它的百分之一，而且升級晶片算力不會讓 decode 變快——decode 想快只有三條路：更大的記憶體頻寬（換卡看 GDDR 速度、上 HBM）、把更多權重塞進更快的記憶體層（VRAM 駐留）、或每個 token 少讀點 weight（更兇的量化、更高的快取命中率）。
PrefillDecode
平行度整個 prompt 一次平行一次一個 token，強制排隊
運算形態矩陣×矩陣（GEMM）矩陣×向量（GEMV）
瓶頸算力 FLOPS記憶體頻寬 GB/s
典型速度（家用卡、7B~125B 級）數百～數萬 token/s10～100+ token/s
決定的指標TTFTTPOT

三、六個核心指標：TTFT、TPOT、速度、吞吐量

業界講效能，真正掛在嘴邊的是這六個名字。前兩個是延遲類（使用者有多難受），中間兩個是速度類（引擎報告上的 token/s 多半指它們），後兩個是服務類（機房 KPI）：

術語全名／別名白話誰最在意
TTFTTime To First Token，首 token 延遲送出問題到看見第一個字的等待時間。主要被 prefill 決定，超長 prompt 時 KV Cache 讀取也參一腳聊天體驗：TTFT 超過 2～3 秒人就開始懷疑當機
TPOTTime Per Output Token；也常叫 ITL（Inter-Token Latency，字間延遲）開始吐字後，平均每個字隔多久出現。約等於 1000ms ÷ 每使用者 tokens/s閱讀流暢感：低於 33ms（=30 token/s）就跟得上人類閱讀速度
Prefill 速度prompt eval speed、prompt processing rate每秒能「讀完」多少個輸入 token，單位 token/sRAG、長文件、agent 系統（每輪都塞大量上下文）
Decode 速度generation speed、output speed每秒能「寫出」多少個 token，單位 token/s。論壇戰帖上講的「我那張卡 40t/s」都是它一般使用者最常問的「AI 有多快」
Throughput吞吐量、系統吞吐整台機器所有人加總每秒處理的 token 數。和單人速度是兩回事：batch 開大，throughput 飆升但每個人的 TPOT 變差雲端服務商的成本報表（每 GPU 每小時服務多少 token）
E2E LatencyEnd-to-End 延遲從送出到收到完整回覆的總時間＝TTFT＋輸出長度×TPOTAPI 整合、批次工作（要的是整份結果）
💡 為什麼雲 API 的「輸出 token」比「輸入 token」貴 3～5 倍？現在你可以自己推出來：輸入 token 走 prefill，平行、便宜、單位成本趨近電費；輸出 token 走 decode，逐個排隊、霸佔 KV Cache 和記憶體頻寬。輸入便宜輸出貴，是架構決定的定價，不是行銷。

四、KV Cache：decode 的「工作記憶」

Prefill 讀完題目後留下的筆記，就叫 KV Cache：每個 prompt token 在模型每一層都會算出一對 Key／Value 向量，生成新 token 時要拿它來「回憶」上下文。有了 KV Cache，decode 每一步只需要算新 token 自己的那一份，歷史部分直接查表——沒有它，每生一個字都要把整篇 prompt 重讀一遍，長度平方級爆炸。

KV Cache 大小 ≈ 2 (K和V) × 層數 × 每頭維度 × KV 頭數 × 上下文長度 × 每數值位元組

三個實務結論：

五、Batching：為什麼雲端服務比你快 10 倍

第二節說過：decode 單人獨跑時，權重搬進來只服務一個 token，頻寬大片浪費。解法很直覺——把很多人的 token 湊在同一批：權重搬進來一次，同時乘上幾十個使用者的向量，算術強度直接乘上 batch 數。矩陣×向量悄悄變回矩陣×矩陣，晶片從等貨變回滿工。

💡 家用的殘酷現實：batching 救不了你——家裡同一時刻通常只有你一個人在問（或只有 Hermes 一個 agent 在排隊）。雲端那張卡「同樣型號快你十倍」，很大成分是它背後有幾十路人馬幫它把 batch 填滿。單一使用者比的就是裸頻寬。

六、MoE 專屬術語：active params、expert cache、layer split

本機跑巨型模型的人會多碰到一組 MoE（Mixture of Experts，混合專家）專屬的詞。MoE 的精神是：模型總參數很大，但每個 token 只激活其中一小撮「專家」，其餘的不用碰。

術語白話
Active parameters（激活參數）每個 token 實際用到的參數量。例如本機這台跑的 Qwen3.8-Flash-Next：總計約 125B，每個 token 只激活約 3B——這就是 80GB RAM 能跑「125B」的原因。算 decode 速度時要用 active 的那個數。
Expert offload（專家卸載）把大部分專家放在 RAM（甚至磁碟），只有熱門的駐留 VRAM。MoE 引擎的核心技。
Expert cache hit rate（專家快取命中率）下一步要的專家剛好已在 VRAM 的比例。命中＝不用從 RAM 搬；不命中＝走慢速通道。命中率影響負載與平順度，但在頻寬受限的平台上，它不是 decode 速度的萬靈丹（本機實測過：命中率翻倍、tok/s 不動）。
Layer split／Tensor split（切分）多張卡時的分工方式：layer split 按層切（每張卡負責前一半／後一半層，各自有專家快取），tensor split 把每個矩陣橫切成兩半兩張卡合算。Strata 的 --gpus 0,1 走的是 layer split。
MTP／Speculative decoding（投機式解碼）用一個小draft 模型（或多頭預測頭）先猜接下來幾個 token，大模型一次驗證。猜對的步驟等於免費——這是近年 decode 速度成長的重要來源，不換硬體也能加速。

把頻寬公式用在自己身上

decode token/s ≈ 記憶體頻寬 (GB/s) ÷ 每 token 需讀的權重量 (GB)

以本機實測為例：IQ4_XS 量化約 0.56 byte/參數，激活約 3B → 每 token 讀約 1.7GB。DDR4 雙通道實際跑出約 30～40 GB/s → 理論上限 ≈ 30～40 ÷ 1.7 ≈ 18～24 token/s，與實測的 22 token/s 單人 decode 吻合到令人絕望。這份運算也直接告訴你：在同一平台上，換更兇的量化（IQ2_XS，體積減半）比換更猛的卡有效得多。

七、跑分報告怎麼看才不被騙

八、在自己機器上實測這些數字

llama.cpp 路線

# 純速度基準（先量 prefill 再量 decode）
llama-bench -m model.gguf -p 512,2048 -n 128

# 自己起 server 手動測
llama-server -m model.gguf --port 8080
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -d '{"model":"x","messages":[{"role":"user","content":"說個笑話"}],"stream":true}' \
  | head -5   # 肉眼感覺 TTFT；精確值看 server log

llama.cpp 的 server log 每筆請求會直接印出 prompt eval time（prefill 速度）和 eval time（decode 速度），單位都是 token/s，還有 TTFT 欄位，是最省事的資料來源。

Strata 路線（本機主力）

# 健康＋即時狀態
curl -s http://127.0.0.1:8080/health
# 引擎日誌直接看逐請求速度與專家快取命中率
grep -E "tok/s|hit" /root/Strata/strata-unsloth-ud-iq4_xs.log | tail

硬體層旁證

watch -n1 rocm-smi        # AMD 卡：VRAM 使用率、功耗、溫度
free -h                   # RAM 餘量（MoE 卸載的真相在這裡）
💡 建議的紀錄習慣：固定同一條 prompt＋固定輸出長度，每換一個設定（量化／KV 量化／卡數／context）記一組「TTFT、prefill tok/s、decode tok/s」三連。三個月後你就擁有比任何網文都可靠的自家硬體效能曲線。

九、術語速查表

英文中文一句話
Prefill / prompt processing前置處理／讀題平行讀完整個 prompt，生成 KV Cache
Decode / generation解碼生成／寫答案逐 token 順序生成，一步一字
TTFT首 token 延遲送出到第一個字的等待
TPOT / ITL每輸出 token 時間／字間延遲吐字節奏，1000ms÷個人 tok/s
Prompt eval speedprefill 速度每秒讀多少 token
Generation speeddecode 速度每秒寫多少 token（論壇常說的那個）
Throughput吞吐量全機加總每秒 token，機房 KPI
E2E latency端到端延遲TTFT＋長度×TPOT
KV CacheKV 快取歷史 token 的筆記，decode 靠它回憶
KV quantizationKV 量化把筆記壓細（int8/q4_0）省 VRAM
Prefix / prompt caching前綴快取重複開頭不重讀，第二輪秒回
Continuous batching連續批處理隨時踢舊插新，機房填滿 batch 的方法
Compute-bound / bandwidth-bound運算受限／頻寬受限prefill 的病 vs decode 的病
Arithmetic intensity / Roofline算術強度／屋頂線模型判「卡在哪」的理論工具
Active parameters激活參數MoE 每 token 真正動到的參數
Expert offload / cache hit rate專家卸載／命中率誰住 VRAM、誰住 RAM
Layer split / tensor split按層切／按維切多卡分工的兩種方式
Speculative decoding / MTP投機式解碼／多頭預測小模型先猜、大模型驗收
SLO / Goodput服務承諾／有效吞吐達標的 throughput 才算數
Warmup / cold start熱機／冷啟動第一發永遠最慢，跑分要先熱

十、延伸閱讀與參考資料

延伸閱讀

參考資料與出處

各術語的論文與專案著作權屬原作者所有，本篇僅為個人學習整理，內文數據取自自家機台實測，以原始論文與官方文件為準。

© 2026 Beruupdown Tech Blog | 本站技術內容僅供學習參考

2026-10-27 發布 ｜ 返回數位科技分類 ｜ BeruUpDownTech 部落格首頁