Local LLM controllerは未知の研究計算タスクを前進させられるか：LLZOとQuantum ESPRESSOで実践

この記事は、Local LLM controllerによる研究計算環境立ち上げの実践記録です。最終到達点はbounded sanity runであり、本番SCF、relax、NEB、AIMD/MD、Liイオン伝導度算出は行っていません。

はじめに

Local LLMは、研究計算の相談相手として有用です。たとえば「LLZOのLiイオン伝導度をQuantum ESPRESSOで調べたい」と聞けば、NEB、AIMD、擬ポテンシャル、構造データといった一般的な手順は提案できます。

ただし、実際に研究計算を立ち上げる段階では、一般論だけでは足りません。実務では、実行環境の不足、パッケージ版アプリケーションのruntime問題、擬ポテンシャルの選定、構造データの妥当性、GPU計算後のcleanupまで確認する必要があります。

今回は、LLZO（Li7La3Zr2O12）のLiイオン拡散評価に向けたQuantum ESPRESSOワークフローを題材に、Local LLM controllerがWeb検索とCLI確認を使いながら、どこまで実行可能な状態へ前進できるかを検証しました。

最初に明確にしておきます。今回の到達点はbounded sanity runです。本番SCFではありません。relax、NEB、AIMD/MD、Liイオン伝導度算出は未実行です。

実験構成

Local LLMにはNemotron3 120B FP8を使いました。LLM単体に自由な操作権限を渡すのではなく、外側にsafety controllerを置き、許可されたWeb検索・URL取得・CLI確認だけを実行する構成にしました。

構成は次の通りです。

• Local LLM: Nemotron3 120B FP8
• Web検索: 自社内の検索エンドポイント
• CLI操作: allowlist付き
• safety controller: 危険操作や未承認操作を制限
• 実行環境: RTX PRO 6000 Blackwell 2GPU評価機
• human approval gate: install、build、長めのrun、手動メンテナンス対応などで使用

これは完全自律エージェントではありません。LLMは次の調査や確認を提案しますが、実行可否はsafety controllerと人間の承認で制御します。

Local LLM controllerが最初に発見したこと

最初のCLI確認では、Quantum ESPRESSOの基本環境がありませんでした。

• pw.x: 未検出
• neb.x: 未検出
• mpirun: 未検出
• LLZO用のLi/La/Zr/O擬ポテンシャルセット: 未整備

Local LLM controllerは、OS package、source build、container、既存module探索を比較しました。最初は、最短で実行環境を用意するため、承認後にOS package版Quantum ESPRESSOを試しました。

Quantum ESPRESSO環境の立ち上げ

OS packageとしてquantum-espresso 6.7-2build4を導入すると、pw.x、neb.x、mpirunは使える状態になりました。

しかし、runtime sanity checkで問題が出ました。tiny Si入力、tiny Al入力、LLZO入力のいずれでも、QE banner前にbuffer overflow / SIGABRTが発生しました。tiny入力でも再現したため、LLZO構造サイズやUPFだけが原因とは考えにくく、apt版QE 6.7は本命環境から外しました。

ここで重要なのは、Local LLM controllerが「コマンドが入ったから成功」と判断しなかったことです。実際のtiny入力でruntimeを検証し、使えない実行環境を切り分けました。

擬ポテンシャルと構造データ

LLZOにはLi、La、Zr、Oの擬ポテンシャルが必要です。候補としてSSSP、PseudoDojo、PSLibrary、既存サンプルUPFなどを比較し、最初の候補としてSSSPを選びました。

選定したUPF setは次の4元素です。

ただし、このUPF setは本番用に検証済みではありません。Li/ZrのUPFヘッダではsuggested cutoffが0.0であり、本番推奨値として扱えません。cutoff、functional consistency、UPF選定は人間レビューと収束テストが必要です。

構造データでは、最初にCOD 7206766を確認しました。cubic garnet LLZO候補として有用でしたが、Li partial occupancyとAl siteが含まれていたため、そのままordered QE入力には使わない判断にしました。

その後、MP-942733をordered undoped LLZO候補として扱いました。確認できた内容は次の通りです。

• formula: Li28 La12 Zr8 O48
• reduced formula: Li7La3Zr2O12
• total sites: 96
• elements: Li, La, Zr, Oのみ
• partial occupancy: 検出なし

この構造を使ってSCF sanity inputを作成し、静的チェックではpass_with_warningsとなりました。警告理由は、cutoffとk点がsanity用の仮設定であり、本番入力ではないためです。

QE 7.5 GPU buildへ切り替え

apt版QEを深追いせず、隔離したQE 7.5 GPU build環境へ切り替えました。

• NVIDIA HPC SDK 26.3
• Quantum ESPRESSO 7.5
• 評価機上の専用ディレクトリに隔離
• system prefixにはインストールしない

build/installは成功しました。ただし、directにpw.xやneb.xを起動すると無出力timeoutしました。一方、mpirun -np 1経由では正常にQE bannerが出て、入力処理へ進みました。

tiny Siでは次を確認できました。

• exit code: 0
• elapsed: 4s
• GPU acceleration: yes
• SCF loop: yes
• JOB DONE: yes
• cleanup: clean

このため、QE 7.5 GPU buildではmpirun -np 1をsanity runの前提にしました。

MP-942733 bounded sanity run

最初のMP-942733 sanity runは60秒timeout付きで行いました。このrunはSCF loopまで進みましたが、timeout後にGPUが高負荷状態に残る現象がありました。

そのため、以後のrunbookには、timeout後のnvidia-smi確認、残存プロセス確認、journal確認、必要時の手動メンテナンス対応を含めました。研究計算では、計算が始まるかだけでなく、異常終了後にGPUが安全に戻るかも重要です。

runbook更新後は、まずtiny Siを再実行してcleanupが正常であることを確認し、その後MP-942733を300秒timeout付きで1回だけ実行しました。

結果は次の通りです。

繰り返しますが、これはbounded sanity runです。本番SCFではありません。

Safety controllerとcleanup runbookの重要性

今回の実験で一番重要だったのは、LLMがそれらしい計画を出したことではありません。実環境で失敗し、その失敗を切り分け、runbookに反映しながら前進できたことです。

必要だった安全設計は次の通りです。

• CLI allowlist
• timeout付き実行
• mpirun -np 1固定
• GPU cleanup確認
• Xid/NVRM確認
• human approval gate
• reset/reboot/killの自動実行禁止
• 本番計算とsanity runの明確な区別

LLM controllerは、未知タスクを進めるうえで強力な補助になります。しかし、実行権限を無制限に渡すべきではありません。安全controllerとrunbookが必要です。

今回の到達点と未実施事項

今回到達したのは、QE 7.5 GPU buildでMP-942733由来のordered LLZO sanity inputが読め、Li/La/Zr/O UPFが読め、SCF loopへ入り、bounded sanity runとしてJOB DONEまで到達した、という点です。

未実施のこと:

• 本番SCF
• cutoff/k点収束
• relax
• NEB
• AIMD/MD
• MSD解析
• Nernst-Einstein式による伝導度算出

今回のecutwfc=60, ecutrho=480, K_POINTS 1x1x1はsanity用の仮値です。UPF、cutoff、k点、構造、収束条件は人間レビューと収束テストが必要です。

まとめ

Local LLM controllerは、未知の研究計算タスクを完全自動で解決したわけではありません。

しかし、QE環境不足を発見し、apt版QEのruntime問題を確認し、擬ポテンシャルと構造データを整理し、QE 7.5 GPU buildへ切り替え、bounded sanity runを成功させるところまで現実的に前進できました。

実務価値は「全部自動化」ではなく、「安全に問題を切り分けて、次の妥当な一手へ進める」点にあります。