GLM 5.2 の reasoning effort：設定次第でコストが 20 分の 1 に（実測）

GLM 5.2 が Synthorai で利用可能になった。token 単価は frontier モデルのおよそ 6 分の 1 で、open-weight ながら frontier 級のベンチマーク性能という評価も実態に沿っている。ただし、見るべき数字は token 単価ではない。GLM 5.2 でコーディングタスクを実行したときの実コストは、reasoning effort という 1 つの設定だけで 10 倍以上変わる。しかもデフォルトは最も不利な設定だ。適切に設定すれば、簡単なタスクでも難しいタスクでも正解でき、frontier モデルより安い。デフォルトのままでは、同じ回答に 20 倍のコストがかかり、完了まで数分を要する。以下は実測結果だ。

TL;DR

• Synthorai での GLM 5.2 の料金は、入力が $1.40/M、出力が $4.40/M。出力単価は claude-opus-4-8 のおよそ 6 分の 1。
• 簡単なコーディングタスクでは、thinking を無効にした GLM 5.2 が 5 秒、$0.0008 で正解した。上限なしのデフォルトでも答えは同じだったが、137 秒、$0.0285 かかった。
• 難しいタスクでは、reasoning_effort: high が 13 秒、$0.0031 で正解した。上限なしのデフォルト（405 秒、$0.062）と比べて、およそ 20 分の 1 のコストで 30 倍高速だった。
• どちらのタスクでも、GLM の low は high より多くの reasoning token を生成した。effort の名前と token 数は対応していない。

GLM 5.2 とは

GLM 5.2 は、Zhipu が 2026-06-13 にリリースした open-weight の frontier モデルだ。総パラメータ数は約 744B、稼働パラメータ数は約 40B の mixture-of-experts 構成で、実用的な 1M token のコンテキストを備える。MIT ライセンスで self-host も可能だ。コーディングと agentic な処理を主な用途とし、公表ベンチマークでも高いスコアを記録している（SWE-bench Pro 62.1、Terminal-Bench 2.1 81.0、AIME 2026 99.2、GPQA Diamond 91.2）。Synthorai では glm-5.2 として提供され、料金は入力 100 万 token あたり $1.40、出力 100 万 token あたり $4.40 だ。

以下の結果を左右するのは、GLM 5.2 が reasoning モデルであり、reasoning の量を設定できる点だ。

価格帯での位置付け

token 単価で見ると、GLM 5.2 は欧米の frontier モデルよりかなり安く、中国系モデルの中でも低価格帯に入る。代表的なモデルに対する Synthorai の料金は次のとおりだ。

出力単価の $4.40 は、gpt-5.5 のおよそ 7 分の 1、claude-opus-4-8 の 6 分の 1 だ。ただし、deepseek-v4-pro と kimi-k2.5 はさらに安い。つまり GLM 5.2 は、絶対的な最安モデルではなく、中国系モデルに近い価格で frontier 級の性能を提供するモデルだ。cache write に個別の料金はなく、書き込み時は通常の入力単価が適用される。割引対象になるのは cache read だけで、料金は上表のとおりだ。割引率はベンダーによって異なる。GLM 5.2 の cache read は入力単価のおよそ 5 分の 1、frontier モデル（gpt-5.5、claude-opus-4-8、gemini-3.1-pro）ではおよそ 10 分の 1 になる。

旧世代の GLM と比べても性能は上がっている。以前の GLM は非常に安価だったが、GLM 5 系で値上げされ、GLM 5.2 の入力単価は GLM-4.6 のおよそ 3 倍になった。以下は Zhipu の公式料金だ。

この値上げによって、1M のコンテキストと frontier 級のベンチマーク性能を得られる。ただし、token 単価は表面的な数字にすぎない。タスク単位の実コストは reasoning effort で決まる。

reasoning effort の調整

GLM 5.2 の reasoning は単純なオンとオフではなく、段階的に調整できる。無効化するには enable_thinking: false を指定する。reasoning_effort は low、medium、high から選べる。何も指定しないデフォルトでは、上限なしで reasoning が実行される。この設定がコストとレイテンシに与える影響は、単価差よりはるかに大きい。簡単なコーディングタスクと難しいコーディングタスクを各設定で実行し、数百件のランダムケースを使って、すべての回答をリファレンス実装と照合した。

簡単なタスク：reasoning はコストを増やすだけ

重み付き区間スケジューリングという、中程度の難易度の動的計画法問題を使った。

注目すべき点は 2 つある。まず、thinking 無効でも正解し、全候補の中で最安だった。frontier モデルのおよそ 8 分の 1 であり、effort を上げるほど同じ回答に余分なコストがかかった。次に、料金を決めるのは回答ではなく reasoning だ。GLM が返すコードは毎回およそ 150 token だが、その前段の reasoning は 0 から約 6,300 token まで増え、出力と同じ $4.40/M で課金される。上限なしのデフォルトは、thinking 無効で reasoning なしに得られたものと同じ答えに到達するまで、余分な reasoning を実行した。この差がそのままコスト差になっている。frontier モデルでは、報告される reasoning がほぼない状態で回答できた。gpt-5.5 は 59 reasoning token を使い、claude-opus-4-8 の usage には reasoning token が記録されなかった。

難しいタスク：reasoning は有効だが、デフォルトは不要

ワイルドカード文字列マッチング（? と *）を使った。わずかな実装ミスが入りやすい定番問題だ。このタスクでは thinking 無効の回答が壊れていた。返されたのは、次のメモ化再帰だった。

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)

一見すると正しく、メモ化もされているため、ある程度は検討された実装に見える。しかし * の分岐では、i に上限を設けず match(i + 1, j) を再帰呼び出ししている。文字列を消費し終えてもパターン側に * が残っていると、i が増え続けて stack overflow になる。高速で安いが、答えは間違っている。

effort を上げると、最後に現れた * まで backtrack する、正しい反復型の two-pointer アルゴリズムが返った。再帰は使っていない。

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 分の 1 のコストで、30 倍高速だった。frontier モデルより数秒遅いだけで、コストは下回っている。GLM 固有の挙動として、low は high より多くの reasoning を生成した。この傾向は両方のタスクで一貫しており、effort の名前と token 数は対応していない。安く高速だったのは medium と high だ。

避けるべき設定は、上限なしのデフォルトだ。タスクに不要かもしれない reasoning にコストをかけ、完了まで数分を要する。しかも最終的には、reasoning_effort: high が 20 分の 1 のコストで返したものと同じ答えに到達する。

設定の判断基準

調整すべきなのは reasoning effort であり、適切な値はモデルではなくタスクに応じて決める。

• 正しさを確認しやすい単純な処理や大量処理では、thinking を無効にする（enable_thinking: false）。正解でき、コストは frontier モデルのおよそ 8 分の 1。
• thinking 無効では失敗する難しい問題では、reasoning_effort: medium または high を使う。正解率を保ちながら、1 タスクあたり約 $0.003。frontier モデルより安く、遅延も数秒増えるだけだ。
• 上限なしのデフォルトは使わない。 effort に上限を設けず reasoning を有効にすると、$0.003 で済む回答が $0.06、7 分の処理になる。

事前に reasoning の要否を判断できない場合は、reasoning_effort: high が安全なデフォルトになる。両方のタスクを解けて、コストも低く、reasoning が制御不能に増えることもなかった。

caching が効くのは入力であり、reasoning ではない

GLM 5.2 は gateway 上の caching に対応しており、想定どおりの箇所で効果がある。1,494 token の共通 prefix（レビュー対象のコードモジュール）に対して、複数の異なる質問を送った。

大きな prefix は、一度処理されると cache される。cache 済みの入力 token は通常の入力単価のおよそ 5 分の 1 で課金されるため、それ以外は同一のリクエストが $0.0026 から $0.0009 に下がった。約 64% の削減だ。完全に同じリクエストは semantic cache から直接返される。コストと回答は cache 済みの呼び出しと同じだが、所要時間は約 5 秒から約 1 秒に短縮された。

ただし、reasoning effort と同じ注意点がある。caching で割引されるのは入力だ。reasoning を有効にすると、コストとレイテンシの中心は cache されない reasoning 出力に移る。そのため caching の効果が大きいのは、thinking を無効にしつつ、毎回同じ system prompt やコードベースなどの長いコンテキストを送る処理だ。reasoning が有効な場合、効果は小さくなる。

Synthorai での使い方

glm-5.2 は gateway ですでに利用できる。テストから得られた実用上のポイントは 3 つある。

• reasoning effort を明示する。 単純な処理では enable_thinking: false、難しい問題では reasoning_effort: medium または high を使う。避けるべきなのは、effort に上限を設けず reasoning を有効にすることだ。上限なしのデフォルトでは、$0.06、7 分の処理になり得る。
• reasoning を有効にするなら streaming を使う。 reasoning の応答には数分かかる場合がある。非 streaming リクエストでは、接続上に何も流れない時間が長くなり、回答が返る前にクライアント側で timeout する可能性が高い。stream: true を使えば、出力を逐次受信しながら最終結果まで取得できる。
• コンテキストを再利用する。 毎回同じ大きな system prompt やコードベースを送る場合、prefix caching で入力コストを削減できる。thinking 無効と組み合わせれば、リクエスト全体を安価に処理できる。

料金は 100 万 token あたり入力 $1.40、出力 $4.40。gateway は呼び出しごとに cost field を返すため、各リクエストの実コストを正確に確認できる。

結論

GLM 5.2 は、低価格で高性能なコーディングモデルだ。適切に設定すれば、簡単な処理でも難しい処理でも frontier モデルより安い。問題は設定にある。reasoning は調整式だが、デフォルトでは上限がない。そのため、本来 $0.003 で済むタスクが $0.06、7 分の呼び出しになる。単純な処理では enable_thinking: false、それ以外では reasoning_effort: medium または high を使えば、GLM 5.2 は一貫して安く、正しい回答を返す。デフォルトのまま reasoning を使うと、選択肢の中で最も遅く、最も高価になる。

出典

• VentureBeat：Z.ai の open-weight モデル GLM-5.2 が長時間コーディングで GPT-5.5 を上回り、コストは 6 分の 1
• eigent.ai：GLM-5.2 の仕様と概要
• CloudPrice：GLM-5.2 の料金と仕様
• Z.ai：GLM API の公式料金（GLM-4.5／4.6／5 世代）

このシリーズの実測コストガイド：7 種類の ASR モデルにおける音声文字起こしのコストと画像生成のコスト。

（上記の Synthorai 掲載料金は 2026-06-24 時点の本プラットフォームの料金。GLM 各世代の料金は Zhipu の公式価格に基づく。）

コストは 2026-06-24 に Synthorai で計測（glm-5.2、100 万 token あたり入力 $1.40、出力 $4.40）。利用時には最新料金を確認すること。

← ブログに戻る