LLM
Local LLM controllerは未知の研究計算タスクを前進させられるか：LLZOとQuantum ESPRESSOで実践
Local LLM controller、Web検索、安全なCLI操作を組み合わせ、LLZOのLiイオン拡散評価に向けたQuantum ESPRESSO環境構築とbounded sanity runまでを実践しました。
Kenetsu Hanabusa
LLM
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入力生成タスクで比較しました。
notes-migration
ローカル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可視
notes-migration
ローカル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
News
Server Gear Blog を開設しました
Server Gear Blog では、GPUサーバー、HPC、RescueReady OS、GPU Start Console、ローカルLLM、ベンチマーク検証などについて発信していきます。 手順書、証跡、runbook は notes.server-gear.com に集約し、このブログでは開発背景、考え方、検証記録、導入事例を中心に扱います。
notes-migration
FP64 synthetic だけでは見えない GPU 比較: QE と LAMMPS の確認結果
FP64 synthetic だけでは見えない GPU 比較: QE と LAMMPS の確認結果 結論 A100 が最速 でした。今回の比較では、QE long-run と LAMMPS selected stable case の両方で最上位です。 Ada は実用域 でした。QE long-run と custom LLZO LAMMPS の selected stable case の両方で、A100に次ぐ現実的な選択肢です。 Blackwell は今回の条件と現行スタックでは Ada より遅い 結果でした。差の主因は収束回数増ではなく、 elec
notes-migration
DoMINOで“外部空力（CFD）”を秒オーダーで試す（初心者向け）
DoMINOで“外部空力（CFD）”を秒オーダーで試す（初心者向け） 結論（1分） DoMINO（DoMINO-Automotive-Aero NIM）は、車体形状（STL）から 抗力/揚力 と 表面圧力分布 を返す「CFDサロゲート（代理モデル）」です。 4GPUマシンでは、 同時リクエスト（並列） を増やすことでスループットがほぼ比例して伸びます。 実測では、H100 NVL 4GPUで conc=1→9.16 req/min、conc=4→36.92 req/min（約4倍）、conc=8→55.49 req/min でした。 --- 1) DoM
notes-migration
オンプレ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
notes-migration
AI推論サービング実測：A100×4 vs H100 NVL×4（vLLM / Qwen2.5-7B）TTFTと同時ユーザー
AI推論サービング実測：A100×4 vs H100 NVL×4（vLLM / Qwen2.5-7B）TTFTと同時ユーザー 結論（3行） 同時32の出力スループット： H100×4 = 5414 tok/s , A100×4 = 3723 tok/s （ 1.45× ） 同時32のTTFT（平均）： H100×4 = 66.66 ms , A100×4 = 82.11 ms （H100の方が短い） つまり 「同時ユーザーが増えるほど差が効く」 ＝社内AI・RAG・運用支援のような“多人数同時利用”でGPU選定の根拠にしやすい --- これは何の実測？
notes-migration
GROMACS 溶媒和ΔGをGPUで回す：λ窓並列で意思決定を前倒し（A100実測→H200 NVLへ）
GROMACS 溶媒和ΔGをGPUで回す：λ窓並列で意思決定を前倒し（A100実測→H200 NVLへ） 前提（ここが大事） このページの数値は A100 80GB×4 での実測です。 販売対象の H200 NVL（1/4/8GPU） でも同じ考え方で、 「λ窓（＋replica/複数案件）を並列化して、壁時計を短縮」 できます。 H200 NVL向けには、お客様の系・条件に合わせて PoCで実測値を提示 します。 結論（先に要点） 同じΔGを再現 ：A100とH100で溶媒和ΔGは誤差内で一致（計算として妥当） A100→H100で壁時計短縮 ：4GP
notes-migration
LLZO粒界のLi-rich仮説を“支持”できた。だからこそGPUで仮説検証を高速に回す価値がある
LLZO粒界のLi-rich仮説を“支持”できた。だからこそGPUで仮説検証を高速に回す価値がある 先に全体像を見たい方へ： LLZO Fast-charge bottleneck map に、bulk / grain boundary / interface をまたいだ比較と、現時点での canonical な fixed stack をまとめています。 結論だけ先に ：今回の検証は、 「LLZOの粒界（GB）がLi-richになりやすい」傾向は“見えた（仮説を支持する方向）” （Li濃度ピーク比 ≈ 3.14× 、過剰面密度 Γ ≈ 15.0 #/n
notes-migration
Research Note Ep0: LLZO + Li + ML-IAP + Allegro
Research Note Ep0: LLZO + Li + ML-IAP + Allegro このページは notes（MkDocs）版へ移行中です。 TL;DR LLZO短絡問題に対し、 QE × ML-IAP（Allegro/NequIP） × LAMMPS で「再現可能に回る」ワークフローを作る導入編です。 DeepMD系ワークフローを土台にしつつ、 E(3)等価 なモデル（Allegro）へ移行する理由と評価観点を整理します。 まずは 粒界（grain boundary）でのLi偏析・局在 を前駆現象として定量化し、後続で界面シナリオへ接続しま