GLM 5.2 Reasoning Effort：實測只要設對，成本就能降到 1/20

GLM 5.2 現已在 Synthorai 上線，每 token 價格約為前沿模型的六分之一，而且「開放權重、效能達前沿水準」並非誇大。不過，只看每 token 價格會抓錯重點。GLM 5.2 執行程式任務的實際成本，會因單一設定，也就是 reasoning effort，而相差超過一個數量級，偏偏預設值又是最差的選擇。設定得當時，GLM 5.2 不論面對簡單或困難任務，都能答對，而且比前沿模型便宜。維持預設值時，同一份答案的成本會高出 20 倍，還要等上好幾分鐘。我們實際測過了。

TL;DR

• Synthorai 上的 GLM 5.2 定價為輸入 $1.40/M、輸出 $4.40/M，輸出費率約為 claude-opus-4-8 的六分之一。
• 在簡單的程式任務中，GLM 5.2 關閉 thinking 後，5 秒內完成，成本為 $0.0008；不設上限的預設值產生相同答案，卻花了 $0.0285 和 137 秒。
• 在困難任務中，reasoning_effort: high 能正確作答，成本為 $0.0031，耗時 13 秒。和不設上限的預設值（$0.062、405 秒）相比，便宜約 20 倍、速度快約 30 倍。
• 兩項任務中，GLM 的 low 都比 high 產生更多 reasoning token：effort 名稱與 token 數量並不一致。

GLM 5.2 是什麼

GLM 5.2 是 Zhipu 於 2026-06-13 發布的開放權重前沿模型。它採用專家混合網路（總參數約 744B、啟用參數約 40B），提供可實際使用的 1M-token context，並採 MIT 授權，可自行託管。這個模型主打程式開發與代理型工作，官方公布的 benchmark 表現很強（SWE-bench Pro 62.1、Terminal-Bench 2.1 81.0、AIME 2026 99.2、GPQA Diamond 91.2）。在 Synthorai 上，模型 ID 為 glm-5.2，每百萬輸入 token 收費 $1.40，每百萬輸出 token 收費 $4.40。

以下所有結果都取決於一個特性：它是 reasoning 模型，而推理量由使用者決定。

價格定位

以每 token 定價來看，GLM 5.2 明顯低於西方前沿模型，在中國模型中也屬於較便宜的一群。以下是 Synthorai 上幾個代表性模型的費率：

它的輸出費率為 $4.40，約是 gpt-5.5 的七分之一、claude-opus-4-8 的六分之一，不過 deepseek-v4-pro 和 kimi-k2.5 仍更便宜。因此，GLM 5.2 提供的是約等於中國模型價位的前沿級能力，而不是市場最低價。它沒有另外收取快取寫入費用：寫入快取按輸入費率計費，只有讀取快取時才會依上表的費率折扣。各供應商的折扣不同。GLM 5.2 的快取讀取費率約為輸入費率的五分之一；前沿模型（gpt-5.5、claude-opus-4-8、gemini-3.1-pro）則約為十分之一。

和前幾代相比，它也有明顯提升。上一代 GLM 的價格低得驚人；GLM 5 系列調高了價格，而 GLM 5.2 的輸入費率約為 GLM-4.6 的 3 倍（依 Zhipu 官方費率）：

多付的費用換來了 1M context 和前沿級 benchmark 成績。不過，每 token 費率只是帳面價格。每項任務最後要付多少錢，取決於 reasoning effort。

reasoning effort 的調整方式

GLM 5.2 的 reasoning 不是單純的開關，而是一個可調整的設定。你可以將其關閉（enable_thinking: false），把 reasoning_effort 設為 low、medium 或 high，也可以維持預設值，讓 reasoning 不受上限控制。這項設定對成本和延遲的影響，遠大於模型定價本身。我們用一個簡單和一個困難的程式任務測試各種設定，並以數百組隨機案例將每個答案和參考實作比對。

簡單任務：reasoning 只會增加成本

加權區間排程，一道中等難度的動態規劃問題：

有兩點很明顯。第一，關閉 thinking 仍能正確作答，而且是表中最便宜的選項，成本約為前沿模型的八分之一。往上調高任何一級，都只是花更多錢取得相同答案。第二，帳單取決於 reasoning，而非答案本身：GLM 每次回傳的程式碼都約為 150 token，但前面的 reasoning 從 0 增加到約 6,300 token，而且同樣按 $4.40/M 的輸出費率計費。不設上限的預設值花了這些 reasoning，最後卻得到和關閉 thinking 相同的答案；兩者的成本差異完全來自這裡。前沿模型在這道題上幾乎沒有回報 reasoning：gpt-5.5 使用了 59 個 reasoning token，而 claude-opus-4-8 的用量報告中則是 0。

困難任務：reasoning 有用，但預設值不值得

萬用字元字串比對（? 和 *）是一道經典問題，實作時很容易出現不易察覺的錯誤。關閉 thinking 後，模型確實答錯了。它回傳了使用 memoization 的遞迴實作：

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

這段程式看起來沒問題，還用了 memo，似乎有仔細處理。但 * 分支呼叫 match(i + 1, j) 時，沒有對 i 設定邊界。字串耗盡後，只要 pattern 中仍有 *，i 就會無限增加，最終造成 stack overflow。速度快、成本低，但答案錯誤。

調高設定後，模型會回傳正確的迭代式雙指標演算法。它不使用遞迴，而是回溯到上一個 *：

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

這項任務在各設定下的完整結果如下：

所有明確指定的 effort 等級都能解出這道題。reasoning_effort: high 在 13 秒內完成，成本為 $0.0031。和相同答案的不設上限預設值相比，便宜約 20 倍、速度快約 30 倍；成本也低於前沿模型，只慢了幾秒。有個現象需要留意：GLM 的 low 產生的 reasoning 比 high 更多，而且兩項任務都是如此，因此名稱與 token 數量並不一致。Medium 和 high 才是成本低、速度快的設定。

唯一應避免的設定就是不設上限的預設值。它兩邊都不討好：花錢做任務可能根本不需要的 reasoning，還要耗費數分鐘，最後得到的答案和 reasoning_effort: high 一樣，成本卻高出 20 倍。

選擇原則

真正要調整的是 reasoning effort，而且應該依任務選擇設定，而不是固定綁在模型上：

• 簡單或大量執行的工作，而且容易驗證正確性：關閉 thinking（enable_thinking: false）。答案正確，成本約為前沿模型的八分之一。
• 較困難、關閉 thinking 會失敗的問題：使用 reasoning_effort: medium 或 high。能正確作答，每項任務約 $0.003，成本低於前沿模型，只慢幾秒。
• 絕對不要使用不設上限的預設值。 不限制 effort 就會讓原本 $0.003 的答案，變成 $0.06、耗時 7 分鐘的請求。

如果無法事先判斷任務是否需要 reasoning，reasoning_effort: high 是安全的預設選擇：成本低、兩項任務都能解出，而且沒有失控。

快取只能降低輸入成本，無法降低 reasoning 成本

GLM 5.2 支援閘道快取，效果也符合預期。我們傳送一段共用的 1,494-token 前綴（一個待審查的程式模組），並搭配數個不同問題：

大型前綴只要使用過一次，之後就會進入快取。快取輸入 token 的費率約為一般輸入的五分之一，因此其他條件完全相同的請求，成本會從 $0.0026 降到 $0.0009，約減少 64%。完全相同的重複請求會直接由語意快取回傳：答案和快取呼叫相同，成本也一樣，但回應時間從約 5 秒縮短到約 1 秒。

限制和 reasoning effort 測試揭示的問題相同：快取只會降低輸入成本。一旦開啟 reasoning，成本和延遲主要來自 reasoning 輸出，而這部分不會被快取。因此，對於關閉 thinking 且 context 很長的工作，例如每次呼叫都使用相同 system prompt 或程式碼庫，快取非常划算；開啟 reasoning 後，節省幅度就小得多。

在 Synthorai 上使用

glm-5.2 已在閘道上線。根據測試，有三點實務建議：

• 明確設定 reasoning effort。 簡單任務使用 enable_thinking: false，困難問題則使用 reasoning_effort: medium 或 high。唯一要避免的是開啟 reasoning 卻不限制 effort，也就是不設上限的預設值；這會掉進 $0.06、耗時 7 分鐘的陷阱。
• 開啟 reasoning 時使用串流。 Reasoning 回應可能持續數分鐘。非串流請求會讓連線長時間沒有任何資料，客戶端很可能在答案回來前就逾時。使用 stream: true 可持續收到增量輸出，最後也能取得完整結果。
• 重複使用 context。 如果每次呼叫都傳送相同的大型 system prompt 或程式碼庫，前綴快取可降低輸入成本；再配合關閉 thinking，整個請求都會非常便宜。

定價為每百萬 token 輸入 $1.40、輸出 $4.40，閘道會在每次呼叫中回傳 cost 欄位，方便確認每個請求的實際成本。

結論

GLM 5.2 確實是一款便宜且能力很強的程式模型。只要設定正確，無論簡單或困難任務，成本都低於前沿模型。問題在於設定方式。它的 reasoning 可調整，但預設值沒有上限，因此原本只需 $0.003 的任務，可能變成 $0.06、耗時 7 分鐘的呼叫。簡單工作使用 enable_thinking: false，其餘任務設為 reasoning_effort: medium 或 high，GLM 5.2 就能兼顧低成本與正確性。如果維持預設 reasoning，它反而會成為最慢、最貴的選項。

資料來源

• VentureBeat：Z.ai 的開放權重 GLM-5.2 在長時間程式任務中勝過 GPT-5.5，成本僅六分之一
• eigent.ai：GLM-5.2 規格與概覽
• CloudPrice：GLM-5.2 定價與規格
• Z.ai：GLM API 官方定價（GLM-4.5／4.6／5 世代）

本系列其他實測成本指南：七款 ASR 模型的音訊轉錄成本與圖片生成成本。

（以上 Synthorai 掛牌價格為此平台截至 2026-06-24 的費率；各代 GLM 費率採用 Zhipu 官方定價。）

成本於 2026-06-24 在 Synthorai 上實測（glm-5.2 每 M token 輸入 $1.40、輸出 $4.40）；實際使用前請確認最新價格。

← 返回部落格