Reasoning Models 與 Test-time Compute：把算力花在推論，以及過猶不及¶

整理自論文與 Anthropic 官方文件（見文末），2026-06-20。近年的能力躍進，有一條主線是「不一定訓練更大的模型，而是在推論時花更多算力思考」。本頁講這條路線的原理、兩種擴展方式、Anthropic 的做法，以及「想太多」的反效果。

實證標記：〔論文〕= 出自學術論文；〔Anthropic〕= 出自 Anthropic 官方文件；〔實務〕= 業界慣例或本人整理。預設 under-claim。

核心概念：Test-time Compute Scaling¶

傳統提升能力靠「把模型練更大」。Test-time compute scaling 換個方向：在推論時讓模型產生更長、更結構化的思考鏈（chain-of-thought），花更多算力換更強的推理——在數學等推理基準上取得了顯著成果，得到「只靠訓練達不到」的推理能力。〔論文〕

兩種擴展方向〔論文〕¶

方向	做法	代表
Sequential（序列式）	延長單一思考鏈，誘導更慢、更慎重的思考（含回溯、自我驗證），在一次前向傳遞內完成	OpenAI o1、DeepSeek R1、Qwen QwQ
Parallel（並行式）	同時跑多條推理再彙整	多數投票 / self-consistency 類

Anthropic 的做法：Adaptive Thinking + Effort¶

Claude 4.6+ 不用「固定思考預算」，而是讓模型自己決定何時、思考多少：〔Anthropic〕

Adaptive thinking（thinking: {type: "adaptive"}）：模型動態決定思考深度，並在工具呼叫間自動穿插思考。舊的 budget_tokens（固定思考預算）在 Opus 4.7/4.8、Fable 5 已移除，Opus 4.6/Sonnet 4.6 上已棄用。
Effort 參數（output_config.effort：low/medium/high/xhigh/max）：控制思考深度與整體 token 花費。high 是多數任務的好起點，xhigh 適合編碼/agentic，low/medium 給例行工作。〔Anthropic〕

〔實務〕概念對應：「固定 budget_tokens」是早期的序列式擴展旋鈕；現在 Anthropic 把它換成「讓模型自適應 + effort 旋鈕」，正是為了避開下一節的「想太多」問題。

重要限制：想太多（Overthinking）會反效果¶

Test-time compute 不是越多越好。研究點出明確的反效果：〔論文〕

Overthinking（過度思考）：o1 類模型在簡單問題上消耗過量 token，準確率卻幾乎沒提升。
在某些領域，更長的 CoT 反而拖累推理表現——不是單調遞增。
Underthinking（思緒散亂）：另一類失敗是思考「到處跳」、沒收斂。
受 context window 限制：test-time scaling 的上限被視窗大小框住，思考鏈塞不下就斷。

〔實務〕實務心法：把「思考多少」當成要調的旋鈕，而不是越高越好。 簡單任務用低 effort（或關閉思考），難任務才拉高；並用評估集量「品質 vs token/延遲」的實際曲線，而不是預設 max。這也呼應 Context Engineering 實作篇：思考鏈也吃 context budget。

怎麼用：實務建議〔實務〕¶

分流：簡單/分類/抽取走低思考；多步推理才開高 effort 或推理模型。
量曲線：對你的任務跑 effort 掃描（low→high），看準確率與成本的拐點在哪，別盲目用 max。
想/填分離：需要結構化輸出時，先自由推理再結構化，避免「邊想邊填格式」壓低推理（見 Structured Output 與 Tool Use）。
評估要含成本：把 token/延遲一起評，否則會在「更貴但沒更好」的設定上最佳化（見 LLM Evaluation 實務）。

延伸閱讀（本站）¶

Structured Output 與 Tool Use 機制 — 結構化 vs 推理的取捨
Context Engineering 實作篇 — 思考鏈也吃 context budget
LLM Evaluation 實務 — 把成本納入評估
Prompt Engineering 核心技術 — CoT 的基礎