オンプレLLMでログ一次切り分け：Llama 3.3 70Bでやってみた（根拠引用を強制）¶
このページの狙い
LLMに「障害の原因を当てさせる」よりも、
(1) ログから根拠を抜き出す → (2) 可能性を整理 → (3) 次に打つコマンドを提案
までを“オンプレで”完結させる例です。
なぜオンプレLLMなのか（クラウドLLMではなく）¶
結論から言うと、ログ解析の現場では 「外に出せない」「外に出したくない」が頻繁に起きます。
クラウドLLM（ChatGPT/Gemini等）が悪いのではなく、次の事情で使いにくいケースが多いです。
- 機密情報が混ざりやすい
ログにはホスト名、IP、ユーザー名、ディレクトリ構成、ジョブ名、社内システム名などが入りやすく、事故の原因になりやすいです。 - コンプライアンス／監査の壁
「どのデータをどこに送ったか」を説明・監査できないと運用に乗りません。 - 運用データは量が多く、都度マスクが現実的でない
一回だけなら手で伏せ字もできますが、日常運用では手間がボトルネックになります。 - ネットワークや利用制限に依存したくない
障害対応は深夜やインターネットに出られない環境（社内ネットワークだけ）でも起きます。外部サービス依存だと詰まります。
オンプレLLMなら、ログを外に出さずに - 根拠引用（どの行を根拠にしたか） - 次に打つコマンド提案 - 社内Runbook参照（RAG） まで完結できます。
※もちろん「クラウド利用可」の組織もあります。その場合でも、オンプレは “インターネットに出られない環境（社内ネットワークだけ）でも動く運用支援”として別の価値があります。
入力ログ（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」ではなく、根拠を示して次の確認に進める一次切り分けとして現実的です。
ファインチューニング無しでもここまでできた（今回のポイント）¶
今回のデモは ファインチューニング無し（追加学習無し）で実施しました。
それでも形になった理由は、モデルに任せきりにせず、
- 根拠はログからの引用だけ（作り話を抑える）
- 出力を JSON形式に固定（人間にも機械にも読みやすい）
- 「次に打つコマンド」を コピペ可能な形で必ず出す
という“運用向けのルール”を先に決めたからです。
ファインチューニングが必要になるのは、たとえば - 自社のRunbook手順やチケット書式に 厳密に合わせたい - 同じ種類の障害が大量にあり、分類体系を 固定化したい - 人手での一次切り分けを さらに省力化したい といった段階です。まずは 追加学習なしで小さくPoCし、必要になった時だけ学習を検討するのが現実的です。
PoC（オンプレ）相談¶
オンプレ環境（H100/H200 NVL等）で、ログを社外に出さずに
- ログのマスク（ホスト名/IP/パス等）
- 根拠引用を強制した構造化JSON
- あなたのRunbook/FAQを参照して「次のコマンド」を提示（RAG）
- 監査・保存ポリシーに合わせた設計
まで含めて短期PoCが可能です。