背景

ローカルLLM環境で対話・コード生成・MCP連携を行うにあたり、モデルの量子化レベルをどう選ぶかは恒常的な課題になる。NousResearch Hermes-4.3-36Bは、ツール利用（Function Calling）に強い36Bクラスのモデルで、vLLM環境での運用候補として評価した。

RTX PRO 6000 Blackwell（96GB VRAM）があれば、BF16（非量子化）でも動くが、VRAM使用率が90%を超えコンテキスト長に余裕がない。nvfp4（4bit）なら約22GBで済む。問題は「速さと引き換えに何を失うか」だった。

目的

  1. Hermes-4.3-36Bの3つの量子化パターン（BF16, FP8, nvfp4）で生成速度・TTFT・VRAM消費を定量比較する
  2. 「速い=賢い」という錯覚がどの程度発生するかを評価する
  3. 用途別の量子化選択基準を確立する

実験環境

項目仕様
GPUNVIDIA RTX PRO 6000 Blackwell Max-Q 96GB
CPUAMD EPYC 9175F
メモリDDR5-6400 768GB
RuntimevLLM 0.14.0rc1
ModelNousResearch / Hermes-4.3-36B

実施内容

BF16（非量子化） 

  vllm serve NousResearch/Hermes-4.3-36B \
  --dtype bfloat16 \
  --max-num-seqs 1 \
  --max-model-len 65536

FP8 

  vllm serve NousResearch/Hermes-4.3-36B \
  --dtype bfloat16 \
  --quantization fp8 \
  --max-num-seqs 1 \
  --max-model-len 65536

nvfp4（4bit） 

  vllm serve NousResearch/Hermes-4.3-36B-nvfp4 \
  --max-num-seqs 1 \
  --max-model-len 32768

それぞれの設定で同一の対話タスク・コード生成タスクを実行し、vLLMのログからスループットを計測した。

結果

横断比較

項目BF16FP8nvfp4
生成速度 (TG)17-19 tok/s18-20 tok/s31-33 tok/s
Prefill速度 (PP)300-500 tok/s1000+ tok/s280-500 tok/s
TTFT遅め改善良好
VRAM使用量90%超中約22GB
KV cache使用率6-8%（短文）改善1-2%（大幅余裕）
品質・安定性最も安定良好やや不安定な場面あり

注目すべきポイント

nvfp4の生成速度はBF16の約1.7-2倍。 31-33 tok/sという速度は対話において「待たされない」体感を生む。VRAM消費も約22GBと、96GB GPUなら他のモデルとの同時運用も容易。

FP8のPrefillが突出して速い。 1000 tok/s超のPrefillは、長いSystem PromptやRAGコンテキストを送る場合にTTFTの大幅短縮に繋がる。生成速度自体はBF16とほぼ同等。

BF16は重いが品質が最も安定。 VRAMを90%以上使うためコンテキスト長に制約があるが、長文の一貫性や厳密なコード修正での信頼性が最も高かった。

考察

速さが生む「賢い」という錯覚

nvfp4の軽快な応答は、体感として「モデルが賢くなった」ように感じさせる。しかし実際には、量子化による品質低下は長文の一貫性や複雑な推論で顕在化する。「速い=賢い」という錯覚は、主観評価だけに頼ると見逃しやすい。

評価は「1回でテストが通る率」のような客観指標で行うべき。体感の軽さと実際の品質は別の軸で評価する必要がある。

用途で切り替える設計思想

検証の結果、以下の使い分けが最も合理的だった。

探索的開発（nvfp4が有利）:

  • 「まずは動かしてみる」フェーズ
  • コード断片の高速な試行錯誤
  • MCP + context7を前提とした対話
  • 短い待機時間が開発リズムを維持する

破壊的変更（BF16/FP8が有利）:

  • リポジトリ全体の整合性を保つリファクタリング
  • 重要ロジックの修正
  • 1回でテストを通す確率が効率を左右する場面
  • 最終レビュー段階

ツール利用能力の評価

Hermes-4.3-36Bは全体的な推論の深さで限界を感じる場面はあったが、ツール利用（MCP連携、Function Calling）は比較的安定していた。引数の指定や後続ステップへの接続に大きな破綻が少なく、外部ツール（静的解析等）と組み合わせる運用では実用的。

aider等のコンテキスト大量送信環境

aiderのように毎回6000トークン程度の履歴を送信する運用では、モデルの量子化精度よりコンテキスト設計（context7/MCP）が支配的になる。この場合、nvfp4のVRAM節約とコンテキスト余裕が直接的なメリットになる。

感想

「nvfp4は速いが雑」「BF16は遅いが堅い」という単純な二項対立ではなく、開発フェーズごとに切り替えるのが現実解だった。nvfp4をデフォルトにして、最終修正だけBF16に切り替える運用が、結果的に最もストレスが少なかった。

FP8は「BF16の重さは嫌だが4bitは不安」という中間需要にピタリとはまる。Prefillの速さ（1000 tok/s超）は、RAGやMCP連携で長いコンテキストを送る場面で特に効果的。

再現方法

1. モデル取得 

  # BF16/FP8用
huggingface-cli download NousResearch/Hermes-4.3-36B

# nvfp4用
huggingface-cli download NousResearch/Hermes-4.3-36B-nvfp4

2. vLLMサーバー起動

上記の「実施内容」セクションのコマンドを参照。--max-num-seqs 1は対話専用の設定。バッチ処理なら適宜増やす。

3. 計測

vLLMのログからAvg generation throughputとAvg prompt throughputを抽出。複数回のリクエストで安定値を確認する。

補足ノウハウ

vLLMでのFP8量子化

vLLMの--quantization fp8は実行時にBF16モデルをFP8に変換する。事前に量子化済みモデルを用意する必要はない。ただしBlackwell世代のGPU（compute capability 12.0）が必要。

nvfp4のVRAM見積もり

36BモデルのnvFP4量子化で約22GB。これは24GB GPUでも動作可能だが、KVキャッシュの余裕を考えると32GB以上が推奨。96GB環境なら、nvfp4モデルを2-3個同時にロードすることも可能。

量子化選択のフローチャート

  1. VRAMが足りない → nvfp4一択
  2. VRAMに余裕あり + 対話メイン → nvfp4（速度重視）
  3. VRAMに余裕あり + コード修正 → FP8（バランス）
  4. 最終レビュー・厳密性重視 → BF16（品質優先）