【AI】中国のオープンウェイトモデル「GLM-5.2」が脆弱性検出ベンチマークでClaude Codeを上回る [すらいむ★]

中国のオープンウェイトモデル「GLM-5.2」が脆弱性検出ベンチマークでClaude Codeを上回る

　中国のAI企業であるZ.aiが2026年6月に発表したオープンウェイトのAIモデル「GLM-5.2」が、脆弱(ぜいじゃく)性の検出精度を測定するベンチマークにおいて、AnthropicのClaude Codeを上回ったと報告されました。

　We have Mythos at Home: GLM 5.2 beats Claude in our Cyber Benchmarks | Semgrep
　https://semgrep.dev/blog/2026/we-have-mythos-at-home-glm-52-beats-claude-in-our-cyber-benchmarks/

（以下略、続きはソースでご確認ください）

Gigazine 2026年06月30日 23時00分
https://gigazine.net/news/20260630-glm-5-2-beats-claude-cyber-benchmarks/

日本遅れてるな

人材が海外に出てるんじゃ？

ハッキングで鍛えた実績がある

何回騙されるん？

>>1
中国だしなぁ…、の一言で終わる。

おおっと
やはり躊躇した方が負けるなこれは
アメリカヤバいで

そりゃ、脆弱性を突いて、悪さするのが仕事みたいな国だからな

盗んで世界一へ伸し上った大朝鮮
こっちは、ゆっくり一歩ずつ確実に基礎を固め、登る

待ってました、と北朝鮮ロシア
ボロ儲けの絶好の機会が来たーーー
不公平なことに中国は狙わない両国

技術提供元は、nvidia（glm-5.2）
半導体もnvidiaから

これ中国らしい物は言いようって気がするよ。
欧米のサーバーをAIを使ってハッキングしまくっていたら、ハッキング能力に特化しちゃったってオチだろ。

以前にも中華スマホでも中国共産党からの監視用の穴を開けまくっていた時のノウハウが溜まって”個人情報へアクセスするアプリを監視できるようになった”とか自慢してたんだよね。

日本のオープンモデルって全然目立たないよね
デカくてカネあるところでも平気で「〇〇のモデルを日本語で教育して〜」とか
まさに二番煎じでしかないのをドヤ顔でプレスリリースしてみっともない

世界の皆さんが無視する中国の発表ですね

現在、Artificial Analysisにおいて「オープンウェイト」モデルのトップに君臨しているのがGLM 5.2です。これはパラメータ数7,530億という怪物級のモデルであり、フル精度（FP32）では1.51TBもの容量を要します。これをそのまま動かせるローカル環境を持っている人はまず存在しません。

重要なのは、どのクオンタイズバージョンをターゲットにし、それを動作させるために何が必要かという点です。

選択肢は、Mac Studio 1台から、GPU 4枚搭載のワークステーション、GPU 8枚搭載のデータセンター向けノードまで多岐にわたり、システムRAMへのオフロード（低速ですが実行は可能）という手段も含まれます。

多くのユーザーが目指すべき「最適なクオンタイズレベル」は「収まる範囲で最大のもの」でも「動く範囲で最小のもの」でもありません。

本ガイドでは、Unslothによるクオンタイズの段階を実際のファイルサイズと共に解説し、各ハードウェア構成で何が実行可能かを提示します。そして最後に、そもそもローカルで実行すべきではない大多数（95%）のユーザーに向けた、現実的な「撤退の選択肢」についても触れます。


ちなみにおれGLM4.7のクオンタイズ版は24GB mac mini m4 pro でゆっくりレベルで動いてくれるぜ

2026年6月16日にGLM 5.2がリリースされると、わずか数日でArtificial Analysis社の「オープンウェイト・インテリジェンス・インデックス」の首位に躍り出ました。MITライセンス、100万トークンのコンテキストウィンドウ、そして実際のソフトウェアエンジニアリング業務においてクローズドな最先端モデル（フロンティアモデル）に肉薄するスコア。当然ながら、Redditの「r/LocalLLaMA」コミュニティでは即座に「自宅で動かせるのか？」という疑問が持ち上がりました。

結論から言えば「イエス」ですが、その「自宅で」という言葉には、かなり大きな前提条件が含まれています。完全なウェイト（モデルの重み）のサイズは1.51TBにも及びます。これは「GeForce RTX 3090でダウンロードして動かせる」ようなモデルではありません。まずは「メモリ要件の計算」が必要なモデルであり、ネット上に出回っているガイドの多くはその計算プロセスを省略してしまっているのです。

そこで、実際に計算してみましょう。以下はUnslothによる最新の量子化対応表（クオンタイゼーション・ラダー）です。単一マシンから8基のGPUを搭載したノードに至るまで、現実的なハードウェア構成ごとの対応状況や実際に搭載可能なモデルサイズを網羅しています。また、これを読んで「割に合わない」と正しく判断した人のための、API利用という選択肢も併せて紹介します。

GLM 5.2の正体

GLM 5.2はZ.aiによる「Mixture-of-Experts（MoE）」モデルです。総パラメータ数は7,530億に及びますが、1トークンあたりの処理で実際に稼働するのは約400億パラメータに過ぎません。この「差」こそが、これほど巨大なモデルをローカル環境で動かすことについて議論できる理由となっています。ルーター（制御機構）がトークンごとに少数の「エキスパート」を選択するため、1トークンあたりの計算量は400億パラメータ級で高速に処理されますが、メモリ上には7,530億パラメータ分をすべて読み込んでおく必要があります。当社のMoE解説記事をご覧になった方ならお分かりでしょうが、これはMixtralやDeepSeekが採用した「400億パラメータ級の動作速度と7,530億パラメータ級のモデルサイズ」というトレードオフと同じ仕組みであり、単にその規模がはるかに大きいというだけのことです。

公式モデルカードに記載されているその他の仕様は以下の通りです。

ライセンス：MIT。地域制限や利用規約上の付帯条件（acceptable-use rider）は一切なし。真にオープンなモデルです。
コンテキスト：100万トークン。長期的なエージェントタスク向けに設計されています。
モダリティ：テキストのみ。画像認識機能（ビジョン）は搭載していません。
ネイティブ精度：BF16。
リーダーボード上での評価も、その期待に違わぬものです。「Artificial Analysis」のオープンウェイト・インテリジェンス・インデックスではスコア51で首位に立ち、「SWE-bench Pro」では62.1を記録しました。これはクローズドな最先端モデル（フロンティアモデル）に肉薄する数値であり、多くのコーディングやエージェント・ワークフローにおいては、その性能差が技術スタック選定の決定的な要因にはならないレベルに達しています。これが本モデルの「売り」です。では、実際のところはどうなのでしょうか。

サイズという現実

ネイティブはBF16フォーマットで、GLM 5.2の重み（ウェイト）データは1.51TBにも及びます。ギガバイトではなく、テラバイト単位です。

Appleがこれまでに発売した中で最大のユニファイドメモリは512GB版Mac Studio。その3分の1すら収まりません。エヌビディアH100 GPUを8基搭載し、利用可能なVRAMとしては最速かつ最大級の640GBを備えたノードだとしても半分がやっと。GLM 5.2をフル精度で動作させることは、データセンターのラック単位での運用を要する規模というわけです。

それで何の問題もありません。誰もそこまでする必要はないからです。

そこでクオンタイズ。重みの精度を16ビットから4ビットに落とせば、メモリ使用量を約4分の1に減らせる。適切なクオンタイズなら、精度の低下はごくわずか。ほとんどの用途では劣化は無視できるレベルです。

「GLM 5.2を動かせるか？」という問いは、実質的に「クオンタイズの段階をどこまで下げるか、そしてそれを何で動かすか」という話なわけです。というわけで、そのクオンタイズのレベルを見ていくことにします。

クオンタイズのレベル
（Quant ladder）

以下は、UnslothのGLM-5.2リポジトリから取得した最新のGGUFサイズ。Unslothの「Dynamic 2.0」クオンタイズ手法は、モデル全体に​​一律のビット幅を適用するのではなく、重要な層にはより多くのビットを割り当て、重要度の低い層には少ないビットを割り当てます。そのため、同名の単純なクオンタイズ手法と比較して、同じサイズでも品質（完全なBF16モデルからのKLダイバージェンスで測定）の低下を抑えることができます。

これが、以下の「UD-」クオンタイズモデルがそのビット数以上の性能を発揮する理由です。

クオンタイズ手法 サイズ ビット数 BF16との品質比較
UD-IQ1_S 217 GB 1-bit 大幅な品質低下。動作はするが、明らかに賢さが劣る
UD-IQ1_M 228 GB 1-bit 大幅な品質低下
UD-IQ2_XXS 238 GB 2-bit 顕著な劣化
UD-IQ2_M 239 GB 2-bit 顕著な劣化
UD-Q2_K_XL 254 GB 2-bit 緊急時には使用可能だが、推論の連鎖（reasoning chains）に難あり
UD-IQ3_XXS 282 GB 3-bit 実用的なレベルになりつつある
UD-IQ3_S 309 GB 3-bit サイズを考慮すると堅実な性能
UD-Q3_K_M 343 GB 3-bit 「GLM 5.2らしさ」を維持できる現実的な最低ライン
UD-Q3_K_XL 343 GB 3-bit 実用上の推奨ターゲット
UD-IQ4_XS 365 GB 4-bit ほとんどのタスクで区別がつかないレベル
UD-IQ4_NL 373 GB 4-bit ほぼ区別がつかない
UD-Q4_K_S 436 GB 4-bit 非常に優秀
UD-Q4_K_M 466 GB 4-bit 非常に優秀
UD-Q4_K_XL 467 GB 4-bit 品質とサイズのバランスが取れた最適解（スイートスポット）
UD-Q5_K_S 527 GB 5-bit ここから効率の低下（収穫逓減）が始まります。
UD-Q5_K_M 561 GB 5-bit Q4と比べてわずかな向上
UD-Q5_K_XL 562 GB 5-bit わずかな向上
UD-Q6_K 626 GB 6-bit BF16との違いは判別できません
UD-Q6_K_XL 684 GB 6-bit 同上
Q8_0 801 GB 8-bit 実質的にロスレスですが、ローカル環境では実質的に無意味です
UD-Q8_K_XL 820 GB 8-bit 同上
BF16 1.51 TB 16-bit フル精度

自分で入れて自分で検知

どれをターゲットにすべきか、その判断基準は以下の通り

品質とサイズのバランスが最も良い「スイートスポット」は、467GBの「UD-Q4_K_XL」
このあたりで品質向上のカーブが緩やかになり、これ以上サイズを大きくしても、体感できるほどのメリットはほとんど得られない。
しかし、品質だけが判断基準ではありません。モデルの重み（ウェイト）は、実際に構築可能なハードウェアに収まらなければならない。467GBというサイズは、読み込ませる（動かす）のが非常に大変

そのため、実際に自分でホスト（運用）しようと考えている大多数の人にとっての答えは、一段階下の343GB版「UD-Q3_K_XL」になります。これでも「GLM 5.2」と同等の推論能力を維持しつつ467GB版では収まらない現実的な構成（単一サーバーやGPU 4枚構成など）に収まるのが343GBというサイズというわけ。「Q3_K_XL」を基本のターゲットとし、「Q4_K_XL」は「メモリに余裕があれば選ぶアップグレード版」と考えるのが良。

ここで一つ、指摘しておきたい意見の相違があります。それは、この表の出典元であるリポジトリ（Unsloth）自身の見解についてです。

彼らの推奨は私よりも低いスペックを指しています。「アクセシビリティと精度のバランスが最良」な選択肢として2ビットの「UD-IQ2_M」（239GB）を挙げていて、その精度を約82%と評価し、さらに1ビット量子化版でも「十分に機能する」としている。

これは単なる保険をかけた発言ではなく、彼らの確固たる見解。
汎用的な用途であれば、彼らの言う通り。
2ビット版なら安価なハードウェアで性能も破綻せずに維持される。

私が推奨ラインを一段階高く設定している理由は「コーディング」や「マルチステップのエージェント作業」用途。低ビット量子化による性能低下が顕著に表れ、推論の過程で小さな誤差が積み重なり、単なるチャットでは現れないような問題が実際のタスク実行時に露呈する。

一般的な用途であれば、Unsloth推奨の2ビット版を選んでコストを抑えるのが賢明。しかし、コーディング用モデルとして運用するなら、やはり「Q3」からがお勧め。

KVキャッシュ用のメモリ領域（ヘッドルーム）を確保することも重要。コンテキスト長を最大に近い1M（100万トークン）に設定すると、キャッシュだけで数十ギガバイトを消費する。

ハードウェア構成の選択肢：低コストから高速動作まで

実際に動かすための方法は4とおり。どれも安上がりとは言えません。

1. システムRAMへのオフロード — 実現可能だが、苦痛を伴う

データセンター向けGPUを使わずとも、llama.cppを使い、CPUとシステムRAMだけでGLM 5.2を完全に動作させることが可能。DDR5メモリを384GB以上搭載したワークステーション（ThreadripperやEpycを搭載し、すべてのメモリチャネルを埋めた構成を想定）に「UD-Q3_K_XL」（343GB）を読み込めば、推論（テキスト生成）を行えます。ここで役立つのがMoE（Mixture of Experts）という設計です。トークンごとにアクティブ化されるパラメータは40B（400億）分だけなので、753Bの密な（dense）モデルの場合ほど、CPUでの推論が絶望的な遅さになるわけではありません。

ただし、落とし穴があります。それは「遅い」ということです。生成速度は1秒あたり数トークン（low-single-digit）程度にとどまります。バッチ処理や一晩かけて実行するようなタスクなら許容範囲ですが、対話的な利用には向かず、非常にストレスが溜まるでしょう。また、現在のメモリ市場においてDDR5を384GBも揃えるとなれば、決して安い出費ではありません。これは「このためだけにGPUを買うのは絶対に嫌だ」という人が選ぶ道です。動作はしますが、快適とは言えません。