オンプレLLMでログ一次切り分け:Llama 3.3 70Bでやってみた(根拠引用を強制)

オンプレLLMでログ一次切り分け:Llama 3.3 70Bでやってみた(根拠引用を強制) このページの狙い LLMに「障害の原因を当てさせる」よりも、 (1) ログから根拠を抜き出す → (2) 可能性を整理 → (3) 次に打つコマンドを提案 までを“オンプレで”完結させる例です。 --- 入力ログ(3行) 今回は、よくあるパターンの短いログ断片で試しました(抜粋)。 NVRM: Xid (PCI:0000:3b:00): 31, pid=1234, Ch 00000010, MMU Fault CUDA error: out of memory s

Share

オンプレLLMでログ一次切り分け:Llama 3.3 70Bでやってみた(根拠引用を強制)

このページの狙い

LLMに「障害の原因を当てさせる」よりも、 (1) ログから根拠を抜き出す → (2) 可能性を整理 → (3) 次に打つコマンドを提案 までを“オンプレで”完結させる例です。

---

入力ログ(3行)

今回は、よくあるパターンの短いログ断片で試しました(抜粋)。

NVRM: Xid (PCI:0000:3b:00): 31, pid=1234, Ch 00000010, MMU Fault
CUDA error: out of memory
slurmstepd: error: Detected 1 oom_kill event(s) in step

---

AIの出力(実際のJSONから抜粋)

LLM(Llama 3.3 70B)に「JSONで返す」よう指示し、さらに根拠は入力ログからの引用のみに制約しました。 (出力の要点だけ読みやすく抜粋しています)

  • カテゴリ:GPU / Memory / Slurm
  • 重大度:High

根拠(ログからの引用)

L1: NVRM: Xid ... 31 ... MMU Fault
L2: CUDA error: out of memory
L3: slurmstepd: ... oom_kill event(s) ...

原因候補(確信度つき)

  • Insufficient GPU memory(confidence: 0.8)
  • Memory leak in the application(confidence: 0.1)
  • GPU driver issue(confidence: 0.1)

次にやること(コピペ可能なコマンド) ※安全性と再現性を重視して、環境依存・危険操作(サービス再起動等)は避けています。

nvidia-smi
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
nvidia-smi -q -d ECC,ERROR,POWER,TEMPERATURE
dmesg -T | tail -n 200
journalctl -k -b | tail -n 200
sacct -j <JOBID> --format=JobID,State,ExitCode,Elapsed,MaxRSS,AllocTRES%60
scontrol show job <JOBID>
ps -p <PID> -o pid,etime,cmd --sort=pid

追加で欲しい情報(不足しているもの)

  • GPU model and driver version
  • System memory configuration
  • Application code and configuration
  • Slurm cluster configuration
  • Detailed system logs

---

なぜ信頼できる?(根拠引用を強制する工夫)

LLMは親切に補完してしまい、入力に無いログ行を混ぜることがあります。 そこで今回は、次の2つの工夫を入れて 「根拠はログ引用のみ」に寄せました。

  • ログに行番号を付けて渡す(抜粋の追跡がしやすい)
  • evidenceは入力ログからの完全一致引用のみにする(捏造を抑える)

「原因を断定するAI」ではなく、根拠を示して次の確認に進める一次切り分けとして現実的です。

---

PoC(オンプレ)相談

オンプレ環境(H100/H200 NVL等)で、ログを社外に出さずに

  • ログのマスク(ホスト名/IP/パス等)
  • 根拠引用を強制した構造化JSON
  • あなたのRunbook/FAQを参照して「次のコマンド」を提示(RAG)
  • 監査・保存ポリシーに合わせた設計

まで含めて短期PoCが可能です。

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