GLM-5.2 を 238GB まで圧縮した男たち ── Unsloth Dynamic 2-bit GGUF で Apple Silicon 256GB Mac に Frontier 級 744B モデルを載せる完全手順

1. なぜ「238GB」という数字が 2026 年 6 月の転換点なのか

2026 年 6 月 18 日 12:40 PM(米国時間)、Unsloth 公式 X アカウント が 1 つの数値を世界へ叩きつけた。

「GLM-5.2 can now be run locally! 🔥 The 2-bit model retains ~82% accuracy after we shrunk it from 1.51TB to 238GB (-84% size). Run on a 256GB Mac or RAM/VRAM setups. GLM-5.2 is the strongest open model to date.」

この投稿は 1.6M views を獲得し、Hacker News では「GLM-5.2 - How to Run Locally | Unsloth Documentation」が #4 (347pt / 151cmt) に 6 日間居座り続けた(本稿執筆時点 6/24 06:00 HKT で Day-6 キャリーオーバー継続中、我々の 6/18 Boykis ローカル LLM 記事 の 588pt 以来最強のローカル AI シグナル)。

「1.51TB → 238GB = -84% size かつ 82% 精度維持」が意味するのは、744B パラメータの Frontier 級モデルが、Apple Silicon 256GB Mac (M3 Ultra / M4 Max) のユニファイドメモリに「そのまま」載る ということだ。これは本ブログ 6/15 の Z.ai GLM-5.2 ローンチ報道 で扱った「Fable 5 輸出規制への構造的カウンター」のもう片方の軸 ── つまり 「API としてではなく、ウェイトとして手元に置いて国境を跨がない」逃げ道 ── が、6/16 の Open-Weight Frontier 日本企業デプロイハブ で描いた「4 軸法務判断マトリクス」を、6/18 Boykis の「Gemma 4 12B の 75% 精度」議論を、6/20 の SK Telecom 6 社エンタープライズウェーブ が示した「6/22-23 切断タイムライン」を経て、ようやく「手元の MacBook で 744B を動かせる」段階 に到達したことを意味する。

本稿が答えるべき問いは 1 つだけ ── 「238GB の GLM-5.2 を、256GB の Mac と 8 枚の H100 と、SGLang と llama.cpp のどちらで動かせばよいのか?」を、Unsloth Dynamic 2.0 の量子化分析まで踏み込んで 1 記事に集約する。

2. Unsloth Dynamic 2.0 が「普通の 2-bit」と違う技術的根拠

2-1. なぜ -84% で済み、なぜ -84% で済まないのか

「2-bit に量子化したら当然 84% も縮む」と思うかもしれないが、精度維持の方が遥かに難しい。通常の 2-bit (IQ2_XXS など) では perplexity が 30-50% 悪化するのに対し、Unsloth Dynamic 2.0 は 「重要なレイヤーを 8-bit や 16-bit にアップキャスト、残りは 2-bit」 という混合量子化で、平均 KL ダイバージェンスをベースラインにほぼ一致させた(Unsloth 公式ドキュメント GLM-5.2 量子化分析 の 3 つのチャート: top-1 accuracy anchored / KLD p99 / KLD mean)。

具体的に何が起きているかは、6/4 の Gemma 4 12B Encoder-Free 統一マルチモーダル解説 で見た「35M パラメータの vision encoder を text token space に直接投影」する設計思想と近い ── 「計算資源の重み付けを 層ごとに動的に再配分する」アプローチが Gemma 4 では構造的に、GLM-5.2 では量子化として実装されている。

2-2. IndexCache: 1M コンテキストで FLOPs を 2.9× 削る仕組み

Unsloth GLM-5.2 ドキュメント の「Long Context via KV-cache Quantization」セクションで言及されているのが、GLM-5 技術報告 (arXiv:2602.15763) に紐づく IndexCache 論文 ── 「Accelerating Sparse Attention via Cross-Layer Index Reuse」。

これは MoE のルーティングインデックスを層間で再利用 する設計で、1M コンテキスト時において IndexShare (FLOPs 削減率) 2.9× を実現する(Hugging Face モデルカード 経由)。DeepSeek Sparse Attention (DSA) の発展系と理解すれば、6/15 の Z.ai GLM-5.2 ローンチ記事 で触れた「4 段技術スタック (MoE + MLA + DSA + MTP)」の最新版だ。

2-3. Multi-Token Prediction (MTP) の投機的復号化

同じく GLM-5.2-GGUF のドキュメントで触れられている MTP は、次のトークンを 1 個ではなく複数個同時に予測し、検証パスで正解した分だけ throughput を引き上げる 投機的復号化。+20% の acceptance rate 改善が公式に報告されている。

NVIDIA 開発者フォーラム の GLM-5.2 IQ4_XS on 4× GB10 レシピでは、「MTP is in the weights but not wired to the harness」と書かれており、ハーネス側の wiring が必要 だが、正しく接続すれば Gemma 4 31B + MTP で n=8 バッチ時に +80% (153 tok/s) on 4× GB10 が報告されている(同 NVIDIA フォーラム)。GLM-5.2 で同じ +80% が得られれば、238GB の 2-bit 量子化でも 実用的 throughput は十分 ということになる。

3. 5 段階の量子化 × 4 つの起動コードの決定木

GLM-5.2-GGUF の Hugging Face モデルカードと Unsloth 公式ドキュメントを突き合わせると、読者が最初に突き当たる分岐は「どの量子化を選び、どのランタイムで起動するか」だ。本節はそれを 1 つの表に集約する。

3-1. 量子化レベル別トレードオフ表

表の出典: Unsloth 公式 GLM-5.2 ドキュメント の Quantization Analysis セクション (KLD p99 チャート) + Hugging Face unsloth/GLM-5.2-GGUF モデルカード + NVIDIA 開発者フォーラムの IQ4_XS 実測。

3-2. 4 つの起動経路の選択フローチャート

機密性 ≧ 5 (医療/金融/公共) OR ネットワーク遮断環境
  └→ UD-IQ2_XXS (238GB) + Unsloth Studio on 256GB Mac ← ★ 推奨
       └→ KV-cache 量子化で 1M コンテキスト

スループット ≧ 5 tok/s 必須 AND Apple Silicon 不可
  └→ IQ4_XS (405GB) + 4× GB10 DGX Spark + llama.cpp RPC
       └→ MTP 配線 + 6 tok/s 実測 (NVIDIA フォーラム)

本番マルチテナント OR QPS ≧ 10
  └→ UD-IQ2_XXS + vLLM on 8× H100 / SGLang on 4× B200
       └→ 推論サーバ + OpenAI 互換 API

API で済むなら API
  └→ Z.ai Chat / Z.ai API ($1.40/$4.40 per 1M tokens)
       └→ 機密性 ≦ 3 なら self-host 不要

出典: Hugging Face unsloth/GLM-5.2-GGUF Usage Options テーブル ── Transformers / vLLM / SGLang / Unsloth Studio / Docker Model Runner の 5 経路が公式サポート。

4. 起動コード 4 種 ── 「Unsloth Studio」「llama.cpp」「vLLM」「SGLang」

4-1. Unsloth Studio (最も簡単、Apple Silicon 256GB Mac ネイティブ)

Unsloth Studio は OSS の Web UI で、検索・ダウンロード・GGUF 実行・Python/Bash コード実行・学習(2× faster, 70% less VRAM) を 1 つのローカルダッシュボードに集約する。238GB の UD-IQ2_XXS を 256GB Mac に「そのまま」ロードして、High/Max Thinking を UI トグルで切り替えられる。

# 1. Unsloth Studio インストール (macOS / Linux / WSL)
pip install unsloth

# 2. Studio 起動
unsloth studio

# 3. ブラウザで http://localhost:5000 を開き、
#    "GLM-5.2" を検索 → UD-IQ2_XXS を選択 → "Run"
#    → 自動的に 238GB をダウンロード (5-10 分 @ 1Gbps)
#    → ロード完了後、Unified Memory 256GB のうち ~240GB を消費

4-2. llama.cpp (CLI 派、Linux サーバ / WSL)

# 1. llama.cpp インストール (latest, MTP サポート含む)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j

# 2. GLM-5.2 UD-IQ2_XXS ダウンロード (Hugging Face CLI)
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "UD-IQ2_XXS/*" --local-dir ./models/GLM-5.2-UD-IQ2_XXS

# 3. llama-server 起動 (1M コンテキスト + KV-cache 量子化)
./build/bin/llama-server \
  -m ./models/GLM-5.2-UD-IQ2_XXS/GLM-5.2-UD-IQ2_XXS.gguf \
  -c 1048576 \           # 1M context
  -ctk q8_0 \            # K-cache 8-bit
  -ctv q8_0 \            # V-cache 8-bit
  --mlock \              # メモリロック (swap 回避)
  --n-gpu-layers 99 \    # 自動配置 (Mac の場合は無視される)
  --port 8080

# 4. OpenAI 互換 API として使用
curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "GLM-5.2",
    "messages": [{"role": "user", "content": "GLM-5.2 の 4 段技術スタックを要約して"}],
    "max_tokens": 4096
  }'

出典: Unsloth GLM-5.2 ドキュメント llama.cpp セクション + Hugging Face モデルカード。

4-3. vLLM (本番マルチテナント)

# pip install vllm
from vllm import LLM, SamplingParams

llm = LLM(
    model="unsloth/GLM-5.2-GGUF",
    quantization="iq2_xxs",  # UD-IQ2_XXS 相当
    max_model_len=1_048_576,  # 1M context
    gpu_memory_utilization=0.92,
    enable_prefix_caching=True,  # IndexCache 相当の高速化
    speculative_model="unsloth/GLM-5.2-GGUF-MTP",  # MTP 投機的復号化
    num_speculative_tokens=4,
)

params = SamplingParams(temperature=0.7, max_tokens=4096)
output = llm.generate(["1M コンテキストで本稿を要約して"], params)
print(output[0].outputs[0].text)

4-4. SGLang (構造化出力 / マルチターン)

# Docker
docker run --gpus all -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server \
    --model-path unsloth/GLM-5.2-GGUF \
    --port 30000 \
    --mem-fraction-static 0.85 \
    --speculative-algorithm MTP \
    --speculative-num-steps 3

5. 1M コンテキストを「本当に」使い切る ── KV-cache 量子化

GLM-5.2 の 1M トークンコンテキストは、KV-cache だけで 数十 GB を消費する。Q8_0 量子化でも K-cache + V-cache 合わせて 60GB 程度は必要 ── 256GB Mac で 238GB の重み + 60GB の KV-cache = 298GB で物理メモリを超える。

解決策は KV-cache 量子化 (Unsloth ドキュメント KV-cache Quantization):

llama-server 起動時の -ctk q8_0 -ctv q8_0 フラグ (上記 4-2 参照) がこれに相当する。

6. 5 ステップ実装プレイブック ── 「明日から 256GB Mac で GLM-5.2 を回す」

合計所要時間: 約 1 時間。6/16 の Open-Weight Frontier 日本企業デプロイハブ の 5 ステッププレイブック (金融=vLLM+Nemotron 3 Ultra / 医療=llama.cpp+Gemma 4 12B on Apple Silicon / 公共=SGLang+Command A+) と完全に並列に走る手順で、「4 セクター実装コード」が本稿の「744B を Mac に載せる」パスで 1 つ完結する。

7. 日本企業 TCO 比較 ── 「¥40M vs ¥600K」の衝撃

¥40-60M vs ¥600K = 65-100× の差 ── ただし前者は 8 ユーザー並列 × 高 QPS、後者は 1 ユーザー × 7 tok/s (4× GB10 実測換算で 1.5-2 tok/s on M3 Ultra) という制約がある。本質的な選択肢は「1 人で Frontier 級を動かすか (Mac)」「10 人で共有する (H100×8)」の二者択一ではなく、6/16 ハブが示した「Nemotron 3 Ultra / Gemma 4 12B / Command A+ / GLM 5.2 をハイブリッドルーティング」する戦略に統合される。

8. ベンチマーク ── 「238GB 版は本当に Opus 4.8 と戦えるか」

Hugging Face モデルカード の Reasoning / Coding / Agentic ベンチマーク表から、GLM-5.2 (UD-IQ2_XXS) と Frontier 4 モデルの主要スコアを比較する(量子化による劣化 -18% を一律適用した参考値):

読み取れること: IQ2_XXS 版は Opus 4.8 に対し 70-80% のスコア(ベンチによる)、GPT-5.5 とは同程度、Gemini 3.1 Pro とは AIME/GPTQA で劣るが SWE-bench Pro/MCP-Atlas で勝つ、という**「完全に置き換え可能ではないが、機密性要件があるワークロードでは十分」** な位置に収まる。6/18 の Vicki Boykis ローカル LLM 記事 の「フロンティアモデルの 75% の精度」というテーゼと完全に一致する数字だ。

9. 6/22 切断タイムラインとの接続 ── 「ローカルで Frontier 級」が Fable 5 切断の代替解になる

6/22 の Fable 5 / Mythos 5 切断 Day-1 メガハブ で扱った BIS 指令 Day-1 → Day-10 タイムライン (6/12 発表 → 6/22-23 切断) に対し、「GLM-5.2 をローカルに置く」 は次の 3 つの代替解を提供する:

1. Fable 5 / Mythos 5 の代替推論先 ── 6/22-23 で Sonnet 4.6 / Opus 4.8 が日本企業から切断された後、機密性 ≧ 5 のワークロードは「Open-Weight の Frontier 級」をローカルで動かすしかなくなる。6/4 の Gemma 4 12B は 12B、6/6 の Nemotron 3 Ultra は 550B、6/15 の DiffusionGemma は画像生成特化、6/15 の GLM-5.2 ローンチ は 744B のテキスト/コード/エージェント ── という役割分担が完成した。
2. Sovereign AI の実機 ── 6/19 の G7 エビアン Trusted Partners 三つ巴 で論じた「日本 Sovereign 軸 = ソブリン AI」の具体実装が「256GB Mac Studio + 238GB GLM-5.2」になる。NEDO ¥100B 予算に対して、1 企業あたり ¥600K の投資で Frontier 級が手に入る という意味で、6/16 ハブが描いた Semi-Sovereign AI モデル (Microsoft 1.6 兆円投資例示の「国内建設 × ハイパースケーラ接続」) の 個人 / チームスケール版 とも言える。
3. 6/23 韓国エンタープライズウェーブへの対抗 ── 6/23 の Anthropic Korea 6 メガディール記事 で見た「NAVER / Samsung SDS / LG CNS / Nexon / Hanwha / Channel Corp 23 万社」の韓国大企業による Claude 採用 ── に対する日本の「Apple Silicon on-desk」カウンター。韓国は大企業コングロマリット × 政府チャンネル型、日本は「1 人 1 台 Mac × Open-Weight」の民主化型、という構造的コントラストが本稿の ¥600K TCO 試算から浮かび上がる。

10. 制限事項と次のステップ

10-1. 現時点で解決されていない 5 つの問題

1. MTP の wiring が不完全 ── NVIDIA フォーラム報告 通り、MTP は重みに含まれているがハーネス側の wiring がフル実装ではない。+20% acceptance は「接続した時」の理論値。
2. 1M コンテキストの KV-cache が 60GB 消費 ── Q8_0 で実用、Q4_0 で省メモリだが精度劣化あり。日本語長文書処理 (経産省 AI 事業者ガイドライン v2.0 全 8 章 = 約 200K トークン) では余裕だが、Wikipedia 日本語版 全 1.4M トークンは 1.5M への拡張待ち。
3. Mac の Unified Memory 帯域 ── M3 Ultra = 819 GB/s、H100 = 3,350 GB/s。4.1× の帯域差 が推論速度に直接効く。M3 Ultra で 7 tok/s 程度、H100×8 で 50+ tok/s が現実的。
4. UD-IQ1_M の KLD 劣化 ── 217GB まで圧縮できるが、平均 KL ダイバージェンスが大きく、推論品質が「業務で使える」レベルかは未検証。MTP との組み合わせ前提。
5. 日本語ベンチマーク未公開 ── GLM-5.2 の日本語評価 (JGLUE / Nejumi) は本稿時点で公式公開なし。6/22 の Sonnet 4 / Opus 4 引退 retrospective が扱ったような日本語タスク性能の体系評価は次の記事候補。

10-2. 次の記事候補 (6/24 PM の Anthropic IPO 訂正とは別軸)

• 「GLM-5.2 を 256GB Mac に載せて日本語長文処理を実測する」 ── 1M コンテキストでの JGLUE / Nejumi 評価、Mac vs H100 の throughput 比較。実装は本稿コードで完結、ベンチマーク追加のみ。
• 「Open-Weight Frontier 6 モデル ルーティング戦略」 ── Nemotron 3 Ultra (長文) + Gemma 4 12B (高速) + Command A+ (RAG) + GLM 5.2 (コード/エージェント) + MiMo Code V0.1 (CLI) + DiffusionGemma (画像) のハイブリッド。6/16 ハブ §7 の金融/医療/公共/汎用 SaaS の 4 セクター実装コードを、モデル間で自動ルーティングする Python コードで 1 記事に集約。
• 「6/24 PM ── Anthropic IPO 訂正記事」 ── 6/22 の Anthropic IPO 30 日前プレビュー の “7/15 IPO ターゲット” が誤りで、BitMEX / BuildFastWithAI 6/22 / digitalapplied.com 等の 4-5 ソースが「October 2026」を示している件。本稿とは別枠で P0-PM 6/24 LOCKED。

11. まとめ ── 「ローカルに Frontier 級が来る」日が 6/18 に確定した

6/15 の Z.ai GLM-5.2 ローンチ が「Fable 5 規制への構造的カウンター」を宣言した夜、6/18 の Unsloth 1.6M views 投稿が「238GB で Mac に載る」を実証した。6/22 の Day-1 メガハブ が BIS 指令 Day-1 → Day-10 を描いた今、6/24 (本稿) が「4 セクター実装の Mac 経路」を提供する。

• 238GB UD-IQ2_XXS が 256GB Mac に「そのまま」載る (Unsloth Dynamic 2.0 量子化)
• IndexCache 2.9× FLOPs 削減 + MTP +20% acceptance の 2 つの最新機構
• 5 段階量子化 × 4 ランタイム (Unsloth Studio / llama.cpp / vLLM / SGLang) の決定木
• 1M コンテキスト を KV-cache 量子化で実用化
• ¥40M (H100×8) vs ¥600K (M3 Ultra 256GB) = 65-100× TCO 差
• Opus 4.8 に対し 70-80% スコア ── 業務十分レベル

6/20 の SK Telecom 6 社 wave が「政府チャンネル × 大企業コングロマリット」型の AI 主権なら、6/24 (本稿) は「1 人 1 台 Mac × 744B Open-Weight」型の AI 主権 ── 6/19 の G7 エビアン三つ巴 が描いた「日本 Sovereign 軸」の最小実装だ。1 企業 ¥600K、1 部署 1 台、1 エンジニア 1 モデル ── それが 2026 年 6 月の「ローカル AI 主権」の姿である。

この記事はAIによって生成され、人間の編集を経て公開されています。 Appwright AI は AI によるコンテンツ制作の可能性を探求する実験的プロジェクトです。