llama-benchy 把 API 也納入基準測試
llama-benchy 把 llama-bench 類型測試搬到 OpenAI 相容 API，能看上下文變長、併發增加時的延遲與吞吐。
llama-benchy 是一個用來測 OpenAI 相容 API 的基準測試工具，重點看上下文變長、併發增加時的延遲與吞吐表現。
說真的，這工具很實用。llama-benchy 目前有 451 顆星、42 個 fork、96 次提交。它不是在比誰的簡報好看。它是直接拿 API 來測。
很多團隊平常只看一個速度數字。那很容易翻車。因為提示詞變長、cache 命中、串流回應、併發請求一變，數字就會整個走樣。llama-benchy 想做的事很單純，就是把這些變數放進同一個 CLI。
| 指標 | 代表什麼 | README 範例 |
|---|---|---|
| pp | 提示詞處理速度 | 2048 token 提示詞，深度從 0 到 32768 |
| tg | Token 生成速度 | 範例跑 32 個生成 token |
| depth | 測試的上下文長度 | 0、4096、8192、16384、32768 |
| concurrency | 平行請求數 | 可用 --concurrency 調整 |
| runs | 每組重複次數 | 預設 3 次 |
為什麼要做這個工具
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
先講白了。llama.cpp 有 llama-bench，但那套主要在 llama.cpp 生態內用。你如果跑的是 vLLM，或 SGLang，或其他 OpenAI 相容伺服器，就很難直接拿同一把尺量。
這就是 llama-benchy 的切入點。它不碰推論引擎內部。它直接量 API 層。這很貼近真實使用情境，因為使用者打到的就是這層。request 處理、串流行為、server-side cache，全都會算進去。
我覺得這個設計很對。因為很多 benchmark 只會在實驗室裡漂亮。真正上線後，第一個 token 出來慢 5 秒，使用者就直接跳走。你在報告上看到的平均值，跟產品體感常常是兩回事。
- 目標是 /v1/chat/completions 風格 API
- 分開量提示詞處理和 token 生成
- 提示詞取自 Project Gutenberg 文字
- 可在 warmup 後做 coherence 檢查
- 輸出 Markdown、JSON、CSV
它到底量了什麼
llama-benchy 量的東西比一般 README 清楚很多。它會報 prompt processing speed、token generation speed、Time To First Response、estimated prompt processing time，還有 end-to-end TTFT。這些數字拆開看，才知道瓶頸在哪。
它也支援可調提示詞長度、生成長度、context depth，還有多次重跑。最後會算平均值和標準差。這點很重要。因為單次結果很容易被雜訊騙。多跑幾次，才知道伺服器是真快，還是剛好那次沒塞車。
另外一個細節我很喜歡。它用 Hugging Face tokenizers 算 token 數。這不是小事。不同模型、不同模板，token 數都可能不一樣。算錯了，整份 benchmark 就會看起來很專業，其實很假。
「It is widely used in LLM community to benchmark models and allows to perform measurement at different context sizes.」
— eugr，llama-benchy README
這句話很直白。它不是要發明新理論。它就是把 llama-bench 類型的量測，搬到任何 OpenAI 相容端點。這個範圍不大，但很實際。
數字怎麼看，才不會被騙
README 的範例很有意思。它用 openai/gpt-oss-120b，base URL 是 http://spark:8888/v1。測試深度從 0 一路拉到 32768。這種設計就是要看上下文變長後，性能會掉多少。
結果很誠實。depth 0 時，prompt processing speed 是 8521.08 t/s。到了 depth 32768，只剩 6896.57 t/s。TTFR 也從 240.36 ms 拉到 5048.31 ms。這不是小波動。這是使用者體感會直接變差的差距。
Token 生成也沒完全倖免。tg32 從 73.18 t/s 掉到 65.80 t/s。雖然不像 prefill 那麼誇張，但這已經足夠影響聊天體驗。尤其是長對話、長文件摘要、或多輪 agent 工作流，差一點點，總時間就會累很多。
- depth 0：8521.08 t/s，TTFR 240.36 ms
- depth 4096：9450.36 t/s，TTFR 253.95 ms
- depth 8192：8481.42 t/s，TTFR 246.50 ms
- depth 16384：7954.96 t/s，TTFR 289.46 ms
- depth 32768：6896.57 t/s，TTFR 5048.31 ms
它還有幾個很務實的功能。可以加噪音避免 cache 命中。可以在測完後跑清理指令。也可以開併發，直接看多請求壓上去後的吞吐。這些都是上線團隊會在意的事，不是紙上談兵。
安裝方式也很接地氣。它主打 uv。你可以用 uvx 跑，也可以裝進虛擬環境，或用 uv run。README 甚至把 release 跟 main branch 的做法都寫了，想追最新版的人會很省事。
和其他工具比，差在哪
如果你把它拿去跟一般壓測工具比，差異會很明顯。像 vegeta 或 wrk 很適合測 HTTP 壓力，但它們不懂 LLM 的語意。它們不會幫你拆 prompt processing，也不會幫你看 token generation。
llama-benchy 的強項，就是把 LLM serving 的細節拆開。你可以看到不同 context depth 的變化。你也可以看 concurrency 拉高後，TTFT 和 throughput 怎麼一起變。這對比單純測 QPS 的工具更接近實戰。
跟 llama.cpp 內建的 llama-bench 相比，llama-benchy 的價值在於 API 中立。你不用綁死某個推論引擎。只要是 OpenAI 相容 API，大多都能接。這對台灣很多做私有化部署、內網模型服務、或多供應商比較的團隊，真的很方便。
如果你的服務有 streaming、cache、或多輪對話，這種工具就更有用了。因為真正的瓶頸常常不在模型本身，而是在 serving 層。這也是很多團隊忽略掉的地方。
這工具背後的產業脈絡
現在做 LLM 服務，光有模型還不夠。你還要管 API、排程、cache、串流、權限、觀測。模型跑得快，不代表產品快。伺服器一塞，前端就卡，使用者只會覺得「這 AI 很慢」。
所以 benchmark 的重點也跟以前不同了。以前大家愛看單卡吞吐。現在要看端到端延遲。尤其是企業場景，很多時候不是跑單輪問答，而是長上下文摘要、文件檢索、agent 工具呼叫。這些情境都很吃 API 行為。
llama-benchy 的出現，等於把測試焦點往前推了一步。它提醒大家，真正要比較的是整條 serving 路徑，不只是模型核心。這種觀念其實很務實。少一點口號，多一點數字，大家才知道錢花在哪。
如果你現在在評估 vLLM、SGLang、或其他 OpenAI 相容服務，我會建議你把這類工具放進 CI 或 nightly job。至少每次版本更新後，你都能看到深度、併發、TTFR 有沒有變差。這比事後救火便宜多了。
結論：先測 API，再談快不快
我對 llama-benchy 的看法很簡單。它不是什麼華麗新玩具。它是把 LLM 服務測試拉回現實。你可以看到長上下文下的速度掉多少，也能看到併發上來後，伺服器還撐不撐得住。
如果你手上有 OpenAI 相容 API，我會直接建議你試一次。先拿 2048 token、再拉到 32768 depth，然後看 TTFR、pp、tg 怎麼變。你很可能會發現，真正的瓶頸不是模型名字，而是你沒量到的那一層。
接下來最值得做的事，就是把這類測試固定化。每次改動 serving 參數、升級版本、換 backend，都跑一次。這樣你才知道，你是在優化，還是在默默把延遲弄爛。