GLM 5.2 をローカルで動かす（2026 年版）— 256GB Mac や 4090 マシンで 2-bit 実行

Zhipu は GLM 5.2 のウェイトを MIT ライセンスで HuggingFace に公開しました。これで問いは「フロンティアのコーディングモデルをダウンロードできるか」から「いま手元にあるマシンで動くか」に変わりました。一台の Mac Studio や、GPU 一枚と大量の RAM を積んだデスクトップなら、答えは条件付きで「はい」です。その条件とは量子化です。

ローカルで動かせるもの（と動かせないもの）

本ガイドは、量子化した GGUF ウェイトと llama.cpp、LM Studio、または Unsloth Studio を使い、自分が所有する一台のマシンで GLM 5.2 を動かす話です。H200 を積んだラックでチームに配信するのとは別の仕事で、それは GLM 5.2 セルフホストのハードウェアとコストガイド が扱います。ホスト型 API を呼ぶのともまた別の仕事で、そちらは GLM 5.2 アクセスガイド が扱います。

GLM 5.2 は 1M トークンのコンテキストを持つ 753B パラメータのモデルで、MIT ライセンスでリリースされました。フル BF16 精度ではウェイトは ~1.5 TB に及び、どんな単一のデスクトップにも収まりません。ローカル推論とは量子化すること ― 多少の品質を、自分の RAM に収まるフットプリントと引き換えにすることです。どこに何が収まるか、30 秒版がこちらです。

正直な見出し ― 256 GB の Mac Studio で 2-bit 量子化を動かすのが、「デスクの上の GLM 5.2」の現実的な構成です。4-bit 量子化は品質のスイートスポットですが、512 GB マシンか重いオフロードを要求します。256 GB に満たないものは、ローカルではなくホスト型 API の仕事です。

判断フレーム：ローカルの GLM 5.2 に値するのはいつか（そして値しないとき）

正しい理由で量子化をローカル実行してください。間違った理由は節約です。ほとんどの人にとってホスト型プランの方が安いからです。

ローカルで動かすとき

• オフラインまたはエアギャップ作業。 api.z.ai への外向き通信が一切許されないので、モデルは自分のハードウェアに置くしかありません。
• 単一マシンでのプライバシー。 プロンプトとコードがマシンを離れず、一台の Mac Studio がそのまま境界の全体になります。
• すでにハードウェアを持っている。 動画や ML 作業のために買った 256 GB / 512 GB の Mac Studio が夜は遊んでいるなら、ローカル量子化を動かすのに追加コストはかかりません。
• いじって学ぶ。 753B MoE がどう振る舞うかを肌で感じたい、サンプリング設定を試したい、レート制限のないローカルの OpenAI 互換 endpoint に対して開発したい。

ローカルで動かさないとき

• 安く速くしたい。 Z.ai Coding Plan は月 ~$30 でフルスピードです。3-9 tok/s の 2-bit ローカル量子化は、電気代だけでもその価格には太刀打ちできません。アクセスガイド を読んでください。
• 2 人以上に配信する必要がある。 一台の Mac Studio は単一セッションのマシンです。2 人の開発者が同時に叩けば、双方とも這うような遅さを感じます。それはデータセンター経路です。
• マシンが 256 GB 未満。 GLM 5.2 を実用品質で 128 GB マシンに収める量子化は存在しません。週末を溶かして試そうとしないでください。
• フルの 1M コンテキストが必要。 長コンテキストの KV キャッシュはコンシューマハードウェアに収まりません。ローカルは実用上 16K-64K で頭打ちです。

中止ルール

ユニファイドメモリかシステム RAM が最低 256 GB なければ、ここで読むのをやめてホスト型プランを使ってください。どれだけ量子化してもこの下限は変わりません。

システム要件

flowchart TD
  A[メモリはどれくらい？] -->|512 GB Mac| B[4-bit UD-Q4_K_XL<br/>ローカル最高品質]
  A -->|256 GB Mac または DDR5| C[2-bit UD-IQ2_M<br/>よくある構成]
  A -->|256 GB 未満| D[ホスト型プランを<br/>ローカル向きではない]
  B --> E[llama.cpp / LM Studio / Unsloth Studio]
  C --> E

240 GB のウェイトを pull する前に、次を確認してください。

• メモリ。 最低 256 GB（Apple シリコンならユニファイドメモリ、CUDA マシンならシステム DDR5）。2-bit 量子化は ~240 GB なので、256 GB マシンでは余白が本当にギリギリです ― 他のアプリを閉じて macOS にユニファイドメモリの取り分を残さないと、スワップに落ちます。4-bit を快適に動かすには 512 GB です。
• ディスク。 量子化分プラス余白 ― 2-bit に ~240 GB、4-bit に ~376-475 GB の空き。回転ディスクではなく SSD を。さもないとロード時間が苦痛になります。
• ランナー。 最近のコミットからビルドした llama.cpp、LM Studio、または Unsloth Studio。アーキテクチャ（GLM MoE DSA）が新しいので、古い llama.cpp ビルドはテンソルのロードに失敗します。
• 正しいリポジトリ。 コミュニティ製の GGUF 量子化は huggingface.co/unsloth/GLM-5.2-GGUF にあります。公式の zai-org/GLM-5.2 リポジトリは BF16 のみで、ローカル推論には向きません。

ステップバイステップ：GLM 5.2 をローカルで動かす

Step 1：GGUF 量子化を pull する

リポジトリ全体ではなく、必要な量子化だけをダウンロードします。--include フィルタを使えば、使いもしない 750 GB のシャードを取りに行かずに済みます。

# 256 GB マシン向けの 2-bit（ディスク上 ~240 GB）
hf download unsloth/GLM-5.2-GGUF \
  --local-dir ~/models/glm-5.2-gguf \
  --include "*UD-IQ2_M*"

~/models/glm-5.2-gguf に GLM-5.2-UD-IQ2_M-0000X-of-0000Y.gguf のシャード一式が揃うはずです。512 GB マシンならフィルタを *UD-Q4_K_XL* に差し替えてください。Unsloth はダイナミック量子化の改善に合わせて量子化ラベルを更新するので、正確なシャード名は HuggingFace の「Files and versions」タブをライブで確認してください。

Step 2：llama.cpp で動かす

これがコマンドライン経路で、最も細かく制御できる方法です。まず最近の llama.cpp をビルドします（Mac では Metal が自動でコンパイルされます。Nvidia マシンでは -DGGML_CUDA=ON を追加）。

# 一度だけビルド
cmake -B build && cmake --build build --config Release -j

# port 8080 で OpenAI 互換 endpoint を配信
./build/bin/llama-server \
  --model ~/models/glm-5.2-gguf/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 999 \
  --temp 1.0 --top-p 0.95 --min-p 0.01 \
  --host 0.0.0.0 --port 8080

各フラグには理由があります。

• --ctx-size 32768 は 32K ウィンドウを設定します。256 GB マシンではこれを上げるとメモリを急速に食うので、ここから始めてリクエストが必要とするときだけ伸ばしてください。
• --n-gpu-layers 999 は可能な限りの層を GPU にオフロードします。Mac ではユニファイドメモリのおかげでほぼコストゼロ。4090 では 24 GB に収まる分だけオフロードし、残りは CPU に残します。
• --temp 1.0 --top-p 0.95 --min-p 0.01 は Zhipu 推奨のサンプリングデフォルトです。これを間違えるのが「ローカルのモデルがホスト版より頭が悪い」の最もよくある原因です。

ロードが終わると、llama-server は層数をログに出し、server listening on http://0.0.0.0:8080 を表示します。SSD なら初回ロードは 1〜2 分です。

Step 3：または GUI を使う（LM Studio / Unsloth Studio）

ビルドツールチェーンに触りたくないなら、2 つの GUI アプリが同じ GGUF 量子化をロードします。

LM Studio はデスクトップアプリから同じ GGUF 量子化を動かします。アプリ内のモデルブラウザで unsloth/GLM-5.2-GGUF を検索し、2-bit か 4-bit の量子化を選べば、ダウンロードと配信を処理して、同じ OpenAI 互換 endpoint をローカルポートに公開します。

Unsloth Studio は自動メモリオフロードを備えた Web UI で、ワンラインでインストールできます。

curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio -H 0.0.0.0 -p 8888

長い llama.cpp コマンドを毎回打ち直さずに量子化や設定を切り替えたいなら、どちらも良い選択です。

Step 4：スモークテスト

任意の OpenAI クライアントをローカルポートに向け、応答が返ることを確認します。

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [{"role":"user","content":"Reply with only the string OK."}],
    "max_tokens": 16
  }' | jq -r '.choices[0].message.content'

少し待つと OK が返ってくるはずです。返答が崩れていたりループしていたりするなら、サンプリングパラメータがずれています。--temp 1.0 --top-p 0.95 --min-p 0.01 を huggingface.co/zai-org/GLM-5.2/generation_config.json の値と照合し直してください。

実測 tokens/sec：階層別に何を期待できるか

ローカルハードウェアでの生成速度は生の演算力ではなくメモリ帯域に縛られます。だからこそ、800 GB/s のユニファイドメモリを持つ Mac Studio が、RAM が 80-100 GB/s 寄りの DDR5 デスクトップを上回ります。計画の目安になる数字がこちらです。

パターンはこうです。ローカルの GLM 5.2 はシングルストリーム、単一開発者のツールです。タスクを考え抜く 1 つのコーディングエージェントには速度は十分。共有 endpoint には不十分で、どのコンシューマ量子化もそれは変えません。チームのスループットが必要なら、セルフホストのハードウェアガイド がデータセンター GPU 上での vLLM と SGLang の経路を案内します。

ローカルセットアップでよくあるエラー（と対処）

チーム / 複数開発者：Mac 一台では足りないとき

ローカルマシン一台は一人を相手にします。2 人目の開発者が同じ llama-server にエージェントを向けた瞬間、コンシューマハードウェアには分配する余剰帯域がないので、両セッションとも這うような遅さに落ちます。これを直す気の利いたフラグはありません。

ローカルがスケールしなくなったときの現実的な選択肢は 2 つ。

1. データセンター GPU に移る。 FP8 を配信する 8x H200 ノードなら、多数の同時ストリームをそれぞれ数十 tokens/sec でさばけます。それはコストと運用の話が別物になりますが、ホスト型プランとの損益分岐の計算まで含めて セルフホストの vLLM とコストガイド で完全に解説しています。
2. ホスト型 endpoint を使い、メタルを動かすのをやめる。 ほとんどのチームにとって、データ所在地以外のあらゆる軸でこれが勝ちます。

ローカル量子化は、モデルを自分のマシンに置きたい一人の開発者には正しいツールです。共有サービスには間違ったツールです。

上級：長コンテキストと思考モード

基本セットアップが動いたら、知っておく価値のあるノブが 2 つあります。

KV キャッシュ量子化。 1M コンテキストはアーキテクチャ上は本物ですが、256 GB マシンでは届きません。KV キャッシュだけで数百 GB 必要になるからです。これを量子化すれば余白を買い戻せます。

./build/bin/llama-server \
  --model ~/models/glm-5.2-gguf/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --ctx-size 65536 \
  --cache-type-k q4_1 --cache-type-v q4_1 \
  --n-gpu-layers 999 --port 8080

これで KV キャッシュメモリがおよそ半分になり、同じハードウェアでコンテキストをさらに押し広げられます ― 非常に長い入力でのわずかな品質低下と引き換えに。

思考モード。 GLM 5.2 には、答える前にトークンを使って考える推論モードがあります。素早い編集や短いプロンプトでは、欲しくないレイテンシを足すことになります。リクエストごとに --chat-template-kwargs '{"enable_thinking":false}' でオフにし、追加の推論が元を取る難しいマルチステップ問題ではオンのままにしてください。

ローカルが間違った答えのとき：ホスト型と ofox の代替

256 GB の下限や単一セッションの速度がローカルを除外するなら、GLM 5.2 自体を諦める必要はありません。同じモデルは ofox カタログに z-ai/glm-5.2 として載っており、入力 $1.40/M、出力 $4.40/M です。base URL と model ID を変えるだけでフルスピードのホスト版を動かせ、買って世話を焼くマシンは要りません。ローカルの llama-server に対してプロトタイプを作り、そのまま同じクライアントをホスト版モデルに向ければよいのです。

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="ofox-..."
export OPENAI_MODEL="z-ai/glm-5.2"   # まったく同じモデル、いまはホスト版

ホスト型アクセスガイド は、同じモデルへの Z.ai Coding Plan 経由のルートもカバーしています。さらに、その 1 つの OpenAI 互換 endpoint の裏で他のオープンウェイト系コーディングモデルもいくつか使いたいなら、ofox はこれらも初日から掲載しています。

ローカル構成にせよホスト型サブスクリプションにせよ、コミットする前にクローズドモデルに対する GLM の価格と品質を見ておきたいなら、GLM 5.2 と GPT-5.5 のコスト比較 を参照してください。

今回の更新で確認したソース

• HuggingFace 公式モデルカード zai-org/GLM-5.2（753B パラメータ、MIT ライセンス、1M コンテキスト）、2026-06-23 確認：https://huggingface.co/zai-org/GLM-5.2
• Unsloth GGUF コミュニティ量子化と量子化別メモリ表、2026-06-23 確認：https://huggingface.co/unsloth/GLM-5.2-GGUF
• Unsloth GLM 5.2 実行ガイド（量子化サイズ、サンプリングデフォルト、KV キャッシュフラグ、Unsloth Studio インストール）：https://unsloth.ai/docs/models/glm-5.2
• llama.cpp プロジェクト：https://github.com/ggml-org/llama.cpp
• LM Studio：https://lmstudio.ai
• 同伴の ofox ガイド：セルフホストのハードウェアとコスト、ホスト型アクセス、GLM 5.2 と GPT-5.5 のコスト比較

面白いのは、フロンティアモデルがローカルで動くこと自体ではありません ― それを確かめるコストがいまやどれだけ小さいか、です。すでに持っている 256 GB の Mac Studio と、ダウンロードに費やす午後ひとつが実験のすべてです。次に注目すべきは FP4 とより緻密なダイナミック量子化です。良い 4-bit が 200 GB を切る日が来れば、ローカルの下限は 256 GB Mac から 128 GB Mac へ下がり、もっと多くのデスクが条件を満たすようになります。