背景

IQuest-Coder-V1-40B-Instructは40B級のDense（非MoE）コーディング特化モデル。MoEモデルと違い推論時に全パラメータを使うため、計算量がそのままモデルサイズに比例する。

96GB VRAMのRTX PRO 6000 Blackwellがある環境で、CPU推論（Q5_K_M）とGPU推論（nvfp4）の両方を試し、さらにAider（AIコーディングエージェント）のwhole-edit形式での実用性を検証した。結論から言うと、Denseモデルの運用にはGPU + 適切な量子化が必須で、CPU推論とwhole-editは構造的に厳しいことがわかった。

目的

  1. CPU推論（Q5_K_M / llama.cpp）で40B Denseが実用になるか検証
  2. GPU推論（nvfp4 / vLLM）でのスループットとVRAM使用量を計測
  3. Aider whole-edit形式でのコード編集速度を実測
  4. MoEとDenseの実運用上の差を明確にする

実験環境

項目仕様
CPUAMD EPYC 9175F（Zen 5, 16C, L3 512MB）
GPUNVIDIA RTX PRO 6000 Blackwell Max-Q（96GB VRAM）
メモリDDR5-6400 768GB（12ch）
OSUbuntu 24.04 LTS

検証構成

構成Runtime量子化配置
A: CPU推論llama.cpp server（Podman）Q5_K_M（GGUF）CPU RAM
B: GPU推論vLLMnvfp4GPU VRAM
C: Aider利用vLLM（Loop-Instruct variant）nvfp4GPU VRAM

結果

構成A: CPU推論（Q5_K_M, ctx=8k）

項目実測値
TTFT（4k-5kプロンプト時）数十秒（体感破綻）
CPU使用率全コア100%張り付き
問題の本質40B全層を毎トークン計算、省略不可

CPU推論は構造的に実用は厳しい。prompt evalが支配的になり、パイプライン処理（低TTFT前提）は成立しない。SSD配置はロード時間には効くが推論速度には無関係。

構成B: GPU nvfp4（vLLM, ctx=8k-32k）

指標実測値
PP速度1,100-2,300 tok/s
TG速度25-28 tok/s（安定）
KVキャッシュ使用率2-12%
Prefixキャッシュヒット率20-45%

vLLMログからの連続計測（抜粋）:

  Engine 000: Avg generation throughput: 28.3 tokens/s, KV cache usage: 2.0%, Prefix cache hit rate: 22.8%
Engine 000: Avg generation throughput: 28.0 tokens/s, KV cache usage: 2.3%, Prefix cache hit rate: 22.8%
Engine 000: Avg generation throughput: 27.8 tokens/s, KV cache usage: 2.8%, Prefix cache hit rate: 22.8%
Engine 000: Avg generation throughput: 27.4 tokens/s, KV cache usage: 3.5%, Prefix cache hit rate: 22.8%

TG速度は25-28 tok/sで安定。出力長別の体感:

  • 200トークン: 約7-8秒
  • 400トークン: 約14-16秒
  • 800トークン: 約30秒

構成C: Aider whole-edit利用

指標実測値
TG速度0.6-8 tok/s（不安定）
KVキャッシュ使用率7-13%（急激に増加）
Prefixキャッシュヒット率6%（ほぼ無効）

whole-edit形式はファイル全体を再生成するため出力トークン数が爆発。repo-map + 複数ファイル添付でコンテキストが肥大し、KVキャッシュが急速に膨張する。

比較サマリ

構成TG速度(tok/s)実用判定用途
A: CPU Q5_K_M測定不能（TTFT破綻）不可-
B: GPU nvfp425-28実用agent/テスト生成/CI
C: Aider whole-edit0.6-8非実用-

考察

なぜDenseはCPUで厳しいのか

MoEモデル（例: Kimi-K2.5の活性32B）はトークンごとに一部のエキスパートだけ計算する。Denseは40B全層を毎回計算するため、計算量の削減が効かない。同じ「40B級」でもCPU推論の負荷は根本的に異なる。

EPYC 9175Fの12チャネルメモリ帯域でも、Denseの全層アクセスパターンではメモリ帯域が飽和する。MoEのようにL3キャッシュにエキスパートを載せる戦略も使えない。

nvfp4の効率性

nvfp4（4bit量子化）でVRAM使用量を抑えつつ、25-28 tok/sを安定して出せている。Performance Factor（tok/s ÷ モデルB数）で比較すると:

モデルパラメータTG速度tok/s per B
command-a-reasoning111B~11 tok/s0.10
IQuest-Coder-40B nvfp440B26-28 tok/s0.65-0.70

Bあたりの生成効率は111B系の約6-7倍。nvfp4が正しく効いていることが数字で確認できる。

Aider whole-editの構造的問題

whole-edit形式が遅い原因:

  1. ファイル全体を出力するためトークン数が膨大
  2. repo-map + 添付ファイルでpromptも肥大
  3. Prefixキャッシュヒット率が6%（変動するコンテキストのため）
  4. KVキャッシュが急速に膨張（7→13%）

対策はwhole-editを避けてdiff/patch形式に変更すること。出力トークン数を大幅に削減でき、生成速度の問題を構造的に回避できる。

感想

40B Denseモデルの位置づけが明確になった。GPU nvfp4なら日常のagent/aider/CI/テスト生成の有力な選択肢になる。25-28 tok/sは「考えすぎないInstruct型」としてちょうどいい速度帯で、111Bのreasoning系を日常使いする理由が薄くなった。

ただしCPU推論は実用的とは言い難い。Denseの全層計算はMoEの構造的優位性（エキスパート選択による計算量削減）が使えないため、CPUで回すならMoEモデルを選んだ方がよさそうだ。

使い分けの結論:

  • 日常（agent/aider/CI）: IQuest-Coder-40B nvfp4（本命）
  • 深い推論・設計レビュー: command-a-reasoning（サブ）
  • バッチ処理（CPU常駐）: MoEモデル（Kimi-K2.5等）

再現方法

GPU nvfp4（推奨構成） 

  vllm serve IQuestLab/IQuest-Coder-V1-40B-Instruct-nvfp4 \
  --max-num-seqs 1 \
  --max-model-len 32768

CPU Q5_K_M（参考: 非推奨） 

  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" \
  --jinja -c 8192 \
  --threads 14 --threads-batch 14 \
  -b 2048 -ub 512 \
  --parallel 1 --flash-attn on

補足ノウハウ

Dense vs MoEのCPU推論比較

項目Dense 40BMoE 229B（活性10B）
毎トークンの計算量40B全層10B相当
L3キャッシュ活用効かない（全層アクセス）効く（エキスパート局所性）
CPU推論のTG測定困難10-37 tok/s
CPU推論の実用性非実用バッチ用途で実用

Aider設定の最適化

  • --edit-format diff: whole-editを避けて出力を削減
  • temperature=0: greedy固定で生成を高速化
  • repo-mapと/add対象を最小限に
  • max_model_lenを必要最小に設定