LOCAL LLM CAPACITY EVIDENCE

「能跑」不等於「多人同時用得動」

把模型、引擎、硬體、請求形狀、到達方式與延遲分位數留在同一筆紀錄。工具不會用單流 tok/s 猜出通用使用者人數。

SCHEMA 1.1 · 2026-09-09

建立一個可重跑的測試點

A. 版本與硬體

測試 ID測試時間證據階段環境推論引擎引擎版本模型 ID模型 revision量化／dtypeTokenizer revision加速器可用記憶體GB；VRAM 或 unified memory，限制中說清楚Driver／runtime／主機

B. 工作負載與到達方式

一個 test ID 只代表一個測試點；做 sweep 時每個 concurrency／request rate 各留一筆。

工作負載名稱資料集或 prompt 來源到達模式StreamingRequest raterequests/s；closed-loop 未控制時可留白Concurrency同時 in-flight 請求，不等於註冊使用者最大 active sequencesContext limittokens輸入 tokens p50輸出 tokens p50Warm-up requests量測 requests測試分鐘

C. 成功、吞吐與延遲

未量測請留白。0 只適用於真的量到 0，不能代表 unavailable。

成功 requests失敗 requestsRequest throughputrequests/sOutput throughputaggregate output tokens/sTTFT p50msTTFT p95msTPOT p50ms/tokenTPOT p95ms/tokenE2E latency p95msQueue time p95msKV cache 峰值%；引擎未提供就留白記憶體峰值GB；寫清楚量測工具Preemption／eviction 次數

D. 成功，而且在可接受時間內完成

選填的 SLO（服務水準目標）核算：先填 B、C 的同批次數量，再填至少一個逐請求延遲上限。未填的上限不參與判斷。先看方法與算術例子。

TTFT 上限ms；每筆請求首 token 等待上限TPOT 上限ms/token；每筆請求的平均輸出 token 間隔E2E 上限ms；每筆請求完整回應時間上限同時達標的成功請求由逐請求 trace 計數；所有已填上限都須達成，不能用 p95 猜計數與時間窗方法

尚缺逐請求資料，不能計算 goodput。

Goodput：unavailable；達標率：unavailable。這是依你提供數據的換算，不是工具代跑測試。前往結果與下載

E. 門檻、結果與證據

結果測試前門檻證據位置限制與不可外推事項

KV CACHE PREFLIGHT · 2026-09-15

先估 KV cache，再用引擎 metrics 驗證

這個簡式只處理每層 KV 結構相同的標準 full-attention 模型。公式為 2 × layers × KV heads × head dimension × dtype bytes × tokens × concurrency；其中 2 代表 K 與 V。它是容量規劃，不是 vLLM、llama.cpp 或任何硬體的實測。

GQA／MQA 請填 KV heads，不是 query attention heads。模型若混合 full、sliding-window、local attention 或 Mamba，請選「混合／其他」並保留 unavailable；vLLM 官方文件也明列 hybrid allocator 需要 group-aware 容量，不能只套單一公式。

Attention 結構層數KV headsGQA／MQA 不填 query headsHead dimensionKV cache dtype權重量化不代表 KV cache 自動同 dtype每請求 active tokensConcurrencyBlock size只做每請求 token 向上取整；實際有效值以 runtime 為準引擎回報可用 KV cache 預算（GiB，選填）不是總 VRAM；請用 profiling／metrics 後的可用 cache 空間

先確認模型結構並填入參數。

每 token KV: unavailable
每請求 KV: unavailable
指定 concurrency: unavailable
預算可容納序列: unavailable

估算不含模型權重、activations、CUDA graphs／workspace、配置檔保留、記憶體碎片、prefix cache 共用、KV offload、tensor／pipeline parallel 或 runtime bug。正式驗收請保存 vLLM 版本、啟動後的 kv_cache_size_tokens／kv_cache_max_concurrency metrics 與真實 concurrency sweep。

FIVE NUMBERS, DIFFERENT QUESTIONS

不要把單流 tok/s 當成多人容量

指標	回答什麼	常見誤讀
Concurrency	同時有多少請求在系統內	直接當成公司可服務的使用者總數
Request rate	每秒有多少新請求抵達	和 closed-loop concurrency 混成同一條曲線
TTFT p95	多數慢請求要等多久才看到第一個 token	只報平均值，漏掉排隊尖峰
TPOT p95	首 token 後的輸出節奏是否變慢	拿 aggregate tokens/s 取代單一請求體感
Queue／KV／錯誤	吞吐增加是有效批次，還是已進入排隊、preemption 或失敗區	只看到總吞吐上升就宣稱容量增加

Goodput：把成功與「準時成功」分開

成功請求吞吐不會排除慢到無法接受的回應。逐請求 goodput 則只計入成功，且同時滿足所有已選延遲上限的請求，再除以同一批次量測秒數；等於上限仍算達標。它不是模型答案品質、最大可持續容量或註冊使用者人數。

測試前選定 TTFT、TPOT 或 E2E 上限，保存引擎版本與逐請求時間。串流與非串流分開；TPOT 不適用時不要補 0。
排除 warm-up，等同一批次的請求都有結果。成功＋失敗必須等於量測請求數；逾時／取消與 drain 時間如何處理要明記，不能把未結束請求偷偷刪掉。
從成功請求中逐筆檢查全部已填上限。缺少必要延遲資料時，先補證據，勿當作達標或填 0。這個表單只檢查數量一致性，不會讀取你的 trace。

算術示例，非本站或任何硬體實測：60 秒量測 100 筆，90 筆成功、10 筆失敗，其中 80 筆同時達標
核算	公式與結果	分母邊界
成功吞吐	90 ÷ 60 = 1.5 requests/s	同批次量測秒數
SLO goodput	80 ÷ 60 ≈ 1.333 requests/s	不是 90 ÷ 60
SLO 達標率	80 ÷ 100 = 80%	包含失敗的全部量測請求
錯誤率	10 ÷ 100 = 10%	0 筆量測不能報 0%

TTFT p95 與 TPOT p95 各自過關，不代表同一批請求有 95% 同時過關。例如 20 筆中，兩個指標各有不同的 1 筆超標，兩者同時達標只有 18／20。請用逐請求資料，不把兩個邊際分位數當成聯合達標率。

vLLM 的 vllm bench serve --goodput ttft:… tpot:… e2el:… 可指定逐請求上限（參數數值以 ms 表示）。此處省略號是佔位符，不是可直接執行的命令。本站對應的 E2E 欄位與 CLI 的 e2el 是同一類端到端延遲；匯出 JSON 是本站紀錄格式，不是 vLLM 原生輸入。重跑時仍要固定引擎版本、到達模式與測試秒數算法。

新增方法查證：2026-09-09。依據 vLLM CLI goodput 文件、固定 commit 的逐請求 AND 判斷與除以量測時間實作，以及 DistServe 論文（2024，TTFT／TPOT 共同 SLO）。論文的容量最佳化問題不等於這裡單一測試點的算術；本頁不引用論文跑分作本站效能。

SOURCES & BOUNDARIES

這些欄位從哪裡來？

vLLM 官方把 TTFT、inter-token latency、end-to-end latency、queue time、running／waiting requests 與 KV cache 使用率分開，並提供 vllm bench serve 控制 request rate、prompt 數與輸入輸出長度。Hybrid KV Cache Manager 文件另說明不同 attention 類型要做 group-aware 分配；因此本頁的簡式只在標準 full attention 顯示估算。這支持欄位與方法，不代表只有 vLLM 才能使用本範本。

2026 年 Ollama／vLLM 併發研究顯示相同模型與硬體也必須在多個 workload、concurrency 與延遲／錯誤指標下比較；該研究只代表指定 H100、Qwen3-4B 與測試方法，不是跨硬體排名。論壇、issue 與社群跑分只用來辨識真人問題，不能當通用容量保證。