GLM-5.2：長期的タスク向けに構築

Back to Articles

GLM-5.2は、長期的タスク向けの最新フラッグシップモデルです。GLM-5.1と比べて長期的タスク能力が大幅に向上し、初めて堅牢な1Mトークンコンテキストでその能力を発揮します。GLM-5.2の新機能は以下の通りです。

• 堅牢な1Mコンテキスト： 長期的作業を安定して維持できる堅牢な1Mトークンコンテキスト
• 柔軟な努力レベルによる高度なコーディング：パフォーマンスとレイテンシのバランスを取るための複数の思考努力レベルを備えた、より強力なコーディング能力
• 改善されたアーキテクチャ：4つのスパースアテンションレイヤーごとに同じインデクサを再利用するIndexShareを提案し、1Mコンテキスト長でトークンあたりのFLOPsを2.9倍削減します。また、投機的デコーディング用のGLM-5.2のMTPレイヤーを改善し、受理長を最大20%向上させました。
• 完全オープン：MITオープンソースライセンス — 地域制限なし、国境を越えた技術的アクセス

長期的タスクをサポートするには、まず長文コンテキストをエンジニアリングで実用的に使えるようにすることが重要です。モデルは単に多くのトークンを受け入れるだけでなく、長く乱雑なコーディングエージェントの軌跡全体で品質を維持する必要があります。1Mコンテキストは主張しやすいですが、実際のエンジニアリング負荷の下で信頼性を保つのははるかに困難です。このため、大規模実装、自動研究、パフォーマンス最適化、複雑なデバッグをカバーするコーディングエージェントシナリオ向けに1Mコンテキストトレーニングを大幅に拡大しました。その結果、範囲が広いだけでなく実行が堅牢な長文コンテキストシステムが実現し、持続的なエンジニアリング作業のための実用的な基盤となりました。

この能力は、3つの長期的コーディングベンチマークにおけるGLM-5.2のパフォーマンスに反映されています。FrontierSWEは、エージェントが数時間から数十時間規模のオープンエンドな技術プロジェクトを完了できるかどうかを測定し、システム最適化、大規模コード構築、応用ML研究に及びます。このベンチマークでは、GLM-5.2はOpus 4.8にわずか1%差で続き、GPT-5.5を1%、Opus 4.7を11%上回りました。PostTrainBenchでは、各エージェントにH100 GPUが与えられ、ポストトレーニングによる小規模モデルの改善度で評価されますが、GLM-5.2はOpus 4.7とGPT-5.5の両方を上回り、Opus 4.8に次ぐ2位となりました。SWE-Marathonは、コンパイラの構築、カーネルの最適化、本番グレードサービスの開発などのタスクをカバーする超長期的ソフトウェアエンジニアリングベンチマークで、GLM-5.2はOpus 4.8に13%差でまだ改善の余地がありますが、Opusシリーズに次ぐ2位を維持しています。3つのベンチマークすべてで、GLM-5.2は最高ランクのオープンソースモデルであり、その1Mコンテキストが実用的な長期的提供能力に変換されていることを示しています。

標準的なコーディングベンチマークでは、GLM-5.2は最強のオープンソースモデルであり、GLM-5.1から大幅に改善しています：Terminal-Bench 2.1で81.0対63.5、SWE-bench Proで62.1対58.4です。また、クローズドソースの最先端モデルとのギャップを大幅に縮めています。Terminal-Bench 2.1（81.0）ではClaude Opus 4.8（85.0）に数ポイント以内に収まり、Gemini 3.1 Proを上回っています。

GLM-5.2はまた、努力レベル制御を導入し、ユーザーがモデルの能力とタスク実行速度および計算コストを明示的にバランスさせられるようにします。図に示すように、GLM-5.2は同等のトークンバジェットでGLM-5.1よりも大幅に強力なエージェント的コーディング性能を発揮し、その能力は類似のトークン消費量でClaude Opus 4.7とClaude Opus 4.8の間に位置づけられます。さらに、Max努力レベルにより、困難なタスクでより高いパフォーマンスが必要な場合に追加の計算を割り当てることができ、モデルのコーディング能力をさらに拡張します。この設計により、ユーザーはコーディングタスクにGLM-5.2を使用する際に、より柔軟に異なるシナリオに最も適した推論モードを選択できます。

1Mコンテキスト向けアーキテクチャ

DSA向けIndexShare

1Mコンテキスト長をサポートするため、GLM-5.2ではDSAのインデクサの計算コストを削減するためにIndexShareを適用します。具体的には、GLM-5.2では4つのトランスフォーマーレイヤーごとに軽量インデクサを共有します。インデクサは4レイヤーの最初のレイヤーに配置され、topkインデックスが4レイヤーで使用されます。これにより、3/4のレイヤーでインデクサのドット積とtopk演算の計算が削減されます。GLM-5.2は128Kシーケンス長で中間トレーニングからIndexShareで訓練され、計算量を抑えつつ長文コンテキストベンチマークでGLM-5.1を上回りました。

IndexShareとKVShareを備えたMTP

投機的デコーディング用のGLM-5.2のMTPレイヤーを2つの目的で改善しました：1）ドラフトモデルとしてのMTPレイヤーのコストを最小化する、2）投機的デコーディングの受理率を最大化する。

最初の目的のために、MTPレイヤーにもIndexShareを適用します。マルチステップMTPでは、インデクサは最初のステップに配置され、topkインデックスは以降のすべてのステップで使用されます。ただし、バックボーンとは異なり、異なるMTPステップの入力トークンは異なります。以下の図に示すように、$h_4$のtopkインデックスを$h_5$に再利用すると、$h_5$は$h_1$から$h_4$までしかアテンションできず、$h_5$にはアテンションできません。この特性により、GLM-5.1のMTPレイヤーにおけるトレーニングと推論の不整合を解消し、2番目の目的を達成できることを示します。

上図は2ステップMTPレイヤーの推論を示しています。最初のステップでは、推論はトレーニングと一致し、すべての隠れ状態がターゲットモデルから来ます。しかし、2番目のステップでは、$h_{1:4}$はターゲットモデルから来て、$h_5$はMTPレイヤーから来ます。したがって、$h_5$のKVキャッシュはターゲットモデルから計算された$kv_{1:4}$とMTPレイヤーから計算された$kv_5$の混合になります。一方、IndexShareを使用すると、$h_5$のKVキャッシュにはターゲットモデルの隠れ状態から計算された$kv_{1:4}$のみが含まれます。トレーニングでは、最初のMTPステップのKVキャッシュとtopkインデックスの両方を再利用します。GLM-5.1と同様に、異なるMTPステップのパラメータも共有されていることに注意してください。さらに、https://arxiv.org/abs/2606.12370に着想を得て、投機的デコーディングに拒否サンプリングを導入し、トレーニングにエンドツーエンドTV損失を使用します。

以下の表は、コーディングシナリオにおける受理長による技術のablationを示しています。実験ではGLM-5.1のバックボーンとトレーニングデータを使用し、MTPステップ数はトレーニングと推論の両方で7に設定しました。ベースラインと比較して、最終MTPレイヤーの受理長は20%増加しました。

1Mコンテキスト長の効率的なサービング

GLM-5.2は最大コンテキスト長を200Kから1Mトークンに拡張したため、コーディングワークロードは大幅に長いプロンプトに向かうと予想されます。これにより、主な推論ボトルネックが計算からKVキャッシュ容量、長文コンテキストカーネルオーバーヘッド、CPUサイドのオーバーヘッドに移行します。新しいGLM-5.2アーキテクチャはトークンあたりの計算FLOPsを削減しますが、トークンあたりのKVキャッシュサイズは比例して削減されません。その結果、限られたGPUリソースの下でより長いコンテキスト、より高い同時実行性、より高いトークンスループットをサポートすることが、推論エンジン最適化の中心的な課題となります。

この課題に対処するため、推論エンジンを3つの方向で最適化します。まず、LayerSplitを基盤として、より細粒度のメモリ管理と並列化戦略を導入し、KVキャッシュ容量を増やし、超長文コンテキストリクエストにより多くの使用可能なキャッシュスペースを提供します。次に、コンテキスト長とともにコストが増加するカーネルを最適化し、キャッシュ転送パイプラインとより良く連携させて、プリフィルとデコードの両方のパフォーマンスに対するキャッシュ転送の影響を最小化します。第三に、CPUサイドのキャッシュ管理、リクエストスケジューリング、ランタイム実行パスを最適化し、GPU実行パイプラインのバブルを減らし、エンドツーエンドのスループットを向上させます。図に示すように、GLM-5.2はコンテキスト長が長くなるにつれてスループットの優位性が拡大し、長文コンテキスト推論シナリオでのより強力なスケーラビリティを示しています。

エージェント的RL向けslime

GLM-5.2のエージェント的RLポストトレーニングは、より大規模で、より多くのドメインにわたり、より複雑な実行パターンを持つタスクを伴います。異種データとタスクは統一されたトレーニングプロセス内で組織化される必要があり、長期的インタラクション、ツール使用、サブタスク分解、マルチターン環境フィードバックはすべてロールアウトとトレーニングオーケストレーションに高い要件を課します。このプロセスをサポートするため、slimeはトレーニングから大規模推論ロールアウトまでの統合インフラストラクチャレイヤーとして機能します。ホワイトボックスロールアウト、ブラックボックスロールアウト、コンパクト軌跡、サブエージェントワークフローなど、複数のトレーニングとタスク組織化モードをサポートし、同じシステムでより大規模で複雑なRLおよびOPDトレーニングワークロードにスケールできるようにします。GLM-5.2のポストトレーニングプロセスでは、slimeフレームワークを使用して並列OPDトレーニングを実施し、10以上のエキスパートモデルを最終モデルに効率的に統合しました。OPDトレーニングプロセス全体は約2日間かかり、高いトレーニング効率を実証しました。

エージェント的RLはまた、システムリソースと推論インフラストラクチャに高い要求を課します。slimeは推論システムに対して非常にオープンで柔軟なインターフェースを提供します。トレーニング側は異なる形式の推論サービスに接続でき、異なる並列化戦略、ルーティングポリシー、PD分離設定、デプロイメントパターンに柔軟に適応できます。同時に、RLロールアウト中に蓄積された設定経験、スケジューリング戦略、最適化パスは、本番サービング段階で再利用およびさらに洗練でき、トレーニング側とサービング側が相互に強化し合います。これにより、ポストトレーニングから本番デプロイメントへのより直接的なパスが作成されます。柔軟なトレーニング推論リソース組織化とKVキャッシュFP8とともに、slimeはGLM-5.2の大規模エージェント的RLトレーニングに重要なインフラストラクチャサポートを提供し、システム効率、ロールアウトスループット、大規模推論同時実行性をさらに向上させます。

アンチハッキングを備えた長期的タスク向けRL

長期的タスク向けRL。GLM-5.2では、長期的タスクは大幅に長い実行トレースを生成し、超長軌跡がコンパクションによって複数のサブトレースに分割されると、同じプロンプトの下での異なるロールアウトは、非常に可変な長さのトレーニング可能なトレースの異なる数を生成します。そのため、グループ相対比較ではなく、トークンレベルのアドバンテージを推定するcriticに依存する、グループワイズ最適化からcriticベースのPPO定式化に移行しました。このシングルロールアウト定式化はコンパクションに自然に適合し、プロンプトが生成するトレースの数や相対長に制約を課しません。すべてのコンパクト化されたサブトレースをトレーニング可能な軌跡として含めることでコンパクションをトレーニングに取り込み、長さの不均衡に対処するためにトークンレベルの損失を適用します。

コーディングエージェントにおけるアンチハック。コーディングRLは、報酬が通常検証可能なパス/フェイル信号であるため、報酬ハッキングに対して特に脆弱です。GLM-5.2はGLM-5.1よりもハッキング行動の可能性を示すことがわかりました。これにより検証信号は最適化しやすくなりますが、モデルの根本的な能力を実際に向上させることはできません。エージェントは保護された評価アーティファクトを読み取ったり、リファレンスや上流コミットから回答内容をコピーしたり、GitHub関連タスクでターゲットソースを直接取得したりできます。たとえば、エージェントはcurl https://raw.githubusercontent.com/<path-to-file>でソリューションをダウンロードしたり、以下のような連鎖漏洩を行う可能性があります。

1. find /workspace -name "*hidden*"
2. cat /workspace/.eval/secret_cases.json
3. python solve.py --case "$(cat /workspace/.eval/secret_cases.json)"

これらの行動は報酬を水増しし、トレーニング信号を破損させるため、実際のタスク解決とショートカットを分離する明確なメカニズムが必要です。これに対処するため、RLトレーニングと評価の両方にアンチハックモジュールを導入します。検出プロセスは2段階です。まずルールベースのフィルタが潜在的なハックを最大限にリコールで捕捉し、次にLLMジャッジがこれらのフラグ付きアクションの意図をチェックして精度を高く保ちます。各ステップでツールコールを監視するオンライン戦略を使用します。ハックが検出された場合、システムはコールをブロックし、結果としてダミー情報を返します。重要なのは、このオンラインガードにより、ハックされたアクションが捕捉された後もモデルがロールアウトを継続できることです。ロールアウト全体を拒否する代わりに特定の無効な行動を処理することで、このアプローチはロールアウトが突然停止した場合に発生する可能性のあるトレーニング不安定性とモデル崩壊を防ぐのに役立ちます。

完全ベンチマーク表

GLM-5.2の始め方

GLM Coding PlanでGLM-5.2を使用する

お気に入りのコーディングエージェント（ZCode、Claude Code、OpenCodeなど）でGLM-5.2をお試しください。https://docs.z.ai/devpack/overview

GLM Coding Planサブスクライバー向け： GLM-5.2はすでにすべてのCoding Planユーザーにロールアウトされています。モデル名を"GLM-5.2"（Claude Codeでは1Mコンテキスト長を有効にするためにGLM-5.2[1m]）に更新することで、今すぐGLM-5.2を有効にできます。また、タスクに応じて異なるthinking effort（HighまたはMax）を選択することもできます。最も高性能なモデルとして、GLM-5.2はピーク時間帯に3×、オフピーク時間帯に2×のクォータを消費します。9月末までの期間限定プロモーションとして、オフピーク使用は1×で請求されます。（ピーク時間は毎日14:00–18:00 UTC+8（北京時間）です。）

GUIをご希望ですか？GLM-5.2を搭載したデスクトップエージェントZCodeを提供しています。長期的タスク向けの/goal、SSHリモート開発、モバイルコントロールを備えています。特別オファー：ZCode内のCoding Planを通じてGLM-5.2を使用すると、6月30日まで1.5倍の実効クォータが得られます。

今すぐ構築を開始： https://z.ai/subscribe

Z.aiでGLM-5.2とチャットする

GLM-5.2はZ.aiで利用可能です。

GLM-5.2をローカルでサーブする

GLM-5.2のモデルウェイトはHuggingFaceとModelScopeで公開されています。ローカルデプロイメントでは、GLM-5.2はtransformers、vLLM、SGLang、xLLM、ktransformersを含む推論フレームワークをサポートします。

脚注

• Humanity’s Last Exam (HLE)およびその他の推論タスク：評価にはtemperature=1.0、top_p=0.95のサンプリングパラメータを使用します。最大生成長163,840トークンで評価します。デフォルトではテキストのみのサブセットを報告し、*付きの結果は完全セットからのものです。AIME、HMMT、IMOAnswerBenchでは、以下のシステムプロンプトを使用して各質問を評価します：Your response should be in the following format:\nExplanation: {your explanation for your final answer}\nExact Answer: {your succinct, final answer}\nConfidence: {your confidence score between 0% and 100% for your answer}. ジャッジモデルとしてGPT-5.5（medium）を使用します。HLE-with-toolsでは、最大コンテキスト長300,000トークンを使用し、コンテキスト管理戦略はありません。
• SWE-Bench Pro：SWE-Bench ProスイートをOpenHandsで実行し、カスタマイズされた指示プロンプトを使用します。設定：temperature=1、top_p=1、max_new_tokens=32k、400Kコンテキストウィンドウ。
• NL2Repo：NL2Repoをtemperature=1.0、top_p=1.0、max_new_tokens=48k、400kコンテキストで評価しました。ハッキングを防ぐため、悪意のある行動（例：無許可のpipまたはcurl操作）を防ぐためにルールベースおよびLLMベースの判断を使用しました。
• DeepSWE：公式pier評価フレームワークとmini-swe-agentハーネス（temperature=1.0、top_p=1.0、timeout=2h、400Kコンテキスト）でDeepSWEを実行しました。各タスクは2 CPU、8 GB RAM、インターネットアクセスなしの分離コンテナで解決されます。
• ProgramBench：ProgramBench（200インスタンス）をClaude-Code 2.1.156で評価し、temperature=1.0, top_p=1.0, max_tokens=64000, max_turns=2000, sample_timeout=6h, reasoning_effort=max、400Kコンテキストウィンドウを使用しました。各インスタンスは（4 CPU、8 GB RAM）のサンドボックスで実行され、インターネットアクセスは無効化されています。
• Terminal-Bench 2.1 (Terminus 2)：Terminal-Bench 2.1をTerminus-2フレームワークで評価し、parser=json、timeout=4h、temperature=1.0、top_p=1.0、max_new_tokens=48k、max_episodes=500、256Kコンテキストウィンドウを使用しました。リソース制限は4 CPUと8 GB RAMに制限されています。
• Terminal-Bench 2.1 (Claude Code)：Claude Code 2.1.167でtemperature=1.0, top_p=0.95, max_new_tokens=131072で評価します。64k CLIキャップをバイパスする透過プロキシを介してmax_new_tokensを128kにオーバーライドします。ウォールクロック時間制限を削除し、タスクごとのCPUおよびメモリ制約を維持します。スコアは5回の実行の平均です。
• MCP-Atlas：すべてのモデルをthinkモードで500タスクのパブリックサブセットで評価し、タスクごとに10分のタイムアウトを設定しました。評価にはGemini-3.0-Proをジャッジモデルとして使用しました。
• Tool-Decathlon：公式評価サービスを使用し、max_tokenを128Kに設定しました。
• FrontierSWE：Proximalが1Mコンテキスト長、max努力レベル、128K最大出力トークンで評価を実施しました。Dominanceスコアは2026/06/16時点で報告されています。
• PostTrainBench：PostTrainBenchが1Mコンテキスト長、max努力レベル、128K最大出力トークンで評価を実施しました。
• SWE-Marathon：Abundant AIが1Mコンテキスト長、max努力レベル、128K最大出力トークンで評価を実施しました。