Token/s 怎麼看？本地大模型速度的正確測試方法

Token/s 是本地大模型最常被拿來比較的速度數字，也是最容易被誤讀的一個。同樣寫「每秒 XX token」，有人量的是模型讀完你貼進去的長文章有多快，有人量的是它一個字一個字吐出答案有多快，這是兩件不同的事，瓶頸也不同。這篇會先把名詞拆清楚，再給你一套可以照著做的測試步驟，最後教你怎麼判斷別人貼的數字能不能信、能不能拿來和你的機器比。

這篇不會給任何「某某顯示卡跑某某模型是多少 tokens/s」的數字，因為那些數字取決於你的整套設定，沒有出處就不該寫。文中出現的數字，若不是來自官方文件（會標明）就是示範計算的假設值（會標明「假設」）。

Token/s 是什麼？

token 是模型處理文字的最小單位，一個字、一個詞或一段字根都可能是一個 token（詳見術語表的 token）。Token/s 就是每秒處理或產生多少個 token。問題在於，一次完整的請求其實分成兩個階段，Hugging Face Transformers 的連續批次處理文件把一個請求的過程列成：等待排隊、Prefilling（提示詞的 token 在一次前向運算中被處理）、Decoding（輸出的 token 一次產生一個）、完成。

• prefill（預填充，又稱 prompt processing）：模型把你送進去的整段提示詞讀完、並建好 KV 快取的階段。llama.cpp 的 llama-bench 把它叫做 pp（prompt processing），README 的說法是「分批處理一段提示詞」。
• decode（解碼，又稱 text generation）：模型接著一個 token 一個 token 往後生成的階段。llama-bench 叫它 tg（text generation），README 的說法是「生成一串 token」。
• KV 快取（key-value cache）：模型把已經處理過的 token 的中間結果存起來，之後生成新 token 時不必重算。Hugging Face 的教學說它能顯著加速，代價是長輸入或多輪對話時，這份快取本身會佔用很多記憶體。

所以「Token/s」至少有兩個版本：prefill 的 Token/s（讀提示詞的速度）和 decode 的 Token/s（寫答案的速度）。你平常在聊天介面「感覺到的快慢」，是這兩段加起來的結果。

速度相關的名詞，一次講清楚

下面這些名詞在不同工具裡常被混用，所以每一個都先說它量的是什麼。vLLM 的官方文件自己也提醒：各基準測試工具的指標術語並沒有標準化，比較結果時要看量測點與算式，不要只看名字。

• TTFT（time to first token，首個 token 時間）：vLLM 文件定義為從送出請求到收到第一個串流輸出的時間；NVIDIA GenAI-Perf 的定義也是「請求送出到收到第一個回應」。對本地使用者來說，它大致就是「按下送出後要等多久才看到第一個字」，主要由排隊、處理提示詞（prefill）決定。
• ITL（inter-token latency，token 間隔）：vLLM 文件說它記錄連續串流輸出之間的時間間隔，統計時把所有成功請求的間隔合併計算。這是「字一個一個跳出來的節奏」。
• TPOT（time per output token，每個輸出 token 的時間）：vLLM 文件的算式是「（端到端延遲 − TTFT）÷（輸出 token 數 − 1）」，每個請求算一次再彙總，不含第一個 token。標準解碼下每次串流輸出通常只含一個 token，所以 ITL 和 TPOT 通常很接近。
• 請求延遲（request latency）：GenAI-Perf 的定義是從請求送出到收到最後一個回應的時間，也就是你等完整個答案的時間。
• 輸出 token 吞吐量（output token throughput）：GenAI-Perf 定義為整段基準測試的輸出 token 總數除以測試總時間。這是「伺服器整體」同時服務多個請求時的產出，不是單一使用者感受到的速度；GenAI-Perf 另外有「每位使用者的輸出吞吐量」（單一請求的輸出 token 數除以其生成階段的時間）。
• goodput：GenAI-Perf 定義為「滿足指定指標門檻的請求，每秒完成幾個」，例如只算 TTFT 和 ITL 都低於門檻的請求。個人本地使用通常用不到，但看伺服器型的測試報告時會遇到。

用 vLLM 的 TPOT 算式移項，可以得到一條好用的關係式（這是代數推導，不是新資料）：

請求延遲 = TTFT + TPOT × (輸出 token 數 − 1)

在標準解碼下，每個 token 的間隔約等於 1 ÷ decode 速度。這可以用 llama.cpp 伺服器 README 裡 timings 範例的欄位互相驗算：predicted_per_token_ms 的倒數乘以 1000，就是 predicted_per_second。

llama.cpp 伺服器回傳的 timings 欄位

如果你用 llama.cpp 的伺服器（llama-server）當後端，每次回應都會帶一個 timings 物件。官方 README 列出的欄位如下，名稱是官方的，意義依官方欄位註解整理：

欄位	意義
prompt_n	這次實際被處理的提示詞 token 數
cache_n	從先前快取重用、因此不必重新處理的提示詞 token 數
prompt_ms	處理提示詞花的毫秒數
prompt_per_second	處理提示詞的速度，也就是 prefill 的 Token/s
predicted_n	生成的 token 數
predicted_ms	生成花的毫秒數
predicted_per_token_ms	平均每個生成 token 花的毫秒數
predicted_per_second	生成速度，也就是 decode 的 Token/s

這裡有個容易被忽略的細節：官方 README 說 cache_prompt 預設為 true，會重用上一次請求的 KV 快取，只處理「沒見過」的後半段。也就是說，如果你連續送同一段長提示詞，後面幾次的 prompt_n 會變得很小，算出來的 prompt_per_second 就不是在量「完整讀一段長文章」的速度。要量 prefill，必須避免快取命中（見下面的步驟）。

為什麼單一個數字會騙人

假設一個請求有 P 個提示詞 token、要生成 N 個 token，prefill 速度是 v_pp、decode 速度是 v_tg（單位都是 token/s），忽略排隊與分詞時間，則：

TTFT      ≈ P ÷ v_pp
生成時間  ≈ N ÷ v_tg
請求延遲  ≈ P ÷ v_pp + N ÷ v_tg

這是簡化模型，只用來看「時間花在哪」。下面用假設數字走一遍（不是任何機器量到的結果，也不代表任何硬體）：

• 假設 v_pp = 500 token/s、v_tg = 20 token/s。
• 情境 A：貼一篇 4000 token 的文章、要求 300 token 的摘要。TTFT ≈ 4000 ÷ 500 = 8 秒；生成 ≈ 300 ÷ 20 = 15 秒；總共約 23 秒。
• 情境 B：只問一個 50 token 的短問題、要求 1000 token 的長答案。TTFT ≈ 50 ÷ 500 = 0.1 秒；生成 ≈ 1000 ÷ 20 = 50 秒；總共約 50.1 秒。

同一台機器、同一組速度，情境 A 的等待大半花在 prefill，情境 B 幾乎全花在 decode。所以你要先知道自己的典型用法落在哪一邊，才知道該看哪個數字。只看「20 token/s」會低估情境 A 的等待，只看「500 token/s」又會高估情境 B 的體驗。

另外兩件事也會讓數字失真：

1. 量測範圍不同。llama-bench 官方 README 特別註明，它的量測不包含分詞（tokenization）與取樣（sampling）的時間，所以它的數字不等於你在真實應用裡感受到的速度，因為少算了這兩段時間。
2. 名稱不同、量的卻是同一件事（或反過來）。例如 GenAI-Perf 的 TTFT 和 vLLM 的 TTFT 都是請求送出到第一個回應，但「回應」是不是剛好一個 token、有沒有包含網路與排隊時間，要看工具怎麼量。

正確的速度測試方法

下面是一份可以照做的步驟。每一步都先說原則，再說在 llama.cpp 的 llama-bench 裡怎麼對應。旗標名稱屬於會變動的細節，一律以官方文件為準，用之前請先看你手上版本的 llama-bench --help。

1. 固定模型檔與量化

同一個模型換了量化格式（例如 Q4 換 Q8），要讀的資料量就不同，速度自然不同。比較時一次只換一個東西，並記下確切的檔名。量化的概念見量化是什麼。llama-bench 用 -m 指定模型檔，而且可以多次指定，在同一次執行裡逐個比較。

2. 固定提示詞長度與生成長度

兩個階段要分開量：

• 只量 prefill：官方說 pp 測試用 -p 指定提示詞 token 數。
• 只量 decode：tg 測試用 -n 指定生成 token 數。
• 兩段一起量：pg 測試用 -pg <pp,tg>，先處理提示詞再生成。

官方預設值是 -p 512、-n 128；你可以改成貼近自己用法的長度。要跳過某一段，README 範例用的是把對應數字設為 0。

3. 先暖機再量測

第一次執行常會比後面慢，因為有些工作只在第一次發生。llama-bench 預設會在正式測試前做暖機，要跳過得明確加 --no-warmup；llama-server 也有 --warmup 選項，官方說明預設為啟用。所以用這兩個工具時，通常不必自己多跑一輪暖機，但不要把暖機關掉再拿第一次的結果當穩態數字。

自己用其他方式量（例如在聊天介面計時）時，就要手動先送一個請求暖機，丟掉第一次的結果。

4. 重複多次，看中位數與離散程度

單次量測會受背景程式、快取、溫度影響。llama-bench 的 -r 控制每個測試重複幾次（官方預設 5），README 說明結果會以平均 tokens/s 和標準差呈現；-o json 之類的輸出還會附上每一次重複的個別結果，你可以自己從中算出中位數。

判讀時兩個數字都看：

• 標準差相對於平均很大，代表這次量測不穩，先找原因（背景程式、散熱、電源模式），不要急著下結論。
• 平均和中位數差很多，代表有離群值，通常是某幾次被其他程式干擾。

5. 記錄所有設定

速度數字只有連同設定一起存起來才有意義。至少要記：

• 模型檔名與量化格式
• 提示詞長度（P）與生成長度（N）
• 上下文長度設定與測試時的「已填入深度」
• 批次大小（batch）與 ubatch 大小
• 執行緒數、GPU 層數（offload 多少層到顯示卡）
• KV 快取的資料型別、是否啟用 flash attention
• 後端（CPU、CUDA、Metal 等）與軟體版本
• 電源模式與室溫（筆電尤其重要）

llama-bench 的 csv、json、sql 輸出已經把許多設定（如 n_batch、n_ubatch、n_threads、n_gpu_layers、build 版本、CPU 與 GPU 資訊）連同結果一起寫出，用這些格式存檔，比手抄可靠。

6. 一次只改一個變數

llama-bench 官方說，除了 -r、-o、-v 之外，其他參數都可以用逗號給多個值，工具會跑所有組合。這很方便，但也容易一次掃太多維度、最後看不出誰造成差異。官方 README 的範例各自只掃一個維度：不同模型、不同批次大小、不同執行緒數、不同 GPU 層數、不同的預填上下文深度。你也照這個方式，先掃一個維度、看懂了再掃下一個。

7. 區分冷啟動與穩態

冷啟動（載入模型、第一次請求）和穩態（已暖機、連續請求）是不同的體驗，要分開記。如果你的使用情境是「每次都重新開程式」，冷啟動的等待就是真實等待，要另外量；如果是常駐服務，穩態才有代表性。

用伺服器量真實使用情境

如果想量的是「你的應用實際收到的速度」，可以讀 llama-server 回應裡的 timings，並且：

• 想量 prefill 時，請求裡把 cache_prompt 設為 false，或每次換一段不同的提示詞，避免快取命中讓 prompt_n 變小。
• 每次都記下 prompt_n、cache_n、predicted_n，才知道這個速度是在多少 token 上量到的。

vLLM 官方文件也有類似的警告：對同一個伺服器重複執行基準測試，可能重用留在前綴快取裡的提示詞，使吞吐量被灌水；他們建議變更種子、重置或重啟伺服器。原理在本地跑 llama.cpp 時同樣適用：任何形式的快取命中，都會讓 prefill 看起來比真實情況快。

速度指標比較表

下表整理每個指標「在量什麼、什麼情境該看、受什麼影響」。「受什麼影響」欄是依上面引用的官方說明與原理推導，不是量測結論。

指標	在量什麼	什麼情境該看它	主要受什麼影響
prefill 速度（pp、prompt_per_second）	每秒能讀完多少提示詞 token	常貼長文章、長程式碼、做 RAG 或長對話歷史的用法	偏運算量（Hugging Face 說 prefill 屬於 compute-bound）；提示詞長度、批次大小設定、是否重用快取
decode 速度（tg、predicted_per_second）	每秒生成多少個新 token	需要長答案、串流閱讀、寫作與聊天	偏記憶體頻寬；模型每個 token 要讀的權重量、量化、上下文深度（KV 快取要重讀）
TTFT	送出請求到第一個 token 出現的等待	在意「按下送出後有沒有反應」的互動式使用	排隊時間、提示詞長度 ÷ prefill 速度、是否命中快取
ITL／TPOT	字與字之間的間隔（約為 1 ÷ decode 速度）	在意串流輸出流不流暢	與 decode 速度相同；同時服務的請求變多時也會變長
請求延遲	從送出到整個答案結束的總時間	腳本與自動化、一次要完整結果的用法	TTFT 加上生成時間，也就是 P、N、兩個速度共同決定
輸出 token 吞吐量（整體）	同時服務多個請求時，伺服器每秒總共產出多少 token	一台機器給多人或多個工作流程共用	同時請求數（併發）、批次與槽位設定；單一使用者的速度通常會因此變慢

最後一列要特別小心：吞吐量變高不代表你單獨使用時變快。llama-server 有 -np（槽位數）和連續批次（continuous batching）等設定（以官方文件為準），把機器切給多個請求共用，整體產出可以提高，但每個請求拿到的速度會下降。個人單人使用時，通常看前五列就夠了。

速度是由什麼決定的

decode：通常卡在記憶體頻寬

Hugging Face 的對話指南寫得很直接：模型越大越慢，因為生成每個 token 時，每個「啟用的參數」都必須從記憶體讀一次；這是文字生成的瓶頸，改善的主要方法是量化模型，或換記憶體頻寬更高的硬體，單純增加運算能力沒有明顯幫助。同一個文件也說，MoE 模型參數雖多，但每個 token 只啟用一小部分，因此對記憶體頻寬的需求通常低得多（MoE 的詳細說明見MoE 混合專家模型）。

把這個說法寫成算式，可以得到一個簡化的上限估算（這是依上述說明做的推導，不是官方公式，實際速度會低於它）：

decode 速度上限 ≈ B ÷ (S_權重 + S_KV)

B       ：有效記憶體頻寬（bytes/s），是權重所在的那塊記憶體的頻寬
S_權重  ：生成一個 token 要讀的權重量（bytes）；MoE 只算被啟用的部分
S_KV    ：生成一個 token 要重讀的 KV 快取量（bytes），隨上下文變長而變大

示範計算（全部是假設數字，只為了說明比例關係）：

• 假設 B = 200 GB/s、S_權重 = 8 GB、S_KV 可忽略：上限 ≈ 200 ÷ 8 = 25 token/s。
• 同樣的 B，量化後 S_權重 變成 4 GB：上限 ≈ 200 ÷ 4 = 50 token/s，也就是權重讀取量減半，上限約加倍。
• 同樣 4 GB 權重，但長上下文使 S_KV = 1 GB：上限 ≈ 200 ÷ (4 + 1) = 40 token/s。

這個算式能回答兩件事：為什麼量化常讓 decode 變快（讀的資料變少，不只是「省空間」），以及為什麼權重放在哪塊記憶體很重要。權重放在顯示卡的顯存（VRAM，顯示卡上的記憶體）、還是系統記憶體（RAM）、還是硬碟，B 差距很大，詳見顯存、記憶體、硬碟各扮演什麼角色。哪些模型裝得進你的顯存，則見依顯存選模型。

prefill：偏向運算

Hugging Face 的量化指南說，prefill 和大批次屬於 compute-bound（運算受限）的情境，而一次一個 token 的生成才是 memory-bound（記憶體受限）。直覺上的解釋（這是簡化的推論，不是官方說法）是：prefill 一次處理很多 token，同一份權重讀進來後可以供一整批 token 共用，所以比起 decode，更容易先碰到運算能力的上限。這也是為什麼同一台機器的 pp 速度數字常常比 tg 大很多：兩個數字本來就不是在量同一件事。

上下文變長，decode 為什麼變慢

生成每個新 token 時，模型都得讀取先前所有 token 的 KV 快取。Hugging Face 的教學說，自回歸解碼時，這些大的 key-value 向量需要在每一步被重新載入，所需的記憶體頻寬可能成為嚴重的時間瓶頸。

KV 快取有多大？教學裡給的算式是：快取中的浮點數個數 = 2 × 序列長度 × 層數 × 注意力頭數 × 每頭維度。教學舉了一個假設的 16000 token 輸入，對一個範例模型算出約 80 億個浮點數，以 float16 儲存約 15 GB，大約是該模型權重的一半。這是該範例模型的數字，不是你的模型；但它說明了上下文夠長時，S_KV 可以大到不能忽略。教學也提到，減少 key-value 頭數（如 MQA）可以同時降低快取大小與頻寬壓力；各模型的實際設計不同，要看模型本身。

要量這個效應，用 llama-bench 的 -d <n>：官方說明它會在測試前先把 KV 快取預填 n 個 token，讓你在指定的上下文深度下量 pp 與 tg。官方 README 的範例就是比較 -d 0 與另一個深度下的 pp 和 tg。

另外，Hugging Face 教學也提到，自注意力的運算量與記憶體在預設實作下會隨序列長度呈二次方成長（Flash Attention 則讓記憶體需求只隨長度線性增加），所以提示詞很長時，prefill 的總時間成長會比提示詞長度更快。實際比例取決於實作與硬體，請量給自己看。

如何判斷你的瓶頸：定性方法

不必先懂硬體細節，用「改一個變數，看哪個指標動」就能推測：

你做的實驗	如果出現這個現象	傾向的判斷
換成更小的量化（讀取量變少）	decode 明顯變快，prefill 變化較小	decode 受記憶體頻寬限制
換成更小的量化	decode 幾乎沒變	瓶頸可能在別處（部分層跑在較慢的裝置上、設定問題、散熱）
調整批次大小（-b、-ub，以官方文件為準）	prefill 跟著明顯變動	prefill 受運算與批次效率影響
調整執行緒數	CPU 後端的速度明顯變化，加到一定程度後不再增加	已接近 CPU 運算或記憶體的上限
提高 -ngl（放到顯示卡上的層數）	層數增加，速度上升，尤其是整個模型都放進去時	先前有層留在較慢的記憶體上拖慢整體
加大上下文深度 -d	decode 隨深度下降	KV 快取讀取量在增加
長時間連續跑，速度逐漸下降	同一組設定，後面幾輪比前面慢	可能是降頻，見下面

執行這些實驗時，記得第 6 步：一次只改一個變數，否則你分不出是哪個造成的。

讀別人的測試數字時要問什麼

在網路上看到「我的機器跑 XX 模型有 YY tokens/s」時，先逐項確認：

1. 是什麼硬體？ 顯示卡型號、顯存大小、系統記憶體，或是 CPU 與統一記憶體的機種。
2. 是哪種量化？ 同一個模型的 Q4 與 Q8 要讀的資料量不同，不能直接比。
3. 上下文長度多少？ 是空上下文量的，還是已經填入長文件後量的。差別可能很大（見上一節）。
4. 是 prefill 還是 decode？ 沒有說明的 tokens/s，最常見的情形是指其中一種，但你無從得知是哪一種。
5. 有沒有暖機？ 取的是第一次還是多次後的穩態。
6. 重複了幾次？ 只有一次的數字，沒有標準差可看。
7. 批次與併發設定？ 是單一請求，還是同時服務多個請求的整體吞吐量。
8. 有沒有重用快取？ 特別是量 prefill 時，快取命中會讓數字失真。
9. 後端與軟體版本、是否 offload 到 GPU？ 同一個模型換個後端或版本，結果可能不同。
10. 量測工具量到哪裡？ 像 llama-bench 就不含分詞與取樣的時間。

另一個原理上的提醒：不同模型可以有不同的分詞器（tokenizer，把文字切成 token 的規則），同樣一段文字被切成的 token 數不一定相同，所以跨模型比較「每秒幾個 token」時，不能直接當成「每秒幾個字」。

答不出其中好幾題的數字，只能當作「這個量級有人跑得到」的旁證，不要拿來決定要不要買硬體。你自己的機器最後還是要自己量：因為你的系統記憶體、散熱、電源模式、背景程式、驅動與軟體版本都和別人不同，而你真正關心的是自己的典型提示詞長度與回答長度下的等待時間。如果你用的是站內介紹的本地大模型工具，可以先看Strata 與 PolyStrata 比較，了解工具各自如何載入與執行模型，再決定用哪種方式量。

筆電與長時間負載

筆電長時間高負載時，晶片可能因過熱或電源限制而降頻，使速度逐漸下降，所以短時間的測試結果可能比長時間使用時的樂觀。這件事的原因與對策請看筆電跑 AI 的散熱與電源注意事項，這裡只提醒一點：在筆電上測速時，除了照上面的步驟，還要把測試拉長，並分段記錄速度有沒有隨時間下降。

常見誤解

• 「Token/s 越高越好」：要看是哪個階段、哪種用法。短問題長答案看 decode，長文章短摘要看 prefill 與 TTFT。
• 「llama-bench 的數字就是我聊天時的速度」：不一定。它不含分詞與取樣，也沒有你的介面開銷、系統提示詞與歷史對話的影響。
• 「換更強的運算晶片 decode 就會快」：Hugging Face 的說明是，單純增加運算能力對 decode 沒有明顯幫助，頻寬與讀取量才是重點。但 prefill 偏運算，情況不同。
• 「吞吐量高代表我用起來快」：整體吞吐量和單一請求的速度是兩回事，同時服務越多請求，單一請求通常越慢。
• 「量一次就夠」：單次量測沒有離散程度可看，至少重複數次，並看標準差。

延伸閱讀

• 依顯存選本地大模型：先確定模型裝得進去，再談速度。
• 量化是什麼：量化如何改變模型的大小與讀取量。
• MoE 混合專家模型：為什麼參數多的模型不一定慢。
• 顯存、記憶體、硬碟各扮演什麼角色：權重放在哪裡，決定可用的頻寬。
• 筆電跑 AI 的散熱與電源注意事項：長時間負載的降頻。
• Strata 與 PolyStrata 比較：本地大模型工具文章。
• 術語表：token、上下文視窗、LLM。