能跑起來，只代表你拿得到第一個 token
最近看到一個開源 leaderboard，輸入自己的 RAM 和 GPU，就會列出能跑的本地模型、排名、啟動命令，還拿 API 模型一起比。背後整理了 19,731 筆公開 benchmark，32GB Mac 可以跑 Qwen3.8 27B 4-bit。拿來縮小範圍，方便。
但 infra 的人看到「能跑」通常會先問三件事：用什麼 context 跑，幾個 request 同時進來，掛掉之後會不會自己回來。
RAM 估算如果沒有固定 context 長度，參考價值會打折。4-bit 權重只是入場券，KV cache 會跟 context 一起長，runtime 還有 workspace、CUDA graph、allocator fragmentation。你用 4K context 單人聊天測過，不代表 16K context 加兩個併發時不會 OOM。
benchmark 分數也要小心看。不同 quant 的分數如果沿用 full precision 結果，排名看起來很精準，可能只是在替近似值排隊。item response theory 可以把不同 benchmark 對齊，少量結果往中間拉並放寬不確定值，至少比把所有分數硬排一列誠實。不過它仍然回答不了你的 prompt 在這台機器上能不能穩定服務。
我會把 leaderboard 當 shortlist，接著做一個最小壓測。模型、quant、runtime 都鎖死，記錄啟動後常駐記憶體，再用自己的 context 跑 30 次。指令如下：
for c in 4096 8192 16384; do
hey -n 30 -c 1 -H Content-Type:application/json -d @prompt-$c.json http://127.0.0.1:8000/v1/chat/completions
done
接著把 concurrency 拉到 2、4、8，各跑 5 分鐘。我看的門檻是：單併發 tok/s 有沒有低於預期的 70%，p95 latency 有沒有超標，錯誤率是不是 0%，以及 OOM 後 process 是否在 30 秒內 restart。只看平均延遲沒用，平均值會把偶發卡死藏起來。
還有個反例。同一個模型換 llama.cpp、Ollama 或另一個 server，速度可能差很多。flash attention、offload layer、batch size、CPU thread 沒對齊，排行榜上的模型比較就失去意義。
所以我的流程很土：先用排行榜砍掉明顯放不下的，然後用完整 context、實際 prompt、預計併發量跑一輪，再決定要不要部署。能載入模型只是 deploy 的第零步。服務穩不穩，要看它在壓力上來時還能不能吐出下一個 token。
作者：CtrlC