同一顆模型,不變動任何參數,只要在推論當下多花一點運算時間去「想」,就能在困難題目上打贏參數量大上十幾倍的對手——這就是 test-time compute(測試時運算擴展)這一年多來重寫的遊戲規則。
📖 學(核心)
什麼是 test-time compute
過去要讓模型變聰明,主要手段是把模型做大、把訓練資料堆多,也就是「訓練時擴展」(train-time scaling)。test-time compute 談的是另一條路:模型大小、權重都固定不動,單純在「推論當下」多花運算資源,讓模型有機會產生更長的思考鏈、嘗試多條解法、或是自我檢查與修正。Google DeepMind 與柏克萊團隊在 2024 年的論文〈Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters〉把這個概念第一次講得很嚴謹:同一個問題,如果讓模型用「用對方法」的推論時間去解,效果可以超過直接換一顆大 14 倍的模型。這篇論文也是後續一整條研究線的起點,DeepSeek-R1、OpenAI 的 o 系列推理模型,基本上都是這條思路的產品化落地。
值得先釐清一個容易搞混的地方:test-time compute 不等於「讓模型多打幾個字」。單純叫模型「請詳細思考」拉長輸出,如果沒有搭配驗證或搜尋機制,邊際效益很快就會打平甚至變差。真正有效的 test-time compute,關鍵在於「用額外的運算做了什麼」,而不是「用了多少運算」。
兩種主要擴展機制
論文把有效的做法歸納成兩大類。第一類是「序列式」(sequential):模型針對同一題目反覆修正自己的答案,靠後訓練(post-training)學會的自我反思能力,一步步把錯誤的中間推理修掉,像是先寫一版解法、檢查哪裡不對、再重寫一版。DeepSeek-R1 展示的正是這種能力可以完全透過強化學習、只給最終答案對錯的訊號,就讓模型自己「長出」這種反思與回頭檢查的行為,不需要人工標註每一步推理過程。
第二類是「平行式」(parallel):模型針對同一題目同時生成多條不同的解法路徑(例如常見的 best-of-N),再用一個驗證器(verifier)或獎勵模型去給每條路徑打分,挑出最可能正確的那一條,或是用多數決、加權投票的方式綜合出最終答案。這類做法的天花板取決於驗證器的品質——如果驗證器判斷不準,生再多條路徑也沒用。實務上,好的系統會把序列式和平行式混著用:先平行生成幾條粗略解法,再對其中較有希望的分支做序列式的深入推敲。
compute-optimal:依難度動態分配運算
這篇論文最關鍵的洞察,是「同一種擴展策略,在不同難度的題目上效果差很多」。太簡單的題目,模型一次就對,硬要它多想幾輪、多生幾條路徑,只是白花運算,甚至可能被過度思考帶偏答案;太困難的題目,就算給再多運算預算,模型可能還是抓不到解法的關鍵,運算等於打水漂。真正划算的,是介於「模型有一定機率答對、但不是每次都對」的中間難度區間——這正是額外運算能發揮最大槓桿的地方。
因此論文提出「compute-optimal」策略:先粗略估計一道題目對這顆模型來說有多難,再決定該投入序列式修正、平行式搜尋、還是乾脆一次生成就好。用這種依難度動態分配的方式,作者量到能比單純的 best-of-N 基準線,在同樣運算預算下效率提升超過 4 倍。這對正在做 AI 產品的人是很實際的提示:「固定用同一套推理設定打天下」幾乎必然是次優解,題目難度分流本身就是一項可以優化的工程。
也別神化它:效果被高估的部分
2026 年也出現不少「潑冷水」的研究,例如〈It’s Not That Simple: An Analysis of Simple Test-Time Scaling〉這類論文指出,許多聲稱「多花運算就等比例變強」的展示,其實只在特定基準測試、特定題型上成立,換一批分布外的題目,增益會明顯縮水,甚至有些「自我反思」看起來像是模型在重複輸出裡湊出更長、更像人類推理的文字,但正確率沒有實質提升。另外,test-time compute 的成本是真金白銀的——每一次多想幾輪、多生幾條路徑,都是額外的 GPU 時間與 API 費用,對使用者來說也代表更長的等待時間。所以工程上真正的問題從來不是「要不要用 test-time compute」,而是「用在哪些請求上、用多少、用什麼驗證機制,才划算」。這也是為什麼像 Snell 等人強調的是「optimally」——重點永遠是資源分配的效率,而不是無腦加碼推論時間。
對開發者與產品設計的意義
如果你在做的是需要精準答案的任務——程式碼生成、數學推理、多步驟規劃、法規或合約分析——test-time compute 提供了一條「不用重新訓練模型」就能提升準確率的槓桿:讓模型多想幾輪、加一層驗證、對高風險輸出做多路徑比對。但如果是閒聊、摘要、簡單分類這類任務,強行套用推理模式只會拖慢回應、增加成本,對使用者體驗反而是扣分。實務上比較成熟的做法,是先做一層「難度/風險分流」判斷這個請求值不值得多花運算,再決定要不要啟動更重的推理路徑——這跟不少產品現在把「快速模式」與「深度思考模式」分開讓使用者或系統自動選擇,是同一套邏輯的體現。
🧠 記
- test-time compute(測試時運算擴展)= 模型參數不變,靠推論當下多花運算時間換取更高準確率。
- 核心論文是 Snell et al. 2024〈Scaling LLM Test-Time Compute Optimally〉,證明小模型 + 足夠推論運算可以打贏 14 倍大的模型。
- 兩種主要機制:序列式(自我反思、逐步修正解法)與平行式(多條路徑生成 + 驗證器挑選)。
- 平行式擴展的天花板取決於驗證器/獎勵模型的品質,驗證器不準,生再多條路徑也沒用。
- compute-optimal 策略:依題目難度動態分配運算,中等難度題目的邊際效益最大,太簡單或太難都是浪費。
- DeepSeek-R1 證明「自我反思、回頭檢查」這類行為可以純靠強化學習(只給最終對錯訊號)自然學出來,不需人工標註推理步驟。
- 2026 年也有研究指出部分「test-time scaling 有效」的結論被高估,換分布外題目增益會縮水,需要留意論文的評測範圍。
- 多花的推論運算等於真實的 GPU 成本與使用者等待時間,產品設計要做難度/風險分流,而非無差別套用深度推理。
✍️ 實踐
- 找一個手邊模型有 API 支援「思考預算」(thinking budget / reasoning effort)的介面,對同一題目跑「低運算」與「高運算」兩種設定,實測輸出品質與延遲差異。
- 挑 5 題不同難度的問題(簡單、中等、困難各幾題),觀察模型在哪個難度區間「多想」帶來的效果最明顯,驗證 compute-optimal 的直覺。
- 試著讓模型針對同一題輸出 3 條不同解法,自己(或用另一次呼叫當驗證器)比較差異,體會平行式搜尋 + 驗證器的運作方式。
- 閱讀 Snell et al. 論文摘要與其中一張圖表(建議 FLOPs-matched 比較圖),寫下你對「訓練時擴展 vs 推論時擴展」抉擇的理解。
- 盤點自己專案中的 AI 功能,標出哪些任務屬於「值得花更多推論運算」(高風險/高價值)、哪些屬於「該用最快最省模式」,設計一套簡單的難度分流規則。
- 找一篇對 test-time scaling 抱持懷疑態度的論文或文章讀完,列出它質疑的具體論點,避免只吸收正面宣傳。
🔗 延伸學習
- Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters (arXiv:2408.03314)
- It’s Not That Simple: An Analysis of Simple Test-Time Scaling (arXiv:2507.14419)
- A Survey of Frontiers in LLM Reasoning: Inference Scaling, Learning to Reason, and Agentic Systems (arXiv:2504.09037)
- Test-time compute vs parameter scaling in AI reasoning — PatSnap
💬 問 AI
我正在做一個 {你的 AI 產品/功能} ,目前用的是 {模型名稱} 。
請幫我設計一套「test-time compute 難度分流」規則:
1. 列出 3-5 種可以快速判斷請求難度/風險高低的訊號(例如輸入長度、關鍵字、任務類型)。
2. 針對「低難度」「中難度」「高難度」各建議該用什麼推理設定(例如單次生成、多路徑投票、加驗證步驟)。
3. 估算每一種設定對延遲與成本的大致影響,提醒我要注意的取捨。