Hermes-4.3-36Bの量子化を比べて、常用モデルをどう決めるか
Hermes-4.3-36BをBlackwell GPU上でBF16・FP8・nvfp4の3パターンで比較検証。単なる速度比較ではなく、対話の初動、コンテキスト余裕、コード生成での安全性まで含めて、常用モデルをどう選ぶかを整理した実測記録。
はじめに
Hermes-4.3-36B をローカルで常用候補にするにあたって、単純なベンチマーク値だけではなく、対話の初動、コード生成時の安心感、コンテキストの余裕まで含めて判断したくなりました。今回は vLLM 0.14.0rc1 と RTX PRO 6000 Blackwell Max-Q 96GB の環境で、BF16、FP8、nvfp4 の3パターンを見比べています。
このメモの目的は、「どれが最速か」を決めることではなく、普段の対話用と、壊したくない作業用で、どの量子化をどう切り替えるのが現実的かを整理することでした。
背景・動機
ローカルLLM環境で対話・コード生成・MCP連携を行うにあたり、モデルの量子化レベルをどう選ぶかは恒常的な課題になります。NousResearch Hermes-4.3-36B は、ツール利用（Function Calling）に強い36Bクラスのモデルで、vLLM環境での運用候補として評価しました。
用途としては、単なる雑談ではなく、対話（TTFT・体感重視）、コード生成 / MCP、そして将来的な context7 併用 を想定しています。こうなると、平均スループットだけを見ても判断を誤りやすく、少なくとも次の4点を一緒に見る必要がありました。
- 生成速度（Avg generation throughput）
- 初動体感（TTFT = prefill影響）
- コンテキスト余裕（KV cache）
- 出力の賢さ・安定性（体感 + 想定用途適合）
RTX PRO 6000 Blackwell（96GB VRAM）があれば、BF16（非量子化）でも動くのですが、VRAM使用率が90%を超えコンテキスト長に余裕がなくなります。nvfp4（4bit）なら約22GBで済む。問題は「速さと引き換えに何を失うか」でした。
検証対象・前提
| 項目 | 仕様 |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q 96GB |
| CPU | AMD EPYC 9175F |
| メモリ | DDR5-6400 768GB |
| Runtime | vLLM 0.14.0rc1 |
| Model | NousResearch / Hermes-4.3-36B |
今回の構成だと、GPUメモリには比較的余裕があります。そのため、「載るか載らないか」よりも、「どこまで軽快に回るか」「その軽快さを品質と取り違えないか」が判断ポイントになりました。
検証した量子化パターン一覧
BF16、FP8、nvfp4 の3パターンをそれぞれ見ています。数値だけなら表に落とし込めますが、実運用では体感差がかなり大きかったので、評価コメントもそのまま残します。
① 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 です。BF16 の安全側をある程度維持しつつ、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は怖い場合
- 常用の現実解候補
FP8 はデコード速度だけを見ると劇的な差はありませんが、prefill が速くなることで操作感が変わります。会話や軽いコード生成では、この「少し軽い」がそのまま常用性に直結しました。4bit に踏み切る前の中間解としてかなり扱いやすい印象です。
なお、vLLMの --quantization fp8 は実行時にBF16モデルをFP8に変換します。事前に量子化済みモデルを用意する必要はありません。ただしBlackwell世代のGPU（compute capability 12.0）が必要です。
③ 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 は、単にスループットが高いだけでなく、VRAM 使用量が約22GBに収まる点が大きいです。KV cache usage も 1〜2% とかなり余裕があり、長い文脈を抱えながら会話や探索を回す運用に向いています。96GB環境なら、nvfp4モデルを2〜3個同時にロードすることも可能です。
ただし、ここで最も警戒しているのは「速いから賢く見える」という錯覚です。対話のテンポがいいとモデル全体を高く評価しがちですが、厳密なコード修正や長文整合性では BF16 側が有利な場面を切り捨てられません。
横断比較まとめ
| 項目 | BF16 | FP8 | nvfp4 |
|---|---|---|---|
| 生成速度 (TG) | 17–19 tok/s | 18–20 tok/s | 31–33 tok/s |
| Prefill速度 (PP) | 300–500 tok/s | 1000+ tok/s | 280–500 tok/s |
| TTFT | 遅め | 改善 | 良好 |
| VRAM使用量 | 90%超 | 中 | 約22GB |
| KV cache使用率 | 6–8%（短文） | 改善 | 1–2%（大幅余裕） |
| 品質・安定性 | 最も安定 | 良好 | やや不安定な場面あり |
| 対話体感 | △ | ○ | ◎ |
表にすると結論はかなり明確で、対話の快適さとコンテキスト余裕で見るなら nvfp4 が頭一つ抜けています。一方で、品質基準の上限として BF16 を持っておく価値は依然として高いです。FP8 はその中間に位置していて、常用の安全側として扱いやすい立ち位置でした。
考察
速さが生む「賢い」という錯覚
nvfp4 の軽快な応答は、体感として「モデルが賢くなった」ように感じさせます。しかし実際には、量子化による品質低下は長文の一貫性や複雑な推論で顕在化します。「速い＝賢い」という錯覚は、主観評価だけに頼ると見逃しやすい。
評価は「1回でテストが通る率」のような客観指標で行うべきです。体感の軽さと実際の品質は別の軸で評価する必要があります。
用途で切り替える設計思想
検証の結果、以下の使い分けが最も合理的でした。
探索的開発（nvfp4が有利）:
- 「まずは動かしてみる」フェーズ
- コード断片の高速な試行錯誤
- MCP + context7 を前提とした対話
- 短い待機時間が開発リズムを維持する
破壊的変更（BF16/FP8が有利）:
- リポジトリ全体の整合性を保つリファクタリング
- 重要ロジックの修正
- 1回でテストを通す確率が効率を左右する場面
- 最終レビュー段階
ツール利用能力の評価
Hermes-4.3-36B は全体的な推論の深さで限界を感じる場面はあったものの、ツール利用（MCP連携、Function Calling）は比較的安定していました。引数の指定や後続ステップへの接続に大きな破綻が少なく、外部ツール（静的解析等）と組み合わせる運用では実用的です。
aider等のコンテキスト大量送信環境
aider のように毎回6000トークン程度の履歴を送信する運用では、モデルの量子化精度よりコンテキスト設計（context7/MCP）が支配的になります。この場合、nvfp4 のVRAM節約とコンテキスト余裕が直接的なメリットになります。
ここはかなり重要で、最終的なボトルネックが常にモデルそのものにあるとは限りません。履歴送付量が大きいワークフローでは、どの量子化を選ぶか以上に、必要な文脈だけをどう渡すかの方が支配的になります。
運用上の結論
対話用・常用 →
nvfp4が最有力。速さ・CTX余裕・体感の良さが圧倒的品質・安全重視（コード破壊防止） →
BF16またはFP8。特に最終修正・レビュー段階実務的ベスト構成
nvfp4: デフォルト対話・探索FP8/BF16: 切替用の保険モデル- 判断基準は「テストが通るか」
「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個同時にロードすることも可能です。
量子化選択のフローチャート
- VRAMが足りない → nvfp4一択
- VRAMに余裕あり + 対話メイン → nvfp4（速度重視）
- VRAMに余裕あり + コード修正 → FP8（バランス）
- 最終レビュー・厳密性重視 → BF16（品質優先）
今後の課題
次にやるべきなのは、用途別の起動テンプレを切り出すことと、品質評価を定量化することです。具体的には、対話用、コード生成用、最終レビュー用で設定を分け、各構成で「1回でテストが通る率」を比較するのが一番実用的です。
体感は大事ですが、それだけでは運用判断として弱いです。最終的には、快適さと再現性の両方が取れる構成に寄せていきます。