Benchmark 分數不等於帳單

為什麼 benchmark 贏家，最後還是把我的 API 帳單炸掉？

Benchmark 常把速度、推理努力和正確率混在一起，所以分數高不代表便宜。

我盯模型排行榜一陣子了，老實說，它最會騙人的地方就這一件事：一個模型拿到漂亮分數，大家就開始點頭，等真的丟進 production，帳單卻像被人惡搞。尤其是 agent loop、tool call、需要多想幾步的任務，這種落差更明顯。問題不在分數假，而在分數把品質和時間揉在一起了。模型如果用更快的方式答對，分數會很好看；如果它花更多時間推理，反而可能看起來比較差，就算它其實做得更穩。

這次讓我把這件事重新想一遍的，是 VentureBeat 這篇文章，裡面提到 Qwen 3.8-Max 和 Claude Opus 5。它不是在講空話，而是直接把 benchmark 行為和 effort、time 這些變數拉出來看。文章也提到 VulcanBench 這個開源 harness，這種東西我才信，因為它讓你看到到底在測什麼。

Benchmark 其實在算時間效率

Benchmarks are implicitly measuring time efficiency, whether or not they shout about that.

翻譯一下就是：benchmark 從來不只是「模型聰不聰明」，而是「模型在這個測試條件下、用這個時間和算力預算，能不能把題目做對」。如果 harness 允許模型花更多 token、更多步驟、更多內部 effort，分數就會跟著飄。這不是數學壞掉，這就是數學本身。

我自己在看 agent 工作流時，最常踩這個坑。紙面上最強的那個，不一定是我想放進 production 的那個。它可能更慢、更貴，還會在簡單任務上想太多。benchmark 有時候獎勵這種多想幾步，有時候又懲罰它，取決於測試怎麼設。大家嘴上說在比「raw benchmark scores」，其實早就把時間成本塞進去了，只是沒人想講清楚。

實操寫法很簡單：不要把單一分數當終局判決。你要先看測試預算、重試次數、推理模式、token 上限，還有模型是不是被允許多花時間去換更高分。如果 benchmark 沒把這些 knob 交代出來，我就只把它當參考，不會直接拿去採購。

• 先確認 benchmark 有沒有允許不同 reasoning effort。
• 看 token 限制、retry 次數、tool-call 數量。
• 把分數、延遲、估算 token 成本一起看。

Effort 開關真的會翻盤

VentureBeat 提到一個很刺眼的例子：在 VulcanBench 的某次報告裡，Claude Opus 5 的最低 effort 反而是表現最好的，23 題解出 20 題，高 effort 只有 18 題。這種結果很值得停一下。要是「更努力」永遠比較好，曲線應該很無聊才對，但現實不是。

白話講，模型不是每次都會因為多想就變強。有時候它會卡進更差的搜尋路徑，有時候多餵一點推理反而把雜訊放大。還有一種更煩的情況，是 benchmark 本身比較獎勵簡潔執行，而不是長篇內部思考。我在 code task 也看過這種事：一個 loop 比較緊的模型，常常比那個一直自我懷疑的模型更快交出可用答案。

實操寫法：你測模型時，別只跑一個 effort。至少跑兩檔，低 effort 和高 effort 都要有，同一組 prompts 直接比。看 success rate、latency、cost。如果低 effort 贏了，通常代表模型本來就有足夠 signal，你只是多付錢讓它亂繞。

• 低、中、高 effort 分開測。
• 不要只看最終分數，要看任務成功率。
• 把 wall-clock time 和 token usage 都記下來。

VulcanBench 好用，因為它把機器攤開

我喜歡 VulcanBench 的原因很單純：它逼你不要只看 vibe。開源 harness 的好處就是，你可以直接看到它怎麼測、怎麼算、怎麼把結果做出來。閉源 benchmark 則常常只剩一張圖，然後大家開始對著圖腦補，最後買單的人通常是自己。

這段我想講白一點：harness 跟 model 一樣重要。模型本身沒有離開上下文就能自證強弱，測法一變，排名就可能翻面。prompt 怎麼寫、給幾次機會、評分偏速度還是偏準確，這些都會影響結果。我自己的內部 eval 也遇過，光是改一點輸入格式，排名就比換模型還大。很煩，但很真。

實操寫法：如果你真要選 production model，自己做一個薄版 benchmark。題目不要多，先抓最像實際工作的一小組。把 effort 設定寫死，output、token、elapsed time 全部 log 起來。如果你在自己的 harness 裡重跑不出同樣排名，那這個排名大概也不值得你掏錢。

• 先做小型、可重複的 eval set。
• 把 effort、token、時間都寫進 log。
• 用自己的工作流程重跑一次，再決定要不要信外部分數。

帳單是 search 的結果，不只是 intelligence

這是財務最晚才會懂的一點：invoice 不是只看模型有多聰明，它還看模型為了找答案搜索了多少次。search 越多，token 越多，call 越多，延遲越高，失敗機會也越多。某個模型如果因為多探索幾輪而拿到更高 benchmark，它可能非常不適合需要大量吞吐的產品。

所以「best benchmark」跟「best bill」常常不是同一件事。你的工作如果是客服分流，你大概需要快、夠好、可以便宜重試的答案。你的工作如果是法務草稿或深度 code review，那你可能願意多花錢換更高準確率。問題是很多團隊把這兩種需求混成一個決策，最後就會選到看起來很強、實際很貴的模型。

實操寫法：先寫下你真正的 business constraint。是每張 ticket 的成本？每個 patch 的成本？還是每個 workflow 的完成成本？我開始這樣算之後，模型選擇就沒那麼戲劇化了，但實用很多。

為什麼 raw score 老是騙到團隊

raw score 很誘人，因為它把複雜問題壓成一個數字。採購喜歡一個數字，產品喜歡一個數字，老闆更喜歡一個數字。但這個數字會把 performance 和 spend 的 tradeoff 蓋掉，而這個 tradeoff 在 agentic system 裡根本就是主角。

也就是說，benchmark chart 有時候會不小心獎勵那些跑起來特別貴的模型。如果模型被允許花更多 effort，而這些 effort 又被算成「更好的推理」，那 chart 其實有一部分是在量 budget。這不代表 chart 沒用，只是你要像修車的人一樣看它，不要像觀光客一樣看熱鬧。

我自己在 model review 裡講過很多次：更高分可能代表更強，也可能只是模型被准許燒更多時間才拿到那個分數。有時候兩者都有，有時候兩者都不是。安全做法只有一個：把分數背後的條件挖出來。

實操寫法：比較模型時，operating envelope 要完全一致。相同 prompts、相同 max tokens、相同 tool access、相同 timeout、相同 temperature。只要有一項不同，分數就不是乾淨比較。

我真正在意的，是上線後會不會失血

如果我今天要在看完這篇之後選模型，我不會先看 leaderboard。我會先做一組像 production 的小 eval，然後盯住直接打到帳單和體感的指標。

白話講，我會看 success rate、median latency、p95 latency、token spend、retry rate、human override rate。這些加起來，才看得出模型是因為效率高所以便宜，還是因為能力差所以便宜，後者通常只是偷偷失敗。我兩種都被坑過。

實操寫法：eval 要做得很 boring、很 repeatable。不要去優化 benchmark，去優化你每天真的在跑的工作流。那才是會付租金的分數。

• 看你自己的 task set 成功率。
• 看 median 和 p95 latency。
• 看每個 completed task 的 token spend。
• 看 retry、fallback、human correction。

可抄的模板

# Model eval template: score + spend + effort

## Goal
Compare models for real workload value, not leaderboard rank.

## Models
- Model A:
- Model B:
- Model C:

## Test setup
- Same prompts for every model
- Same max output tokens
- Same tool access
- Same timeout
- Same temperature
- Same effort setting, then repeat at low and high effort

## Metrics
- Task success rate
- Median latency
- p95 latency
- Input tokens
- Output tokens
- Retry count
- Fallback count
- Human override count
- Estimated cost per completed task

## Run plan
1. Run each model at low effort.
2. Run each model at high effort.
3. Log every output and failure.
4. Compare success rate against token spend and latency.
5. Pick the cheapest model that meets the target quality.

## Decision rule
Choose the model that satisfies the workload target at the lowest total cost,
not the model with the highest raw benchmark score.

## Notes
- If higher effort improves score but doubles cost, treat that as a tradeoff.
- If lower effort matches or beats higher effort, prefer lower effort.
- If rankings change across effort levels, the benchmark is measuring search behavior too.

這篇的原始觸發點是 VentureBeat 對 Qwen 3.8-Max 和 Claude Opus 5 的整理，還有它指到的 VulcanBench。我上面那份模板是我自己整理的，但核心拆法來自這些公開材料。

如果你要回頭看原始脈絡，先從這兩個 URL 開始：VentureBeat 文章、VulcanBench repo。我這篇是把它拆成工程上能直接用的版本，不是原文照抄。