wwfandy: 🧰 新手也能跑的 LLM Bench：安裝流程、測試方法、結果判讀與優化方向

1. LLM Bench 是什麼？能解決什麼問題

LLM Bench（泛指用來量測大型語言模型推論效能的基準測試工具/腳本）主要用來回答三個問題：

體感好不好？ 使用者互動時，從送出到「看到第一個字」快不快（TTFT）。
穩不穩？ 併發拉高或負載上來時，是否開始抖動、超時或錯誤（p95、ErrRate）。
扛得住多少人？ 多使用者或代理（Agent）同時打進來，吞吐量是否維持（TPS / tokens per second）。

當你在比對不同模型（7B/8B/14B）、不同硬體（CPU/GPU/統一記憶體）、或不同部署方式（本機/VM/容器）時， LLM Bench 能讓你用「數字」而不是「感覺」做決策。

2. 你應該先懂的 5 個測試名詞（TTFT / Latency / TPS / Concurrency / ErrRate）

名詞	代表意義	你最常用來判斷什麼
TTFT（Time To First Token）	從送出請求到回傳「第一個 token」的時間	互動體感：聊天「有沒有卡住」
Latency	整個請求完成的延遲（含生成完）	長文生成耗時、整體等待時間
TPS（tokens/sec）	每秒可生成多少 token（吞吐量）	多使用者承載量、長輸出效率
Concurrency（併發）	同時送出幾個請求	壓力測試：服務端是否扛得住
ErrRate（錯誤率）	請求失敗比例（timeout/400/500/429 等）	穩定性：是否適合上線或做 Agent

3. 安裝方式（Windows / Linux / Python 環境注意事項）

你可以把「LLM Bench」理解成一組可跑的 Python benchmark 腳本（或同類工具），核心前提是：

你能呼叫到一個推論服務端（例如 Ollama 的 OpenAI 相容 API）。
你能用 Python 執行腳本並送出 HTTP 請求。

3.1 Windows（PowerShell）

python -V
python -m pip install -U pip
python -m pip install -U requests

如果你要跑 async/並發版本（常見會用 aiohttp/httpx），可以再補：

python -m pip install -U aiohttp httpx

3.2 Linux（Ubuntu/Debian 類）

python3 -V
python3 -m pip install -U pip
python3 -m pip install -U requests aiohttp httpx

注意：若你遇到 PEP 668（系統 Python 不允許直接 pip 安裝）的限制，建議用 venv：

python3 -m venv .venv
. .venv/bin/activate
python -m pip install -U pip requests aiohttp httpx

4. 測試前準備：確認你的推論服務端（Ollama / OpenAI 相容 API）

這篇以 Ollama 為例，Ollama 預設會提供 OpenAI 相容的 API 端點。你可以先確認服務是否起來：

4.1 檢查 Ollama 是否在跑

Windows：

ollama ps

Linux：

curl -s http://127.0.0.1:11434/api/tags | head

4.2 你這次測試的目標端點（示例）

http://127.0.0.1:11434/v1

如果你的 bench 腳本是走 OpenAI 格式（/v1/chat/completions），這個端點就是最常用的入口。

5. 基礎測試：跑出第一份報告（單併發、短輸出）

先用「單併發」確保流程都通，並且用短輸出減少變數（例如 max_tokens=128）。以下是你實際跑成功的範例（Windows PowerShell）：

$env:BENCH_CONCURRENCY="1"; python .\bench_ollama_ttft_async.py

你當時輸出重點如下（摘錄關鍵行）：

Target: http://127.0.0.1:11434/v1
Model:  llama3-groq-tool-use:8b
N=50  concurrency=1  max_tokens=128

=== Summary ===
OK: 50  ERR: 0  ErrRate: 0.0%
TTFT  p50: 0.349s  p95: 0.389s

解讀：在 concurrency=1 下，TTFT p50 約 0.35 秒、p95 約 0.39 秒，且 ErrRate=0%，代表互動體感快且穩。

6. 進階測試矩陣：併發、長輸出、長 Prompt 的壓力測試怎麼設計

如果你要評估「能扛多少人」或「Agent 同時跑會不會炸」，你需要把測試做成矩陣（固定一個變因，其他不動）。下面給你一個新手最實用的矩陣順序：

6.1 併發壓力（Concurrency）

建議從 1 → 2 → 4 → 8 逐步拉高，每個點至少 N=50：

# 以環境變數或參數方式調整（依你的 bench 腳本而定）
BENCH_CONCURRENCY=1
BENCH_CONCURRENCY=2
BENCH_CONCURRENCY=4
BENCH_CONCURRENCY=8

觀察三件事：

ErrRate 是否開始上升
TTFT p95 是否突然跳高（抖動變大）
完成時間是否線性變慢（顯示吞吐不足）

6.2 輸出長度（max_tokens）

用 128 / 256 / 512 / 1024 比較「短答」與「長文」的吞吐差異。

6.3 Prompt 長度（Context 壓力）

把 prompt 分三段：短（數十 token）、中（數百 token）、長（數千 token）。很多部署在「長上下文」時 TTFT 會明顯變慢，這是 Agent 場景的常見瓶頸。

7. 測試結果怎麼看：p50 / p95、抖動、瓶頸與「好不好」判斷標準

新手最推薦的看法是：先穩定、再體感、最後承載。

7.1 穩定性：ErrRate

ErrRate = 0%：理想（你這次就是 0%）
ErrRate > 1%：開始需要查原因（timeout、VRAM、Gateway/反向代理、速率限制等）

7.2 體感：TTFT

< 0.5s：多數情境會覺得「很順」
0.5–1.5s：可用但會感覺在等
> 2s：互動體感明顯卡（除非是超大模型或高負載）

7.3 抖動：p95 vs p50

p95 代表「比較倒楣那 5%」的使用者體感。理想狀況是 p95 不要比 p50 大太多。你這次的 TTFT（p50 0.349s / p95 0.389s）差距很小，屬於穩定型。

7.4 常見瓶頸對照

現象	最可能原因	優先處理方向
TTFT 明顯變慢，但 TPS 還可以	前處理/排隊/上下文過長	縮短 prompt、降低 context、提高批次/併發策略
併發一拉高就 timeout/ErrRate 上升	VRAM 不足、服務端排程飽和	降低併發、換小模型、增加 GPU/記憶體、調整 batch
長輸出非常慢	吞吐不足（TPS 低）、CPU/GPU 受限	改推論後端、開啟 GPU offload、換更快模型

8. 常見問題排除（400/429、Timeout、VRAM 不足、工具不支援 tools）

8.1 400（模型不支援 tools）

你曾遇到類似訊息：某些模型不支援 tools（function/tool calling），在 Agent/工具模式會直接 400。

解法：改用支援 tools 的模型（或關閉 tools 模式）。
檢查：你的請求 payload 是否帶了 tool/schema。

8.2 429（速率限制）

併發太高、或服務端有限流。
解法：降低 concurrency、加重試/退避（backoff）。

8.3 Timeout / 503

服務端排隊過久、或 GPU/CPU 飽和。
解法：降低 max_tokens、縮短 prompt、調整併發策略。

8.4 VRAM 不足（OOM）

常見於大模型 + 高併發 + 長上下文。
解法：換小模型、降低 context、減少併發、或改用分層/量化版本。

9. 優化方向：從「體感」到「承載量」的調校清單

先把 ErrRate 壓到 0%：不穩就先別談快。
優化 TTFT：縮短 prompt、避免超長 system 指令、減少不必要上下文。
提升 TPS：確保 GPU offload 正常、避免 CPU 被打滿、選擇吞吐較高的模型。
併發策略：逐步拉高 concurrency 找到拐點（ErrRate 上升或 p95 飆升的臨界值）。
比較模型要「同條件」：同 N、同 prompt、同 max_tokens、同併發，才有可比性。

10. 小結：建議你照這個順序跑，最快找到最佳模型與配置

concurrency=1、max_tokens=128：確認流程通、ErrRate=0%
concurrency 逐步拉高：找出穩定承載上限
max_tokens 拉長：評估長文吞吐
prompt 拉長：模擬 Agent 場景
做模型對照表：用數據挑出最適合你的部署組合

💬 留言聊聊

你目前是用 Ollama、本機 GPU、還是雲端 API 在跑 LLM？如果你貼上你的測試參數（N / concurrency / max_tokens）與 Summary，我可以幫你一起解讀 p50/p95、找瓶頸，並建議下一步怎麼調。

🧰 新手也能跑的 LLM Bench：安裝流程、測試方法、結果判讀與優化方向