Hermes-4.3-36BのBF16・FP8・nvfp4比較

比較した3形式

Hermes-4.3-36B の BF16、FP8、nvfp4 を、vLLM 0.14.0rc1 と RTX PRO 6000 Blackwell Max-Q 96GB で比較しました。生成速度に加え、最初の応答、context の容量、コード生成の出力を確認しています。

対話と探索を日常で使う構成と、最終修正やレビューの構成を選ぶための検証です。

用途と比較項目

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

対話、コード生成 / MCP、将来的な context7 併用を想定しました。比較項目は次の4点です。

1. 生成速度（Avg generation throughput）
2. 初動体感（TTFT = prefill影響）
3. コンテキスト余裕（KV cache）
4. 出力の賢さ・安定性（体感 + 想定用途適合）

BF16 は動きますが、VRAM 使用率が90%を超えやすく、context の余裕が減ります。nvfp4 は約22GBでした。速度と出力品質を別々に確認します。

検証対象・前提

今回はモデルが GPU に収まるため、応答時間と品質を中心に見ました。

検証した量子化パターン一覧

数値と、実行時に感じた違いを示します。品質に関する評価は、このタスクでの主観評価です。

① BF16（非量子化）

BF16 を品質比較の基準にしました。

設定例

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

観測結果

• 生成速度: 17〜19 tok/s
• Prompt throughput: 300〜500 tok/s 前後
• VRAM使用率: 非常に高い（90%超えやすい）
• KV cache usage: 6〜8%（短文時）
• 安定性: 非常に高い

評価

• 今回の主観評価では、品質と一貫性の比較基準です
• TTFTが長く、対話では待ち時間を感じました

向いている用途

• 重要なコードの修正と最終レビュー
• 長文仕様や厳密な手順
• 品質と性能の比較基準

対話で往復する際は BF16 の待ち時間が気になりました。最終修正やレビューでは、基準として残す方針です。

② FP8（vLLM / –quantization fp8）

FP8 は TTFT が改善するかを確認しました。

設定例

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

観測結果

• 生成速度: 18〜20 tok/s
• Prompt throughput: 1000 tok/s 超（prefillが明確に速い）
• VRAM使用率: BF16より軽減
• Prefix cache hit率: 条件次第で有効

評価

• BF16比で TTFTが改善
• 生成速度は大差なしだが体感は軽い
• 品質劣化は体感レベルでは軽微

向いている用途

• BF16の待ち時間を減らしたい対話
• 4bitの品質低下を避けたいコード生成
• 日常の対話用候補

decode の差は小さくても、prefill が速くなり、対話や軽いコード生成の待ち時間が減りました。

③ nvfp4（4bit, 約22GB）

nvfp4 は生成速度とメモリ使用量の違いが大きい構成でした。

設定例

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

観測結果

• 生成速度: 31〜33 tok/s（安定）
• Prompt throughput: 280〜500 tok/s
• VRAM使用量: 約22GB
• KV cache usage: 1〜2%（非常に余裕あり）

評価

• 生成速度は約1.7〜2倍
• 対話の待ち時間が減りました
• CTXに使える容量が増えました
• 今回の主観評価では、対話に使える出力でした

注意点

• 応答の速さと品質を分けて評価します
• 長文の一貫性と厳密性はBF16より下がる可能性があります
• コード修正はテストで確認します

向いている用途

• MCP + context7を使う日常の対話
• 長い入力を使う設計相談と探索

nvfp4 は約22GB、KV cache usage は1〜2%でした。96GBなら2〜3モデルを同時に載せる容量がありますが、同時実行性能は別に確認が必要です。

速度の印象だけでは、コード修正や長文の品質は判断できません。

横断比較まとめ

対話と context の余裕を優先する場合は nvfp4、比較の基準には BF16、prefill の速度も重視する場合は FP8 を候補にしました。

考察

速度と品質を分けた評価

速い応答は品質も高く感じさせる場合があります。長文の一貫性や複雑な推論は、別に評価する必要があります。

今後は「1回でテストが通る率」などで、速度と品質を分けて比較する予定です。

開発工程による切り替え

この検証では、次の使い分けを考えています。

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

• コード断片を生成して試す作業
• MCP + context7を使う対話
• 待ち時間の短さを優先する探索

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

• リポジトリ全体の整合性が必要なリファクタリング
• 重要なロジックの修正と最終レビュー
• 1回でテストを通す確率を重視する作業

ツール利用の観察

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

aiderの履歴とcontext

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

大きい履歴を送る運用では、必要な文脈を絞ることも、LLM導入や開発支援の応答時間に影響します。

運用上の結論

• 対話・探索: nvfp4。速度と CTX の余裕を優先します

• 最終修正・レビュー: BF16 または FP8 を使い、テストで結果を確認します

• 切り替え運用: nvfp4 を対話の標準、FP8/BF16 を確認用に残す案です

nvfp4 を標準にして、最終修正を BF16 に切り替える運用は、今回の作業では待ち時間を減らせました。

再現方法

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見積もり

nvFP4 の36Bモデルは約22GBです。24GBにも入る容量ですが、KV cache を考慮して32GB以上を候補にしています。96GBなら2〜3個のモデルを載せる容量があります。

用途別の選択案

1. BF16がVRAMに収まらない場合: nvfp4を候補にします
2. 対話の速度を優先する場合: nvfp4
3. コード修正でprefill速度も必要な場合: FP8
4. 最終レビューで品質比較の基準が必要な場合: BF16

今後の課題

次は対話、コード生成、最終レビューの起動設定を分け、「1回でテストが通る率」を比較する予定です。