test-time compute 是什麼？讓 AI 想久一點

2024 年 8 月，Google DeepMind 與 UC Berkeley 的研究者發了一篇論文，標題把結論直接寫完——《Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters》。裡面有個違反當時直覺的數字：把總運算量（FLOPs）拉平來比，一個小模型只要在答題時分到更多算力，就能在一部分題目上贏過參數大 14 倍的模型。

一個月後，2024 年 9 月 12 日，OpenAI 發表 o1，AIME 數學競賽成績從 GPT-4o 的 13% 跳到 83%。學界論文加上商業產品，前後一個月，把同一件事釘死了：算力可以花在「用的時候」，而且效果好到能跟「把模型做大」正面比。

Test-time compute（測試時運算）指的是在模型推理（inference）階段投入額外運算來換取更好答案的做法。常見手段有兩類：讓模型生成更長的思考鏈（chain-of-thought）、或對同一題採樣多個答案再由驗證器（verifier）挑出最好的。它與「擴大參數與訓練資料」（pre-training）、「訓練後對齊與強化」（post-training）並列，被稱為第三條 scaling 曲線。投入越多推理算力，表現通常越好——但成本按 token 計費、延遲直接變長，而且 2026 年的研究已經標出它在多輪 agent 任務上的天花板。

站內的 what-is-reasoning-model 條目介紹過 reasoning model 這個產品形態。這一條往下挖一層：reasoning model 是你看得到的產品，test-time compute 是它背後那條資源曲線——以及 2026 年這條曲線被修正成什麼樣子。

三條 scaling 曲線，算力花在三個時間點

把一個 LLM 從無到有推到你面前，算力花在三個階段：

曲線	算力花在哪	代表做法	成本誰付
Pre-training	訓練前期	更大參數、更多資料	模型廠一次付清
Post-training	訓練後期	RLHF、reasoning RL、蒸餾	模型廠一次付清
Test-time	每一次推理	更長思考鏈、多次採樣＋驗證器	每次呼叫的人付

前兩條曲線的錢是模型廠在訓練時燒掉的，燒完就固定了；第三條曲線的錢跟著每一次 API 呼叫走。這是 test-time compute 跟你直接相關的原因——它的成本結構會出現在你的帳單上，而且由你（部分地）控制開關。

用考試打比方：pre-training 是讓學生多讀三年書，post-training 是考前特訓，test-time compute 是監考老師允許延長考試時間。同一個學生，多給 30 分鐘檢查考卷，分數就是會變高。這個比喻等一下還會用到，因為它也能解釋天花板在哪。

想久一點的兩種姿勢

「多花推理算力」有兩條具體路線，Snell 等人 2024 年的論文把它們放在同一個框架下比較：

1. 序列式（sequential）——同一條思考鏈拉長：想、檢查、修訂、再想。o1 和各家 thinking 模式走這條。考試比喻裡是「延長時間讓同一個學生反覆檢查」。
2. 平行式（parallel）——同一題採樣 N 個答案，用驗證器或投票挑出最好的（best-of-N）。考試比喻裡是「找五個同學各寫一份，挑分數最高的交」。

該論文的核心發現：哪條路線划算，取決於題目難度。簡單和中等的題目，平行採樣加修訂就夠；真正難的題目，序列式的深度修訂才有用。按題目難度動態分配算力的「compute-optimal」策略，效率比固定用一種策略高 4 倍以上。

這件事對使用者的翻譯：不存在「永遠開最深思考」的最佳解，分配比總量重要——這個 2024 年的結論，在 2026 年被 agent 研究用更難看的方式再驗證了一次。

2026 年的修正——天花板與過度思考

第三條曲線在單輪的數學、程式題上很爭氣，但 2025 到 2026 年一批研究把它放進多輪 agent 場景後，畫面變了。

天花板一：context ceiling 與 verification gap。2026 年 2 月，CMU 參與的團隊發表 General AgentBench，橫跨搜尋、coding、推理、工具使用測試通用 agent 的 test-time scaling。結論是兩條路線各撞一道牆：序列式擴展有 context ceiling——互動歷史累積超過門檻後，表現持平甚至下降，餵更多輪次換不到進步；平行式擴展卡在 verification gap——採樣再多條軌跡，缺乏可靠的驗證器就挑不出對的那條。單輪題目上「加算力就加分」的曲線，到多輪 agent 任務上不成立。

天花板二：想太多會壞事。更早一步，2025 年 2 月 Berkeley、CMU 等機構的研究《The Danger of Overthinking》分析了 SWE-bench Verified 上 4,018 條 agent 軌跡，發現 reasoning model 在多輪互動裡有系統性的過度思考（overthinking）傾向：埋頭在腦內模擬後果，該去跟環境互動（跑測試、讀報錯）的時候不去。過度思考分數越高，表現越差。反過來操作——同一題採樣多個解、故意挑「想得少」的那個——表現提升近 30%，算力省 43%。考試比喻的殘酷版：延長時間給到某個程度後，學生開始把原本寫對的答案改錯。

但天花板高度依方法而定。2026 年 4 月 CMU 與 Meta 研究者的《Scaling Test-Time Compute for Agentic Coding》給了另一面：問題出在「盲目重試」，把先前嘗試壓縮成軌跡摘要、再做選擇與精煉，Claude-4.5-Opus 在 SWE-Bench Verified 上從 70.9% 推到 77.6%。跟 Snell 等人 2024 年的結論同一個方向——算力怎麼組織，比算力給多少重要。

最深的一刀砍向訓練配方。2026 年 4 月另一篇論文《Test-Time Scaling Makes Overtraining Compute-Optimal》提出 Train-to-Test scaling laws：既然已經知道模型上線後會做 test-time scaling，推理算力就該算進總帳——這一算，最佳訓練策略大幅偏向「較小模型＋更多資料」的過度訓練（overtraining），遠超出傳統 scaling law 建議的範圍。第三條曲線的存在，反過來改寫了第一條曲線的配方。三條曲線從三條獨立的線，變成一套要聯合最佳化的預算分配問題。

帳單怎麼算，thinking 什麼時候該開

概念講完，講錢。test-time compute 對多數讀者的直接觸點是兩個參數：API 帳單和等待時間。

計費現實（以 Anthropic 官方文件為準，OpenAI 的 reasoning token 邏輯相同）：

• 思考 token 按 output token 費率計價——是各家費率表上最貴的那格。
• 即使介面只顯示思考摘要，帳單算的是完整思考 token，摘要長度與計費無關。
• budget_tokens 設的是上限，模型不一定用滿；較新的 Claude 模型改用 adaptive thinking 搭配 effort 參數，讓模型自己決定想多久。

開關判斷可以直接抄前面三節的研究結論：

情境	開或關	依據
數學、複雜 coding、高風險單次決策	開	單輪深推理是 test-time compute 的主場
FAQ、改寫、簡單 lookup	關	算力換不到分數，純付費
即時對話、voice agent	關	延遲不可接受
大量 batch 處理	關或低檔	單價乘上量，成本失控最快的場景
多輪 agent 的每一步	低檔或 adaptive	overthinking 研究＋context ceiling 都指向「步步深思」有害

可以直接試的動作：從你 production 裡挑一類最常跑的任務，開 thinking 與關 thinking 各跑 20 題，記下正確率差距和 token 用量，算出「每多對一題花多少錢」。這個數字比任何 benchmark 都能告訴你，第三條曲線對你的場景值不值。

收尾

三個帶走的點。

第一，test-time compute 把「模型多聰明」從固定值變成可調的參數——同一個模型，你出多少推理算力，它就多準一點，成本轉嫁到每次呼叫。

第二，2026 年的共識已經從「加算力」移到「配算力」：單輪深題有效、多輪 agent 有 context ceiling 和 overthinking 兩道牆，突破靠的是組織算力的方法，而且訓練配方也開始為此重寫。

第三，這條曲線上你唯一能控制的槓桿是開關與檔位。用 20 題實測算出你自己的「每多對一題的單價」，比追任何論文都實際。

資料來源：arXiv（Snell et al.、General AgentBench、The Danger of Overthinking、Test-Time Scaling Makes Overtraining Compute-Optimal、Scaling Test-Time Compute for Agentic Coding）、OpenAI、Anthropic

矽基前沿 · 大百科線（編輯：廖玄同），《test-time compute 是什麼？讓 AI 想久一點》，矽基前沿 [Si]gnals，2026-07-05。https://signals.tw/articles/what-is-test-time-compute/