GLM-4.5: エージェント性・推論・コーディング(ARC)基盤モデル
(arxiv.org)- GLM-4.5は、オープンソースの Mixture-of-Experts(MoE)大規模言語モデルで、エージェント性、推論、コーディング性能に優れている
- このモデルは、23Tトークンによる多段階学習、専門家モデルの反復、強化学習を通じて発展した
- TAU-Bench、AIME 24、SWE-bench Verified などの主要ベンチマークで 上位の成績 を記録した
- 少ないパラメータ数でも効率的な性能を発揮し、主要な商用モデルに 迫る、または上回る
- GLM-4.5 と小型版の GLM-4.5-Air が公開され、研究や AI システム開発に活用できる
概要
- GLM-4.5は、総パラメータ数3550億、アクティブパラメータ数320億を持つオープンソースの Mixture-of-Experts(MoE)大規模言語モデルである
- ハイブリッド推論方式を採用し、深い思考を行う Thinking モードと即時応答の Direct Response モードの両方をサポートする
- 23兆トークンを用いた多段階学習、専門家モデルの反復、そして強化学習ベースのポストトレーニングを経ている
- その結果、エージェント性(Agentic)、推論(Reasoning)、コーディング(Coding・ARC)の各タスク領域で高い成績を達成した
- TAU-Bench 70.1%、AIME 24 91.0%、SWE-bench Verified 64.2% を記録
- GLM-4.5 は競合モデルより少ないパラメータ数で、総合モデルランキング3位、エージェントベンチマーク基準で2位を獲得した
- 大規模モデルの GLM-4.5(3550億パラメータ)と、小型化した GLM-4.5-Air(1060億パラメータ)の2バージョンをともに公開した
- コード、モデル、詳細情報は公式 GitHub(https://github.com/zai-org/GLM-4.5)で確認できる
LLM 性能評価:エージェント性・推論・コーディングのベンチマーク
- GLM-4.5 およびグローバル主要モデルを、12種類の代表的ベンチマーク(MMLU-Pro、AIME 24、SWE-Bench Verified など)でテストした
- GLM-4.5 は総合平均順位3位、GLM-4.5-Air は6位を記録した
- エージェント性スコアでは OpenAI o3 に次ぐ2位、コーディングベンチマークでも Claude Sonnet 4 に迫る3位を達成した
- GLM-4.5 は DeepSeek-R1 の半分、Kimi K2 の3分の1のパラメータ数で同等の性能を示した
- SWE-bench Verified における性能対パラメータ数でも、GLM-4.5 と GLM-4.5-Air は Pareto Frontier 上に位置する
- 性能データは 2025年7月28日時点のものである
序論
- 大規模言語モデル(LLM) は、従来の汎用データの蓄積庫から、汎用的な問題解決器へと急速に進化している
- 人工知能の到達点である AGI(Artificial General Intelligence)は、複数領域で人間レベルの認知能力を備えたモデルを目指す
- そのためには、複雑な問題解決力、一般化、自己改善能力が統合的に求められる
- 実務や複雑な専門問題の解決に重要な3つの中核能力は次のとおりである:
- エージェント性能力:ツールおよび外部世界との相互作用
- 複合推論:数学・科学などにおける複雑な段階的問題解決
- 高度なコーディング:実践的なソフトウェアエンジニアリング遂行能力
- 既存の SOTA 商用モデル(OpenAI、Anthropic)は個別領域で特化した性能を示すが、オープンソースモデルの中でこの3分野すべてに優れた公開モデルはまだ少ない
GLM-4.5 および GLM-4.5-Air モデル紹介
- GLM-4.5 / GLM-4.5-Air は、エージェント性・推論・コーディングのすべての分野でオープンソース最高水準の性能を示す
- 両モデルともハイブリッド推論モードをサポートする
- Thinking Mode は複雑な推論とエージェント性に強みを持つ
- Non-thinking Mode は高速な応答に特化している
- GLM-4.5 の主な成績:
- エージェント性:TAU-Bench 70.1%、BFCL v3 77.8%、BrowseComp 26.4%(競合商用モデルより優位)
- 推論:AIME 24 91.0%、GPQA 79.1%、LiveCodeBench 72.9%、HLE 14.4%
- コーディング:SWE-bench Verified 64.2%、Terminal-Bench 37.5%(GPT-4.1 および Gemini-2.5-pro を上回り、Claude Sonnet 4 に迫る)
- GLM-4.5-Air は 1060億パラメータで、1000億規模モデルの中でも Qwen3-235B-A22B、MiniMax-M1 と同等または優位である
ベンチマーク性能の現状と特徴
- 12の主要ベンチマーク全体で、GLM-4.5、GLM-4.5-Air ともに高順位を記録した
- GLM-4.5 はエージェント性、推論、コーディング各分野でバランスの取れた性能を示し、パラメータ効率の高さが際立つ
- SWE-bench Verified 基準で、パラメータ数に対する最高効率領域(Pareto Frontier)を達成した
- 商用・オープンソースの複数モデルとともに、精密な性能比較を実施した
公開とオープンソース支援
- GLM-4.5 / GLM-4.5-Air モデルは、Z.ai、BigModel.cn に加えて Huggingface(https://huggingface.co/zai-org/GLM-4.5)でも公開されている
- ベンチマークの再現性のため、評価ツールキット(https://github.com/zai-org/…
事前学習
アーキテクチャ
- GLM-4.5 シリーズは Mixture-of-Experts(MoE)構造を採用し、学習および推論の計算効率を大きく高めている
- MoE レイヤーに loss-free balance routing とシグモイドゲーティングを適用している
- DeepSeek-V3、Kimi K2 と異なり、モデルの幅(hidden 次元、ルーティング専門家数)は抑え、深さ(レイヤー数)を増やしている。より深いモデルは推論能力の成長に効果的である
- Self-Attention には Grouped-Query Attention + partial RoPE を適用し、96個の attention head により hidden 次元 5120 に対して 2.5 倍の attention head 構成としている
- ヘッド数の増加は学習損失には影響しない一方、実際の推論・ベンチマーク性能には好影響が確認された
- QK-Norm の適用により attention logit 値の安定性を高めている
- GLM-4.5、GLM-4.5-Air ともに MoE レイヤーベースの MTP(Multi-Token Prediction)レイヤーを追加し、推論時の speculative decoding をサポートする
- アーキテクチャのパラメータ集計では、MTP レイヤーのパラメータは含め、単語埋め込みおよび出力レイヤーは含めていない
結論と期待される効果
- GLM-4.5 / GLM-4.5-Air は、オープンソース AI 市場において 高性能・高効率・汎用性 を兼ね備えた次世代言語モデルである
- 複数分野を統合した高難度問題の解決能力、商用モデルに対する競争力、パラメータ効率性において存在感を示している
- 学術界、産業界、開発者コミュニティ全般において、オープンソース大規模言語モデルのイノベーション基盤として貢献する可能性を広げる
2件のコメント
Hacker Newsのコメントでもそうですし、RedditのLocalLLaMAフォーラムでも、GLMはかなり良いという評価が出ていますね
GLM 4.5 AIR IS SO FKING GOODDD
Hacker Newsのコメント
今回の論文は、普段よく見かけるモデル発表のブログ記事とは違って、踏み込んだ内容を扱っていて本当にうれしい
Zhipu/Tsinghuaチームが「何を」だけでなく「どうやって」まで詳しく説明しており、この種のモデルを自分で作ったり活用したりしたい人にとって特に興味深い情報だ
とりわけ Sec 3 のポストトレーニング手法が印象的だった
推論/エージェント/チャットなどに特化した「専門家モデル」を別々に作り、その能力を最終的な統合モデルへ蒸留(distill)するアプローチが魅力的だ
いろいろな役割を中途半端にこなすジェネラリストモデルの限界を、はるかに体系的に解決しようとする試みだ
単にデータを混ぜるだけではなく、汎用モデルが専門家集団から学ぶように設計したとも言える
RL の実験結果で興味深かった点の一つは、64K コンテキスト全体に一度で RL を適用する方式が、段階的な RL より高性能だったことだ(Fig 6 参照)
多くのチームは逆だと考えそうだが、実際の結果は違う
そして、関数呼び出しフォーマットに XML テンプレートを使うという小さいが賢い選択のおかげで、JSON のエスケープ問題から解放されている(Fig 4 参照)
実運用では、JSON の中でコードをエスケープ処理するのは本当に厄介だ
SWE-bench での性能もかなり高く、はるかに大規模なモデルや商用モデルに匹敵する
今後気になるのは、こうしたハイブリッド学習法が ARC-style 評価以外の環境でも通用するかどうかだ
たとえば実務のように API ドキュメントがなく、エラーが頻発し、入力も曖昧な複雑なワークフローでも、エージェント性能をうまく維持できるのか気になる
こうした post/mid-training の調整が、すでにデータとラベルが豊富にあり十分検証されている特定ドメイン学習でも本当に必要なのか気になる
少人数のチームでも最新のスケールアップ訓練スタックをきちんと踏襲するだけで十分なのか、それともこうした手法を使わないと大きな差が出るのか知りたい
いちゃもんをつけているように見えないか少し心配だが、文章の文体に LLM 特有の感じがかなりある
以前にも同じ指摘を見たことがある リンク
こういう点を指摘するのは、オンライン環境を健全に保つうえで大事だと思う
GLM-4.5 のコーディングモデルをかなり長く使ってみたが、性能は本当に優れている
開発中のコーディングエージェント Octofriend で GLM-4.5 を動かしているとき、Claude 4 と勘違いしたこともある
私の経験では、Claude のほうがコードベース全体を文脈に置き、システム相互作用まで考慮する必要がある状況にやや強い印象だ
一方で GLM-4.5 は「正直」なタイプで、Claude がよくやるようにテストコードを直して問題をこっそり回避するような挙動はあまりしない
どちらも高水準だが、GLM-4.5 が Claude 4 Sonnet や 4.1 Opus で見つけられなかったバグを見つけてくれたこともある
デバッグに限れば Claude のほうがわずかに勝つことが多いが、差は大きくない
GPT-5 と比べると、Claude も GLM も一貫性が高い
GPT-5 は本当に見事な結果を出すことが時々あるが、一度おかしな方向にそれると正常な軌道に戻すのが難しくて厄介だ
Octofriend 参考: https://github.com/synthetic-lab/octofriend
このコメントを見て Kilocode で GLM-4.5 を試してみた
今日一日ずっと Gemini CLI でコンパイラコードの厄介なバグを追っていたが、うまくいかなかった
ところが GLM-4.5 はすぐに核心の問題を指摘した
Gemini CLI は見当違いの関数ばかり疑い、中途半端な修正を繰り返していたが、結局まったく関係のない部分だった
GLM-4.5 の問題への集中力は確かに際立っている
私も GLM-4.5 を小規模プロジェクトや短い依頼で良い感じに使えた経験がある
残念ながら文脈が長くなるほど性能が落ちる印象があるので、今は Sonnet 4 のバックアップとして使っている
aider で architect モードを使っている
Deepseek R1(上位設計担当)+ Qwen3 480B(低レベルコーディング担当、あるいは qwen code API を利用)の組み合わせで使っている
この構成は本当によく動く
99.99% の問題を単独で解決するレベルだ
まだ aider では役割分担が完全ではないので、自分でワークフローを改善したツールを作ろうと思っている
最初のポイントに同感だ
私も Claude は文脈が多いほどよく働き、GLM-4.5 はそういう状況では結果がいまひとつだと感じる
GLM-4.5 シリーズは総/アクティブパラメータ数を数える際、埋め込み層と出力層を除外し、MTP 層だけを含める方式になっている
自分で計算した値(355B A32B)とも一致している
GPT OSS シリーズは埋め込み/出力の両方を総パラメータには入れ、アクティブパラメータには出力だけを含めている
Qwen3 シリーズは総/アクティブの両方で埋め込みと出力をどちらも含めている
モデルごとにパラメータ計算方式が異なるので、なぜ標準がないのか、どの計算方法がより妥当なのか気になる
アクティブパラメータについては、unembedding パラメータはトークン生成ごとにすべて使われる一方、埋め込みは1列しか使われないため、この特性を反映して計算しないと、帯域幅やレイテンシとの関係を正しく把握できない
今後数年以内に、2000ドル程度のワークステーション PC で Sonnet 4 クラスのローカルなオープンモデルを使ってコーディングできるようになると思う
現在のクラウドベースのモデルも有用だが、開発者体験の中核になるツールである以上、ローカルで動かせてほしい
私は2年ではなく、今年末には十分可能だと思う
オープンソースの観点からも、こうしたモデルは不可欠だ
そうでなければオープンソース開発そのものが持続不可能になりかねない
むしろ 2 年以内に Sonnet 4 以上の性能を 2000 ドル PC に載せられることをもっと期待している
今回のモデルは、既存の商用フロンティアモデルとほぼ対等に比較できる最初のオープンモデルという印象だ
パラメータ効率を見るだけでも、学習方法に本当の革新があったことがわかる
Aider の LLM Leaderboard で独立した性能検証結果も気になる
私のように論文の要旨から読みたい人向けにリンクを置いておく https://www.arxiv.org/abs/2508.06471
Apache ライセンスという点まで含めて、とても素晴らしい公開だ
オープンソースモデルが限界に挑み続ける姿を見るのは本当にうれしい
この論文で観察された内容が多すぎて、それぞれ単独で論文にできるほどだ
とくに学習過程とデータ収集/合成に関する知見が非常に豊富だ
著者たちが以前にもこのレベルの優れた論文を書いていたか知っている人はいる?
論文のグラフ指標が紛らわしい
最初の図では sonnet 4 の swebench スコアが 53 前後に見えるのに、その次では 70 に近い
実際の値は 70 にもっと近い 参考
なぜ Qwen3 はコーディングベンチマークから外れているのに、他のベンチマークには含まれているのか気になる
Section 4.3.2 に Qwen3-Coder が含まれている
Qwen はまだ大規模コードベースの理解には未熟だ