RTX PRO 6000 Blackwell 2枚で科学計算LLMを検証:72B BF16、120B FP8、235B NVFP4を比較

RTX PRO 6000 Blackwell 2GPU評価機で、Qwen2.5-72B BF16/FP8/NVFP4、Nemotron3 120B FP8、Qwen3 235B NVFP4をQE/LAMMPS入力生成タスクで比較しました。

Share

ローカルLLMを科学計算の実務に使う場合、単にtokens/secが速いだけでは足りない。Quantum ESPRESSOやLAMMPSの入力ファイルを生成したときに、必要なセクションが揃っているか、エラー修正の指示に沿っているか、テンプレートとして破綻していないかが重要になる。

今回はRTX PRO 6000 Blackwell 2GPU評価機で、ローカルLLMがQuantum ESPRESSO / LAMMPS入力生成・修正支援にどこまで使えそうかを短時間で比較した。比較対象は、72B級BF16、同一モデルのFP8/NVFP4、120B FP8、235B NVFP4、そしてコード生成寄りのQwen3-Coder-Nextである。

今回のタスクセットでは、Nemotron3 120B FP8が速度・品質・安定性のバランスで最も良かった。同一モデルQwen2.5-72Bの比較では、FP8がBF16と同じ静的checker結果を保ったまま約1.76倍高速化した。一方、NVFP4も実行可能で高速化は見られたが、failが増えたため、用途別の検証が必要だ。

検証環境

  • GPU: RTX PRO 6000 Blackwell 2GPU評価機
  • 推論エンジン: vLLM
  • tensor parallel size: 2
  • 評価タスク: QE/LAMMPS入力生成・エラー修正、全14タスク
  • 生成設定: temperature 0.1、max_tokens 1024
  • 評価方法: raw出力を保存し、Markdown fenceなどを正規化したうえで静的checker v2を実行

Blackwell SM120環境では、FP8/FP4系カーネルでFlashInfer JITが走る場面があり、nvcc/CUDA_HOMEを明示する必要があった。FP8やNVFP4を実運用に持ち込む場合、モデルだけでなく、vLLM、FlashInfer、CUDA toolkit、GPUアーキテクチャの組み合わせも確認した方がよい。

検証タスク

タスクは大きく3種類に分けた。

  • Quantum ESPRESSO入力生成: Si diamondのscf.in、Al fccのrelax.in、ZrSe3やLLZOテンプレートなど
  • LAMMPS入力生成: LJ流体、Al EAM minimize、read_dataテンプレート、DeepMD、Allegro/NequIP系テンプレートなど
  • エラー修正: QEの壊れた&SYSTEM修正、擬ポテンシャル名不整合修正、LAMMPS units / pair_style不整合修正、LAMMPSログエラー修正

評価は静的checkerで行った。これはpw.xlmpで実際に実行した検証ではない。今回の結果は、あくまで静的checkerで見た構造的な妥当性と、短時間serving時の速度・メモリ・温度・消費電力の実測である。

実際のプロンプトと出力例

今回の比較では、モデル間の条件をそろえるため、プロンプトは英語で統一しました。これは「英語でないと使えない」という意味ではありません。実運用では日本語で依頼しても利用できます。ただし、Quantum ESPRESSOやLAMMPSの入力ファイル、エラーメッセージ、キーワードは英語表記が多いため、日本語で依頼する場合でも、scf.inK_POINTSpair_styleread_data などの技術キーワードは英語のまま含めると安定しやすくなります。

日本語での依頼例:

Quantum ESPRESSOでSi diamond構造のscf.inを作成してください。
&CONTROL, &SYSTEM, &ELECTRONS, ATOMIC_SPECIES, ATOMIC_POSITIONS, K_POINTSを含めてください。
擬ポテンシャル名は例として Si.pbe-n-kjpaw_psl.1.0.0.UPF を使ってください。
K_POINTS automaticを使い、Markdownのコードフェンスなしで入力ファイル本文だけを返してください。

タスク別の詳細ステータス表は長いため本文には展開せず、ここでは代表的なpass例とfail例だけを掲載する。各結果は静的checkerによる判定であり、pw.xlmpでの実行成功を意味するものではない。

以下は、実際に使ったベンチマークプロンプトと、公開用に抜粋した出力例である。いずれも静的checkerでの評価であり、pw.xlmpで実行確認した結果ではない。

QE Si diamond scf.in生成のpass例

task_id: qe_si_diamond_scf 代表モデル: Nemotron3 120B FP8 判定: pass

プロンプト:

Create a Quantum ESPRESSO pw.x scf.in for silicon in the diamond structure. Use a conventional safe template with ibrav=2 or explicit CELL_PARAMETERS, two Si atoms if appropriate, reasonable ecutwfc/ecutrho placeholders, ATOMIC_SPECIES with a clearly named Si pseudopotential, ATOMIC_POSITIONS, K_POINTS automatic, and no Markdown fences.

出力抜粋:

&CONTROL
    calculation='scf',
    prefix='silicon',
    pseudo_dir='./pseudo',
    outdir='./tmp',
/
&SYSTEM
    ibrav=2,
    celldm(1)=10.26,
    nat=2,
    ntyp=1,
    ecutwfc=30.0,
    ecutrho=120.0,
/
&ELECTRONS
    conv_thr=1.0e-8,
    mixing_beta=0.7,
/
ATOMIC_SPECIES
 Si 28.0855 Si.pbe-n-rrkjus_psl.1.0.0.UPF
ATOMIC_POSITIONS crystal
 Si 0.000000 0.000000 0.000000
 Si 0.250000 0.250000 0.250000
K_POINTS automatic
 4 4 4 0 0 0

LAMMPS DeePMDテンプレートのpass例

task_id: lammps_deepmd_template 代表モデル: Qwen3-Coder-Next 判定: pass

プロンプト:

Create a LAMMPS input template for running a structure with DeePMD-kit pair_style deepmd using a graph.pb model. Include units metal, atom_style atomic, read_data, pair_style deepmd graph.pb, pair_coeff, neighbor settings, thermo, timestep, and a short run or minimize option. Return only the input script.

出力抜粋:

units metal
atom_style atomic

read_data datafile.data

pair_style deepmd graph.pb
pair_coeff * *

neighbor 2.0 bin
neigh_modify every 10 delay 0 check yes

thermo 100
timestep 0.001

minimize 1.0e-6 1.0e-8 1000 10000
# or for dynamics:
# run 10000

LAMMPS EAM修正のfail例

task_id: fix_lammps_units_pair_inconsistent 代表モデル: Qwen2.5-72B NVFP4 判定: fail

プロンプト:

Fix this inconsistent LAMMPS input and return only a corrected script:
units real
atom_style charge
lattice fcc 4.05
region box block 0 4 0 4 0 4
create_box 1 box
create_atoms 1 box
pair_style eam/alloy
pair_coeff * * Al99.eam.alloy Al
run 1000

出力抜粋:

units real
atom_style charge
lattice fcc 4.05
region box block 0 4 0 4 0 4
create_box 1 box
create_atoms 1 box
pair_style eam/alloy
pair_coeff * * Al99.eam.alloy Al
mass 1 26.981539
run 1000

なぜfailか: EAM/alloyのAl入力として修正すべきunits metalatom_style atomicに変更されず、元のunits realatom_style chargeが残ったため。

結果1: 実用上限モデル比較

[Figure: tokens/sec comparison]

[Figure: pass/warn/fail comparison]

ModelPrecision/dtypetaskspasswarnfailavg latencyavg tok/s
Qwen2.5-72B-InstructBF1614130111.428s19.021
Qwen3-Coder-Nextcached dtype1412021.373s149.922
Nemotron3 120B A12BFP81413105.951s113.795
Qwen3 235B A22BNVFP41412023.309s62.328
Modelmax GPU memmax tempmax power
Qwen2.5-72B-Instruct BF1683114 MiB62C406.97W
Qwen3-Coder-Next83728 MiB50C223.68W
Nemotron3 120B A12B FP883976 MiB56C315.98W
Qwen3 235B A22B NVFP483106 MiB54C285.96W

この表で目立つのはNemotron3 120B FP8である。全14タスクで13 pass / 1 warn_incomplete / 0 fail、平均113.795 tok/sとなり、今回のタスクセットでは品質と速度のバランスが最も良かった。

Qwen3-Coder-Nextは149.922 tok/sで最速だった。静的checkerでは12 pass / 2 failだが、QE/LAMMPS入力生成のようなコード・設定ファイル寄り用途では非常に有力な候補になる。

Qwen3 235B NVFP4は、2GPUでロード、serving、全14タスク評価まで到達したこと自体が重要な結果である。ただしQwen3系ではreasoning出力が長くなり、必要な入力ファイル本体に到達しないことがあったため、enable_thinking=falseが重要だった。

結果2: 同一モデル Qwen2.5-72B のBF16/FP8/NVFP4比較

[Figure: same-model precision comparison]

Precisiontaskspasswarnfailavg latencyavg tok/srelative tok/s
BF1614130111.428s19.0211.00x
FP81413017.207s33.5621.76x
NVFP41412025.427s37.1031.95x
Precisionmax GPU memmax tempmax power
BF1683114 MiB62C406.97W
FP882326 MiB58C331.12W
NVFP485848 MiB48C368.60W

FP8はBF16と同じ13 pass / 1 failを維持しながら、19.021 tok/sから33.562 tok/sへ伸びた。これは約1.76倍の高速化で、今回の同一モデル比較では最も分かりやすい改善だった。

NVFP4は37.103 tok/sでさらに速かった。ただし静的checkerでは12 pass / 2 failとなり、BF16/FP8よりfailが1件増えた。この結果からは、NVFP4は有望だが、FP4だから常にFP8より良いとは言えない。用途ごとに生成物の品質を確認する必要がある。

実運用上の注意

Blackwell SM120でFP8/FP4を動かす場合、FlashInfer JITがnvccを必要とすることがある。今回もCUDA_HOMEを明示することで起動できたモデルがあった。再現性を重視するなら、CUDA_HOME、nvcc、vLLM、FlashInferの組み合わせを記録しておくべきだ。

Qwen3系ではthinking/reasoning出力の制御も重要である。今回のQwen3 235B NVFP4では、enable_thinking=falseを使うことで、<think>出力にmax_tokensを消費せず、入力ファイル本体に到達できた。

また、今回のGPUメモリ値はvLLM serving時の観測値であり、モデル重みだけのサイズではない。KV cache、vLLMのメモリ予約、プロファイリングの影響も含まれる。

まとめ

今回の短時間評価では、RTX PRO 6000 Blackwell 2GPU評価機で、72B BF16、同一モデルFP8/NVFP4、120B FP8、235B NVFP4を実際にservingし、QE/LAMMPS入力生成タスクを回せた。

今回のタスクセットで最もバランスが良かったのはNemotron3 120B FP8。最速はQwen3-Coder-Next。同一モデル比較では、Qwen2.5-72B FP8がBF16と同じ静的品質を保ったまま約1.76倍高速化した。

235B NVFP4も2GPUで全14タスク評価まで到達した。ただしthinking制御や静的品質の確認が必要であり、FP4を万能解として扱うべきではない。

次にやるべきことは、静的checkerを越えて、実際のpw.xlmpで短時間のパース・最小実行確認を行うことだ。

Read more

ローカルLLMはAllegro/NeQUIPの学習設定YAMLを作れるのか:Nemotronでmetadata-only preflightを検証

ローカルLLMはAllegro/NeQUIPの学習設定YAMLを作れるのか:Nemotronでmetadata-only preflightを検証 これは性能ベンチマークではありません。A100x4上のローカルLLMで、Allegro / NeQUIPの学習設定YAMLをどこまで安全に作り、実行前に確認できるかを調べた機能検証です。 結論から言うと、NemotronはAllegro / NeQUIPのtraining YAML候補を生成できました。既存SIF内で torch / nequip / allegro のimport、A100x4のCUDA可視

By Kenetsu Hanabusa

ローカルLLMはHPC入力ファイルを作り、エラーを直せるのか:NemotronでQuantum ESPRESSOとLAMMPSを検証

ローカルLLMはHPC入力ファイルを作り、エラーを直せるのか:NemotronでQuantum ESPRESSOとLAMMPSを検証 この記事の位置づけ これは性能ベンチマークではなく、 ローカルLLMがHPC入力ファイルの生成、実行ログを使った修正、再実行まで支援できるか を確認した機能検証です。 H200 NVLやRTX PRO 6000 Blackwellへの一般化はせず、次回以降の別フェーズとして扱います。 結論 A100 80GB x4上で NVIDIA-Nemotron-3-Nano-30B-A3B-BF16 をローカル配信し、Quantum

By Kenetsu Hanabusa