GLM-5.2は旗艦級のオープンソースGLM AIモデルであり、安定した100万トークンのコンテキスト、非思考/高い/最高いの三つの思考力で、Terminal-Bench 2.1で81.0、FrontierSWEで74.4と報告されています。各GLMモデルを比較するか、無料のAI体験場を試してみてください。
登録不要、アカウント不要、クレジット不要。タグを入力するとストリーミング回答を受け取ることができます。
返信はここでストリーミング出力されます…
本体験はGLM大規模言語モデルを使用しており、入力タグを入力するとリアルタイムのストリーミング回答を受け取ることができます。
4つの能力が現在のGLMモデル世代を定義しています — 全てモデルの著者によって報告され、オープンアクセスで再現可能です。
100万トークンのコンテキストは利用可能であり、質を維持します：GLM-5.2は大規模な実装、自動化研究、複雑なデバッグなどの長いコンテキストのエージェントの軌跡で訓練されています。
非思考、高い、最高いの三つのレベルで、タスクに応じて遅延と能力のバランスを取ることができます。アーキテクトプログラミング評価では、約63%（~35Kのオプトトークン）から74%（~83K）までです。
4つの稀疏な注意力層が1つの軽量インデックスエンジンを共有し、100万トークンのコンテキスト長さで各トークンのFLOPsを2.9倍に削減し、長距離の品質を無損に保ちます。
MITライセンスの下でのオープンソースのGLMモデルで、ウェイトはHuggingFaceとModelScopeで公開され、地域制限はありません。transformers、vLLM、SGLang、xLLM、ktransformersを通じてローカルデプロイメントをサポートします。
以下のすべてのデータは、モデルの著者が発表したGLM-5.2および比較モデルの結果です。glmmodel.netはこれらの評価を実行しません。
タスクの長さは最大20時間まで達します
H100の1枚上で最大10時間
非常に長いサイクルのソフトウェアエンジニアリング、最大10時間
長期の基準テストでGLM-5.2は常に最も高いいランクを持つオープンソースモデルであり、百万トークンのコンテキストが実際の生産性に変換されることを証明しており、受け入れ可能なトークン数を超えるだけでなく、実際のトークン数です。FrontierSWEではOpus 4.8に1ポイント、GPT-5.5に1ポイント、前世代のOpus 4.7に11ポイントリードしています。
発表されたGLMモデルの基準結果は、8つのモデルの17項の評価をカバーしています。
| 基準テスト | GLM-5.2 | GLM-5.1 | Qwen3.7-Max | MiniMax M3 | DeepSeek-V4-Pro | Claude Opus 4.8 | GPT-5.5 | Gemini 3.1 Pro |
|---|---|---|---|---|---|---|---|---|
| 推論 | ||||||||
| HLE | 40.5 | 31.0 | 41.4 | 37.0 | 37.7 | 49.8* | 41.4* | 45.0 |
| HLE（ツール付き） | 54.7 | 52.3 | 53.5 | – | 48.2 | 57.9* | 52.2* | 51.4* |
| CritPt | 20.9 | 4.6 | 13.4 | 3.7 | 12.9 | 20.9 | 27.1 | 17.7 |
| AIME 2026 | 99.2 | 95.3 | 97.0 | – | 94.6 | 95.7 | 98.3 | 98.2 |
| HMMT 2025年11月 | 94.4 | 94.0 | 95.0 | 84.4 | 94.4 | 96.5 | 96.5 | 94.8 |
| HMMT 2026年2月 | 92.5 | 82.6 | 97.1 | 84.4 | 95.2 | 96.7 | 96.7 | 87.3 |
| IMOAnswerBench | 91.0 | 83.8 | 90.0 | – | 89.8 | 83.5 | – | 81.0 |
| GPQA-Diamond | 91.2 | 86.2 | 90.0 | 93.0 | 90.1 | 93.6 | 93.6 | 94.3 |
| プログラミング | ||||||||
| SWE-bench Pro | 62.1 | 58.4 | 60.6 | 59.0 | 55.4 | 69.2 | 58.6 | 54.2 |
| NL2Repo | 48.9 | 42.7 | 47.2 | 42.1 | 35.5 | 69.7 | 50.7 | 33.4 |
| DeepSWE | 46.2 | 18.0 | 18.0 | 20.0 | 8.0 | 58.0 | 70.0 | 10.0 |
| ProgramBench | 63.7 | 50.9 | – | – | 47.8 | 71.9 | 70.8 | 39.5 |
| Terminal-Bench 2.1 (Terminus-2) | 81.0 | 63.5 | 75.0 | 65.0 | 64.0 | 85.0 | 84.0 | 74.0 |
| Terminal-Bench 2.1（最適なフレームワーク） | 82.7 (Claude Code) | 69.0 (Claude Code) | – | – | – | 78.9 (Claude Code) | 83.4 (Codex) | 70.7 (Gemini CLI) |
| FrontierSWE Dominance | 74.4 | 30.5 | – | – | 29.0 | 75.1 | 72.6 | 39.6 |
| PostTrainBench | 34.3 | 20.1 | – | – | – | 37.2 | 28.4 | 21.6 |
| SWE-Marathon | 13.0 | 1.0 | – | – | – | 26.0 | 12.0 | 4.0 |
| エージェント | ||||||||
| MCP-Atlas（公開セット） | 76.8 | 71.8 | 76.4 | 74.2 | 73.6 | 77.8 | 75.3 | 69.2 |
| Tool-Decathlon | 48.2 | 40.7 | – | – | 52.8 | 59.9 | 55.6 | 48.8 |
* 完整データセット上のスコアです。
GLMモデルには1つの速度だけではありません。思考の強度制御により、必要なときにのみ多くの計算リソースを割り当てることができます。
~35K 平均トークン
迅速な編集、テンプレートコード、一般的なリファクタリングなどの遅延が深さよりも重要なシーン。
~43K 平均トークン
大多数のエージェントプログラミングのデフォルト選択：約半分のトークン消費で最高いクラスの品質に近づけます。
~83K 平均トークン
困難な長期問題 — 必要な場合にのみ追加の計算リソースを割り当てます。
データはTerminal-Bench 2.1、DeepSWE、SWE-Atlas QnAの平均値で、Claude Code 2.1.167で評価されています。モデルの著者によって報告されています。近似のトークン予算で、GLM-5.2のパフォーマンスはClaude Opus 4.7とOpus 4.8の間に位置しています。
コンテキストの上限を200Kから100万トークンに引き上げるのは、設定パラメータではなく技術的な問題です。3つの変更が鍵となります。
4つのTransformer層ごとに軽量インデックスエンジンを共有します。これは最初の層に位置し、top-kインデックスは残りの3層で共有されるため、4分の3の層でのインデックスエンジンの点積とtop-k計算を省略します。結果として、100万のコンテキスト長さで、各トークンのFLOPsは2.9倍に低下します。IndexShareはトレーニング中期の128Kシーケンス長さから導入されました。
多トークン予測層は最初の草稿ステップでインデックスエンジンを実行し、その後のステップでインデックスを再利用し、前世代のトレーニング/推論のKVキャッシュの不適合を解消します。拒絶サンプリングとエンドツーエンドのTV損失を組み合わせ、長さは4.56から5.47に増加し、約20%、7つのMTPステップを越えます。
| ベースライン | 4.56 |
| + IndexShare + KVShare | 5.10 |
| + サンプルを拒否 | 5.29 |
| + 端到端 TV 損失 | 5.47 (+20%) |
数十万トークンを超えると、ボトルネックは計算ではなく、KVキャッシュ容量、長いコンテキストのカーネル、CPUコストになります。三つの修正として、LayerSplitに基づく微細なメモリ管理と並列化、キャッシュ伝送パイプラインと調整されたコンテキスト長さのスケーリングカーネル最適化、CPU側のキャッシュ管理、リクエストスケジューリング、ランタイムパスの最適化があります。スループットの利点はコンテキストの増加に伴って拡大します。
正規化通量の利点
トレーニングスタック（slime）は、白盒とブラックボックスのrollout、コンパクトな軌跡とサブエージェントのワークフローを組み合わせています。並行OPDトレーニングは約2日で10数個の専門モデルを統合し、FP8 KVキャッシュはrolloutのメモリ予算を超えないことを確保します。
長期のRLは短絡を引き起こすため、まずルールに基づく召回フィルタを通じて疑わしいアクションを先にし、その後LLMの精度チェックを通じて正確に評価します。確認されたハッキング行為はオンラインでインターセプトされ、仮想ツールの結果で応答し、rolloutが継続されることを確保します。Criticに基づくPPOは単一のrolloutでトレーニング可能な子トレイルを圧縮します。
30Bフラッシュレベルから百万トークンのコンテキストの旗艦モデルまで — 一つのGLMモデルを選択して完全なスペック表と基準データを確認してください。
100万トークンのコンテキスト、プログラミングおよび長期タスクのためのオープンソースSOTA、より強力なエージェントの工学能力。
前世代の旗艦モデル：大幅に向上した長期能力と数時間の自主的な作業のエンジニアリングレベルのアウトプット。
より強力なプログラミング能力、より信頼性の高いい多段階実行、そしてより良い複雑なエージェントの行動。
基本的なモデルで、長いリンクや動的エージェントシーンに最適化されています。
強化されたプログラミング能力、安定した多段階推論と改善されたフロントエンド生成。
300億パラメータ；高い効率の性能で、同規模のオープンソースモデルをリードしています。
小さなボディのGLMモデル、単位算力性能が優秀。
リアルタイム音声認識を提供し、CERが0.0717まで低減しています。
単一のコンテキストウィンドウを超える多ファイル機能：モデルは全体のリポジトリの状態を視野に保ち、数回ごとに再読み込みするのではなく、全てを保持します。
数時間の実験サイクルで、エージェントは計画、実行、結果の読み取り、修正を行う必要があります。これがFrontierSWEとPostTrainBenchが評価する作業負荷です。
完全な呼び出しグラフ、解析器の出力、および前回の試みを同じ軌道に保つために必要な内核とシステムの動作を分析する必要があります。
長い再現追跡、不安定なテスト、およびサービス間の障害が続く中、コンテキストのカットオフがバグの原因となりました。
上記のすべてのシナリオは、自分のハードウェアで実行できます。MITウェイト、transformers · vLLM · SGLang · xLLM · ktransformersです。GLMモデルをローカルで実行する方法 →