Llama-4-Scout-17B-16E実測：CPU Q6_K 17tok/s vs GPU nvfp4 60tok/s、キャッシュ戦略と100kコンテキスト境界
Llama-4-Scout（17B活性/16エキスパートMoE）をEPYC 9175FのCPU Q6_K推論とRTX PRO 6000 Blackwell Max-QのGPU nvfp4推論で実測比較。CPU 17tok/s vs GPU 30-60tok/s。mmapキャッシュ戦略、prompt cache、100kコンテキスト境界を検証した。
背景
Llama-4-ScoutはMetaのMoEモデルで、16エキスパート・17B活性パラメータ。Maverickの128エキスパートと比べてエキスパート数が少ないため、CPUでのキャッシュ効率が構造的に有利になる。
同じモデルをCPU推論（Q6_K / llama.cpp）とGPU推論（nvfp4 / vLLM）の両方で動かし、速度・品質・メモリ挙動を比較した。「CPU LLMは遅い」という印象が初回挙動に引きずられている可能性を、キャッシュ温後の定常性能で示す。
目的
- CPU Q6_K推論の定常速度を実測（キャッシュ温後）
- GPU nvfp4推論のPrefill/Decode速度とVRAM配分を記録
- mmapページキャッシュとprompt cacheの効果を定量化
- 100kコンテキスト境界の実態を把握
実験環境
| 項目 | 仕様 |
|---|---|
| CPU | AMD EPYC 9175F（Zen 5, 16C, L3 512MB） |
| メモリ | DDR5-6400 768GB（12ch） |
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q（96GB VRAM） |
| OS | Ubuntu 24.04 LTS |
2構成
| 構成 | Runtime | 量子化 | 配置 | ctx |
|---|---|---|---|---|
| A: CPU | llama.cpp | Q6_K（3分割GGUF） | 全CPU | 8,192 |
| B: GPU | vLLM 0.14.0rc1 | nvfp4（NVIDIA ModelOpt） | 全GPU | ~110K |
結果
構成A: CPU Q6_K（th=16, ctx=8K）
| 指標 | 測定値 | 備考 |
|---|---|---|
| PP（Prefill） | 約40 tok/s | 2.5k-5kトークンでも安定 |
| TG（Decode） | 16.3-17.5 tok/s | 16コア均一負荷、温度64℃固定 |
初回実行はmmapページフォールト＋フルPrefillで極端に遅い。2回目以降、OSページキャッシュ＋prompt cacheが効いて定常速度に到達。prompt cacheのLCP（Longest Common Prefix）一致時はf_keep > 0.7を確認。
構成B: GPU nvfp4（vLLM, Blackwell 96GB）
| 指標 | 測定値レンジ | ピーク | 備考 |
|---|---|---|---|
| PP（Prefill） | 700-1,200 tok/s | 1,370 tok/s | 長文プロンプトで顕在化 |
| TG（Decode） | 30-60 tok/s | 112 tok/s | ウォームアップ後安定 |
Prefix Cache Hit Rate: 10-48%。48%到達時はTTFTが大幅短縮。
VRAM内訳
| 項目 | 占有量 |
|---|---|
| モデル常駐 | 約63.5 GiB |
| KVキャッシュ利用可能分 | 約20.2 GiB |
| 最大コンテキスト長 | 約110,256 tokens |
BF16相当のKV管理で約100kトークンが1GPU上限。256k以上にはFP8 KVまたはTP=2が必要。
比較サマリ
| 構成 | TG(tok/s) | VRAM | 用途 |
|---|---|---|---|
| A: CPU Q6_K | 16-17 | 0 | バッチ要約、F&Fパイプライン |
| B: GPU nvfp4 | 30-60 | ~64GB | aider、対話型コード生成 |
考察
CPUキャッシュ戦略の効果
「CPU LLMは遅い」は初回挙動だけを見た限定的な評価。mmapとprompt cacheを正しく設計すれば、定常状態で17 tok/sが安定する。重要なのは:
--mlockで全重みを物理メモリにロック- System Promptを固定してLCP一致率を最大化
- プロセスを再起動しない（OSページキャッシュを維持）
16エキスパートの構造的優位性
128エキスパートのMaverickと比較して、Scoutは16エキスパートで「疎の密度」が低い。EPYC 9175Fの1CCD=1Core配置では、選択されるエキスパートが少ないことがL3キャッシュ内のワーキングセット保持率を高め、メモリ帯域依存を下げる。
nvfp4の品質
Django/Python設計タスクでの品質はFP4でも実用レベル。指示追従性、日本語品質ともに安定。数学的厳密推論はやや弱いが、ボイラープレート生成やロジックレビューでは許容範囲。
感想
CPU 17 tok/sとGPU 30-60 tok/sの間には体感で明確な差がある。だがCPUの17 tok/sは非対話型パイプラインでは十分実用的で、GPUを他のモデルに割り当てられる。
GPU nvfp4の1,370 tok/s Prefillは圧倒的。aiderでの反復リファクタリングではTTFTの短さが開発速度に直結する。Prefix Cacheが48%に達するとほぼ即応。
16エキスパート構成は128エキスパートのMaverickより「キャッシュに優しい」。CPU推論でのtok/s差（Scout 17 vs Maverick 21-24）はエキスパート数の違いよりモデルサイズの違いが支配的だが、安定性ではScoutの方が読みやすい挙動をする。
再現方法
CPU Q6_K
numactl --cpunodebind=0 --membind=0 \
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 /models/Scout-17B-Q6_K.gguf \
--threads 16 --threads-batch 16 \
--batch-size 2048 --ubatch-size 512 \
--mlock --ctx-size 8192 --flash-attn on \
--parallel 1 --jinja
GPU nvfp4（vLLM）
vllm serve nvidia/Llama-4-Scout-17B-16E-Instruct-NVFP4 \
--dtype auto --gpu-memory-utilization 0.88 \
--max-num-seqs 1 --max-model-len 110000 \
--enable-prefix-caching --trust-remote-code
補足ノウハウ
キャッシュが効かなくなる条件
- プロンプト先頭のテンプレートやツール定義を1文字でも変えるとprompt cacheが無効化、フルPrefillに戻る
- プロセス再起動でOSページキャッシュがパージされ、再びコールドスタートの重いI/O待ちが発生
- cache上限に達すると古いpromptが破棄される
100kコンテキスト境界
1GPU 96GBでnvfp4モデル（63.5 GiB）を載せると、KVキャッシュは約20 GiB。BF16精度のKVで約110kトークンが物理上限。256k/512kを扱うにはFP8 KV＋TP=2構成への拡張が必要。