背景

GLM-4.7-Flashは、THUDM（Tsinghua大学）が公開したMoEモデルで、64エキスパート中4個を活性化するDeepSeek2アーキテクチャを採用している。総パラメータ約30B、活性パラメータ約2.6Bという軽量構成ながら、多言語対応と長文脈（最大202K tokens）を備えている。

手元のEPYC 9175F + RTX PRO 6000 Blackwell環境で、3つの実行パターンのスループットを比較した。CPU推論とGPU推論で桁違いの性能差が出ること自体は予想通りだが、「MoEのExpertだけをCPUに置くHybrid構成」がどの程度のパフォーマンスになるかが本検証の主題だった。

目的

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

実験環境

項目仕様
CPUAMD EPYC 9175F（Zen 5, 16C, L3 512MB）
GPUNVIDIA RTX PRO 6000 Blackwell Max-Q 96GB
メモリDDR5-6400 768GB（12ch）
OSUbuntu 24.04 LTS
Runtime（CPU/Hybrid/GPU）ik_llama.cpp（build 4192, commit 1cb7e1bf）
Runtime（NVFP4）vLLM（OpenAI API互換サーバー）
ModelGLM-4.7-Flash IQ5_K（GGUF, ubergarm量子化）
Model（NVFP4）GLM-4.7-Flash-NVFP4
コンテキスト131,072 tokens（128K）

モデル仕様

項目値
アーキテクチャDeepSeek2（MoE）
レイヤー数47
エキスパート数64（活性4）
共有エキスパート1
AttentionMLA（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速度合計処理時間備考
ACPUオンリー100.32 t/s20.23 t/s879s純CPU、128K文脈では遅い
BHybrid（exps=CPU）1,635.35 t/s66.84 t/s169sPPがCPU比16倍
CFull GPU3,723.34 t/s99.42 t/s80s生成100 t/s到達

Pattern A: CPUオンリー詳細

#PP(tok)TG(tok)PP速度(t/s)TG速度(t/s)合計時間(s)
131,151427100.3221.51330.4
29806,28445.5519.85338.1
32,8862,92148.5319.34210.5
合計35,0179,63289.4419.76879.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)
131,1517741,635.3570.0130.1
29814,091792.9167.0462.3
32,3882,692900.8266.2643.3
48742,106619.9066.1033.3
合計35,3949,6631,453.7666.84168.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)
131,1516303,723.34106.6714.3
29814,3251,638.0499.1644.2
32,3731,9181,619.9797.8421.1
合計34,5056,8733,308.1999.4379.6

Full GPUではPP 3,700 t/s超、TG 100 t/s近辺。30K+トークンの入力処理が10秒以内で完了する。

NVFP4（vLLM）参考値

指標値備考
Prefill80-250 t/s（ピーク459 t/s）Prefix cache有効時にピーク
Decode60-100 t/s（ピーク112 t/s）安定レンジ
TTFT（800-1100トークン入力）4-6秒Prefix cache効果で短縮可能
Prefix cache hit rate20-40%反復agent実行で上昇
GPU KV cache使用率<1%大幅な余裕あり

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

項目GLM-4.7-Flash GPUMaverick CPU (Q4/Q8)
TTFT4-6秒12-20秒
Prefill80-250 t/s50-68 t/s
Decode60-100 t/s15-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構成（-ot exps=CPU）の性能が想像以上に良かった。Expert（全パラメータの大部分）をCPUに置いても、Attention層だけGPUに任せるだけでTGが3.3倍になる。これはik_llama.cppのExpert Offload機能の成熟を示している。

VRAMに余裕があるならFull GPU一択だが、96GB GPUで複数モデルを同時運用したい場合や、より大きなモデルを試したい場合、Hybrid構成は「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が期待できる。