LOCAL LLM CAPACITY EVIDENCE
「能跑」不等於「多人同時用得動」
把模型、引擎、硬體、請求形狀、到達方式與延遲分位數留在同一筆紀錄。工具不會用單流 tok/s 猜出通用使用者人數。
SCHEMA 1.0 · 2026-09-02
建立一個可重跑的測試點
FIVE NUMBERS, DIFFERENT QUESTIONS
不要把單流 tok/s 當成多人容量
| 指標 | 回答什麼 | 常見誤讀 |
|---|---|---|
| Concurrency | 同時有多少請求在系統內 | 直接當成公司可服務的使用者總數 |
| Request rate | 每秒有多少新請求抵達 | 和 closed-loop concurrency 混成同一條曲線 |
| TTFT p95 | 多數慢請求要等多久才看到第一個 token | 只報平均值，漏掉排隊尖峰 |
| TPOT p95 | 首 token 後的輸出節奏是否變慢 | 拿 aggregate tokens/s 取代單一請求體感 |
| Queue／KV／錯誤 | 吞吐增加是有效批次，還是已進入排隊、preemption 或失敗區 | 只看到總吞吐上升就宣稱容量增加 |
SOURCES & BOUNDARIES
這些欄位從哪裡來？
vLLM 官方把 TTFT、inter-token latency、end-to-end latency、queue time、running／waiting requests 與 KV cache 使用率分開，並提供 vllm bench serve 控制 request rate、prompt 數與輸入輸出長度。這支持欄位與方法，不代表只有 vLLM 才能使用本範本。
2026 年 Ollama／vLLM 併發研究顯示相同模型與硬體也必須在多個 workload、concurrency 與延遲／錯誤指標下比較；該研究只代表指定 H100、Qwen3-4B 與測試方法，不是跨硬體排名。論壇、issue 與社群跑分只用來辨識真人問題，不能當通用容量保證。