【2026 最新】本機 LLM 跑分怎麼看？短中長 Context 成績單教你量速度、記憶體與品質

看到一張「本機 LLM 跑分 100 tok/s」的截圖，你可能想立刻下載同一個模型。可是它用了多長的 Context？100 tok/s 是讀入問題的速度，還是吐出答案的速度？如果把一份長文件塞進去，第一個字要等多久，答案還能不能用？這就是本機 LLM 跑分最常被忽略的問題。

這篇寫給沒有跑分經驗、但願意照著幾個指令操作的讀者。我們會把速度、等待時間、記憶體與答案品質寫進同一張可重跑成績單。你不必先懂 GPU 術語；照著欄位留下紀錄，下一次看到別人的漂亮數字，就知道該問什麼。

先說結論：本機 LLM 跑分要有「四張收據」

一張可比較的成績單 ＝ 固定環境＋三種輸入長度＋分開計時＋品質驗收。 少了其中一項，單獨的 tok/s 只能說明某個測試設定下的局部速度，不能保證你手上的長文件工作也順。

• 固定環境：模型檔、量化、Runtime 版本、硬體、Context 與取樣設定。
• 三種長度：短、中、長輸入各跑三次，記實際 token 數與失敗。
• 分開計時：冷啟動、首字等待（TTFT）、讀入速度（Prefill）、生成速度（Decode）。
• 品質驗收：用相同的小任務檢查答案是否正確、有無亂補或漏掉關鍵資訊。

本機 LLM 跑分怎麼看？先拆開一個 tok/s

把模型想成一位要先讀完題目再作答的助理。Prefill 是讀題；Decode 是逐字回答；TTFT 是你送出問題到看見第一個答案 token 的等待。速度單位都可能寫 tok/s，但它們測的工作不同。Context 則是模型這次能放在工作記憶裡的 token 空間，會被題目、歷史對話和答案一起占用。

例如一則宣稱只寫「100 tok/s」，你不知道它是短題目下的 Decode，還是長文件的 Prefill。也不知道測試有沒有把模型載入、分詞、取樣或網路傳輸算進去。llama.cpp 官方 llama-bench 說明明列 pp、tg、pg 三種測法，並指出它的計時不含分詞與取樣。因此它適合比較引擎算力，不能直接當使用者看到的完整等待時間。

最容易踩的坑是空 Context 的生成速度。llama-bench 的 -n 測試從空 Context 開始；官方討論也提醒，Context 變長後的表現不能直接外推。要測長對話，需把深度或實際輸入長度帶進測試；把這個條件寫在成績單上。

做之前先固定什麼？六個欄位決定可重跑性

① 模型檔：檔名還不夠，要有雜湊

同名模型可能被重新量化或換檔。保留完整模型檔名、來源與 SHA-256。macOS 可輸入 shasum -a 256 /path/to/model.gguf；Linux 常用 sha256sum /path/to/model.gguf。這串字相當於檔案指紋，下一個人才能確認比較的是同一份位元資料。

② 量化與 Runtime：把「引擎」一起寫出來

量化是把模型權重用較少位元儲存；不同量化檔的記憶體與輸出可能不同。記錄 GGUF 的量化名稱、推論程式名稱和版本或 Git commit。若從原始碼編譯 llama.cpp，在該原始碼目錄記下 git rev-parse HEAD 的結果；若用已安裝的 Ollama，記下 ollama --version 與 ollama show <模型名稱> 顯示的模型資訊。更換 Runtime 時，同一個模型檔也應重新量。

③ 硬體與載入位置：速度背後的成本

至少寫 CPU、GPU、RAM／VRAM 容量、作業系統和是否有 CPU offload。Ollama 的 Context 說明示範用 ollama ps 查看實際配置的 Context 與 PROCESSOR 欄位；把這個畫面中的數值抄進成績單。當 Context 設大、記憶體需求上升時，只看模型檔大小會低估執行所需空間。

④ 生效設定：尤其是 Context、快取與並行數

寫下實際 num_ctx 或 --ctx-size、GPU layers、batch、KV cache 類型、prompt cache 是否啟用、同時請求數、輸出上限與 temperature。若設定值會由引擎自動調整，留存執行紀錄中的生效值。llama.cpp server 文件會回傳 generation_settings，也有 truncated 欄位可協助檢查輸入是否碰到 Context 邊界。

⑤ 冷暖啟動：第一位讀者和第十位讀者不同

先記一次模型剛載入的等待，再記載入後的重複請求。Ollama 的 Generate API在完成回應裡列出 total_duration、load_duration、prompt_eval_duration 與 eval_duration，單位都是奈秒。load_duration 要單列，不要混進常態 Decode 速度。

⑥ 題目與判分：讓品質有同一把尺

保留三組固定題目：一題從長文找出明確事實、一題依條件分類、一題摘要且要求引用原文段落。每題事先寫答案要點和常見錯誤。對同一批題目、同一 temperature 與相同輸出上限評分；若答案結構不同，用「要點正確／漏答／編造」逐項記錄，比主觀打總分更容易覆核。

本機 LLM 跑分怎麼做？短、中、長各跑三次

先選一份可以公開使用、沒有個資的文字素材，切成短、中、長三段。可以把 500、2,000、8,000 token 當成設計目標，實際長度以 Runtime 回傳的 token 數為準；若你的模型或機器容不下長段，改用它能穩定承載的長度，並記下上限與失敗原因。三段都問同一類問題，例如「找出合約生效日並引用原句」，這樣才有可比性。

在已安裝 Ollama 且已準備好模型的電腦上，先用 ollama ps 核對載入位置和 Context，再用同一個請求格式測每段。以下是格式示意，將 <你的模型名稱> 與 <你的測試文字> 換成自己的內容；正式紀錄時把完整請求 JSON 存檔。

curl http://localhost:11434/api/generate -d '{"model":"<你的模型名稱>","prompt":"<你的測試文字>","stream":false,"options":{"num_ctx":16384,"temperature":0,"num_predict":256}}'

每個長度重複三次，保留完整 JSON 回應與錯誤。Decode tok/s 可由 eval_count ÷ (eval_duration ÷ 1,000,000,000) 算出；Prefill 要同時看 prompt_eval_count、prompt_eval_cached_count 和 prompt_eval_duration：官方把後者定義為未快取輸入的耗時。若有快取命中，直接拿全部輸入 token 去除未快取耗時會高估讀入速度。

TTFT 要另外量。把請求改成串流，從送出請求到收到第一個非空答案片段計時，並註明是否包含網路、排隊與模型載入；不要把 API 的 prompt_eval_duration 直接改名為 TTFT。要測真實體驗，計時器應放在呼叫端。對跑分引擎本身，可再用 llama-bench -m /path/to/model.gguf -pg 1024,128 -d 0,2048,8192 -r 3 -o json 做補充；深度參數會先把 KV cache 填到指定 token 深度，這組數字與 Ollama API 端到端數字應分欄報告。

每次記下峰值 RAM／VRAM 與是否出現交換記憶體、CPU offload、逾時或 Context 截斷。監測工具依系統而異：macOS 可看「活動監視器」的記憶體壓力與程序占用，NVIDIA GPU 可用 nvidia-smi；量測方法和取樣間隔也寫在備註。三次取中位數，同時保留三筆原始值與失敗筆數，避免平均數掩蓋一次嚴重卡頓。

一張可填的成績單：看什麼才算能用？

最上排寫固定環境；下面每個長度留三筆原始紀錄，再寫中位數和失敗次數。速度要標單位，記憶體要標測量工具，品質要附原題與評分規則。若要分享給別人，連同模型檔雜湊、請求 JSON、原始輸出與測試日期一起保存。看不見這些條件的「100 tok/s」，先視為線索，別當購買硬體或選模型的結論。

選型時先從自己的任務倒推：短聊天看 TTFT 和 Decode；長文件問答看 Prefill、長 Context 下的 Decode 與正確引用；記憶體緊的設備先看峰值占用與失敗率。品質驗收先過門檻，再在通過者中挑速度。答錯生效日的模型，即使輸出很快，也不適合替你處理那份文件。

常見 8 題：把跑分誤讀一次釐清

1. 100 tok/s 代表我每秒看見 100 個字嗎？

不一定。token 不是中文字數；還要先確認測的是 Prefill 或 Decode，以及是否包含首字等待。

2. 只跑短提示，可以預測長文件體驗嗎？

不夠。把實際 Context 深度與長輸入測試列出來，再看延遲、記憶體與答案品質。

3. 模型檔一樣，換 Runtime 要重新量嗎？

要。引擎版本、快取、batch 和 GPU offload 都是測試條件。可先讀 同檔換 Runtime 的公平比較，再填這張成績單。

4. 量化變小，就一定更值得用嗎？

要看任務。容量、速度和答案品質一起量；GGUF 量化指南可幫你理解檔名背後的取捨。

5. API 回傳的 prompt_eval_duration 就是 TTFT 嗎？

不是同一個欄位。它記未快取輸入的評估耗時；TTFT 要由呼叫端從送出到第一個答案片段另外量。

6. 三次結果不一樣，怎麼寫？

三筆都留。用中位數做摘要，再列範圍、冷暖啟動和失敗次數；不要只截最快的一筆。

7. Context 設得越大越好嗎？

看工作需求和記憶體。Ollama 官方說明指出，拉大 Context 會增加記憶體需求；先量你常用的文件長度，再決定預留多少空間。

8. 外部模型榜單能直接代替本機成績單嗎？

不能直接代替。模型榜單讀法可幫你挑候選者，實際機器、題目與長度仍要照自己的工作驗收。

給新手的三個選型規則

• 先過品質：三道真任務答對關鍵點、沒有編造，再比較速度。
• 再看最慢情境：用你真正會貼入的長文件，確認 TTFT、記憶體與失敗率可接受。
• 最後才看峰值 tok/s：只有測試環境、Context 和計時範圍都相同，速度比較才有意義。

如果你正在建立會自行讀檔和呼叫工具的系統，Agent Harness 入門說明模型之外還有哪些執行層；實作版可幫你把成績單延伸到整個流程。想系統性學 AI，也可以逛 AlphaLab 課程。