Day 10 的 37.5% pass@1 和 83.33% pass@8 兩組數據，後者明顯厲害，但相對而言它也多耗費八倍的候選機會，而沒有考慮計算成本，實務上可不能把 accuracy 的成本壓縮成一個含糊的 compute。

所以我們得嘗試對齊一整組預算，畢竟題目集合一換，比較對象也跟著換了；候選數不同，成功機會便不同；input 與 output token 就算總和相同，推論工作與計價仍可能不同。延遲還牽涉串行、平行與 batching，peak VRAM 決定硬體能否吃得下某些推論方法，工具呼叫則可能把搜尋、Python、retrieval 或另一個 verifier 的成本藏在 LLM token 之外。「compute-matched」若沒有說清楚究竟 match 哪些欄位，這個詞本身就僅是一個形容詞；類似的比較也可以在 SOTA 模型展示中得證，frontier lab 可能會宣稱 A 模型的表現比 G、O 等其他家模型更好，但是否有可能 A 模型的推理強度是 max，而其他只是 medium?

我們先不替任何方法算總分，而是把每一個候選的成本寫成 ledger，最小紀錄包含：

strategy_id
task_id
sample_id
correct
input_tokens
output_tokens
latency_ms
peak_vram_bytes
tool_calls

聚合規則同樣需要固定下來：input token、output token、sample latency 與 tool calls 可以逐筆相加，peak VRAM 只能取觀察到的最大值，把每一筆 peak 加起來會得到一個很大的數字，卻不對應任何機器實際需要的記憶體。至於 sample latency sum、同題候選串行執行的時間，以及理想完全平行時的 lower bound，三者都可以由 ledger 推導，在缺乏真實排程資訊時不等於 serving throughput。

價格方面則是另外的考量，雖然我們是在 local 端運算，不花費 tokens，不過為了方便計算，我們還是可以指定 input、output 和 tool 的 tariff，使用以下假設：

input:  $0.25 / 1M tokens
output: $1.00 / 1M tokens
tool:   $0.01 / call

這組價格只是假設，與任何供應商在 2026 年 8 月的報價無關，也沒有納入我自己的 RTX 3090 Ti 的電費、折舊或 total cost of ownership。四組策略重用 Day 10 的六道合成題與 normalized answer keys，再附上刻意設計的 counterfactual resource profiles；用途是驗證成本帳本和 matching identity，沒有測量 Qwen3 的速度、VRAM scaling 或多抽樣準確率。

跑完後，四組策略留下這份摘要：

strategy                         samples  any-success  input  output  total  latency-sum  tools  estimated USD
one_long                               6       0.5000    192   2,880  3,072      6,000 ms      0      0.002928
four_short_token_matched              24       0.6667    768   2,304  3,072      6,000 ms      0      0.002496
four_short_price_matched              24       0.6667    768   2,736  3,504      6,000 ms      0      0.002928
four_short_plus_tool                  24       0.6667    768   2,304  3,072      6,000 ms      6      0.062496

one_long 是每題一個 480-token 長候選，六題合計 192 input tokens 與 2,880 output tokens；four_short_token_matched 則讓每題產生四個 96-token 短候選，因此 prompt 被付了四次，合計變成 768 input tokens 與 2,304 output tokens。兩者的 total tokens 都是 3,072，sample latency sum 也同為 6,000 ms，但 sample count、input/output 組成與估計金額都不同。這組實驗可寫成 total-token-matched under the declared ledger，若只剩下 compute-matched，反而把真正對齊的東西省略了。

這個差異解釋了為什麼 token 總數相同，價格仍從 0.002928 美元變成 0.002496 美元：假設費率對 input 與 output 採不對稱設計，四個短候選重複支付 prompt，同時少生成了一些較貴的 output token。反過來看，four_short_price_matched 把每個短候選調成 114 output tokens，最後和 one_long 同為 0.002928 美元，total tokens 反而增加到 3,504。Price-matched 確實成立，也確實只成立在這份 tariff 裡。

第三個對照可觀察到 four_short_plus_tool 與 four_short_token_matched 的候選數、input、output、total tokens、sample latency 和 single-sample peak VRAM 欄位完全相同，唯一差異是每道題多記一次工具呼叫。六次工具把估計金額從 0.002496 美元推到 0.062496 美元；即使把 tool tariff 改成零，那六次呼叫仍然消耗外部服務、執行時間與失敗重試，紀錄不會隨著帳單歸零而消失。

在延遲的部分，四組策略的 sample latency sum 都是設計好的 6,000 ms，每題串行工作的平均也都是 1,000 ms；不過 one_long 每題只有一筆，因此 ideal parallel lower bound 仍是 1,000 ms，四個短候選若能完全平行，衍生下界則是 250 ms。這個 250 ms 沒有真的在 server 上被量到。Batching、同步、資料搬移、排程與資源競爭都可能改寫 wall time，四筆同時執行也可能讓 peak VRAM 高於目前的 sequential profile。取總和與取最大值各自描述一個界線，沒有哪一個會自動變成部署吞吐量。

至於真實模型，今天同樣沒有重跑 Qwen3，我們只讀取 Day 07 已凍結的 1,000 題 validation summary，建立一組成本估算：

examples                         1,000
pass@1                           0.178
output tokens total              511,552
output tokens mean               511.552
mean latency / example           1,154.954 ms
recorded total wall time         1,154,954.1248 ms
peak VRAM allocated              9,906,179,072 bytes
input tokens                     not_recorded
tool calls                       not_recorded
monetary cost                    not_derivable_from_recorded_fields
serving throughput               not_established
sealed-test inference count      0

缺少的欄位我就寫成 not_recorded，這些欄位足以描述那一次 validation run 的 output-token、latency 與 peak-VRAM 快照，目前無法追溯 input-token 總量、金額或 serving concurrency。

未來要比較實際多抽樣、self-consistency 或 selector，一列策略至少得同時帶著 checkpoint revision、eval split、prompt 與 verifier 版本、sampling config、seed、每題候選數、input/output token、實測 wall time 與執行拓撲、peak VRAM、tool calls、成本假設、pass@k、最終選擇準確率和信賴區間。我相信唯有比較多個欄位，才能更公平地去做評估，當然如果你手頭寬裕或不在乎這些成本，直接用最頂級的計算資源，那顯然本日的鐵人賽內容並不適用於你。