背景

Qwen3-Coder-Nextは約80BパラメータのMoEコーディング特化モデル。コード生成・レビュー・セキュリティ監査に強く、ローカルコーディングアシスタントとして期待できる。

問題は実行方法の選択肢が多すぎること。BF16無量子化のCPU推論、IQ4_NLのHybrid GPU offload（Expert CPUオフロード）、nvfp4のフルGPU推論。それぞれ速度・品質・VRAM消費が異なる。同一環境で3モード全てを実測し、用途別の選択基準を出した。

目的

  1. BF16 CPU推論の速度と品質を確認（精度最優先モード）
  2. IQ4_NL Hybrid構成でExpert Offloadの速度ペナルティを定量化
  3. nvfp4 GPU推論のスループットを計測
  4. コーディングタスクでの品質評価

実験環境

項目仕様
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

3構成の概要

構成Runtime量子化Expert配置ctx
A: CPU BF16llama.cppBF16（無量子化）全CPU16k
B: Hybrid offloadik_llama.cppIQ4_NLExpert=CPU, Attn=GPU65k
C: GPU nvfp4vLLMnvfp4全GPU32k

結果

構成A: BF16 CPU推論（th=13, ctx=16k）

指標実測値
PP速度（短prompt）33.37 tok/s
PP速度（287トークン）117.40 tok/s
TG速度（持続）7.59 tok/s
TTFT（287トークン）約2.58秒

2,233トークンの長い生成でもスループットは一定。KV cacheをq8_0にすることでメモリ圧を抑制。

構成B: IQ4_NL Hybrid（Expert CPU offload, ctx=65k）

Run A: exps=CPU（Expert重みをCPUに配置）

指標実測値
GPU buffer（weights）1,403 MiB
CPU buffer（weights）41,472 MiB
graph_splits98
TG速度（加重平均）58.94 tok/s
PP速度（代表値）761-1,120 tok/s

Run B: exps=CPUなし（全重みGPU）

指標実測値
GPU buffer（weights）42,875 MiB
graph_splits2
TG速度（加重平均）85.36 tok/s
PP速度（代表値）880-3,572 tok/s

Expert Offloadの速度ペナルティ: -31%（58.94 → 85.36 tok/s）

構成C: nvfp4 GPU（vLLM, ctx=32k）

指標実測値
TG速度（安定時）17-100 tok/s（変動大）
PP速度17-669 tok/s（バースト時）

vLLMのローリング平均ログのため、値の変動が大きい。安定的な生成時は58-100 tok/s程度。

3構成比較サマリ

構成TG速度(tok/s)VRAM使用品質用途
A: BF16 CPU7.590最高精密レビュー・監査
B: Hybrid exps=CPU58.94~3GB良好通常コーディング
B: Hybrid 全GPU85.36~43GB良好高速コーディング
C: nvfp4 GPU58-100~22GB良好vLLM統合環境

ライブ実演動画

Qwen3-Coder-Nextの実際の出力品質を確認するため、リアルタイム実行を撮影しました。以下の動画はコード生成と論理説明を行っている様子を示しています：

この実演では以下を確認できます：

  • トークン生成の様子をリアルタイムで見ることで、「CPU推論が動いている」という実感が得られます
  • トークン生成の内容を確認できます

考察

BF16 CPU推論の価値

7.59 tok/sは対話用途には遅いが、コードレビューやセキュリティ監査では十分。BF16は量子化劣化がゼロのため、SQLインジェクション検出やパスワード平文リスクの指摘など、精密な判断が求められるタスクで信頼性が高い。

12チャネルDDR5-6400の帯域がBF16の巨大データ転送を支えており、Zen 5のAVX-512 BF16ネイティブ演算が効いている。

Expert Offloadの31%ペナルティ

exps=CPUはVRAMを40GB以上節約する代わりに、生成速度が31%低下する。graph_splitsが98（全GPUでは2）に増加しており、CPU-GPU間の頻繁なデータ転送が原因。

59 tok/sでも十分高速だが、VRAMに余裕がある場合は全GPUロードの方が明確に有利。Expert Offloadは「VRAMが足りない時の妥協策」であり、速度最適化の手段としては向いていない。

コーディング品質

BF16での評価:

  • セキュリティ監査: SQLi脆弱性、平文パスワードリスクを正確に検出し、修正コードとユニットテストを提供
  • ハルシネーション制御: スペック外の質問に対して「NOT IN SPEC」と正しく拒否
  • 複雑なロジック: Django要件の90%を満たすが、マルチテナント安全性の一部を見落とす。高品質なドラフト生成器 + エキスパートレビュー向け

感想

3モードの使い分けが明確になった:

  • 精密作業（BF16 CPU）: セキュリティ監査、最終レビュー。速度は犠牲にするが量子化劣化ゼロ
  • 通常コーディング（Hybrid / GPU）: 日常の開発作業。59-85 tok/sで体感的に速い
  • vLLM統合（nvfp4）: tool-call-parser対応、prefix caching、API統合が必要な場合

Expert Offloadの31%ペナルティは想像より大きかった。「VRAMに載らないから仕方なく使う」設定であることが実測で確認できた。

再現方法

BF16 CPU 

  podman run --rm -it \
  -p 8081:8080 --shm-size 16g --cap-add=SYS_NICE \
  -v "$MO":/models:Z compute.home.arpa/llamacpp-zen5:qwen3-coder-next \
  -m /models/.../BF16/Qwen3-Coder-Next-BF16-00001-of-00004.gguf \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --flash-attn on --ctx-size 16384 \
  --parallel 1 --threads 13 --threads-batch 13 \
  --batch-size 2048 --ubatch-size 512 \
  --jinja --host 0.0.0.0 --port 8080

IQ4_NL Hybrid（Expert CPU offload） 

  podman run --rm -it --device nvidia.com/gpu=all \
  -p 8001:8080 --shm-size 16g --cap-add=SYS_NICE \
  -v "$MO":/models:ro,Z $IMG \
  --host 0.0.0.0 --port 8080 -m "$MODEL" \
  -c 65536 --threads 13 --threads-batch 23 \
  -b 2048 -ub 2048 -ngl 99 \
  -ot exps=CPU -fa on --no-mmap --jinja

nvfp4 GPU（vLLM） 

  vllm serve vincentzed-hf/Qwen3-Coder-Next-NVFP4 \
  --dtype auto --gpu-memory-utilization 0.88 \
  --max-num-seqs 1 --max-model-len 32768 \
  --enable-prefix-caching --trust-remote-code \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder

補足ノウハウ

256kコンテキスト設定

IQ4_NL構成ではctx=262144まで設定可能だが、Expert Offload + 256kの組み合わせはKVキャッシュが巨大になるため現実的ではない。実運用はctx=65536程度が上限。

graph_splitsの意味

graph_splitsはCPU-GPU間のデータ転送回数の指標。exps=CPUでは98（毎層のExpert計算でCPUに戻る）、全GPUでは2（入出力のみ）。この差がそのまま速度差に反映される。