GLM-4.7-Flash IQ5_K ベンチマーク：CPU/Hybrid/Full GPUの3パターン実測比較
GLM-4.7-Flash（IQ5_K GGUF）をCPUオンリー、MoE Expertオフロード（Hybrid）、Full GPUの3構成で実測。Prefill 100 vs 1635 vs 3723 tok/s、Decode 20 vs 67 vs 99 tok/sという桁違いの差が出た理由と、各構成の使いどころを整理する。
背景
GLM-4.7-Flashは30B-A3BのMoEモデル（総パラメータ30B、活性パラメータ3B）で、多言語対応と長文脈（最大128K tokens）を備えている。
手元のEPYC 9175F + RTX PRO 6000 Blackwell環境で、3つの実行パターンのスループットを比較した。CPU推論とGPU推論で桁違いの性能差が出ること自体は予想通りだが、「MoEのExpertだけをCPUに置くHybrid構成」がどの程度のパフォーマンスになるかが本検証の主題だった。
用途別の推奨構成
| パターン | 構成 | Max PP Speed | Avg TG Speed | 推奨用途 |
|---|---|---|---|---|
| A | CPU-only | 100.32 t/s | 20.23 t/s | オフライン・バッチ処理 |
| B | exps=CPU (Hybrid) | 1635.35 t/s | 66.84 t/s | VRAM 節約 + 実用速度の両立 |
| C | exps on GPU (Full) | 3723.34 t/s | 99.42 t/s | 対話・パイプライン・常駐エージェント |
Hybridは「妥協構成」ではなく、ホームラボ環境では主役になり得る。
目的
- GLM-4.7-Flash（IQ5_K）のCPU/Hybrid/Full GPUの3パターンでPrefill・Decode速度を定量比較する
- MoE Expert Offload（
exps=CPU）の実用性を検証する - NVFP4量子化でのvLLM実行との比較データを得る
実験環境
| 項目 | 仕様 |
|---|---|
| CPU | AMD EPYC 9175F（Zen 5, 16C, L3 512MB） |
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q 96GB |
| メモリ | DDR5-6400 768GB（12ch） |
| OS | Ubuntu 24.04 LTS |
| Runtime（CPU/Hybrid/GPU） | ik_llama.cpp（build 4192, commit 1cb7e1bf） |
| Runtime（NVFP4） | vLLM（OpenAI API互換サーバー） |
| Model | GLM-4.7-Flash IQ5_K（GGUF, ubergarm量子化） |
| Model（NVFP4） | GLM-4.7-Flash-NVFP4 |
| コンテキスト | 131,072 tokens（128K） |
モデル仕様
| 項目 | 値 |
|---|---|
| アーキテクチャ | DeepSeek2（MoE） |
| レイヤー数 | 47 |
| エキスパート数 | 64（活性4） |
| 共有エキスパート | 1 |
| Attention | MLA（Multi-head Latent Attention） |
| コンテキスト長（学習時） | 202,752 |
| 語彙サイズ | 154,880 |
実施内容
Pattern A: CPUオンリー
ksh3@compute-server:~$ podman run --rm -it -p 8081:8080 --shm-size 16g --cap-add=SYS_NICE \
-v "$MO":/models:ro,Z $IMG \
--host 0.0.0.0 --port 8080 -m "$MODEL" --no-mmap --jinja \
-c 131072 -n 8192 --threads 13 --threads-batch 23 \
-b 2048 -ub 2048 -ctk f16 -ctv f16
AVX-512 VNNI / BF16が有効な状態（AVX512 = 1 | AVX512_VNNI = 1 | AVX512_BF16 = 1）で、全レイヤーをCPUで実行。
Pattern B: Hybrid（Expert=CPU, Attention=GPU）
# -ot exps=CPU を追加
ksh3@compute-server:~$ podman run --rm -it -p 8081:8080 --shm-size 16g --cap-add=SYS_NICE \
--device nvidia.com/gpu=all \
-v "$MO":/models:ro,Z $IMG \
--host 0.0.0.0 --port 8080 -m "$MODEL" --no-mmap --jinja \
-c 131072 -n 8192 --threads 13 --threads-batch 23 \
-b 2048 -ub 2048 -ctk f16 -ctv f16 \
-ot exps=CPU
MoEのExpertウェイト（モデル容量の大部分）をCPUに配置し、Attention/KVキャッシュのみGPUで処理するik_llama.cpp固有の機能。
Pattern C: Full GPU
全レイヤー・全Expertを GPU にロード。48/48レイヤーGPUオフロード。
NVFP4（vLLM）
vLLMのOpenAI互換サーバーでGLM-4.7-Flash-NVFP4を実行。GPU上でNVFP4量子化で動作。
結果
3パターン比較サマリー（128Kコンテキスト, 30K+トークン処理）
| パターン | 構成 | 最大PP速度 | 平均TG速度 | 合計処理時間 | 備考 |
|---|---|---|---|---|---|
| A | CPUオンリー | 100.32 t/s | 20.23 t/s | 879s | 純CPU、128K文脈では遅い |
| B | Hybrid（exps=CPU） | 1,635.35 t/s | 66.84 t/s | 169s | PPがCPU比16倍 |
| C | Full GPU | 3,723.34 t/s | 99.42 t/s | 80s | 生成100 t/s到達 |
Pattern A: CPUオンリー詳細
| # | PP(tok) | TG(tok) | PP速度(t/s) | TG速度(t/s) | 合計時間(s) |
|---|---|---|---|---|---|
| 1 | 31,151 | 427 | 100.32 | 21.51 | 330.4 |
| 2 | 980 | 6,284 | 45.55 | 19.85 | 338.1 |
| 3 | 2,886 | 2,921 | 48.53 | 19.34 | 210.5 |
| 合計 | 35,017 | 9,632 | 89.44 | 19.76 | 879.0 |
CPUオンリーでも20 t/sのDecode速度。IQ5_K量子化の30Bモデルとしては十分な数値だが、30K+トークンのPP処理に5分以上かかる。
Pattern B: Hybrid詳細
| # | PP(tok) | TG(tok) | PP速度(t/s) | TG速度(t/s) | 合計時間(s) |
|---|---|---|---|---|---|
| 1 | 31,151 | 774 | 1,635.35 | 70.01 | 30.1 |
| 2 | 981 | 4,091 | 792.91 | 67.04 | 62.3 |
| 3 | 2,388 | 2,692 | 900.82 | 66.26 | 43.3 |
| 4 | 874 | 2,106 | 619.90 | 66.10 | 33.3 |
| 合計 | 35,394 | 9,663 | 1,453.76 | 66.84 | 168.9 |
Hybrid構成でPPが16.3倍、TGが3.3倍に向上。ExpertをCPUに置いても、Attention層をGPUが担うだけで劇的な改善が得られる。
Pattern C: Full GPU詳細
| # | PP(tok) | TG(tok) | PP速度(t/s) | TG速度(t/s) | 合計時間(s) |
|---|---|---|---|---|---|
| 1 | 31,151 | 630 | 3,723.34 | 106.67 | 14.3 |
| 2 | 981 | 4,325 | 1,638.04 | 99.16 | 44.2 |
| 3 | 2,373 | 1,918 | 1,619.97 | 97.84 | 21.1 |
| 合計 | 34,505 | 6,873 | 3,308.19 | 99.43 | 79.6 |
Full GPUではPP 3,700 t/s超、TG 100 t/s近辺。30K+トークンの入力処理が10秒以内で完了する。
NVFP4（vLLM）参考値
| 指標 | 値 | 備考 |
|---|---|---|
| Prefill | 80-250 t/s（ピーク459 t/s） | Prefix cache有効時にピーク |
| Decode | 60-100 t/s（ピーク112 t/s） | 安定レンジ |
| TTFT（800-1100トークン入力） | 4-6秒 | Prefix cache効果で短縮可能 |
| Prefix cache hit rate | 20-40% | 反復agent実行で上昇 |
| GPU KV cache使用率 | <1% | 大幅な余裕あり |
CPU MoE（Llama-4 Maverick Q4/Q8）との比較
| 項目 | GLM-4.7-Flash GPU | Maverick CPU (Q4/Q8) |
|---|---|---|
| TTFT | 4-6秒 | 12-20秒 |
| Prefill | 80-250 t/s | 50-68 t/s |
| Decode | 60-100 t/s | 15-24 t/s |
| 対話用途 | 優 | やや不向き |
| バッチ用途 | 優 | 実用的 |
考察
Hybrid構成の費用対効果
Pattern B（Hybrid）はこの検証の最大の発見だった。VRAMが足りないからExpertをCPUに逃がす、というのは妥協策に見えるが、実際にはTG 67 t/sという「対話にも使えそうな」速度が出る。Full GPUの99 t/sには及ばないが、ExpertをCPUに置くことでVRAMを大幅に節約でき、より長いコンテキストや複数モデルの同時実行が可能になる。
これはVRAMが限られた環境（96GB以下のGPU）でも、MoEモデルの恩恵を最大限に受けるための戦略として有用な選択肢になりうる。
PPとTGの支配要因の違い
- PP（Prefill）: 演算量に比例。GPUの並列演算能力が直接効く。CPU→GPU移行で37倍の差
- TG（Decode）: メモリ帯域に比例。CPU→GPU移行でも5倍程度に留まる
この非対称性は、MoEモデルの構造に起因する。Prefillはバッチ処理で並列化しやすいが、Decodeはトークンごとの逐次処理でメモリアクセスが支配的になる。
CPUオンリーでも20 t/sは実用的
Pattern Aの20 t/sは、人間の読書速度（約6 t/s）を大きく上回る。バッチ処理（Dagsterパイプラインなど）では十分な速度。ただし30K+トークンのPP処理に5分以上かかるため、長文脈のリアルタイム利用には不向き。
EPYC 9175FのL3キャッシュはここでも効いている
CPUオンリーで20 t/sが出るのは、512MB L3キャッシュによるMoE Routerとホット領域のキャッシュヒットが効いていると考えられる。IQ5_K量子化の30Bモデルであれば、Kimi-K2.5（1T級）より作業セットが小さく、L3のヒット率はさらに高いはず。
Hybridが持つパイプライン的な意義
ExpertのウェイトをCPUにオフロードする目的はVRAM節約だけではない。Hybridは、1モデルをとにかく最速にする発想ではなく、GPUを別の用途に残しながらGLM-4.7-Flashを実用速度で回すための構成とも言える。
GPU 使用量 Hybrid vs Full GPU
┌───────────────────────────────┐
│ Full GPU │
│ Attention │ Experts (GPU) │ ← GPU 全占有
└───────────────────────────────┘
┌───────────────────────────────┐
│ Hybrid │
│ Attention (GPU) │ [余剰VRAM] │ ← 別モデル・別ジョブに使える
└───────────────────────────────┘
↓
Experts (CPU)
これは次のような要件に対して有効な構成になる。
- 1台のGPUを完全占有したくない
- より長いコンテキストや別モデルの同居を考えたい
- それでもCPU-onlyよりは大幅に快適にしたい
感想
Hybrid構成（-ot exps=CPU）の性能が想像以上に良かった。Expert（全パラメータの大部分）をCPUに置いても、Attention層だけGPUに任せるだけでTGが3.3倍になる。これはik_llama.cppのExpert Offload機能の成熟を示している。
VRAMに余裕があるならFull GPU一択だが、96GB GPUで複数モデルを同時運用したい場合や、より大きなモデルを試したい場合、Hybrid構成は「VRAMを節約しつつ実用的な速度を維持する」戦略として有効。
NVFP4 + vLLM 運用評価
IQ5_Kのベンチマークに加え、GLM-4.7-Flash-NVFP4をvLLMで運用した場合の適性も評価した。
出力品質
指示に対する追従性は高く、出力が破綻するケースはほとんど見られなかった。「リポジトリの読解 → 構成の把握・説明 → ファイルの生成 → Gitコミット」という一連の複雑なフローを、一気通貫で完走できた。量子化によるデグレードが実用上の問題になるレベルではない。
CPU MoE推論との比較
| 項目 | GLM-4.7-Flash (GPU/vLLM) | Maverick Q4/Q8 (CPU) |
|---|---|---|
| TTFT | ~4–6秒 | 12–20秒 |
| Prefill tok/s | 80–250（ピーク ~459） | 50–68 |
| Decode tok/s | 60–100（ピーク ~112） | 15–24 |
| 対話用途の適性 | 優 | やや不向き |
| バッチ用途の適性 | 優 | 実用的 |
用途別の適性
向いている用途:
- 常駐型agent / マルチチャット — 応答が速く、複数セッションを並行して捌く余裕がある
- ストリーム前提のUI / API — 高いDecode速度によりスムーズなストリーミング表示が可能
- 高スループットな生成・要約・変換パイプライン
- NATS等と組み合わせた非同期ワークフロー
向いていない用途:
- GPU不使用の完全CPU-only環境
- 1リクエストあたりのコストを極端に抑えたいケース
総合評価
| 観点 | 評価 |
|---|---|
| 性能 | ローカルGPU環境でのスループットは実用上の問題なし |
| 安定性 | Prefix cacheが効果的に機能し、反復実行・連続ワークフローに強い |
| 実用性 | 対話型agentとバッチ/パイプラインの両立が十分可能 |
現在のローカルGPU環境における「主力LLM」の最有力候補として評価している。これまで頼りにしていたCPU稼働のMoEモデル（Maverick等）を補完、あるいは置換する存在として位置づけている。
次のステップ
- 日常利用や本番寄りの対話用途では
Full GPUが最強 - VRAMと速度の両立を狙うなら
Hybrid (-ot exps=CPU)が非常に優秀 CPU-onlyも成立するので、完全CPU環境の現実性確認としては意味がある
次に詰めるなら、同じGLM-4.7-Flash系でコンテキスト長や同時実行数を振ったときの変化、そしてHybrid構成でどこまでGPU側の余剰を別モデルや別ジョブに回せるかを見ていきたい。特にHybridで67 t/s近い生成速度を出しながらVRAM圧力を下げられる構成は、長大コンテキスト運用や複数ワークロード共存の足場としてかなり使いやすい。
再現方法
1. モデル取得
# IQ5_K GGUF
huggingface-cli download ubergarm/GLM-4.7-Flash-GGUF \
--include "GLM-4.7-Flash-IQ5_K.gguf" \
--local-dir /mnt/data/hf/hub/models--ubergarm--GLM-4.7-Flash-GGUF
2. ik_llama.cppのビルド
ik_llama.cppはllama.cppのフォークで、MLA（Multi-head Latent Attention）とExpert Offloadに対応している。Zen 5最適化ビルドが必要。
3. 実行（3パターン）
# 共通変数
IMG=compute.home.arpa/ik_llama-cpu:latest
MO=/mnt/data/hf/hub/models--ubergarm--GLM-4.7-Flash-GGUF
MODEL=/models/snapshots/.../GLM-4.7-Flash-IQ5_K.gguf
# Pattern A: CPUオンリー
podman run --rm -it -p 8081:8080 --shm-size 16g --cap-add=SYS_NICE \
-v "$MO":/models:ro,Z $IMG \
-m "$MODEL" --no-mmap --jinja \
-c 131072 -n 8192 --threads 13 --threads-batch 23 \
-b 2048 -ub 2048 -ctk f16 -ctv f16 \
--host 0.0.0.0 --port 8080
# Pattern B: Hybrid（Expert=CPU）
# 上記に --device nvidia.com/gpu=all と -ot exps=CPU を追加
# Pattern C: Full GPU
# --device nvidia.com/gpu=all を追加（-ot exps=CPU なし）
補足ノウハウ
Expert Offloadの仕組み
MoEモデルでは、パラメータの大部分がExpertウェイトに集中している（GLM-4.7-Flashの場合、64個のExpert x 各1.5GB程度）。-ot exps=CPUはこのExpert部分のみをCPU RAMに配置し、Attention層・Embedding層・Router層をGPUに残す。
Expert選択後の計算はCPUで行われるが、Attention計算（特にKVキャッシュのアクセス）がGPUで高速化されるため、全体のボトルネックがExpert計算からAttention計算に移り、Decode速度が大幅に改善する。
ik_llama.cppとllama.cppの違い
ik_llama.cppはMLA（Multi-head Latent Attention）のネイティブサポートを持ち、DeepSeek2/GLM-4.7系のモデルで最適なパフォーマンスを発揮する。標準のllama.cppでもGGUFは読めるが、MLAの最適化が不十分な場合がある。
VRAMが96GB未満の場合
Expert OffloadによりVRAM消費はAttention層+KVキャッシュ程度（GLM-4.7-Flash IQ5_Kで約10-15GB程度）に抑えられる。24GB以上のGPUがあれば、Hybrid構成でTG 60+ t/sが期待できる。