GLM 5.2：コストを決めるのは reasoning effort だ

GLM 5.2 が Synthorai に登場した。トークン単価はフロンティアモデルのおよそ 6 分の 1 で、オープンウェイトかつフロンティア級ベンチマークという触れ込みも誇張ではない。ただ、トークン単価を判断の基準にするのは間違っている。GLM 5.2 でコーディングタスクを実行したときの実コストは、reasoning effort というたった一つのつまみ次第で 1 桁以上も変動する。しかも、そのつまみはデフォルトだと最悪の位置に置かれたままなのだ。うまく設定すれば、GLM 5.2 は簡単なタスクでも難しいタスクでも、正しい答えをフロンティアモデルより安く出す。デフォルトのまま放置すれば、同じ答えを得るのに 20 倍のコストがかかり、数分待たされる。実際に計測した結果がこれだ。

GLM 5.2 とは何か

GLM 5.2 は Zhipu のオープンウェイトのフロンティアモデルで、2026-06-13 にリリースされた。mixture-of-experts 構成（総パラメータ約 744B、アクティブ約 40B）で、実用的な 1M トークンのコンテキストを持ち、MIT ライセンスなのでセルフホストもできる。狙いはコーディングとエージェント的なタスクで、公開ベンチマークの数字も強い（SWE-bench Pro 62.1、Terminal-Bench 2.1 81.0、AIME 2026 99.2、GPQA Diamond 91.2）。Synthorai 上では glm-5.2 というモデル名で、料金は input が 100 万トークンあたり $1.40、output が $4.40 だ。

以下のすべてを左右する要点はこれだ。GLM 5.2 は reasoning モデルであり、どれだけ reasoning させるかは自分で設定する。

価格帯における位置

トークン単価で見ると、GLM 5.2 は欧米のフロンティアモデルよりかなり安く、中国系モデルの中では安い側に入る。代表的なモデルについて Synthorai の料金を並べると次のようになる。

output の $4.40 は gpt-5.5 の約 7 分の 1、claude-opus-4-8 の約 6 分の 1 だが、deepseek-v4-pro と kimi-k2.5 はさらに安い。つまり GLM 5.2 は、フロンティア級の性能をおおむね中国系モデルの価格で提供するもので、最安というわけではない。cache write に別料金はなく、cache write は input レートで課金され、割引が効くのは cache read だけで上の表のレートになる。割引率はベンダーによって異なり、GLM 5.2 の cache read は input レートの約 5 分の 1、フロンティアモデル（gpt-5.5、claude-opus-4-8、gemini-3.1-pro）は read を約 10 分の 1 まで割り引く。

自社の旧モデルと比べても一段上がっている。一世代前の GLM は非常に安かったが、GLM 5 系で値上げされ、GLM 5.2 の input レートは GLM-4.6 の約 3 倍に着地した（Zhipu の公式レート）。

この価格で 1M コンテキストとフロンティア級ベンチマークが手に入る。とはいえ、トークン単価はあくまで見出しにすぎない。タスクあたりに実際に支払う額を決めるのは reasoning effort だ。

reasoning effort というダイヤル

GLM 5.2 の reasoning はスイッチではなくダイヤルだ。オフにする（enable_thinking: false）こともできるし、reasoning_effort を low / medium / high に設定することもできる。あるいはデフォルトのまま放置すると、reasoning は無制限で動く。この設定はコストとレイテンシを、価格差よりはるかに大きく動かす。簡単なコーディングタスクと難しいコーディングタスクを 1 つずつ、各設定で実行し、ランダム化した数百のケースについてすべての答えをリファレンスと突き合わせて検証した。

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

重み付き区間スケジューリング、中程度の難易度の動的計画法の問題：

ここで目立つ点が 2 つある。まず、thinking off は正解を出せているうえに、この表のなかで最も安く、フロンティアモデルのおよそ 8 分の 1 で済んでいる。ダイヤルを上げても、同じ答えに対してコストが乗っていくだけだ。そして、課金されているのは答えではなく推論のほうである。GLM が返すコードは毎回およそ 150 トークンだが、その手前の推論は 0 から約 6,300 まで膨らみ、いずれも同じ $4.40/M の出力レートで課金される。上限なしのデフォルトは、thinking off が推論ゼロで出したのと同じ答えにたどり着くためにその推論を消費しており、その差分がコスト差のすべてだ。一方フロンティアモデルは、報告される推論がほとんど、あるいはまったくない状態でここを解いている。gpt-5.5 は推論トークンを 59 使い、claude-opus-4-8 の usage では推論ゼロと報告されている。

難しいタスク：ここでは reasoning が効く、デフォルトはダメ

ワイルドカードの文字列マッチング（? と *）。地味に間違えやすい古典的な問題だ。ここでは thinking off は通らなかった。返ってきたのはメモ化付きの再帰だ。

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)

一見正しそうだし、メモ化からはそれなりの配慮も感じられる。だが * の分岐で match(i + 1, j) を呼ぶときに i の上限を見ていない。文字列を使い切ってもパターンに * が残っていると、i がどこまでも増え続けてスタックオーバーフローになる。速くて安い、しかし間違いだ。

ダイヤルを上げると、正しい反復版の 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 は $0.0031、13 秒で解いている。同じ答えを出すのに、unbounded default と比べてコストで約 20 倍安く、約 30 倍速い。しかもコストではフロンティアモデルを下回り、数秒遅いだけだ。知っておくと役立つ妙な点がひとつ。GLM の low は high よりも多くの reasoning を生成し、しかも両タスクで一貫してそうなった。つまり名前は token 数と対応していない。安くて速かったのは medium と high のほうだ。

避けるべき設定は unbounded default ただひとつ。これは両方の悪いところ取りで、タスクに不要かもしれない reasoning に金を払い、しかもそれに数分かける。たどり着く答えは reasoning_effort: high と同じなのに、コストは 20 倍だ。

判断ルール

レバーは reasoning の effort であり、適切な設定はモデルではなくタスクに紐づく。

• 単純、もしくは大量に回す処理で正しさを担保しやすいもの：thinking off（enable_thinking: false）。正しく、かつフロンティアの約 8 分の 1 のコストで済む。
• 難しい問題で thinking off が落ちるもの：reasoning_effort: medium か high。正しく、1 タスクあたり $0.003 前後。コストはフロンティアを下回り、遅れは数秒だけだ。
• unbounded default は絶対に使わない。 effort の上限を設けずに reasoning をオンのままにすると、$0.003 で済む答えが $0.06・7 分のものに化ける。

そのタスクに reasoning が必要かどうか事前に判断できないなら、reasoning_effort: high が無難なデフォルトだ。安く、両方のタスクを解き、暴走することもなかった。

キャッシュが効くのは入力であって、推論ではない

GLM 5.2 はゲートウェイ上でキャッシュに対応していて、効く場所は想像どおりだ。1,494 token の共通プレフィックス（レビュー対象のコードモジュール）を、いくつか異なる質問とともに送ってみた。

大きなプレフィックスは一度通れば、以降はキャッシュされる。キャッシュされた入力 token は通常の入力レートのおよそ 5 分の 1 で課金され、内容が同じリクエストのコストを $0.0026 から $0.0009、つまり約 64% 削減できた。完全な繰り返しはセマンティックキャッシュから直接返る。コストはキャッシュありの呼び出しと同じで答えも同じだが、5 秒ではなく 1 秒ほどで返ってくる。

落とし穴は、ダイヤルの話で見たのと同じだ。キャッシュが割り引くのは入力で、推論をオンにした瞬間、コストとレイテンシはキャッシュされない推論出力側に乗る。だからキャッシュが本当に効くのは、思考オフで高コンテキストな処理（毎回同じシステムプロンプトやコードベースを送るケース）であり、推論をオンにすると効果はわずかになる。

Synthorai での使い方

glm-5.2 はゲートウェイで利用可能だ。検証から得た実用的なポイントを 3 つ挙げておく。

• reasoning effort を明示的に設定する。 単純な処理には enable_thinking: false、難しい問題には reasoning_effort: medium または high を使う。避けたいのはただ一つ、effort の上限を設けずに推論をオンのままにすること（上限なしのデフォルト）だ。これが $0.06・7 分の罠になる。
• 推論をオンにするときは streaming を使う。 推論レスポンスは数分かかることがある。非ストリーミングのリクエストは無言の接続をそのまま保持し続けるので、答えが届く前にクライアントがタイムアウトする可能性が高い。stream: true を使えば、出力が逐次返ってくるうえ、最終結果も得られる。
• コンテキストを使い回す。 毎回同じ大きなシステムプロンプトやコードベースを送るなら、プレフィックスキャッシュで入力コストが下がる。思考オフと組み合わせれば、リクエスト全体が安くなる。

価格は 100 万 token あたり $1.40 / $4.40 で、ゲートウェイは呼び出しごとに cost フィールドを返すので、各リクエストにいくらかかったかを正確に確認できる。

まとめ

GLM 5.2 は本当に安く、しかも能力の高いコーディングモデルだ。うまく設定すれば、簡単な処理でも難しい処理でもフロンティアモデルの価格を下回る。問題はその設定にある。推論はダイヤルであり、デフォルトでは上限なしのままになる。これが、本来 $0.003 で済むはずのタスクを $0.06・7 分の呼び出しに変えてしまう。単純な処理には enable_thinking: false、それ以外には reasoning_effort: medium または high を設定すれば、GLM 5.2 はどんな場面でも安く正確だ。逆に推論をデフォルトのままにすると、選べる中で最も遅く最も高い選択肢になってしまう。

ソース

• VentureBeat: Z.ai’s open-weight GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6 the cost
• eigent.ai: GLM-5.2 specs and overview
• CloudPrice: GLM-5.2 pricing and specs
• Z.ai: official GLM API pricing (GLM-4.5 / 4.6 / 5 generations)

（上記の Synthorai 掲載価格は 2026-06-24 時点の当プラットフォームのレート。GLM の世代別レートは Zhipu の公式リスト。）

コストは 2026-06-24 に Synthorai で計測（glm-5.2、100 万 token あたり $1.40 / $4.40）。利用前に現在の価格を確認すること。

← ブログに戻る