On this page

GLM-5.2 GGUFの量子化・MTP・expert配置を比較

GLM-5.2 GGUFの1.630bpwと2.244bpwを192GB VRAMで比較。LLM導入の速度・品質・省VRAM構成とMTPの実測を記録します。

技術メモとして残していた ObsidianノートにAIの要約を利用しています。

sokann の GLM-5.2-GGUF-1.630bpw と GLM-5.2-GGUF-2.244bpw を動かし、MTPとexpert配置を比較しました。

2.244bpwのREADMEは、--spec-type mtp:n_max=4,p_min=0.5 でMulti-Token Prediction（MTP）を有効にするとTGが11.81 → 18.02 t/s、acceptanceが0.98259（508 accepted / 517 generated）になったとしています。手元では同じフラグで0.8に届かない程度でした。指定のlayer配置と -mla 1 でTGは増えましたが、-cram 0 が影響した可能性もあります。

RTX PRO 6000 Blackwell Max-Q 96GBx2 = 192GB VRAMで、量子化、MTP on/off、expert配置を変えました。試した構成では、MTPを入れるとTGが下がりました。網羅的な検証ではありません。以前のGLM-5.1でもTGが約5下がった記憶があり、量子化はsmol-IQ2K_Sだったと思います。

動画リンク: https://www.youtube.com/watch?v=Wm0SfXveHnQ

テスト環境

GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q 96GBx2 (PCIe Gen5, NVLinkなし) = 192GB VRAM
CPU: AMD EPYC 9175F, 16 cores, L3 512MB
RAM: 768GB DDR5
Model: sokannのGGUF2種 — 1.630bpwと2.244bpw
Base model: zai-org/GLM-5.2 (753B params / A40B active, arch glm-dsa, 79 layers + NextN/MTP layer 1枚, 256 experts, top-8)
Runtime: ik_llama.cpp (CUDA 13), commit 29a54f4, Podman経由

取得したモデルは次の2つです。

1.630bpw — expertsがIQ1_S_R4 / 残りがQ6_0、142.9 GiB。192GB VRAMに丸ごと載る。
2.244bpw — expertsがIQ2_KT / 残りがQ6_0、196.756 GiB (PPL 3.8402)。KV cacheとcompute bufferを足すと192GBをわずかに超えるので、フルGPUには載りきらない。

IQ2_KT と IQ1_S_R4 はik_llama専用です。mainlineの llama.cpp はggml type 133を拒否してロードできません。両モデルのMTP/NextN layer（layer 78）は Q6_0 です。

--spec-type mtp:n_max=4,p_min=0.5 でMTPを有効にします。n_max は1回のdraft token数の上限、p_min は提案するtokenの確率下限です。

Part 1 — 1.630bpw・フルGPU・MTP off

1.630bpw（142.9 GiB）を2枚に全載せし、CTX128Kで動かしました。

  podman run --rm --device nvidia.com/gpu=all -p 8000:8000 --cap-add SYS_NICE \
  -v /mnt/data/hf/hub/models--sokann--GLM-5.2-GGUF-1.630bpw:/models:ro,Z \
  registry.home.arpa/ik_llama:latest \
  -m /models/snapshots/451d18c5c05952bc322b9f9e612abc625d48b211/GLM-5.2-GGUF-1.630bpw.gguf \
  --merge-qkv --ctx-size 131072 --parallel 1 --threads 15 --threads-batch 15 \
  -ctk q8_0 -b 8192 -ub 2048 -ngl 80 -mla 3 -muge -ger -amb 512 \
  --temp 0.6 --top-k 20 --top-p 0.95 --jinja --reasoning off \
  --host 0.0.0.0 --port 8000 --warmup-batch --alias test-model

80/80 layersをGPUに置きました（CUDA0 71.0GB / CUDA1 72.7GB / CPU 0.7GB）。Zedでは4k出力付近から細かなミスが増え、短出力向けと感じました。

実測値です。

  Overall:        PP 359.5 t/s   TG 39.0 t/s   E2E 37.0 t/s
Long prefill:   14,895 tokens at ~747 t/s, 78 gen tokens at ~39 t/s, ~22 s total
Steady-state:   PP ~250-450 t/s (cached-prefix dependent), TG ~34-40 t/s, E2E ~35 t/s

HF communityにはCPU only（EPYC + RAM）の18〜20 t/sという投稿もありましたが、ログはありませんでした。TGが出てもPPは厳しいと推測しています。動画の -cmoe 構成では約5 t/sでした。

Part 2 — 同じ構成でMTP on

Part 1に --spec-type mtp:n_max=4,p_min=0.5 だけを加えました。

  # ... Part 1 と同一、加えて:
  --spec-type mtp:n_max=4,p_min=0.5

実測値です。

  MTP on:   TG ~15-22 t/s   draft acceptance swings 0.25-0.56   PP 350-750 t/s

TGは約半分になりました。acceptanceがdraft / verifyの処理コストを補うほど高くありませんでした。

フィルタの影響を調べるため、p_min を 0.0 にして再度測りました。

  MTP on, p_min=0.0:   TG 17-23 t/s   acceptance never cleared ~0.56

acceptanceは約0.56まででした。

Config (1.630bpw, full GPU)	MTP	TG (t/s)	Acceptance
`-ngl 80 -mla 3 -ger`	off	34-40	—
`-ngl 80 -mla 3 -ger` + spec-type	on	15-22	0.25-0.56
`-ngl 80 -mla 3 -ger` + spec-type, p_min=0.0	on	17-23	<= 0.56

Part 3 — 2.244bpw (大きいほうのモデル)

2.244bpw（196.756 GiB）はKVとcompute buffer込みで192GBを超え、expertの一部がCPUに残ります。試した範囲で安定した構成は2 GPU、-ngl 65、grouped expert routing（-ger）、MTP offでした。

  podman run --rm -it --name test-model --network host --device nvidia.com/gpu=all --cap-add SYS_NICE \
  -v /mnt/data/hf/hub/models--sokann--GLM-5.2-GGUF-2.244bpw:/models:ro,Z \
  registry.home.arpa/ik_llama:latest \
  -m /models/snapshots/16264a0f7b811d976a9acf704d8511f1127ada30/GLM-5.2-GGUF-2.244bpw.gguf \
  --merge-qkv --ctx-size 102400 --parallel 1 --threads 15 --threads-batch 15 \
  -ctk q8_0 -b 2048 -ub 2048 -sm graph -ngl 65 -mla 3 -amb 512 -muge -ger \
  --temp 0.6 --top-k 20 --top-p 0.95 --jinja --reasoning off \
  --host 0.0.0.0 --port 8000 --warmup-batch --alias test-model

実測値です。

  2.244bpw, 2 GPU, ngl65, -ger, MTP off:   PP 672 t/s   TG 15.28 t/s

この比較の最良は約15.28 t/sで、1.630bpw全GPUの半分以下です。PPL 3.84は良いものの、全GPUには載りません。

Part 4 — 単一GPUにexpertを詰めるだけ詰める(2.244bpw・MTP off)

2.244bpwを単一GPUへできるだけ載せました。-ot でexpert 3-5、40-42、60-77をCUDA0へ振り分けます。

  podman run --rm -it --name test-model --network host --device nvidia.com/gpu=0 --cap-add SYS_NICE \
  -v /mnt/data/hf/hub/models--sokann--GLM-5.2-GGUF-2.244bpw:/models:ro,Z \
  registry.home.arpa/ik_llama:latest \
  -m /models/snapshots/16264a0f7b811d976a9acf704d8511f1127ada30/GLM-5.2-GGUF-2.244bpw.gguf \
  -ngl 99 -cmoe \
  -ot 'blk\.([345]|1[0-9]2[0-9]|6[0-9]|7[0-7])\.ffn_.*_exps\.weight=CUDA0' \
  -ot 'blk\.6\.ffn_(up|gate)_exps\.weight=CUDA0' \
  -ot 'blk\.(40|41|42)\.ffn_.*_exps\.weight=CUDA0' \
  --threads 15 --threads-batch 15 -mla 3 -amb 512 -c 131072 -ctk q8_0 -khad \
  -b 8192 -ub 4096 -wgt 1 -muge --jinja --parallel-tool-calls \
  --chat-template-kwargs '{"reasoning_effort": "low"}' \
  --host 0.0.0.0 --port 8000 --alias test-model

記録ではexpert 3-6、40-42、60-77がCUDA0、残りがCUDA_Hostです。CUDA0 buffer 74347 MiB、CUDA_Host buffer 124459 MiB でした。121.54 GiBのpinned host memory確保に、起動時約13秒かかりました。

20,508-token prefill、-ub 4096 の実測です。

  2.244bpw, 1 GPU, expert-saturated, MTP off:   PP 576.73 t/s   TG 10.23 t/s

nvtopはGPU0 85GB/95GB（memory 88%、compute約32%）でした。単一GPUでは最も速く、Part 8のMTP構成（8.93 t/s）を上回りました。

Part 5 — expertをCPUに寄せたときの下限(`-ot exps=CPU`と`-cmoe`)

下限を確認するため、expertの大半をCPU、一部をGPUへ置きました。

  1.630bpw, -ot exps=CPU hybrid, MTP on:   TG 2.34-2.36 t/s (task 0/13)

  2.244bpw, -cmoe (all experts CPU):   prefill ~63 s for 20,480 tokens, TG a few t/s

-cmoe はTG約5 t/s、20,480 tokenのprefillに約63秒でした。-ot exps=CPU にMTPを加えたhybridは2.34-2.36 t/sへ下がりました。CPU forwardが遅い構成では、draft / verifyがさらに負担になる結果です。

Part 6 — 2.244bpwの`-ngl`を下げていく(何層がCPUに残るか)

2.244bpw・2 GPUで -ngl を段階的に下げ、CPUに残る上位layerのコストを調べました。

-ngl 70 (10層をCPU)・MTP off:

  podman run --rm -it --name test-model --network host --device nvidia.com/gpu=all --cap-add SYS_NICE \
  -v /mnt/data/hf/hub/models--sokann--GLM-5.2-GGUF-2.244bpw:/models:ro,Z \
  registry.home.arpa/ik_llama:latest \
  -m /models/snapshots/16264a0f7b811d976a9acf704d8511f1127ada30/GLM-5.2-GGUF-2.244bpw.gguf \
  --merge-qkv --ctx-size 32768 --parallel 1 --threads 15 --threads-batch 15 \
  -ctk q8_0 -b 2048 -ub 2048 -ngl 70 -mla 3 -amb 512 -muge -ger \
  --temp 0.6 --top-k 20 --top-p 0.95 --jinja --reasoning off \
  --host 0.0.0.0 --port 8000 --warmup-batch --alias test-model

offloaded 70/80 layers to GPU で、CUDA0 91.6GB / CUDA1 89.0GB / CUDA_Host 18.1GBでした。expert 69-78がCPUに残り、両GPUはほぼ満杯です。

  task 0:   PP 611 t/s   TG 17.64 t/s   (20,502-token prefill)
task 69:  PP 630 t/s   TG 20.02 t/s

TGは17.6-20 t/sでした。nvtopではGPU1が100%になる一方、GPU0が0%へ落ちる動きが見え、CPU↔GPUをまたぐlayer配置の影響と考えました。

-ngl 65 (15層をCPU)・MTP on: -ngl 65のhybridに--spec-type mtp:n_max=4,p_min=0.5を足すと:

  2.244bpw, ngl65 hybrid, MTP on:   TG 4.6 t/s   acceptance 0.67-0.71

acceptanceは0.67-0.71でも、遅いCPU forwardをMTPで補えませんでした。

Part 7 — `-mla 1` vs `-mla 3`

-mla 1 はKV VRAMが少ない代わりに -mla 3 より遅くなりました。MTP acceptanceは少し高く、1 GPU / 2 GPUで同じ傾向でした。

2 GPU・-ngl 50・-otでexpert 3-9 / 40-49・MTP on:

  # -mla 1 variant
... -ngl 50 -mla 1 -amb 512 -ot "blk\.([3-9]|4[0-9])\.ffn_.*_exps\.weight=CPU" ... \
  --spec-type mtp:n_max=4,p_min=0.5

  ngl50, ot[3-9/40-49], -mla 1, MTP on:   PP 369 t/s   TG 5.40 t/s   acceptance 0.763
ngl50, ot[3-9/40-49], -mla 3, MTP on:   PP 371 t/s   TG 5.14 t/s   acceptance 0.712

1 GPU・-ub 4096・MTP on:

  1 GPU, -mla 1, MTP on:   PP 406 t/s   TG 6.52 t/s   acceptance 0.766   (470-token gen)
1 GPU, -mla 3, MTP on:   PP 505 t/s   TG 7.05 t/s   acceptance 0.682

-mla 1 のacceptanceは約+0.05（2 GPU 0.712→0.763、1 GPU 0.682→0.766）でした。PP/TGは -mla 3 がわずかに高いものの、どちらもMTP offには届きません。

Part 8 — 作者の`-ot`配置を再現してみる(今回のMTP最良)

READMEは2x24GB向けに -cmoe + -ot + -mla 1 + -ub 2048 + -cram 0 で大半のexpertをCPUへ置きます。手元で同様の配置にすると、今回のMTPで最も高いacceptanceが出ました。

  podman run --rm -it --name test-model --network host --device nvidia.com/gpu=all --cap-add SYS_NICE \
  -v /mnt/data/hf/hub/models--sokann--GLM-5.2-GGUF-2.244bpw:/models:ro,Z \
  registry.home.arpa/ik_llama:latest \
  -m /models/snapshots/16264a0f7b811d976a9acf704d8511f1127ada30/GLM-5.2-GGUF-2.244bpw.gguf \
  --no-mmap -ngl 99 -cmoe -sm graph \
  -ot 'blk\.([345])\.ffn_.*_exps\.weight=CUDA0' \
  -ot 'blk\.6\.ffn_(up|gate)_exps\.weight=CUDA0' \
  -ot 'blk\.(40|41|42)\.ffn_.*_exps\.weight=CUDA1' \
  -mla 1 -amb 512 -c 102400 -ctk q6_0 -khad \
  -b 2048 -ub 2048 -wgt 1 -cram 0 -muge -cuda graphs=1 \
  --jinja --parallel-tool-calls \
  --chat-template-kwargs '{"reasoning_effort": "high"}' \
  --spec-type mtp:n_max=4,p_min=0.5 ...

expertはほぼCPU、blk 3-6 / 40-42だけGPUで、実効VRAMは約48GBです。

  -ot, MTP on:   PP 351 t/s   TG 8.93 t/s   acceptance 0.835

TG 8.93 t/s、acceptance 0.835で、今回のMTPでは最良でした。約48GBで動かす、省VRAM向けの配置です。

1.630bpw (sub-2-bit)の生成品質

短い関数では実装から修復まで破綻しませんでした。4k tokenを超えると細かなミスが増え、== が ==== になる例がありました。短い出力を検査しながらSFT用データを作る用途は考えられますが、長文は歩留まりが悪いと感じました。

結果まとめ(今回試した範囲)

Config	Quant	GPUs	MTP	PP (t/s)	TG (t/s)	Acceptance	VRAM
Full GPU `-ngl 80`	1.630	2	off	250-750	34-40	—	144GB
Full GPU `-ngl 80` + spec	1.630	2	on	350-750	15-22	0.25-0.56	144GB
Full GPU, p_min=0.0	1.630	2	on	350-750	17-23	<= 0.56	144GB
`-ngl 65 -ger -sm graph`	2.244	2	off	672	15.28	—	2枚フル+15層CPU
`-ngl 70` (10 CPU)	2.244	2	off	611-630	17.6-20	—	GPU180.6+CPU18.1
1 GPU expert-saturated	2.244	1	off	576	10.23	—	85GB
author `-ot` (blk 3-6/40-42)	2.244	2	on	351	8.93	0.835	~48GB
1 GPU `-mla 1`	2.244	1	on	406	6.52	0.766	—
1 GPU `-mla 3`	2.244	1	on	505	7.05	0.682	—
`-ngl 50` ot, `-mla 1`	2.244	2	on	369	5.40	0.763	—
`-ngl 50` ot, `-mla 3`	2.244	2	on	371	5.14	0.712	—
`-ngl 65` hybrid	2.244	2	on	—	4.6	0.67-0.71	—
`-ot exps=CPU` hybrid	1.630	—	on	—	2.34-2.36	—	—
`-cmoe` (all CPU)	2.244	2	on	floor	few	—	—

PP・TG・VRAMのトレードオフ

速度優先：1.630bpw全GPU・MTP offで約37 t/s、VRAM約144GBです。
省VRAM：作者の -ot 配置・MTP onで約48GB、TG 8.93、PP 351でした。

量子化、GPU枚数、layer配置、attention、MTPを変えた範囲の記録です。VRAM 48GB、TG 8、PP 350程度なら、LLM導入後の長時間パイプライン処理に使う案があります。MTPのコストや別ハード・エンジンの工夫は、次の記事を参考にしています。 https://dnhkng.github.io/posts/gh200-benchmarking-part-3-glm52/

DeepSeek V4 Flash 0731のvLLM実測とCPU KV offload

RTX PRO 6000 96GB 2枚でDeepSeek …

DeepSeek-V4-FlashをDwarfStar4の2ノードで評価

DeepSeek-V4-FlashのIQ2XXSを2GPUで …

GLM-5.2 GGUFの量子化・MTP・expert配置を比較

テスト環境

Part 1 — 1.630bpw・フルGPU・MTP off

Part 2 — 同じ構成でMTP on

Part 3 — 2.244bpw (大きいほうのモデル)

Part 4 — 単一GPUにexpertを詰めるだけ詰める(2.244bpw・MTP off)

Part 5 — expertをCPUに寄せたときの下限(-ot exps=CPUと-cmoe)

Part 6 — 2.244bpwの-nglを下げていく(何層がCPUに残るか)

Part 7 — -mla 1 vs -mla 3

Part 8 — 作者の-ot配置を再現してみる(今回のMTP最良)

1.630bpw (sub-2-bit)の生成品質

結果まとめ(今回試した範囲)

PP・TG・VRAMのトレードオフ

Part 5 — expertをCPUに寄せたときの下限(`-ot exps=CPU`と`-cmoe`)

Part 6 — 2.244bpwの`-ngl`を下げていく(何層がCPUに残るか)

Part 7 — `-mla 1` vs `-mla 3`

Part 8 — 作者の`-ot`配置を再現してみる(今回のMTP最良)