GLM-5 系モデルの読み方: 重みを落とす前に確認すべき4世代の差分

1つのリポジトリに4世代が同居している構成

zai-org/GLM-5 というリポジトリ名から単一モデルを想像すると、README の冒頭でまず面食らう。見出しは「GLM-5.3 & GLM-5.2 & GLM-5.1 & GLM-5」であり、4つの世代が同じツリーに置かれている。デフォルトブランチは main、ライセンス表記は Apache-2.0、最終 push は 2026-09-01 と記録されている。リリースは取得できておらず、タグやバージョン番号から特定の重みを引く手段は README からは読み取れない。

ここで最初に押さえるべきは、4世代が同じ設計の延長線上にあるわけではないという点だ。README によれば GLM-5.3 は GLM-5.2 と同一の基盤モデルを使い、差分はポストトレーニングのみで生み出されている。一方 GLM-5.3-Flash は新規に学習した基盤モデルから出発し、アーキテクチャと学習レシピを能力と効率の両面から再設計したと説明されている。つまり同じ 5.3 という番号の中に、基盤を共有する派生と、基盤から作り直した派生が並んでいる。採用検討の出発点は、ベンチマークの数値ではなくこの系譜の把握になる。

GLM-5 が解こうとしている問題: 長い horizon で息切れしないこと

README が繰り返し使う語は long-horizon、つまり長時間・多段階のタスクである。GLM-5 の説明では「complex systems engineering and long-horizon agentic tasks」を対象と明記され、GLM-5.1 の節では先行モデルの失敗が具体的に言語化されている。以前のモデルは「exhaust their repertoire early」、つまり早い段階で手持ちの手札を使い切り、その後は時間を与えても改善しないという。

GLM-5.1 はこの plateau を越えることを狙って作られ、曖昧な問題に対して判断を保ち、長時間のセッションでも生産性を維持すると README は述べる。問題を分解し、実験を走らせ、結果を読み、詰まりを特定する。推論を見直して戦略を更新する反復を通じて、数百ラウンド・数千回のツール呼び出しにわたって最適化を続けるという記述がある。

ここは評価が分かれる箇所だ。この主張は README 内の自己申告であり、独立した再現結果は提示されていない。長時間稼働の品質は、モデル単体ではなくハーネス、ツール定義、コンテキスト管理の設計に強く依存する。README が示すのは方向性であって、手元のエージェント基盤で同じ持続性が出る保証ではない。

IndexShare と mHC: 長文脈のコストをどこで削っているか

GLM-5.2 の節には、アーキテクチャ側の具体的な変更が2つ書かれている。1つは IndexShare で、4つの sparse attention 層ごとに同一の indexer を再利用する。これにより 1M コンテキスト長でのトークンあたり FLOPs を 2.9 倍削減すると README は述べ、arXiv の論文リンクを添えている。もう1つは MTP 層の改善で、投機的デコードの acceptance length を最大 20% 伸ばすとされている。

GLM-5.3-Flash 側では別の手段が取られている。GLM シリーズで初めて sparse attention と linear attention を組み合わせたハイブリッド構成を導入し、長文脈のサービングコストを大きく下げつつ長文脈の精度を保つと説明されている。加えて Manifold-Constrained Hyper-Connections (mHC) を採用してスケーリング効率を改善し、30T トークンのマルチモーダル事前学習コーパスと組み合わせている。

注目したいのは、GLM-5 の時点で DeepSeek Sparse Attention (DSA) を取り込み、配備コストを下げつつ長文脈容量を保つと書かれていることだ。つまり世代を追うごとに、長文脈の扱い方は DSA、IndexShare、sparse と linear のハイブリッドへと置き換わっていく。同じ 1M コンテキストという看板を掲げていても、内部の機構は世代ごとに別物である。推論エンジン側の対応を確認するときは、この違いを前提にしたほうがよい。

ベンチマークの読み方: 社内評価と公開評価を分ける

README に並ぶ数値は、出自によって信頼度が異なる。GLM-5.3 の「50% improvement over GLM-5.2」は Z.ai Code Bench という社内評価での比較であり、外部の第三者が同じ条件で再現できるものではない。同じ節で Terminal Bench 3.0 と Agents' Last Exam における open-source SOTA にも触れているが、こちらも README の主張として読むのが妥当だ。

相対比較として読みやすいのは GLM-5.2 の節である。Terminal-Bench 2.1 で 81.0 対 62.0、SWE-bench Pro で 62.1 対 58.4 と、GLM-5.1 からの改善幅が具体的に示されている。同時に Claude Opus 4.8 の 85.0 という数値も併記され、数ポイント差に迫りつつ Gemini 3.1 Pro を上回ると説明されている。閉源モデルとの比較数値を自ら併記している点は、差分を読むうえでは助けになる。

GLM-5 の節では CC-Bench-V2 という社内評価スイートの名前が出てくる。Vending Bench 2 については、1年間の模擬自動販売機事業を走らせて最終残高 $4,432 で終えたと記され、open-source モデル中 1 位と主張されている。ただしこれは README の記述であり、実行ログや設定は示されていない。数値を採用判断の根拠にするなら、自前のタスクで同じ指標を回す以外に確かめる方法はない。

導入時に読むべきファイルと、確認できない部分

この README はモデルカードとして書かれており、pip install や docker run の類の手順は含まれていない。取得経路として README が示すのは、Z.ai API Platform のドキュメント（docs.z.ai/guides/llm/glm-5.3）と、z.ai 上での試用、そして Download Model と題された表である。表の列は Model、Download Links、Model Size、Precision の4つで、行ごとに重みの配布先が入る形式になっている。

したがって導入手順は、API 経由で使うか、表のリンクから重みを取得して自前の推論基盤に載せるかの二択になる。後者を選ぶ場合、実際に読むべきファイルはリポジトリ直下の LICENSE と、重みに付随する条件の記述である。ライセンス表記は Apache-2.0 とされているが、この表記がコード部分を指すのか重みの配布まで覆うのかは、与えられた情報からは判別できない。ここは推測せず、取得先のファイルで直接確認するしかない。

同様に確認できないものとして、リリース一覧、量子化済み重みの有無、推論エンジン側の対応バージョンがある。README には量子化に関する記述も、対応エンジンの一覧も見当たらない。744B パラメータ（40B active）という規模を自前で動かすなら、この3点は導入前に潰しておく必要がある。

slime という前提: 学習側のインフラが別リポジトリにある

GLM-5 の節で異色なのは、モデル本体ではなく学習インフラの説明に紙幅が割かれている点だ。README は「RL training inefficiency」を課題として挙げ、これを解決するために slime という非同期 RL インフラを開発したと述べ、github.com/THUDM/slime へリンクしている。事前学習データは GLM-4.5 の 23T から 28.5T トークンへ、パラメータは 355B（32B active）から 744B（40B active）へ拡大したと記されている。

これは利用者にとって両義的である。推論だけを行う立場なら slime は関係なく、重みとサービング環境があれば足りる。しかし自前でファインチューニングやポストトレーニングを行いたい立場では、この非同期 RL 基盤が事実上の前提になる。README がポストトレーニングの反復粒度を上げたことを能力向上の主要因として繰り返し挙げている以上、その再現には slime 側の理解が要る。

モデルカードとしては、この点はもう少し分けて書かれていてもよかった。推論利用者と学習利用者では必要な情報がまったく違うのに、Introduction の中で両者が同じ密度で混ざっている。読み手は自分がどちら側かを先に決めてから、該当する節だけを追うほうが早い。

比較対象としての閉源フロンティアモデル: 差分はどこにあるか

現実的な代替は、Claude Opus 4.8 や Gemini 3.1 Pro といった閉源のフロンティアモデルを API で叩く選択である。アプローチの違いは明快だ。閉源側は重みが手元に来ない代わりに、配備・スケーリング・更新をベンダーが引き受ける。GLM-5 系は重みが配布される代わりに、サービング基盤、量子化、長文脈のメモリ設計を自分で用意する。

README 自身がこの差を数値で示している。Terminal-Bench 2.1 で GLM-5.2 は 81.0、Claude Opus 4.8 は 85.0。数ポイントの差は残るが、同じ土俵で比較できる数字が出ていること自体が、以前の世代との違いである。GLM-5 の節でも Claude Opus 4.5 との差が縮まったと述べられている。

判断を分けるのは性能差よりも、データを外に出せるかどうかと、推論コストを固定化できるかどうかになる。閉源 API は従量課金で、長文脈を大量に流すと費用が読みにくい。自前配備は初期の計算資源と運用要員を要求するが、単価は自分で制御できる。1M コンテキストを常用するワークロードでは、この差が性能差を上回ることがある。

世代選択の実務: 5.2 と 5.3 のどちらを落とすか

4世代が並んでいると、最新を選べばよいという結論になりがちだが、README の記述はそう単純ではない。GLM-5.3 は GLM-5.2 と基盤を共有し、差分はポストトレーニングのみと明記されている。つまり推論時のメモリ特性やコンテキスト処理の挙動は 5.2 と近く、変わるのは出力の質である。既に 5.2 を動かしている環境なら、重みを差し替えるだけで比較検証ができる可能性がある。

一方 GLM-5.3-Flash は基盤から作り直されており、sparse と linear のハイブリッドという別のアーキテクチャを取る。長文脈のサービングコストを下げる方向に振ってあるため、同じ比較は成立しない。Flash という名前から軽量版と想像すると外れる可能性がある。README は能力と効率の両面で再設計したと述べており、単純な縮小版として扱う記述にはなっていない。

選定の順序としては、まず長文脈の常用有無で Flash 系を検討するかどうかを切り、常用しないなら 5.2 と 5.3 を同一基盤の出力差として比較する。5.1 は 1M コンテキストの記述が 5.2 側にしかないため、長文脈が要件なら候補から外れる。この切り分けは README の記述だけで行える。

編集部の結論

採用を検討すべきなのは、Terminal-Bench や SWE-bench 系のエージェント型コーディングを自前の推論基盤で回したいチームと、1M トークン級の長文脈を継続的に扱う必要があるチームである。逆に、単発のチャット用途や短いコンテキストの要約タスクが中心なら、744B パラメータ級の重みを抱える理由は薄い。最初に確認すべきは、リポジトリ直下の LICENSE が重みの配布にまで及ぶのか、それともコード部分のみを覆うのかという点である。次に、利用したい世代がどの基盤モデルを共有しているかを README の Introduction で突き合わせ、量子化や推論エンジン側の対応状況を確認する。この2点が埋まらない限り、ベンチマークの数値だけを見て配備を決めるのは早い。

公式情報源

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. zai-org/GLM-5 on GitHub