最近我在 Windows 上用 LM Studio 跑本地模型，想把評測做成可重複、可比較、可自動化。這篇把完整流程整理成一份可直接上手的實戰筆記，包含：
- 如何同時做「能力評測」與「效能評測」
- 怎麼用 PowerShell 批次跑多模型
- 常見錯誤（
apply_chat_template、全零分數、中文 prompt 亂碼、PowerShell 版本相容）怎麼排 - TTFT、P95、warmup 等指標要怎麼讀
為什麼要分成兩種 benchmark
只看單一分數很容易誤判模型體驗。實務上我建議分兩條線：- 能力評測：
lm-eval跑任務分數（例如truthfulqa_gen、gsm8k） - 效能評測：直接打 LM Studio
/api/v1/chat，抓TTFT、tokens_per_second
這樣你可以同時回答兩個問題：
- 答得準不準？
- 回得快不快？
環境與專案初始化（Windows）
先在專案目錄建立虛擬環境：
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -U "lm-eval[api]"
如果專案還沒版控，先初始化：
git init自動化腳本設計（可批次多模型）
我最後整理成一支 run-lmstudio-benchmark.ps1，搭配 benchmark-config.json 使用。核心能力如下：
- 一次跑多個模型
- 能力與效能可分開執行（
-SkipQuality/-SkipPerformance） - 輸出統一落在
results\yyyyMMdd-HHmmss\ - 自動匯出：
- quality_metrics.csv
- perf_raw.csv
- perf_summary.csv
- run_manifest.json
最關鍵的幾個坑與修法
1) local-chat-completions 報錯：expects messages as list[dict]
這是因為沒套聊天模板，輸入格式不符。要加上：
--apply_chat_template
2) truthfulqa_gen 分數全是 0
不是模型一定很爛，而是輸出可能是空字串。我實際檢查 samples_*.jsonl 發現 filtered_resps 全空，導致 BLEU/ROUGE 全歸零。
常見原因是生成停止條件太早截斷。可先小樣本驗證：
lm-eval run --model local-chat-completions --apply_chat_template `
--model_args "model=google/gemma-4-26b-a4b,base_url=http://localhost:1234/v1/chat/completions,num_concurrent=1,max_retries=3,tokenized_requests=False" `
--tasks truthfulqa_gen --limit 5 `
--gen_kwargs "max_gen_toks=1024,until=[]" `
--output_path .\results\debug_truthfulqa --log_samples
先確認 samples 裡不是空輸出，再跑正式量測。
3) PowerShell 5.1 相容問題：ConvertFrom-Json 沒有 -Depth
如果看到「找不到符合參數名稱 ‘Depth’」，代表你在 PowerShell 5.1。修法是把：
ConvertFrom-Json -Depth 100
改成：
ConvertFrom-Json
4) 中文 prompt 變問號或亂碼
這是 Windows 下最常見的編碼坑。修兩件事：
- 讀設定檔時明確指定 UTF-8
- 送 API 時用 UTF-8 bytes +
charset=utf-8
我在腳本裡實作後，中文已可正常送出。另外終端顯示若還是亂碼，通常是顯示層問題，可先：
chcp 65001
我加的 -DebugEncoding 模式（很實用）
為了快速確認中文是否真的正確傳輸，我加了 -DebugEncoding。它會印出：
- Prompt 長度與 code points
- Request body 前幾個 bytes
- 第一筆回應型別與內容 code points
使用方式：
.\run-lmstudio-benchmark.ps1 -SkipQuality -DebugEncoding
看到中文 code points 不是 63,63,63...（問號）就代表傳輸沒壞。
指標名詞白話版
warmup：暖機回合，不納入正式統計，用來排除冷啟動噪音ttft：首 token 延遲，從發請求到吐第一個字的時間，越低越好p95：95 百分位，觀察尾端慢請求的重要指標sample_count：統計用了幾筆樣本（通常不含 warmup）model_load_time_seconds：模型載入到記憶體的時間，常出現在冷啟動
建議的實務流程
- 先用
--limit跑小量驗證流程是否正確。 - 檢查
samples_*.jsonl是否有非空輸出。 - 再移除
limit跑正式 benchmark。 - 用
perf_summary.csv比較模型穩態體驗（看ttft_p95與tps_avg）。 - 保留
run_manifest.json方便追溯每次設定差異。
結語
在本地模型場景，真正可用的 benchmark 不只是跑出一個分數，而是要能持續重跑、可追溯、可比較。把能力分數與效能指標分開，搭配穩定的 Windows 編碼處理與腳本化流程，才是長期可維護的評測基礎。
如果你也在用 LM Studio，我很推薦先把這套流程搭起來，再談模型選型，決策會快非常多。
