GLM-4.7-FlashのCPU・Hybrid・GPU比較

測定した3構成

GLM-4.7-Flash IQ5_K を、EPYC 9175F + RTX PRO 6000 Blackwell で3通りの配置にして計測しました。30B-A3B の MoE で、総パラメータ30B、活性3B、多言語と最大128K tokens の文脈に対応するモデルです。

比較したのは CPU-only、Expert を CPU に置く Hybrid、Full GPU です。PP は100 / 1635 / 3723 tok/s、TG は20 / 67 / 99 tok/sでした。

用途と配置

Hybrid は、GPU の容量を他のモデルや長い context に残したい場合の候補です。

目的

1. GLM-4.7-Flash（IQ5_K）のCPU/Hybrid/Full GPUの3パターンでPrefill・Decode速度を定量比較する
2. MoE Expert Offload（exps=CPU）の実用性を検証する
3. NVFP4量子化でのvLLM実行との比較データを得る

実験環境

モデル仕様

実施内容

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
  

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
  

ik_llama.cpp の Expert Offload で、Expert weights を CPU、Attention と KV cache を GPU に置きました。

Pattern C: Full GPU

48/48レイヤーと全 Expert を GPU に載せました。

NVFP4（vLLM）

GLM-4.7-Flash-NVFP4 は、vLLM の OpenAI 互換サーバーで GPU 実行しました。

結果

3パターン比較サマリー（128Kコンテキスト, 30K+トークン処理）

Pattern A: CPUオンリー詳細

CPU-only の decode は20 t/sでした。ただし30K+ tokens の PP に5分以上かかりました。

Pattern B: Hybrid詳細

Hybrid は CPU-only に対して PP が 16.3倍、TG が 3.3倍でした。

Pattern C: Full GPU詳細

Full GPU は PP 3,700 t/s超、TG は100 t/s近くで、30K+ tokens の入力処理が10秒以内に終わりました。

NVFP4（vLLM）参考値

Llama-4-Maverick Q4/Q8とのCPU比較

考察

配置の使い分け

Hybrid は TG 67 t/sでした。Full GPU の99 t/sより遅い一方、Expert を CPU に置いて VRAM を減らせます。長い context や複数モデルに容量を割くための構成です。

ローカルLLM導入では、速度と GPU 占有量を選ぶ際の比較になります。96GB以下の GPU でも、配置方法を検討する材料です。

PPとTGの支配要因の違い

• PP（Prefill）: 演算量に比例。GPUの並列演算能力が直接効く。CPU→GPU移行で37倍の差
• TG（Decode）: メモリ帯域に比例。CPU→GPU移行でも5倍程度に留まる

prefill はバッチで並列化できます。decode は token ごとの逐次処理で、メモリアクセスの影響を受けます。

CPUで20 t/sの用途

CPU-only の20 t/sは、読書速度の目安約6 t/sを上回ります。Dagster などのバッチ処理が候補ですが、30K+ tokens の PP に5分以上かかるため、長文の即時応答には向きません。

L3 cacheが寄与した可能性

512MB L3 cache が router や頻繁に使う領域の読み込みに効いた可能性があります。30B IQ5_K は1T級 Kimi-K2.5 より作業セットが小さいものの、cache hit rate 自体は測っていません。

他の処理と共存するHybrid構成

Hybrid は 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よりは大幅に快適にしたい

感想

-ot exps=CPU で TG が3.3倍になりました。今回の構成では、Attention 側の GPU 利用が速度改善に寄与しています。

速度を優先する場合は Full GPU、複数モデルやより大きいモデルの容量を残す場合は Hybrid を候補にします。

NVFP4 + vLLM 運用評価

NVFP4 版を vLLM でも動かし、運用時の出力を確認しました。

出力品質

検証した実行では、「リポジトリ読解 → 構成の説明 → ファイル生成 → Gitコミット」を完走しました。出力の破綻はほとんど見られませんでした。この範囲では、量子化による品質低下は実用上の問題になりませんでした。

CPU MoE推論との比較

用途別の適性

向いている用途:

• 常駐型agent / マルチチャット — 応答が速く、複数セッションを並行して捌く余裕がある
• ストリーム前提のUI / API — 高いDecode速度によりスムーズなストリーミング表示が可能
• 高スループットな生成・要約・変換パイプライン
• NATS等と組み合わせた非同期ワークフロー

向いていない用途:

• GPU不使用の完全CPU-only環境
• 1リクエストあたりのコストを極端に抑えたいケース

総合評価

記事時点では、常駐するローカル LLM の候補と考えています。CPU の MoE（Maverick など）を補完・置換する用途を検討中です。

次のステップ

• 対話と速度を優先する場合は Full GPU
• VRAM を残しながら速度も確保する場合は Hybrid (-ot exps=CPU)
• 待ち時間を許容するバッチ処理は CPU-only

次は context 長と同時実行数を変え、Hybrid で別モデルや job に割り当てられる GPU 容量を確認する予定です。

再現方法

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 の fork で、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の仕組み

Expert がパラメータの大部分を占めます。元の見積もりは GLM-4.7-Flash の64 Expert × 各約1.5GBです。-ot exps=CPU は Expert を CPU RAM に置き、Attention、Embedding、Router は GPU に残します。

Expert 選択後の計算は CPU で行います。Attention と KV cache の GPU 処理が、decode の速度改善に寄与します。

ik_llama.cppとllama.cppの違い

ik_llama.cpp は MLA を native support し、DeepSeek2 / GLM-4.7 系を最適化しています。標準 llama.cpp でも GGUF を読めますが、MLA の最適化状況で性能が変わる場合があります。

VRAMが96GB未満の場合

Expert Offload では、Attention と KV cache が主な VRAM 消費です。IQ5_K で約10–15GBと見積もっています。24GB以上の GPU で TG 60+ t/sを期待していますが、この環境以外では未確認です。