GLM-5.2は、2026年6月にMITライセンスでフルウェイトが公開されたオープンウェイトのコーディング向けモデル。長期のコーディングやエージェント用途で注目を集め、「重みが公開された＝自分のPCで動かせる」と受け取られがちです。ただ、この2つは別の話。重みを誰でもダウンロードできることと、手元のマシンで実際に動かせることのあいだには、かなり大きなメモリの壁があります。
約750B級という規模は、家庭用GPUのVRAMでは量子化してもまず載りません。配布されている量子化ファイルは、最小級でも約217GBあります。本稿では必要メモリを具体的な数字で詰めたうえで、16GB／32GBの実機ベンチが示す限界線を起点に、ユニファイドメモリ機でどこまで届くのか、そして現行で購入できるハードウェアの限界がどこにあるのかを整理します。
- ・GLM-5.2は約750B級（活性40B級）のMoE。配布GGUFは最小級の1bit量子化でも約217GBある
- ・専用VRAMの家庭用GPU（16〜32GB）では量子化しても載らない。最小GGUFが約217GBあり、筆者の検証環境で快適に回せた範囲は35B級MoEまで
- ・ユニファイドメモリが鍵になるが、128GB級では届かない。現行で新規購入できるM3 Ultra Mac Studioは96GB構成で、最小217GBの量子化ファイルにも届かない
- ・現実に扱うには、過去の大容量Mac構成（中古・整備済み）、業務用デスクサイド機、大容量メモリのサーバー級構成が要る。本稿で確認した主要な消費者向け・小型単体機の公式販売構成には、2026年6月時点でGLM-5.2を快適に動かす実用解が見当たらない
GLM-5.2とは何か｜約750B級のMoEとオープンウェイト公開
GLM-5.2は、Z.ai（旧Zhipu AI）が公開したMoE（Mixture of Experts）型のモデルで、DeepSeek Sparse Attention（DSA）を組み合わせた構成。各MoE層に256の専門家（routed experts）を持ち、1トークンあたりではそのうち8個を使います。パラメータ数は出典で表記が割れており、GLM-5系の公開資料では744Bと説明される一方、GLM-5.2のGGUF配布ページは754B、Ollamaのモデルページは756Bと表示します。カウント基準や付随層の扱いによる差を含むため、本稿ではまとめて「約750B級」と表記します。活性パラメータは40B級、コンテキスト長は最大100万トークン、ライセンスはMITです。
| 項目 | GLM-5.2 |
|---|---|
| アーキテクチャ | MoE ＋ DSA（DeepSeek Sparse Attention） |
| 総パラメータ | 約750B級（GLM-5系資料は744B／GLM-5.2配布表記は754〜756B） |
| 活性パラメータ（1トークンあたり） | 約40B級 |
| 専門家（expert）数 | 256 routed experts（各トークン8個を使用） |
| コンテキスト長 | 最大100万トークン |
| ライセンス | MIT（フルウェイト公開） |
| 主な狙い | 長期コーディング・エージェント用途 |
評価面では、Z.aiがTerminal-Bench 2.1、SWE-bench Pro、FrontierSWEなどで高い成績を公表しています。ただし公開直後のモデルであり、推論ハーネスやトークン予算、ツール構成をそろえた独立比較はまだ限られます。ここではベンダー公表値を性能の確定的な順位ではなく、モデルの狙いと注目度を示す材料として扱います。ベンチの読み取り方そのものに注意が要る点はローカルLLMのベンチマーク数値の読み取り方でも触れたとおりです。
導入経路についても整理しておきます。2026年6月時点で、Ollamaの公式ライブラリにはglm-5.2:cloudがあり、ollama run glm-5.2:cloudでクラウド実行できます。ただしこれは:cloudが示すとおりホスト型の推論で、手元の機材で動かすローカル実行ではありません。ローカルで試すなら、UnslothなどがHugging Faceで公開している量子化済みGGUFを、llama.cpp系やOllamaで扱う方法があります。vLLMのGGUF対応は公式に実験的・低最適化とされ、2026年6月確認時点のドキュメントでは別途プラグイン（vllm-gguf-plugin）の導入が前提です（安定版・開発版で挙動が変わり得るため、導入前に使用版のGGUFドキュメントを確認してください）。GLM-5.2のGGUFは複数ファイルに分割されているため、vLLMで扱うなら、使うvLLM版・プラグイン・量子化ファイルの結合やtokenizer互換性を個別に確認する必要があります。一方、複数GPU・複数ノードで本格的にサーバー運用するなら、GGUFよりもBF16／FP8の重みをSGLangやvLLMで扱う構成が中心です。いずれにせよ起動経路は用意されていますが、後述するとおりファイルサイズが巨大なため、「コマンドがある」ことと「一般的な家庭用PCで実用的に動く」ことは別問題です。
本稿はローカル実行に絞りますが、GLM-5.2は重みを落として自前で動かすオープンウェイトとしてだけでなく、Z.ai自身が公式のAPIやサブスクのコーディングプランとして、ホスト型でも提供しています。Ollamaの
glm-5.2:cloudも、このホスト型の推論に接続する経路。つまり「自宅の機材で動かす」と「公式のクラウドで使う」の二通りの入口があり、家庭用ハードで動かせないことが、そのまま「使えない」を意味するわけではありません。本稿が扱うのは前者（自宅で動かせるか）ですが、2026年6月時点では公式APIやOllama cloudなどのホスト型の入口も用意されています（いずれもアカウント・料金・利用上限・データ取り扱いポリシーの確認は必要）。量子化済みファイルでも最小217GB｜サイズの桁が合わない
「巨大なモデルでも量子化すれば小さくなる」は半分正しく、半分は楽観的です。量子化は1パラメータあたりのビット幅を削ってサイズを圧縮する手法で、確かにサイズは小さくなります。問題は、元が約750Bと大きすぎるため、削ったあとでも家庭用GPUの容量とは桁が合わないこと。
下の表は、UnslothがHugging Faceで配布しているGLM-5.2向けGGUFのファイルサイズ目安です。無圧縮のBF16は約1.51TB。攻めた低ビット量子化まで落としても、最小級で約217GBあります。
| 形式 | GLM-5.2のファイルサイズ目安 | 家庭用GPUのVRAM（16〜32GB）で載るか |
|---|---|---|
| BF16（無圧縮） | 約1.51TB | 論外 |
| 1bit級 UD-IQ1_S | 約217GB | 不可 |
| 1bit級 UD-IQ1_M | 約228GB | 不可 |
| 2bit級 UD-IQ2_XXS | 約238GB | 不可 |
| 2bit級 UD-IQ2_M | 約239GB | 不可 |
| 4bit級 UD-IQ4_XS | 約365GB | 不可 |
| 4bit級 UD-Q4_K_XL | 約467GB | 不可 |
注目したいのは最小行。重みをここまで削ると品質低下の可能性は大きくなりますが（本稿では量子化別の品質は評価していません）、それでも約217GBが必要です。なお本稿のGGUFサイズはHugging Face上のファイルサイズ（10進GB表記）で、217GBは約202GiBに相当します。nvidia-smi等のGiB／MiB実測表示とは基準が異なるため、256GB前後の比較では換算に注意してください。家庭用GPUのVRAMが16〜32GBであることを思い出すと、最小構成でも一桁違う、という関係が見えてきます。量子化による圧縮と精度のトレードオフ自体はローカルLLMの量子化はどれを選ぶかで実測込みで整理していますが、GLM-5.2の場合は「どの量子化を選ぶか」以前に「そもそも器に入るか」が先に問われます。
さらに見落とせないのは、上のサイズがあくまで量子化済みファイルそのものの大きさで、実行に必要なピークメモリではないという点。実際の推論では、OSや推論エンジンの作業領域、文脈を保持するKVキャッシュがこれに上乗せされます。GLM-5.2は最大100万トークンの文脈をうたうモデルで、長い入力を流し込むほどこの上乗せは膨らむ。つまり「最小で約217GB」はファイルが載るための下限であって、まともな文脈長で使おうとすれば、実際に要るメモリはここからさらに上振れすると見ておくのが安全です。後段の容量比較も、この「ファイル＋実行時の上乗せ」を念頭に、搭載メモリには相応の余裕を見て読んでください。
「活性40Bだから軽い」という誤解
MoE型と聞くと、「活性が40Bなら、40Bモデル並みのメモリで動くのでは」と考えたくなります。これは速度とメモリを混同した見方で、半分外れています。
MoEは各トークンで256の専門家のうち8個だけを使うため、1トークンあたりの計算量は活性40B相当で済みます。生成速度が総パラメータの割に速いのはこのおかげ。ところが、どの専門家が選ばれるかはトークンごとに変わるため、モデル全体の重みは総パラメータ数に近い規模を抱えることになります。つまり、速度は活性パラメータ（40B級）で、ファイルやメモリの規模は総パラメータ（約750B）で決まる。「活性40BだからVRAM40GBで足りる」は成り立ちません。
もっとも、全部の重みを常にGPUのVRAMへ載せておくことだけが選択肢ではありません。実装によっては、当面使わない専門家をCPUのRAMやストレージへ逃がし、必要になったら読み込むexpert offloadingやメモリマップといった手も使えます。Unslothの大型MoE向けガイドでも、少ないVRAMに大きなシステムRAMを組み合わせてMoEをoffloadする例が示されています。ただしその場合、転送やメモリ帯域がボトルネックになりやすく、生成速度は大きく落ちます。要するに、活性40Bだから40GB前後のVRAMで快適に動く、とは言えない、というのがここでの結論。この性質は小さなMoEでも同じで、検証環境で測ったQwen3.5系の35B-A3B（活性3B）も、速度は軽快な一方、重みのサイズは総35B側に近く、16GBのGPU単体では収まりきらずあふれます。MoEが省電力・高速で回る仕組みはRTX 5080でMoEモデルだけ消費電力が1/4に落ちる、あふれた分を2枚目のGPUへ逃がす挙動は16GB VRAMで38%あふれるqwen3.5:35b-a3bで扱っています。
専用VRAMの家庭用GPUでは届かない｜実機の天井
では、実際に家庭用GPUではどのあたりまで快適に動くのか。筆者の検証環境（16GB級のGPU単体、あるいは32GB級のデュアル構成、例：RTX 5080 ＋ RTX 5060 Ti、2026-06-18計測）で快適に回せた範囲は、35B級のMoEまででした。これは同条件での参考値であり、16GB／32GB級GPU全般の仕様上限ではありません。
| モデル（量子化Q4級） | 16GB級単GPU | 32GB級デュアル | 備考 |
|---|---|---|---|
| qwen3.5:35b-a3b（MoE・活性3B） | 66.8 tok/s（VRAMほぼ満杯） | 117.6 tok/s | 単GPUでは約4割があふれてCPU側へ |
| qwen3-coder:30b（MoE） | あふれ前提 | 144.6 tok/s | この検証環境で最も高速だったコーディング用モデル |
| qwen3:32b（Dense） | 厳しい | 25.9 tok/s | Dense型はオフロードで失速 |
| gemma4:26b | 65.5 tok/s | 101.2 tok/s | 16GBの天井近くまで使用 |
表の上限にいる35B級MoEでも、Ollama公式タグのQ4級ではおおむね18〜24GB級で、モデルによっては16GB単体だとCPU側へのオフロードが前提になります。GLM-5.2の最小GGUF約217GBは、そこからさらに10倍前後のサイズです。「VRAMに載らないならCPUのRAMへ逃がせばいい」という発想（VRAMに収まらない大型LLMをRAMオフロードで動かすで扱った手法）も、GLM-5.2の規模では足りません。仮に96GBのシステムRAMと32GBのVRAMを合算しても128GBで、最小級の約217GBに対しておよそ89GB足りない。しかも「VRAMとRAMを単純合算すれば届く」という見方は速度面では危険で、CPUオフロード時にはメモリ帯域と転送設計がボトルネックになります。16GBで27B・32B級が動かない理由を細かく追ったRTX 5080 16GB VRAMの壁や、用途別に16GB GPUを整理したVRAM 16GB GPU を選ぶならと同じ理屈が、ここでは桁を上げて立ちはだかります。
では、もっと大きなGPUや複数枚を足せば届くのか。ここでも器の壁が先に来ます。GLM-5.2のFP8重みは約0.75TB級、BF16は約1.5TB級。H200は1枚141GBのHBM3eを積むため、8枚構成なら合計約1.13TBとなり、FP8版を扱うデータセンター級の構成としては候補に入ります。
ただし、これは重みだけを見た話です。実際にはKVキャッシュや推論エンジンの作業領域も上乗せされます。BF16版は約1.5TBあるため、H200（141GB）やB200（192GB）を8枚積んだ単一ノードには収まらず、B300（288GB）を8枚積む構成か、複数ノードが必要になります。このFP8／BF16で要るGPU構成の整理は、GLM-5.2向けSGLang公式ガイドの案内とも揃います。
つまり、コンシューマ向けGPUを数枚足した程度では、最小217GBの量子化ファイルさえ実用的に扱いにくい。CPUのRAMへオフロードして実行経路を作ることはできても、速度はGPUとCPUメモリ間の転送、システムRAMの帯域、量子化方式、推論エンジン、文脈長に大きく左右されます。載るかどうかと、使える速度が出るかどうかは別問題です。
そうなると、個人が一台のマシンで現実的に狙えるのは、専用VRAMを束ねる方向ではなく、大きな器を一つ持つ——ユニファイドメモリの方向です。ただし後述するとおり、その大容量構成は新品市場から急速に姿を消しています。
ユニファイドメモリで届くのか｜容量と帯域の現実
専用VRAMで詰まる根っこは、GPUが基本的に自分のVRAMしか高速に触れない点にあります。大きな器（CPUのRAM）はあるのに、そこへ逃がした瞬間に帯域が落ちる。ユニファイドメモリは、CPUとGPUが同じ大容量メモリプールを共有するため、大きな器にモデルを載せたまま、GPUがそこそこの帯域で直接アクセスできる。容量と帯域の妥協点が、専用VRAM＋CPUオフロードより一段高くなります。ただしGLM-5.2の規模に対しては、このユニファイドメモリでも容量帯ごとに届く・届かないが分かれます。
128GB級｜100〜200B級までは開くが217GBには届かない
AMDのStrix Halo（Ryzen AI Max+ 395）は、AMD公式仕様で最大128GBのLPDDR5X-8000メモリに対応し、メモリ帯域は理論256GB/s。GPUが扱える領域は製品実装に依存し、たとえばFramework Desktopでは最大96GBのgraphics-addressable memoryとうたわれています。実効帯域は構成と測定方法に依存して理論値を下回りますが、本稿では実測していません。NVIDIAのDGX Spark（GB10）は128GBのユニファイドメモリで帯域は毎秒およそ273GB。どちらも、70BをQ4で余裕を持って載せられる、専用GPUでは難しかった領域を一気に開きます。目安として、NVIDIAはDGX Spark単体で最大200B、2台接続で最大405Bのモデルを扱えるとうたっています。
ただし、GLM-5.2の最小級である約217GBには容量が足りません。1bit量子化でも128GBを超えるため、これらの128GB級では単体で載せられない。Strix HaloやDGX Sparkは「100〜200B級を静かに低電力で回す」ための強力な選択肢ですが、約750Bに対しては手前で止まります。
Appleストアの現行構成は96GB止まり｜最小量子化ファイルにも届かない
大容量のユニファイドメモリといえばApple Siliconが代表格です。M3 Ultraを積むMac Studioは、登場時には最大512GBの構成も選べ、技術仕様上は256GB構成にも対応していました。ところが2026年に入って販売構成は段階的に縮小しました。報道によれば3月に512GB、5月までに256GBが新規購入の選択肢から外れ、2026年6月時点でAppleオンラインストアから新規に選べるM3 Ultra Mac Studioは96GB構成のみです（Apple公式ページで確認できるのは現在の販売構成で、削除の時期・背景は報道ベース）。2026年6月確認時点のapple.com（米国）の現行Mac Studio仕様・購入ページでは、M3 Ultraの新規購入構成は96GBで、メモリはConfigure to Order対象外（Not configurable）と表示されます（地域・時点で構成は変わり得ます）。なおApple Supportの2025年発売時の技術仕様ページには256GB構成可能の記載が残るため、購入可否は現行の販売ページで最終確認してください（発売時には最大512GB構成が案内されていました）。なお、この縮小はメモリ供給の逼迫を背景とする市場観測として報じられているもので、Appleが理由を公式に説明したわけではありません。メモリの容量や価格そのものが入手性の制約になる局面は、AIハードウェアはいつ買うべきかでも触れたテーマです。
この96GBという上限が、GLM-5.2には決定的に足りません。最小級の1bit GGUF（約217GB）でも、96GBではファイル単体すら収まらない。M3 Ultraの毎秒約819GBという高いメモリ帯域は大型推論に有利な設計ですが、GLM-5.2では帯域以前に容量が足りない、というのが現状です。Mac側でローカルLLMを回す実測の感触はMacBook Air M5でローカルLLM 21モデル比較でも見たとおりですが、約750B級はその射程の外にあります。
| 構成 | メモリ容量 | 帯域（目安） | GLM-5.2（最小約217GB）を実用的に動かせるか |
|---|---|---|---|
| 家庭用専用GPU（RTX 5080等） | VRAM 16〜32GB | 速いが容量が小さい | ✗ 量子化しても遠い（上限は35B級MoE） |
| AMD Strix Halo（Ryzen AI Max+ 395） | ユニファイド 128GB（GPU割当は実装依存・最大96GB級） | 理論256GB/s（実効は下回る） | ✗ 70B Q4は余裕だが217GBに届かず |
| NVIDIA DGX Spark（GB10） | ユニファイド 128GB | 約273GB/s | ✗ 目安〜200B（2台で405B） |
| 現行Mac Studio M3 Ultra（新規購入構成） | ユニファイド 96GB | 約819GB/s | ✗ 最小217GBの量子化ファイルすら収まらない |
| 業務用デスクサイド／大容量メモリのサーバー級 | 数百GB〜 | 構成による | △〜○ 構成と推論エンジン次第・短文脈でも実測確認が必要 |
では何なら現実的に扱えるのか。やっかいなのは、単体マシンの解がほぼユニファイドメモリ一択でありながら、その大容量構成が新品市場から消えてしまった点です。消費者向けの単体マシンに限れば、過去の256GB・512GB構成のM3 Ultra Mac Studioを中古・整備済み市場で探す道が見えやすい（在庫は流動的で、それでも短い文脈が前提）。ただし業務用まで含めれば、NVIDIA DGX Stationのように数百GB規模のcoherentメモリを備えたデスクサイド機もあり、さらに上はFP8の重みを載せるだけでH200を8枚（合計約1.13TB）要するサーバー構成の世界（SXM/HGXのデータセンター向けGPUで、Linuxサーバー・kW級電源・専用冷却が前提）。いずれも一般的な新品PCの予算・消費電力・設置性からは大きく外れます。「Macだけが単体解」というわけではありませんが、消費者が手の届く単体機という条件を付けると、選択肢が事実上、過去の大容量Macに寄っていく、というのが2026年6月の実情です。
速度の面も触れておくと、容量が足りても快適とは限りません。低ビット量子化の超大型モデルは、容量の壁を越えてもメモリ帯域が生成速度の頭打ち要因になりやすく、専用GPUで小型モデルを回すような軽快さは期待しにくい。容量で「載る」ことと、速度で「使える」ことは別の指標として見ておくのが安全です。
結局どう選ぶか｜現実的な選択肢
「最強のオープンウェイトが公開された」という話に引っ張られすぎず、自分の用途と機材から逆算するのが現実的です。大きく三つの方向があります。
一つめは、35B級MoEで足りないか再考すること。 コーディング補助の多くは、検証環境でqwen3-coder:30bが32GB級デュアルで毎秒140トークン超を出すように、35B級MoEで実用域に入ります。GLM-5.2の賢さは魅力ですが、日常のコード補完や短い生成なら、手元で高速に回る35B級のほうが待ち時間の面で有利な場面は少なくありません。ただし本稿では、GLM-5.2と35B級の回答品質・タスク成功率・主観的な体験までは比較していません。コーディング用途の必要スペックはAIコーディング用ローカルLLMの必要スペックに実測でまとめています。
二つめは、本気でローカルに置くなら業務用クラスの容量を見込むこと。 GLM-5.2を手元のマシンで動かすには、数百GB規模のメモリを積む業務用デスクサイド機や、大容量メモリのサーバー級構成が要ります。128GB級のStrix HaloやDGX Sparkは約750Bには容量が足りませんが、70〜200B級を低電力で静かに回す用途では強い。どの機材を選ぶにせよ、買う前に「動かしたいモデルの最小量子化サイズ＋実行時の余裕 ＜ 搭載メモリ」を必ず突き合わせること。
三つめは、クラウドのAPIや:cloud実行を使うこと。 重みがMITで公開されている強みは、自分の管理下のサーバで推論し、外部API・外部ツール・外部ログ保存を使わない構成にすれば、入力をモデル提供事業者へ送らずに運用できる余地がある点です。一方で、Z.aiや第三者が提供するAPI、あるいはOllamaのglm-5.2:cloudのようなホスト型実行は、入力がリモートで処理される（ローカル完結ではない）。ただし「リモートで処理される」ことと「保存される」ことは別で、たとえばOllamaはCloudについてデータ非保持をうたっています。提供元ごとに最新の利用規約・保持ポリシー・料金を確認したうえで、手軽さとデータ管理のどちらを優先するかで選ぶことになります。
まとめ｜「動かせる権利」と「動かせる機材」は別レイヤー
MITのオープンウェイトは、ライセンス条件に従えば誰でも利用・改変・再配布できるという開放であって、「誰のマシンでも動く」という保証ではありません。GLM-5.2を実際に動かせるかは、手元のメモリ容量と帯域で決まります。専用VRAMを増やす方向の家庭用GPUは、量子化しても最小217GBの器には届かない。ユニファイドメモリは方向としては正しいものの、128GB級では足りず、現行で新規購入できるMac Studioも最大96GBで、最小217GBの量子化ファイルにすら届きません。単体マシンで狙うならユニファイドメモリの大容量構成がほぼ唯一の道ですが、それは新品市場から消え、過去の大容量Mac（中古・整備済み）にほぼ限られてきている。本稿で確認した主要な消費者向け・小型単体機の公式販売構成には、GLM-5.2を快適に動かす実用解が2026年6月時点で見当たらない、というのが現在地です。もっとも、Z.aiは公式のAPIやコーディングプランとしてGLM-5.2をホスト提供しているため、「自宅で動かせない」ことと「使えない」ことは別問題。手元で動かすことにこだわらないなら、入口はちゃんと用意されています。
覚えておくと応用が利くのは、「最小量子化のファイルサイズ＋実行時の上乗せ ＜ 搭載メモリ」が動く・動かないの第一関門で、容量が足りたあとに帯域が速度を決める、という二段構え。GLM-5.2ならその下限が約217GBです。この見方さえ持っておけば、次にどれだけ巨大なモデルが来ても、自分のマシンで動くかどうかを数字で判定できます。あわせて、メモリの容量や価格そのものが入手性の制約になりつつある点（大容量Mac構成が新品市場から段階的に消えたことは、その一例）も、ハードウェア選びでは見落とせません。メモリの階層構造を用途別に俯瞰したAIエージェント自動化のメモリ消費も、あわせて読むと全体像がつかめます。
参考資料
- Z.ai（GLM-5.2 公式）
- Unsloth — GLM-5.2-GGUF（量子化ファイルサイズの一覧）
- Ollama — glm-5.2（cloud実行タグ）
- Apple — Mac Studio 技術仕様（ユニファイドメモリ構成）
- NVIDIA — DGX Spark（GB10・128GB統合メモリ）
- SGLang — GLM-5.2 デプロイガイド（FP8／BF16・必要GPU構成）
- NVIDIA — H200（141GB HBM3e 仕様）
- NVIDIA — DGX Station（大容量coherentメモリのデスクサイド機）
- MacRumors — Mac Studio／Mac mini のRAM構成削減（販売構成の時系列・報道）
