ローカル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 ESPRESSOとLAMMPSの最小ケースについて、次の流れを確認しました。
- LLMがHPC入力ファイルを生成する。
- 静的チェックで空出力、説明文混入、危険な外部依存を止める。
- 実際のHPCソフトウェアで入力を実行する。
- 意図的に入力を壊して失敗ログを取る。
- 失敗ログをLLMに読ませて修正版を生成する。
- 修正版を再実行し、成功するか確認する。
Quantum ESPRESSOでは、Si SCF入力がSCF convergenceとJOB DONEまで到達しました。LAMMPSでは、Lennard-Jones melt入力がrun 20、thermo出力、Loop timeまで到達しました。さらに、どちらも意図的な失敗を作り、ログからLLMが修正版を生成し、再実行で成功しました。
重要なのは、LLMの出力をそのまま信用しないことです。今回の成功は、人間承認、静的チェック、外部fetch抑止、実行ゲート、証跡保存を組み合わせた結果です。
なぜローカルでやるのか¶
HPC研究支援でLLMを使うと、入力ファイル、実行ログ、研究メモ、未公開コードを扱うことになります。クラウドAPIへ送れない情報を扱う環境では、オンプレGPUサーバー上で完結するLLM支援に意味があります。
今回の関心は、チャット応答が自然かどうかではありません。HPCソフトウェアが実際に受理し、最小計算が完走する入力を作れるか。そして、失敗ログから修正できるかです。
検証環境¶
| 項目 | 内容 | 備考 |
|---|---|---|
| GPU | NVIDIA A100 80GB PCIe x4 | ホスト側NVIDIA driverへ復旧後に検証 |
| LLM | NVIDIA-Nemotron-3-Nano-30B-A3B-BF16 |
Nemotron OmniではなくNemotron-3 Nano 30B BF16 |
| Serving | vLLM 0.12.0 | OpenAI互換APIとしてローカル配信 |
| vLLM設定 | TP=4, max_model_len=8192, max_num_seqs=2, gpu_memory_utilization=0.82 |
TP=1/2/4 smoke後の標準設定 |
| Python/Torch | torch 2.9.0+cu128 | 専用venv |
| Quantum ESPRESSO | PWSCF v7.5 | 既存userland binary |
| LAMMPS | LAMMPS 22 Jul 2025 Update 4 | serial-stubs runtime、no mpirun |
| Vibe | Mistral Vibe | sandboxでread/review/controlled editのみ確認 |
詳細な証跡は社内proofpackに保管しています。この記事では、raw logやsession logを直接公開せず、検証手順と結果の要点だけを示します。
今回証明していないこと¶
今回の結果から、次のことはまだ言えません。
- HPCワークフロー全般をLLMだけで自動化できる。
- LAMMPS GPU/KOKKOS実行が検証済みである。
- Allegro/NeQUIPのtraining、inference、LAMMPS連携が検証済みである。
- GPU Start Console本体へ安全に適用できる。
- H200 NVLやRTX PRO 6000 Blackwellでも同じ結果になる。
今回確認したのは、限定された最小ケースで、ローカルLLMが入力生成とログベース修正を支援できることです。
Quantum ESPRESSO: 生成、実行、修正¶
最初の失敗: content=None¶
最初にNemotronへQuantum ESPRESSOの最小Si SCF入力を生成させたところ、reasoning側で出力予算を使い切り、finish_reason='length'かつcontent=Noneになりました。つまり、実行できる入力ファイルは得られませんでした。
この段階で静的チェックが効きました。&CONTROL、&SYSTEM、ATOMIC_SPECIES、ATOMIC_POSITIONS、K_POINTS automatic、Si.pz-vbc.UPFなどがない入力は実行しない、というゲートで空入力を止めました。
プロンプトを短くし、テンプレートに近い形へ寄せたところ、QE入力を取得できました。
生成入力の実行¶
生成入力をQuantum ESPRESSO / PWSCF v7.5で実行した結果、SCF convergenceとJOB DONEを確認しました。
| 項目 | 結果 |
|---|---|
| exit code | 0 |
| SCF convergence | あり |
JOB DONE |
あり |
| GPU acceleration ACTIVE | あり |
| 4 visible GPUs per MPI rank | あり |
| total energy | -15.83715888 Ry |
| pseudo download | なし |
mpirun |
なし |
GPU acceleration ACTIVEは実行時の確認信号であり、ここでは性能比較やベンチマークの主張には使っていません。
失敗ログからの修正¶
次に、成功入力の擬ポテンシャル名を意図的に壊しました。
Si.pz-vbc.UPF -> Si.WRONG.UPF
QEは期待通り、file ./pseudos/Si.WRONG.UPF not foundで失敗しました。
この壊れた入力とstdout/stderrをNemotronへ渡すと、NemotronはSi.pz-vbc.UPFへ戻した修正版入力を生成しました。修正版は静的チェックを通過し、再実行でもSCF convergenceとJOB DONEまで到達しました。
QEでは、入力生成とエラー修正ループの両方が成功しました。
LAMMPS: 生成、実行、修正¶
LAMMPSでは、まず手書きの最小LJ melt canaryでserial-stubs LAMMPSが動くことを確認しました。その後、Nemotronに同じ条件の入力を生成させました。
静的チェックでは、units lj、atom_style atomic、pair_style lj/cut 2.5、pair_coeff、run 20があること、read_data、package gpu、KOKKOS、include、shell、外部ファイル依存がないことを確認しました。
生成入力の実行¶
生成入力をserial-stubs LAMMPSでsingle-process実行しました。
| 項目 | 結果 |
|---|---|
| LAMMPS version | 22 Jul 2025 Update 4 |
| exit code | 0 |
run 20 |
あり |
Loop time |
あり |
| thermo output | steps 0, 10, 20 |
log.lammps |
あり |
| ERROR | なし |
mpirun |
なし |
| GPU/KOKKOS | 未使用 |
ここで使ったLAMMPSはserial-stubs runtimeです。GPU/KOKKOS性能やLAMMPS+Allegro連携を検証したものではありません。
失敗ログからの修正¶
成功入力からpair_coeff行を削除しました。
pair_coeff 1 1 1.0 1.0 2.5
LAMMPSは期待通り、次のエラーで停止しました。
ERROR: All pair coeffs are not set. Status:
Pair style not yet initialized
壊れた入力とログをNemotronへ渡すと、pair_coeff 1 1 1.0 1.0を復旧しました。元の行と完全一致はしていません。元はcutoff 2.5を明示していました。しかし、入力にはpair_style lj/cut 2.5があり、LAMMPS上ではグローバルcutoffが効きます。
実際に修正版をLAMMPSで再実行すると、exit code 0、run 20、Loop time、thermo出力まで到達しました。これは、シミュレータ実行が最終的な意味検証になった例です。
結果マトリクス¶
| Phase | 対象 | 入力種別 | LLM使用 | 実行 | 結果 | error repair loop | 主なシグナル |
|---|---|---|---|---|---|---|---|
| QE Phase 5C | Quantum ESPRESSO | Si SCF | あり | あり | 成功 | なし | exit 0, SCF convergence, JOB DONE, total energy -15.83715888 Ry |
| QE Phase 5D | Quantum ESPRESSO | pseudo名を意図的に破壊 | なし | あり | 期待通り失敗 | 入口 | file ./pseudos/Si.WRONG.UPF not found |
| QE Phase 5E | Quantum ESPRESSO | 修正版生成 | あり | なし | 静的チェックPASS | 生成 | Si.WRONG.UPFを除去しSi.pz-vbc.UPFへ復旧 |
| QE Phase 5F | Quantum ESPRESSO | 修正版入力 | なし | あり | 成功 | 成功 | exit 0, SCF convergence, JOB DONE |
| LAMMPS Phase 6B | LAMMPS | LJ melt | あり | あり | 成功 | なし | exit 0, run 20, thermo output, Loop time |
| LAMMPS Phase 6C | LAMMPS | pair_coeff削除 |
なし | あり | 期待通り失敗 | 入口 | All pair coeffs are not set |
| LAMMPS Phase 6D | LAMMPS | 修正版生成 | あり | なし | 静的チェックPASS | 生成 | pair_coeffを復旧 |
| LAMMPS Phase 6E | LAMMPS | 修正版入力 | なし | あり | 成功 | 成功 | exit 0, run 20, Loop time, ERRORなし |
失敗と対策¶
| 失敗 | 起きたこと | 対策 |
|---|---|---|
content=None |
reasoningに出力予算を使い切り、QE入力が空になった | 静的チェックで止める。プロンプトを短くし、テンプレート化する |
K_POINTS automatic削除 |
Vibeのsearch_replace承認時に構造行が消えた |
diffの削除行を必ず確認する |
| QE pseudo名エラー | 存在しないUPF名でQEが停止 | ログをLLMへ渡し、正しいUPF名へ修正 |
LAMMPS pair_coeff欠落 |
ペア係数未設定でLAMMPSが停止 | ログをLLMへ渡し、必要な係数行を復旧 |
| byte一致しない修復 | LAMMPSの修復行が元入力と完全一致しなかった | シミュレータ実行で意味的に有効か確認する |
Vibeで見えた承認ゲートの課題¶
Mistral Vibeもlocal Nemotron endpointへ接続し、sandbox repositoryで読み取り、レビュー、小さなcontrolled editを確認しました。
ただし、search_replaceを承認した際、意図せずK_POINTS automatic行が削除されました。後で補正しましたが、HPC入力では1行の削除で意味が壊れます。
この経験から、承認画面では追加行だけでなく削除行を見る必要がある、というルールを明文化しました。
安全ゲート¶
今回の検証では、次のゲートを入れました。
| ゲート | 目的 |
|---|---|
| 静的チェック | 必須セクション、外部依存、Markdown混入、空出力を検出 |
| 人間承認 | Vibeのtool実行やcontrolled editを止める |
| 外部fetch抑止 | pseudo downloadや追加モデル取得を防ぐ |
| no mpirun | 最小single-process検証に限定する |
| 実行検証 | LLM修正が意味的に正しいかをソフトウェア側で確認 |
| 証跡保存 | prompt、raw response、input、stdout/stderr、diffを追跡可能にする |
ライセンスと再配布について¶
NemotronはNVIDIAのモデルカードとライセンス条件を確認して利用しています。Quantum ESPRESSO、LAMMPS、UPF/pseudopotentialは、それぞれの配布条件に従って扱う必要があります。
本記事では検証手順と結果を説明し、モデル、ソフトウェア、pseudopotential、raw proofpackの再配布は行いません。
まとめ¶
今回の最小検証では、ローカルLLMがHPC入力ファイルの生成とエラー修正に使える可能性を確認できました。特に、Quantum ESPRESSOとLAMMPSの両方で、生成、実行、意図的失敗、ログベース修正、再実行成功まで到達できたのは重要な成果です。
ただし、安全な使い方の中心はLLMそのものではなく、ゲート設計にあります。
- 出力を静的チェックする。
- 実行フェーズを分ける。
- 失敗ログを保存する。
- 修正版も再チェックする。
- 最終判断はシミュレータ実行結果に委ねる。
この前提なら、ローカルLLMはHPC研究支援の現実的な構成要素になり得ます。
次の展開¶
次は次の順序が現実的です。
- Allegro/NeQUIPのmetadata-only preflightへ進む。
- GPU/KOKKOS LAMMPSやLAMMPS+Allegro連携を別フェーズで検証する。
- H200 NVLやRTX PRO 6000 Blackwellとの比較は、別ハードウェア検証として扱う。