Post-training Scaling Law 最近被一句更聳動的話帶紅了：「參數量已死。」2026 年 8 月，Z.ai 用 GLM-5.3 說明同一個 base model（尚未進入這一輪後訓練的底座權重）如何在擴大後訓練後改變；一篇 Reddit 討論隨即爭論參數是否還有意義。問題是，這兩句話不是同一件事。
這篇專為完全沒有技術背景、卻要選本機模型或 API 的讀者寫。不寫一行你看不懂的程式碼，我們會把模型表現拆成四個旋鈕，解釋 GLM-5.3 支持哪些結論、哪些仍待驗證，最後交付十題 diagnostic mini-eval 的設計配方與空白紀錄欄位，讓你在自己的任務上分開比較能力、成本、速度與穩定度。
先說結論：參數量沒有死，只是不再能單獨回答問題
一句話先記住：你量到的系統表現，是四個層次共同作用的結果：① 預訓練資料與算力，② 底座架構、總／active 權重與每個 token 實際計算，③ 後訓練配方與算力，④ 推論時的 reasoning、採樣／搜尋、工具、harness 與預算。Eval 決定我們怎麼觀察結果；參數量只是第二層的一個描述值，四層也不是能直接相加或相乘的同單位數字。
因此，「參數量已死」適合當標題，不適合當採購規則。總參數主要影響模型檔、完整權重容量與容量代理值；每 token 運算還要看架構、active 路徑與實際 FLOPs，GPU 峰值則看常駐／offload 配置。資料怎麼配、後訓練教了哪些行為，以及回答時允許思考多久，也會改變結果。
Scaling Law 是什麼？先從「可預測的趨勢」開始
Kaplan 等人的早期 scaling-law 研究觀察到，語言模型的測試 cross-entropy loss（正確下一個 token 的平均負對數機率；越低越好）會隨模型規模、資料量與訓練計算呈規律變化。它描述的是特定條件下的統計趨勢，不等於「參數翻倍，所有能力就翻倍」。
接著，Chinchilla 研究用 400 多次、橫跨不同預訓練計算預算的實驗，估計每一個 compute budget 下應如何一起擴大模型參數與訓練 token。在它的同算力比較裡，較小但看過更多資料的 Chinchilla 勝過更大的 Gopher；這是特定訓練配方的實驗結果，不是固定比例的宇宙常數。
後來的 inference-aware scaling 研究又把可預測的部署期輸入／輸出 token 量納入生命週期成本。在固定目標 loss、需求量可估且有足夠訓練資料的條件下，高推論需求可能讓「訓練更久、部署較小模型」更經濟。這些工作共同提醒我們，scaling law 必須先說清楚「固定什麼、增加什麼、預測什麼」。
Post-training Scaling Law 到底是什麼？
預訓練像讓學生讀完一座圖書館；後訓練則像進入實習。後訓練是一個總稱，常見方法包括 supervised fine-tuning（SFT，用示範教回答形式）、偏好最佳化，以及 RL（用回饋調整策略）。工具環境、長任務、合成軌跡與 verifier（自動核對結果的評分器）則提供練習題、互動場景與 reward。這些因素中的部分已被實驗證明會改變效率或能力上限，其餘仍須逐項驗證，所以「多花後訓練算力」仍不是完整配方。
嚴格來說，單一模型從舊版升到新版，只是一個前後比較，不足以建立「law」。要稱為 scaling law，至少要掃過多個後訓練預算或模型尺度，在固定評測條件下擬合並驗證可預測關係。本文引用的兩項研究呈現不同、且受模型家族、資料、任務與評分指標限制的曲線，不能合併成一條跨模型定律。這裡的縱軸可能是 loss、reward／通過率，或下游任務分數，本來就不是同一件事。
例如 ScaleRL 研究在固定模型、資料、recipe 與指標後，掃過多個 RL 計算預算，得到逐漸飽和的 sigmoid 曲線；白話說，低 compute 區先緩慢、中段加速，靠近上限後邊際回報再縮小。另一項 Qwen2.5 數學 RL 研究則把 test loss 定義為 1 − 通過率，再用近似 power-law 描述它對 compute／data 的變化。兩者的模型、橫軸、縱軸與曲線都不同。因此本文把「Post-training Scaling Law」當成一組研究問題的總稱：增加哪種後訓練資源，會讓哪個指標以什麼曲線改變？
這也解釋了它和AI 模型如何學習的關係：預訓練建立廣泛的預測能力；後訓練會改變模型在特定提示與環境下的輸出分布和可觀察行為。它也不同於模型蒸餾；蒸餾重點是把教師模型的行為轉移到學生模型，後訓練 scaling 則問增加練習資源時，行為改善如何變化。
用四個旋鈕拆解模型表現
旋鈕 1：預訓練資料與算力，決定模型先看過什麼
痛點：兩個參數量相同的模型，表現可能明顯不同。解法是先看預訓練旋鈕：資料的數量、品質、語言、程式碼比例、重複程度與難度分布，以及用多少算力學習它們，都會改變模型形成的表示；不要由參數量反推「它一定懂更多」。
實務上，把目標工作拆成資料需求：繁體中文客服需要在地語境；程式代理需要相關語言、repo 結構與除錯軌跡；研究助理則需要引用與來源判讀。測試題要貼近這個分布，而不是只看一個綜合榜。
旋鈕 2：架構、total／active parameters 與 effective depth
Total parameters 是模型全部可學權重；active parameters 是一個 token 前向計算實際使用的參數量發布口徑，是否包含 attention、shared expert 等常駐模組，要依各模型定義。總參數像整間公司的人力名冊，active parameters 像這張工單實際叫來的團隊；不同論文與模型報告可能採不同口徑，跨廠商比較前要先讀定義。
Active 小不代表整個部署只需儲存 active 部分；GPU 常駐量則取決於 full-resident、offload 與 cache 策略。權重容量可先粗估為「總參數 × 每個權重的位元數 ÷ 8」，再加量化 metadata；GPU 記憶體峰值還包含實際常駐權重、KV cache（長上下文的中間記憶）、activations 與 runtime workspace（執行軟體的暫存空間）。Offload（把部分權重移到 CPU／RAM）可降低 GPU 常駐量，但常以延遲為代價；記憶體頻寬主要影響速度，不是容量。
一項 MoE 稀疏度研究在固定模型寬度與 top-k（每次選幾位 expert）、再增加 expert 數的受控模型中，看到數學任務呈非單調變化，知識型任務卻仍可能隨總參數改善。它支持的是「任務不同，合適的稀疏度不同」，不能概括成所有推理能力。
本文引用的兩項研究使用不同的 effective-depth 定義。一項初步研究用多種診斷方式估標準 Transformer 裡實際有功能貢獻的層；recurrent-depth 架構則把共享區塊重跑多次，增加展開後的計算深度。一般 chain-of-thought 增加的是生成 token 與 forward pass（權重完成一次由輸入到輸出的計算）的次數，工具迴圈增加的是系統回合；兩者都不等於單一 token 穿過更多獨立 Transformer 層。比較時應分開記錄獨立層數、共享區塊重複次數、生成 token、候選／搜尋次數與工具回合。
旋鈕 3：後訓練，決定模型被練成怎麼做事
痛點：base model 能答對孤立子題，不代表它能穩定完成整個多步任務。解法是拆開後訓練配方：環境是否貼近真實工作、任務是否多樣、回饋是否獎勵正確過程、verifier 能否抓到投機答案，以及訓練是否覆蓋失敗後恢復。
增加 RL 計算可能帶來可測的進步，但關係會依模型、資料與任務而變。一項後訓練 scaling 實驗在數學任務上系統比較模型大小、累積 FLOPs／已處理 token、unique samples 與資料重用；它提供的是特定領域的實證，不是所有 Agent 工作都必然遵循的比例。
後訓練也可能把弱點放大：若 verifier 只獎勵容易鑽漏洞的分數，增加 rollout（一次完整嘗試）與算力，可能擴大的是 reward hacking，而不是真實能力。因此每次 scaling 都要另跑未參與調整的回歸題，檢查跨領域退步、安全邊界與失敗恢復。
旋鈕 4：推論系統，決定這一題願意花多少預算
在模型研究裡，test-time compute 常指不更新權重、卻增加生成、revision（自我修訂）、候選搜尋或 verifier 評分所花的模型計算。產品選型還要把工具 API、sandbox 與 Agent 回合列入「推論階段的系統成本」，但那不等於模型 FLOPs。Snell 等人的實驗侷限於 PaLM 2、MATH、revision 與 process-reward-model search；它支持「合適策略依模型與題目難度而變」，不能直接證明所有工具型 Agent 多跑幾輪都會變好。
API 使用者要記錄 reasoning effort（產品的思考強度）、最大輸出、工具、重試與 timeout；本機使用者還要記錄 tokens/s、首 token 延遲、記憶體峰值與功耗條件。若其中任何一項不同，表面上的「模型差距」可能其實是推論系統差距。
GLM-5.3 案例：它讓我們看到後訓練，不等於證明參數失效
Z.ai 在 2026 年 8 月 14 日的 GLM-5.3 官方說明自述，新版沿用 GLM-5.2 的同一個 base model，這一個月擴大的是環境數量、任務多樣性與後訓練算力。這支持「廠商報告同底座版本仍有明顯變化」；本文只把它當作 Z.ai 的 before／after 自述，不把它當成已獨立驗證的因果分解。
若把後訓練預算視為 x 軸，官方發布文只給 GLM-5.2／5.3 的版本級結果，算力以 more compute 定性描述；環境、任務與算力又是同一個變動組合。這些公開數字本身無法把增益精確歸因給算法、verifier 或某個單一成分，也不能建立預算—表現曲線。官方表格還橫跨多種 protocol：例如 Terminal-Bench 3.0 報 avg@3，CyberGym 是 single-run Pass@1，PostTrainBench 則是三次 weighted average；只有無法產生分數的 run，才回填官方 zero-shot base-model baseline。各列可按自己的規則閱讀，整張表不宜合成一場統一設定的跨模型競賽。
官方發布文把權重釋出排在 launch 後兩週，並以完成安全評估與強化為前提。本文聚焦跨模型的判讀框架；如果你要把 GLM-5.3 接進開發工具，可另讀GLM-5.3 串接 Claude Code／OpenCode 教學。
設計十題 diagnostic mini-eval，驗證選模敘事
十題不能證明一個模型「全面更強」，但能替你淘汰不合工作流的候選。這裡的 fixture，是固定不變的測試題、輸入檔、初始環境與標準答案。先用另外的 pilot 題調整 prompt／harness，再把正式十題封存；看到結果後不能回頭改 rubric（驗收規則）。若要把方法擴成持續回歸，可接著讀AI Evals 七步教學。
請分成兩條賽道：共同外部預算賽道固定同一題、prompt、工具權限、金額上限、wall time（從開始到結束的總時間）與工具回合上限；它比較相同使用者約束，不宣稱底層 FLOPs 相等。原生系統賽道讓每個產品使用官方建議的 reasoning、prompt 與工具；它比較官方建議的產品組合，不是隔離 base model。兩條結果分開，不能合成一個模型排名。
步驟 1：先做十題 fixture，再開模型
- 文件取證：答案只存在你提供的五頁文件；驗收結論、頁碼與引用句是否一致。
- 版本衝突：把多版政策文件中的現行規則整理成 JSON；用 fact ID、版本日與 schema 自動驗收。
- 帳本對帳：提供重複、沖銷與匯率四捨五入事件；以 Decimal 精確總額與 JSON schema 驗收。
- 限制排程：依固定 seed 產生人員與時間限制；用 oracle 最佳解與 constraint checker 驗收。
- Python 修 bug：從乾淨 commit 修正跨檔 cache／邊界錯誤；用 public＋hidden pytest 驗收。
- TypeScript 重構：完成跨檔 schema migration，但不可改外部 API；用 typecheck、lint、unit test 驗收。
- 離線 API 遷移：只提供新舊版 bundled docs 與舊程式；用隔離的 integration test 驗收。
- 有狀態工具任務：透過 mock 訂單 API 完成取消／退款；以最終資料庫狀態、必要澄清與禁做操作 log 驗收。
- 故障恢復：在 container 首次 restart 時注入一次 deterministic failure；驗收服務健康、狀態保存與是否能續跑。
- 長任務跨 repo：依序改 API、CLI 與 migration，途中提供一個會失敗的 checkpoint；以 hidden end-to-end test 與恢復紀錄驗收。
步驟 2：凍結容易偷換的條件
每一批都保存模型 ID／revision（固定版本）與日期、system prompt、harness（把模型接到工具與任務的執行層）版本、工具 schema（參數格式）、fixture commit、context 與最大輸出、temperature／sampling、reasoning effort、timeout、retry、價格快照、cache（重用舊結果）規則與執行順序。這和Coding Agent 公平比較協議的核心相同：先鎖住可觀察邊界，才較能判斷差異來源；仍不能完全歸因。
正式題先封存 SHA-256 manifest，run 順序隨機或交錯；cold-cache 與 warm-cache 分成不同批次。每次都記實際 billed usage，而不是只記設定上限，並把模型失敗、工具失敗、rate limit、timeout 與評分器失敗分開。自由文字若非得人工判讀，先匿名模型身分並保存 judge／rubric 版本；能用 deterministic test 就不要用印象打分。
步驟 3：四張成績單分開看
- 能力：acceptance test 通過數、引用正確率、盲評 rubric；不要把 pass@k coverage 誤叫單次可靠度。
- 成本：輸入／輸出／reasoning token、工具呼叫與每個成功任務成本。
- 速度：首 token 延遲、總 wall time；本機再記錄 tokens/s。
- 穩定度：失敗類型、重試、重複輸出、人工介入與長任務是否中斷。
每題重跑三次，只把結果原樣寫成 0/3 到 3/3，用來篩出明顯不穩；它不是穩定成功率或統計保證。碰到價格、token 或速度缺值要記 null，不能寫成 0。最後只比較你的工作分布，不把十題結果外推成全民排行榜。本文的所有結果欄位維持空白，等你實際跑完再填。
本機與 API 使用者，該怎麼選模型？
你跑本機：先過「放得下、跑得動、等得起」三關
先用總參數、精度與量化粗估權重容量，再用實機量測常駐權重、目標 context 的 KV cache、activations 與 runtime workspace 峰值。接著才看 active 計算、記憶體頻寬與實際 tokens/s，判斷跑得多快。模型下載得下來不代表互動速度可接受；active parameters 也不能代替 VRAM 實測。想看一個本機案例，可參考27B 模型完成 80 次工具呼叫的紀錄，但不要把單次軌跡當通則。
你用 API：把「每次呼叫價格」改成「每個成功任務成本」
對 API 選型，參數規格即使存在，也不能直接換算成帳單與成功率。請記錄實際 billed usage、reasoning、工具回合、失敗重試與人工收尾，用同一組十題計算 模型與工具實付金額 ÷ 成功任務數；若成功數為 0，就記為未定義／∞，人力成本則另外估值。再和 wall time、介入次數並排看。便宜但常失敗的模型，可能比單價較高、一次完成的模型更貴。
四個常見誤判
- 只按總參數買：你忽略了資料、稀疏路由、後訓練與推論預算。
- 把 active 當記憶體：active 描述每 token 動用的部分，不是完整部署需求。
- 把廠商榜當同場賽：模型版本、prompt、工具、reasoning、rollout 與評分器不同，就不能直接比較。
- 把一次升級叫 law：before／after 能提出假設；多預算 sweep、曲線擬合與 held-out 外推能支持有範圍的可預測關係，要廣泛概括仍需跨模型與任務驗證。
Post-training Scaling Law 常見問題 FAQ
1. 參數越大，模型一定越強嗎？
不一定。在資料、訓練、架構、推論預算與評測較可比時，參數效果才較容易解讀；跨模型只能把它當粗略訊號，不能單押。
2. Post-training Scaling Law 已經是公認定律嗎？
本文引用的證據是兩條定義與範圍不同的條件曲線。ScaleRL 在固定 recipe 下得到會飽和的 sigmoid；另一項 Qwen2.5 數學 RL 研究則用近似 power-law 描述 loss。兩者使用不同模型、橫軸與縱軸。
3. GLM-5.3 證明後訓練比預訓練重要嗎？
不能由這個案例單獨推出。官方發布文呈現的是 5.2→5.3 的後訓練 before／after；這份公開證據本身不支持「後訓練比預訓練更重要」。
4. Active parameters 可以拿來估 VRAM 嗎？
它只描述每個 token 啟用的部分。VRAM 容量還要看總權重、精度／量化、常駐／offload 方式、KV cache、activations 與 runtime workspace；速度才另外看記憶體頻寬。最終以目標 context 的實機峰值為準。
5. Effective depth 是公開規格嗎？
不要把它當成可跨產品直接排序的單一欄位。本文兩項研究分別指功能上使用的層與重複計算深度；推理步數則另外記錄，先看作者如何定義與量測。
6. Reasoning effort 開最大就最好嗎？
要看你自己的任務。在 Snell 的 PaLM 2／MATH 設定裡，更多計算與同一策略並非一律最佳；商用產品的 reasoning 控制與工具流程，仍須用自己的 fixture 比較成功任務成本。
7. 十題 Eval 能決定最佳模型嗎？
它的用途是初選。它應該暴露明顯失敗與成本差異；正式採購前，還要擴充成你的真實任務分布並持續回歸測試。
8. 新模型發布時，我第一個該看什麼？
先看評測設定，不是最大分數。確認模型版本、工具、reasoning、context、rollout、成本與 timeout，再判斷它是否回答你的工作問題。
給新手的 5 個重點
- 參數量仍有用，但只是一個旋鈕。
- total、active 與 effective depth 描述不同東西。
- 後訓練能改變行為；單一升級不等於通用 scaling law。
- 推論時計算要連同成本、速度與成功率一起算。
- 固定條件下、貼近自己任務的可重跑 Eval，是一項直接且實用的選型證據。
想把這套判讀方式延伸到更多工具，可以逛 AlphaLab AI 專區；想建立完整的 AI 工作流，則可查看 AlphaLab 線上課程。
接著閱讀
左右滑動查看更多推薦
結語：別問哪個數字最大，問四個旋鈕怎麼一起工作
你量到的系統表現，是預訓練資料與算力、底座架構與權重、後訓練配方、推論系統與預算共同作用的結果。GLM-5.3 把第三個旋鈕推到檯面上；判讀它時，另外三個層次仍要一起保留。
下次看到「參數量已死」或「某模型跑分第一」，先把宣傳拆回四個旋鈕，再用十題 fixture 跑自己的共同外部預算賽道。你要買的不是一個最大的數字，而是在可接受成本與等待時間內，穩定完成真實任務的系統。