GLM-5.1: 長期的なタスク遂行に向けた進化

 (z.ai)
8 ポイント 投稿者 GN⁺ 22 일 전 | 1件のコメント | WhatsAppで共有
  • 次世代のエージェンティック・エンジニアリングモデル GLM-5.1は、コーディングと問題解決能力を大幅に強化したフラッグシップ版であり、長期的最適化と継続的改善を中核として設計されている
  • SWE-Bench Pro、NL2Repo、Terminal-Bench 2.0などの主要ベンチマークで最高水準の性能を記録し、長時間の反復実行でも生産的な持続性を維持する
  • VectorDBBench、KernelBench、Webアプリ構築シナリオなどでは、数百〜数千回の反復を通じて性能を継続的に向上させ、独自のログ分析と戦略修正によってボトルネックを取り除く
  • モデルは自己評価と構造的転換を通じて、複雑なソフトウェアエンジニアリング課題でも効率的に動作し、長期実行時に結果品質が着実に改善される
  • MITライセンスのオープンソースとして公開され、さまざまなプラットフォームやフレームワークで利用可能であり、長期最適化型AIモデルの新たな基準として提示されている

GLM-5.1 概要

  • GLM-5.1は次世代のエージェンティック・エンジニアリング（agentic engineering）モデルで、従来版よりコーディング性能が大幅に向上したフラッグシップモデルである
  • SWE-Bench Proで最高性能を記録し、**NL2Repo（リポジトリ生成）およびTerminal-Bench 2.0（実際のターミナル作業）**でも GLM-5 に対して大差で優位を確保した
  • 単純な1回実行性能を超えて、長期的な最適化能力と継続的な問題解決力を重視して設計されている
  • 曖昧な問題をより適切に判断し、長いセッションでも生産性を維持し、反復的な実験と戦略修正によって数百回の反復でも性能を継続的に向上させる
  • 長時間実行するほど結果が改善される構造で、**長期的なタスク持続性（long-horizon capability）**を中核的特徴とする

複雑なソフトウェアエンジニアリング課題

  • GLM-5.1 は複雑なソフトウェアエンジニアリング作業で最高水準の性能を達成
  • 以前のモデルは初期の性能向上後すぐに停滞するが、GLM-5.1 は長期的なエージェンティック作業でも効率を維持する
  • モデルは問題を細分化し、実験を実行し、結果を分析してボトルネックを特定し、反復的推論によって戦略を修正する
  • これを、段階的に構造化の弱い3つの課題で実証した
    • ベクトル検索最適化問題（単一の数値指標ベース）
    • GPUカーネルベンチマーク（問題ごとの高速化を測定）
    • Webアプリケーション構築（明示的な指標なしに自己判断ベースで改善）

シナリオ 1: 600回の反復によるベクトルデータベース最適化

  • VectorDBBenchは、近似最近傍探索向けの高性能データベースを構築するモデルのコーディング能力を評価するオープンソースチャレンジ
  • モデルには Rust ベースのスケルトンコードと HTTP API エンドポイントが与えられ、**50回のツール呼び出し（tool-call）**以内でファイルの読み書き、コンパイル、テスト、プロファイリングを行う
  • 既存の最高性能は**Claude Opus 4.6 の 3,547 QPS（Recall ≥ 95%）**だった
  • GLM-5.1 は外部最適化ループを追加して600回超の反復（6,000回超のツール呼び出し）を実行し、最終的に21.5k QPSを達成
    • これは単一の50回セッションと比べて約6倍の向上
  • 性能向上の過程は階段状（staircase）パターンを示し、段階的なチューニングと構造的転換が交互に現れる
    • 約90回目: IVFクラスタープロービング + f16 ベクトル圧縮を導入 → 6.4k QPS
    • 約240回目: u8 プリスコアリング + f16 リランキングの2段階パイプラインを導入 → 13.4k QPS
  • 合計6回の構造的転換が発生し、各転換はモデルが独自のログを分析してボトルネックを特定した結果だった
  • Recall が95%未満に落ちた地点は、主に新たな戦略を探索する時点に集中していた

シナリオ 2: 1,000回超の反復による機械学習ワークロード最適化

  • KernelBenchは、PyTorch の基準実装を同一出力のより高速な GPU カーネルへ変換するモデルの能力を評価する
  • 3段階（Level 1〜3）で構成され、Level 3 にはMobileNet、VGG、MiniGPT、Mambaなど、モデル全体単位の最適化が含まれる
  • torch.compile のデフォルト設定は1.15×、max-autotune は**1.49×**の速度向上を達成
  • GLM-5.1 は Level 3 で3.6×の高速化を記録し、GLM-5 よりはるかに長時間にわたって有効な最適化を継続した
  • GLM-5 は初期の急上昇後に停滞し、Claude Opus 4.5はより長く持続するものの後半で鈍化
  • Claude Opus 4.6は最終的に**4.2×**で最も高い性能を維持し、なお追加改善の余地がある

シナリオ 3: 8時間にわたる Linux デスクトップ Webアプリ構築

  • Webサイト生成は、明示的な数値指標がない主観的な課題であり、完成度・視覚品質・インタラクション品質が評価基準となる
  • テストプロンプト: “Linux スタイルのデスクトップ環境を Web アプリケーションとして構築せよ”
    • 初期コード、デザイン、中間フィードバックなしで開始
  • 多くのモデルは基本UIを生成した時点で終了するが、GLM-5.1 は自ら結果を見直して改善するループを通じて継続的な発展を遂げた
  • 8時間にわたって反復実行し、初期の単純なレイアウトから徐々に完全なデスクトップ環境へ拡張
    • ファイルブラウザ、ターミナル、テキストエディタ、システムモニター、計算機、ゲームなどを追加
    • 各機能は一貫したUIとして統合され、スタイルとインタラクション品質が段階的に改善された
  • 最終結果は、ブラウザ内で動作する完全で視覚的一貫性のあるデスクトップ環境

長期最適化の意味と課題

  • 3つのシナリオすべてで中核となる変数は、実行時間そのものではなく、追加時間が実際に有効かどうかである
  • GLM-5.1 は GLM-5 と比べて**生産的持続時間（productive horizon）**を大きく拡張した
  • しかし KernelBench など一部の課題では、なお改善の余地が残る
  • 残された課題
    • 段階的チューニングが限界に達したときの局所最適からの脱出
    • 数千回のツール呼び出しにわたる一貫性の維持
    • 明示的な数値指標がない課題における信頼できる自己評価（self-evaluation）
  • GLM-5.1 は、このような長期最適化の方向に向けた第一歩として提示されている

ベンチマーク比較の要約

  • GLM-5.1 はSWE-Bench Pro 58.4、NL2Repo 42.7、Terminal-Bench 2.0 63.5などの主要なコーディングベンチマークで GLM-5 を上回る
  • Reasoning、Coding、Agentic全般で競合モデルに対して上位圏の性能
  • Claude Opus 4.6、Gemini 3.1 Pro、GPT-5.4などの最新モデルと比較しても、多くの項目で拮抗または優位

公開と利用方法

  • MITライセンスでオープンソース公開
  • api.z.ai、BigModel.cnで利用可能で、Claude CodeおよびOpenClawと互換性がある
  • GLM Coding Planの購読者は、モデル名を "GLM-5.1" に変更するだけですぐに利用可能
    • ピーク時間（UTC+8 14:00–18:00）には 3×、オフピーク時間には 2× のクォータ消費
    • 4月末まではオフピーク時間に 1× のプロモーションを適用
  • GUI 環境としてZ Codeを提供し、SSH によるリモート開発とモバイル作業をサポート
  • モデル重みはHuggingFaceとModelScopeで公開
  • vLLM、SGLangなど主要な推論フレームワークをサポートし、GitHub で配布ガイドを提供
  • まもなくZ.ai チャットプラットフォームでも利用可能となる予定

評価設定と注記

  • HLE およびその他の推論課題: 最大 163,840 トークン生成、GPT-5.2 を判定モデルとして使用
  • SWE-Bench Pro: 200K コンテキストウィンドウ、OpenHands ベースで実行
  • NL2Repo: 悪意あるコマンドの検出とブロックを含む
  • Terminal-Bench 2.0: 16 CPU、32GB RAM 制限、3時間タイムアウト
  • KernelBench Level 3: H100 GPU 環境、1,200回のツール呼び出し制限、独立監査を実施
  • CyberGym、MCP-Atlas、τ³-bench、Vending Bench 2など、さまざまな外部ベンチマークで独立評価を実施

関連記事

1件のコメント

 
GN⁺ 22 일 전
Hacker Newsの意見

  • 毎日、次の3つがますます明らかになっている
    (1) OpenAIとAnthropicは、もはやほとんど競争力がないと思う
    (2) ローカル/プライベート推論こそがAIの未来だと確信している
    (3) まだ「キラー製品」は登場していないのだから、今こそ本当に作るべき時だ

    • 「キラー製品がない」という意見には同意しない。コーディングアシスタントとLLMは、私の人生で最も驚異的な技術的成果だ。産業革命の前後のように、まもなく人類の歴史はAI以前とAI以後に分かれることになると思う
    • AIコーディングアシスタントは、これまで作られた技術の中でも最も有用なものの一つだ。モデルの品質が最も重要なので、ハードウェアが根本的に変わらない限り、ローカル推論が主流になるのは難しいと思う
    • 個人がGPUに5万ドルを費やして自分で回すことに、格好いい趣味プロジェクト以上の実質的な利点があるのか疑問だ

  • たった今、Claude Mythosに関する記事を見たが、今回は単なる改善ではなく本当の飛躍のように感じる。公開時期はまだ分からないが、スペックが異常なほど強力に見える次のGLMリリースにも期待している

  • Unsloth quantization版もあわせて公開された。GLM-5.1-GGUFモデルのIQ4_XSは754Bパラメータで361GBもあり、一般的なローカルLLMファンが動かすには無理がある

    • 良いソフトウェアサポートがあれば、SSDオフローディングも可能だ。もちろんその場合は「実行」というより「這う」レベルだろうが、それでもローカルで応答は得られる。最近では、そもそもSSDオフローディングを考慮してn-gram、内部埋め込みパラメータ構造を設計する試みまで出てきている

  • このモデルは、私のために素晴らしいペリカンの絵を描いてくれただけでなく、それをアニメーションにもしてくれた
    関連リンク

    • はるかに現実的な表現だ。ペリカンは自転車に乗るより空を飛ぶ方が自然だ
    • Simon、そろそろもっと良いベンチマークを作る時だ

  • 正直少し残念だ。GLM 5.1はOpusやCodexよりずっと良いTypeScriptを生成するが、長いコンテキストでは時々おかしなモードに入る。それでも20万トークンを超えて安定して動作したセッションもあった

    • ちゃんと動いて速度もそこそこなら、本当に印象的だ。昨日はKimi K2.5が解けなかった問題を解決した。ただ、まだ遅い時がある。Opus 4.5級に近い感触だ
    • 私はコンテキストウィンドウを100kに設定し、定期的にcompactするか状態を文書化して新しいセッションを始めている。最近はOpus 4.6が不安定なので、主にGLM 5.1を使っている。オープンモデルの品質がここまで良くなったのは驚きだ
    • オープンソースモデルがクローズドモデルより優れているのは、ユーザーにとって純利益だ
    • 10万トークンあたりになったら、新しいセッションを開くか/compactコマンドを使うべきだ
    • 昔のClaudeとCodex時代の癖が残っていて、今でもコンテキストを頻繁に整理している。どれだけ最新のモデルでも、巨大なコンテキストはまだ信用していない

  • GLM-5.0は、オープンソースモデルの中でも本当に実力がある。内部ベンチマークでは常に上位で、GPT-5.2と似たレベルだ。コーディングよりも非構造化タスクで主に使っている

    • 5.1はまだ使っていないが、PHPコーディングではSonnet/Opus/GPT-5と99%同じ結果を出す。しかもローカルでも動かせる
    • 私はPython ↔ Cython変換用データセットを作っているのだが、Gemini Pro 3.1に次ぐ高い受理率（16%）を示している。中位クラスのモデルは6～7%程度なので比較にならない
    • 私のユースケースはコード作成よりコードベースの理解と文書分析寄りだが、このモデルは米国系モデルより半額で、しかもより良く動く

  • 私のテストでは、GLM 5.1はGLM 5より性能が低い
    比較リンク
    モデルは今やエージェント型/コーディング中心にチューニングされたようだ

    • 特に**(none)**版で性能低下が顕著だ

  • モデルの品質をエージェントが生成したコードの実行速度で評価するアプローチが興味深い。私はベンチマークを作り、基準を定めた上で、1.4倍以上改善する形でテストしている。Opus 4.6はRustコードで低レベル最適化を見つけ、従来より6倍高速にしつつ、テストもすべて通過した。こうした方法の方が、実際の性能をより実用的に比較できる

  • コメントを見ると、まるで皆このモデルを長く使ってきたかのように話しているが、本当にそうなのか気になる

    • ブログ記事は新しく上がったものだが、モデル自体は2週間前から公開されていた
    • 地元のテニスコート予約サイトが壊れたのでGLM-5.1にAPIを分析させたところ、5分で**/cancel.php**エンドポイントを見つけ、ブラインドSQLインジェクションで予約IDを抽出した。積極的すぎたが、本当に驚いた
    • かなり前から公開されていた

  • GLM 4.7 Flash版をローカルでエージェントコーディング用として主に使っているが、本当に素晴らしい。今回もFlash版が出ることを期待していたが、リリースノートでは触れられておらず残念だ。それでも、近いうちに出ると信じている