「GLM-5.2はQwenより速い」は64GB Macでは成立しない — active 40B vs 3Bの原理とSSD実測

#llm

Originally published on Zenn (Japanese). Cross-posted here.

「GLM-5.2はQwenより速いらしいから、ローカルAIを乗り換えたい」——そう思って64GB統合メモリのM1 Max(MacBook Pro)で検証したら、たどり着いた結論は逆だった。乗り換えない。理由は2つある。①そもそも64GBに載らない、②仮に載ったとしても原理的に約13倍遅い。この記事はその検証過程の実録で、比較の錨として自機Qwen3.6の実測値(60.6 tok/s・3回中央値)も載せる。

結論を先に: 「オープンソースで速い」は本当だが、自分のマシンの話ではない

GLM-5.2はMIT公開の753B(7,530億)パラメータMoEモデルで、重みは誰でもダウンロードできる。「オープンソース」は嘘ではない。だが動かせるハードは別問題で、以下の2点を測ると64GB Mac向けの答えは変わらなかった。

量子化を極限まで削っても64GBに載らない(1bitでも217GB)
MoEの実効速度は「総パラメータ」ではなく「activeパラメータ」で決まり、GLM-5.2はここでも約13倍不利

速度の原理: MoEはメモリ帯域×activeパラメータで決まる

Mixture of Experts(MoE)モデルは、1トークンを生成するたびに全パラメータを使うわけではない。ルーターが一部の「Expert」だけを選んで計算する。この「1トークンあたりに実際に使うパラメータ数」がactiveパラメータで、デコード速度はほぼこれで決まる(正確には「メモリ帯域 ÷ activeパラメータのバイト数」)。総パラメータ数は、モデルを保存するのに必要な容量には効くが、速度にはほぼ効かない。

	Qwen3.6(現行・自機)	GLM-5.2
総パラメータ	34.7B MoE	753B MoE
active/token	3B	40B
1トークンあたりの実仕事量	1×	約13×
配置	GPU常駐 21GB(統合メモリ帯域)	64GBに載らずSSD経由

GLM-5.2の"1トークンぶんの実仕事量"(active 40B)は、Qwen3.6の総パラメータ(34.7B)より大きい。出典: huggingface.co/zai-org/GLM-5.2、自社実機の ollama show(2026-07-18)。
つまり同じメモリ帯域のハードで動かした場合、GLM-5.2は原理上おおよそ40B÷3B≒13倍遅い計算になる。「GLM-5.2は賢いから速い」という噂の出どころは、以下のどれかだと考えられる。

z.aiのクラウドAPI上の速度 — データセンターGPUの話。ここは実際に速い
「賢いので手戻りが減り結果的に速い」 — 正当な読みだが、後述のとおり2 tok/s前後ではこの利点は吹き飛ぶ
512GB級マシンでの比較 — DeepSeek-V4との対比などで言及される水準で、64GB Macの話ではない

そもそも64GBに載らない: 量子化サイズの実表

unslothが配布するGGUF量子化(unsloth/GLM-5.2-GGUF)のサイズを並べると、量子化をどれだけ削っても64GBに届かないことが数字で分かる。

64GBに収めるには0.7bit/paramが必要という計算になる。1bitを切るのは情報理論的に無理筋。出典: unsloth/GLM-5.2-GGUF(HuggingFace)。
1bit(世界の底値)でも217GBで、64GBの3.4倍。これは量子化の改良でどうにかなる差ではなく、桁が違う。

ここで一つ罠がある。SixVolts/GLM-5.2-ewaste-edition-GGUFは名前の通り「非力なハード向け」を謳っているが、実サイズはQ2_K_XLで226.9GB、Q4_K_XLで403.8GBだった。READMEを読むと、Q2_K_XLは「256GB(32GB×8枚)にゼロスピルで載せる」ための設計だと明記されている。想定読者のマシンは自機の4倍。名前だけで判断すると事故る。(ちなみにQ3_K_M比で困惑度(perplexity)+27%という品質の下限でもある。)

Ollamaでの提供形態も紛らわしい。ollama.com/library/glm-5.2のタグはglm-5.2:cloudの1本のみで、GBサイズ表示がない。ollama runで呼べるが、これは自機ではなくOllama Cloudのサーバー側で動く。ローカルAIとして数えてはいけない。

抜け道は実在した — ただし前言撤回が必要だった

ここまでの調査で一度「64GBでは不可能」と断定しかけたが、それは誤りだった。「全重みをRAMに常駐させる」前提でのみ正しい話で、その前提を外す実装が実在する。

andreaborio/glm52-ds4-native-64g-q2k-experimental(HuggingFace・MIT)は、GGUF本体は244.14GiB(6分割+SHA-256マニフェスト+再構築スクリプト)とSSDに置いたままにし、常駐メモリは19.56GiBに抑える構成をとっている。attention/router/shared expertはq8_0/f16、routed MoE部分はq2_kで224.44GiBという内訳だ。ランタイムはantirez/ds4——Redisの作者Salvatore Sanfilippoが書いた監査可能なLLMランタイムのglm5.2ブランチで、頻繁に使われるlayer/expertのペア2,600個を別パックにまとめ、元のGGUFは変更せずに済む仕組みになっている。

MoEの「activeは40Bだけ」という性質を、RAM容量ではなくディスク帯域で回収しているのがこの実装の要点だ。必要なExpertだけを19.5GBのRAMに出し入れする。

作者が公開している実測速度は次の3点(検証環境はAWS L40S＋Apple M5 Pro 64GiB。あくまで参考値であり、自機M1 Maxでの実測ではない)。

コンテキスト長	速度
n=8	2.52 tok/s
n=32	2.28 tok/s
n=64	2.01 tok/s

平均を出さずに3点とも書くのは理由がある。コンテキストが伸びるほど速度が落ちるという傾向そのものが情報だからだ。検証環境はAWS L40S＋Apple M5 Pro 64GiBで、M1 Maxでの実測ではないことは明記しておく。

そして、この数字を鵜呑みにする前に読むべき但し書きが作者自身から出ている。

「この実装はまだCPU診断コード(CPU diagnostic code)」と明記
品質テストは未実施。"Paris"と出力させる疎通確認が通った段階
通常のds4生成はまだ無効。動くのは--glm-dsa-previewという短コンテキストのプレビュー経路のみ
→ GLM-5.2最大の売りである1M contextが使えない
長文DSAインデクサ・本番統合・Metal/CUDAフルグラフ実行は未実装
ダウンロード数・いいね数は追跡されていない(＝広く使われている証拠はない)

正確に言うなら「RAM常駐では不可能・ストリーミングなら2 tok/s前後で動く(ただし診断段階)」となる。「完全に不可能」でも「もう実用段階」でもない、その中間が実態だ。

自機の実測: 一度は測れず、GPUが空いてから測った

比較対象として自機(Qwen3.6, 34.7B MoE, active 3B)の実tok/sを測る手順自体はシンプルだ。社内のGPU調停スクリプト(複数の生成ジョブが同じ統合メモリを奪い合わないよう順番待ちさせる自作ラッパー)経由でollamaのgenerate APIに投げ、レスポンスのeval_countとeval_durationからtok/sを算出する。

ところが最初の試行は応答なしのままタイムアウトした。原因は調停スクリプトの設計にあった。ロックを取得する際に、Ollamaプロセス自体を一旦停止(SIGSTOP)して他ジョブにGPUを譲る設計だった。今回のように計測対象そのものがOllamaだと、自分で自分を止めてから自分に話しかける形になって応答が返らない。調停ラッパーは「動画・画像生成がOllamaからGPUを奪う」ケース専用で、Ollama自身を測る用途は想定外だった。裏では別の動画生成ジョブも走っており、無理に割り込んで測る値ではないと判断して、その場では計測を見送った。

後日、GPU使用率3%・他の生成ジョブなしを確認できたタイミングで測り直した。統合メモリの同居によるスワップを避けるため、まず裏で常駐していた画像生成サーバ(ComfyUI)を停止して確保メモリを51GB→42GBに解放し、その状態で調停ラッパーを通さず直接Ollamaに投げた(測りたい対象を凍結しては本末転倒なので)。num_predict=300・各3回・中央値をとった結果がこれだ。

モデル	サイズ	中央値 tok/s	3回の値
qwen3.6(35B-A3B MoE)	23.9GB	60.6	60.3 / 60.6 / 61.0
qwen3.6-uncensored-cc	21.2GB	60.3	60.3 / 60.3 / 60.5

振れ幅は0.2〜0.7 tok/sと極小で、単発でなく3回の中央値なので信頼できる値だ。プレフィル(prompt eval)は約593 tok/s。2モデルがほぼ同速なのは、active 3Bという実仕事量が同じで、総サイズ(21GB vs 24GB)の差が速度に効かないという、この記事の主題そのものの裏付けになっている。

そして肝心の比較——自機Qwen3.6の約60 tok/s に対し、GLM-5.2(ds4ストリーミング)は参考値で2 tok/s前後。実に約30倍の開きがある。active比の原理から予想される13倍に、SSDストリーミングのディスク帯域ペナルティが上乗せされて、原理値よりさらに広がっている。「賢いから速い」がこの差を埋めるのは、64GB機では現実的でない。

教訓として一点。ベンチマークは、他のGPUジョブを止めてまで急いで取る値ではない。混んでいる時に無理に割り込むより、空くのを待ってクリーンな状態で測る方が、数字の信頼性も運用の健全性も高い。今回もそうした。

一次情報を疑う手順: 「GLM 5.2 Air」は自己矛盾で偽と分かった

調査の過程で、あるベンチマークサイト(llmcheck.net)が「GLM 5.2 Air / 106B / Q4_K_M」としてMac別のtok/sを掲載しているのを見つけた(M4 Ultra 192GB=38、M5 Max 128GB=34、M5 Max 64GB=30、M4 Max 128GB=26 tok/s)。「64GB Macで30 tok/s」なら魅力的な数字だが、裏取りをすると次の3点が分かった。

「GLM-5.2-Air」というモデルは実在しない。HuggingFaceのzai-org/GLM-5.2-Airは401(リポジトリ不在)。Z.ai公式リリース(2026-06-13)にAirの記載はなく、HF discussionsの「Air or Flash model coming?」「We need some Air」も要望のまま未回答だった。既に存在するモデルなら、この手のスレッドは立たない。
同じページが自己矛盾している。「106B / Q4_K_M」と明記しているが、106B-A12BのQ4_K_M実測はbartowski/TheDrummer_GLM-Steam-106B-A12B-v1-GGUFで72.9GBあり、64GB機には載らない。つまり同ページが自分で書いた量子化と、自分で書いた「64GB Macで動く」が両立しない。
これらから、実在するGLM-4.5-Air(110B-A12B)を「GLM 5.2 Air」と誤記したものと判断した。

外部に問い合わせなくても、同一ページ内の記述同士が噛み合うかどうかだけで真偽を判定できるケースがある、という手順として記録しておく。(なお、実在するGLM-4.5-Air 110B-A12Bは64GBに載る量子化も存在するが、現行のQwen3.6の方が強いという判断で今回は候補から外している。)

再現できる学び

新しいモデルが話題になったとき、「パラメータ数がでかい」「オープンソースで無料」という見出しだけで自分のマシンで動くかどうかを判断すると事故る。今回の検証で使った判断軸は次の2つだけだった。

最小量子化のGB — 一番削った量子化でも自機のメモリに載らないなら、それ以上検討しても無駄
active/token — 総パラメータではなく、1トークンあたりに実際に動くパラメータ数が速度を決める

この2つを先に確認するだけで、「載るか」「速いか」の大半は判断できる。今回のGLM-5.2は、どちらの軸でも64GB Macには厳しい結果だった。ただし「RAM常駐でなければ不可能」という強い言い方は誤りで、SSDストリーミング(ds4)という診断段階の抜け道は実在する——この一点だけは、当初の自分の判断を撤回しておく。

測った範囲は自機1台・M1 Max 64GBのみで、一般化はしていない。他のモデル・他のマシンでは結論が変わりうる点は前提として断っておきたい。その上で、この記事で答えの出ていない、読者しか持っていなさそうな情報を3つ聞きたい。

ds4のストリーミング版を実際に常用している人はいるか。作者自身が品質テスト未実施と明記しているが、2 tok/s前後で実用になる用途はあるか
GLM-5.2-Air/Flashの実在情報を知っているか。llmcheck.netには行があったが、公式発表もHFリポジトリも見つけられなかった
M1 Max世代でのGLM-5.2(ds4)実測値を持っている人はいるか。今回Qwen3.6側はM1 Maxの実測(60 tok/s)を1点出せたが、GLM側のM1 Max実測は見つけられなかった。ベンチマークサイトの多くはM4/M5世代に偏っており、4年前の機体の数字はほとんど出回っていない