日本語でGPU計算サーバーを構築する：ComputeBuilder AI実機検証 この実演でのLLMと制作側の役割 サーバー上の導入・ビルド・設定・修正コマンドは、ComputeBuilder AIのローカルLLMが作成・実行しました。制作担当のAI（ChatGPT）は、利用者役の日本語プロンプト作成・入力と追加確認、独立した読み取り検証を担当しています。実行中の入力は全8回、うち追加確認2回です。修正コマンドを外から渡して代行修復する方式ではありません。 初心者自身が操作して目的を達成できるか、最初の依頼だけで最後まで自律的に進められるかは、今回の検証では確認していません。 この記事は、日本語で説明を求め、回答の不整合や確認条件を問い直しながら構築した事例です。 動画：https://www.youtube.com/watch?v=77FJNsCshe0 日本語でGPU計算サーバーを構築する：ComputeBuilder AI実機検証 日本語の相談から、GPUで計算できる状態へ GPUサーバーを使い始めるとき、最初に戸惑うのは「目的の計算をするには、何を入れればよいのか」という点ではないでしょうか。OSを入れただけでは、GPUドライバー、コンパイラ、ライブラリ、計算ソフトウェア、ジョブ管理の準備が残っています。 ComputeBuilder AIは、Linuxの計算環境づくりを日本語で相談し、調査・説明・実行を進めるためのソフトウェアです。この記事では、DGX Spark上のローカルLLMからH100を2枚搭載したサーバーへ接続し、クリーンな基準環境から構築した実機検証を紹介します。 2026年10月1日の検証では、NVIDIAドライバーの導入と再起動なしの有効化、NVIDIA HPC SDKの導入、Quantum ESPRESSO（以下、QE）のGPU向けビルドとテスト、Slurmによる独立した2ジョブの同時実行まで完了しました。途中には失敗や説明の誤りがあり、日本語の追加確認を2回行っています。 この記事と動画は、同じ実行記録に基づいています。動画はログと対話を読みやすく再構成した解説版で、連続した画面録画ではありません。記事では、動画で省略した判断理由・トラブル・確認方法を補います。 1. どの機械で、何を動かしたのか 役割 | 今回の構成 操作・推論側 | DGX Spark／ComputeBuilder AI／Codex CLI 0.158.0 ローカルモデル | Qwen3.8-Flash-Next UD-IQ4_XS／コンテキスト262,144トークン／思考low 操作対象 | Ubuntu 24.04／kernel 6.8.0-138-generic／H100 PCIe 80GB×2 CPU・メモリ | AMD EPYC 9354P、32コア／システムメモリ約188 GiB 接続先 | dl@h100x2-clean（この検証で用いたSSH接続名） 使用したツール | 汎用シェル・SSH、Tavilyの検索・ページ抽出 開始時点 | NVIDIAドライバー、HPC SDK、QE、Slurmなし DGX Spark上のモデルが調査や操作を考え、SSHで対象サーバーへコマンドを送ります。QEの計算は対象サーバーのGPUで行います。今回、セットアップ手順を固定した専用MCPや、事前検証済みの導入ヘルパーは使用していません。 「ローカルLLM」は推論の実行場所を表します。今回の構成ではTavilyによるウェブ検索・抽出とソフトウェア取得にインターネットを利用しました。完全オフラインの実演ではありません。動画制作で使うMarinの音声生成も、製品が対象サーバーを操作する仕組みとは別です。 開始前の準備と、動画中の操作を分ける 準備担当がクリーンOS用の基準スナップショットから新しい環境を起動し、SSHで利用できる状態にしました。基準状態には234個のパッケージがあり、ドライバーや計算スタックは未導入でした。「クリーン」はGPU計算用ソフトウェアのない基準環境を指し、物理ディスク全体が空という意味ではありません。既存の/dataの研究データは変更対象から外しています。 その後の導入・ビルド・Slurm設定・修正コマンドは、ローカルモデルが生成して実行しました。制作側は利用者役の日本語入力を代行し、別途、読み取り専用の確認で結果を照合しています。修正コマンドを外から渡して代行修復する方式ではありません。実行中に製品の指示ファイルを変更していないこともハッシュで確認しました。 今回は上級者モードで実行 computebuilder-ai --general-tools --advanced これは検証環境で使用した起動コマンドです。ドライバーやシステムサービスの導入にsudoを使うため、上級者モードを選んでいます。CLIの承認確認とサンドボックスを無効にした構成であり、「まず説明して、まだ変更しないで」という区切りは、日本語プロンプトで指示しています。承認ダイアログで毎段階を強制停止する実演ではありません。 標準モードではsudoを使わないようAIへ指示する方針ですが、その指示自体はOSによる権限制御と同じではありません。この記事で確認したのは上級者モードでの構築です。 2. ドライバーは、実行前に選定理由を聞く 最初の依頼では、対象、目的、制約、調査だけに留めることをまとめて伝えます。「何を入れるべきか」を先に説明してもらうことで、利用者が選定理由を確認できます。 01：構成調査とドライバー選定 ssh dl@h100x2-cleanでハードウェア、OS、ソフトウェア環境、空き容量を調べ、このサーバーに適したNVIDIAドライバーと導入手順を説明してください。長期安定運用を重視します。再起動せずに使える可能性と、できない場合の条件も確認してください。Tavilyを使って公式情報を確認し、出典URLを示してください。まだインストールや設定変更はしないでください。 これはクリーンなUbuntuから計算環境を作る実演です。以降も接続先はこのサーバーだけです。/dataにある既存の研究データや他の環境は変更しません。作業ファイルはホーム配下の専用ディレクトリで管理してください。事前作成されたセットアップヘルパーや過去の検証ログは参照せず、実機と公式資料から判断してください。 モデルはハードウェア、OS、カーネル、既存のドライバー、権限などを調べ、Tavilyで公式情報を確認しました。今回の選定はR580系列です。実際の導入版は580.178.04でした。 ドライバー導入では、実行中カーネルに合うヘッダーやモジュール、OSとGPUの対応を確認する必要があります。選定番号だけでなく、導入前提と検証方法を見ることが大切です。公式の準備・導入・検証の考え方は、NVIDIA Driver Installation Guideに整理されています。 記事中のバージョンは、2026年10月1日の選定・実測値です。リンク先の公式文書は更新されるため、後日の「最新版」としてこの番号を固定して扱わないでください。 3. 導入後、再起動なしでGPUを有効化できた 02：ドライバー導入と有効化 説明した推奨方針でNVIDIAドライバーをインストールしてください。再起動せず有効化できる場合は、2枚のGPUが使用可能か確認するところまで進めてください。再起動が必要なら、その前に止めて教えてください。実行が失敗したときは原因を調べ、依頼の範囲内で修正して再確認してください。 モデルはbuild-essential、DKMS、カーネルヘッダーなどを導入し、nouveauの設定とinitramfsを扱い、NVIDIA公式APTリポジトリを登録しました。ブランチを固定するパッケージとドライバーを導入し、モジュールを読み込んで確認しています。以前の別検証のパッケージ手順を混ぜず、この実行記録に基づいて説明しています。 今回、DKMSのビルドとモジュールの有効化が成功し、nvidia-smiでH100を2枚とも認識しました。開始時と最終確認時のboot_idが一致しており、基準環境の起動後に再起動していないことを独立して確認しています。 確認項目 | 結果 ドライバー | 580.178.04（パッケージ580.178.04-1ubuntu1） GPU認識 | NVIDIA H100 PCIe×2 導入後の再起動 | なし 確認の根拠 | モジュール・デバイス認識、nvidia-smi、boot_idの一致 再起動せず有効化できるかどうかは、既存モジュールを使用しているプロセス、競合するドライバー、セキュアブート、カーネルなどの状態に依存します。今回の成功を、すべてのGPUサーバーで再起動不要という意味には広げません。また、nvidia-smiのCUDA Version表示だけでは、CUDA Toolkitやnvccがインストールされているとは分かりません。 4. QEのビルドに必要なものを説明させる 03：QEの構築計画を調査 Quantum ESPRESSOの最新の安定版をGPUで使いたいです。公式のリリース情報とこのサーバーの状態を調べ、必要なソフトウェア、ドライバーとの互換性、インストールとビルドの手順、必要な空き容量を説明してください。NVIDIA HPC SDKを使ったGPU向けビルドを考えています。最終的には1枚のGPUで小さなテスト計算を行い、同じ計算をSlurmで2ジョブ同時に実行したいです。今回は調査と説明だけで、パッケージやソースのダウンロード、インストール、ビルドはまだ始めないでください。 説明は、選定理由・変更範囲・確認方法・出典を中心に800字程度で簡潔にまとめてください。詳細なコマンド列は実行を依頼した段階で示してください。調査段階では、作業用ディレクトリやファイルの作成も行わないでください。 ここでは「GPUで使いたい」「NVIDIA HPC SDKを使う」「後でSlurmから独立した2ジョブを動かす」と目的を伝えています。調査段階の出力を800字程度に制限し、詳細コマンドは実行段階で求めることで、利用者が計画を読みやすくしています。 ソフトウェア | 今回の役割 NVIDIAドライバー | OSからGPUを利用する NVIDIA HPC SDK | nvfortranなどのコンパイラ・開発環境 CUDA | GPU向けビルド・実行に必要な開発基盤 MPI | 複数の計算プロセスの通信と協調 FFTW等 | QEが必要とする数値計算ライブラリ Quantum ESPRESSO | 今回構築して動作確認する計算ソフトウェア 最初の回答には、1台のサーバーを「2ノード」と扱う説明や、SDKを「26.x」とする曖昧な選定がありました。そのまま実行せず、次の質問を追加しています。 03b：台数とSDK・CUDA・MPIの選定を確認 説明を確認しましたが、サーバーは1台で、その中にH100が2枚あります。「2ノード定義」という説明で正しいのでしょうか。また、HPC SDKが「26.x」「程度」では判断しにくいので、実際に使う版・同梱CUDA・MPIの選び方と必要容量を公式情報で確認して、計画を具体化してください。最初は小さな独立計算を1枚のGPUで動かし、後でそれを2ジョブ同時に動かすのが目的です。互換性に条件がある場合は明記してください。まだインストールやファイル作成はしないで、修正点と実行方針を簡潔に説明してください。 この質問は、コマンドや修正値の指示ではなく、説明の不整合と目的の確認です。モデルは1台・GPU2枚の構成へ説明を修正し、選定を具体化しました。利用者が説明を吟味してから作業を依頼する流れを、今回の実演では残しています。 空き容量も「その場の実測」で確認する 今回の基準状態のルート空き容量は約124.2 GiB、全工程終了時は約107 GiBでした。/dataは最終時点で約192 GiBの空きがありました。これは検証時のファイルシステムの値で、HPC SDK単体の必要容量を測定した値ではありません。パッケージ、ソース、ビルドツリー、キャッシュ、計算出力を含めて、その場の空き容量を見て判断します。 HPC SDKの一般的な導入情報はNVIDIA HPC SDK Installation Guide、QEのビルドの考え方はQEの公式ビルドガイドを参照できます。ガイドの掲載版と実際に取得するソースの版は、別々に確認します。 5. ビルド中のエラーを調べて修正する 04：開発環境導入、GPUビルド、テスト計算 その手順で必要なHPC SDKとビルド環境を用意し、Quantum ESPRESSOの公式ソースをダウンロードして、このサーバーのGPU向けにビルドしてください。小さなテスト入力と必要な擬ポテンシャルも公式配布物から用意し、まず1枚のGPUで計算してください。正常終了と収束、GPUが使われた根拠を確認してください。ダウンロード・ビルドが長くかかる場合も、終了と実際の結果まで確認してください。エラーが出たら原因を調べて修正してください。再起動が必要な変更は行わないでください。 モデルはHPC SDK 26.9をAPT経由で導入し、QE 7.6の公式ソースを取得しました。今回取得したのはqe-7.6タグのソースです。実行記録では、同梱CUDAは13.3、nvfortranは26.9-0でした。 エラー①：意図しないFortranコンパイラが選ばれた 最初のCMake設定は/usr/bin/f95などを選び、GPUビルドの前提と一致しませんでした。実際のエラーは次の通りです。 NVHPC compiler is mandatory when CUDA is enabled due QE is based on CUDA Fortran language -- Configuring incomplete, errors occurred! モデルは出力を読み、NVIDIAコンパイラを使うように設定を変更しました。しかし、コンパイラを指定すれば全て解決したわけではありません。 エラー②：既存MPIのFortranモジュールを読めない UbuntuのOpenMPIとnvfortranの組み合わせで、MPIのFortranインターフェースの検出が失敗しました。モデルは小さなプログラムで原因を調べ、モジュールファイルの読み込みエラーを確認しています。 NVFORTRAN-F-0004-Corrupt or Old Module file .../openmpi/mpi.mod NVFORTRAN/x86-64 Linux 26.9-0: compilation aborted 途中には不適切なコンパイラオプションや存在しない取得先を試す寄り道もありました。最終的にはOpenMPI 4.1.7をnvfortranで構築し、そのMPIを使ってQEの設定とビルドを通しています。MPIも、コンパイラと整合する構成が必要だったという事例です。 今回、実際にできたビルド 項目 | 確認した値 NVIDIA HPC SDK | 26.9-0 同梱CUDA | 13.3 MPI | OpenMPI 4.1.7（nvfortranによるビルド） QE | 7.6 GPUバックエンド | OpenACC + CUDA GPUアーキテクチャ | sm_90 この環境でビルドと小さな計算が成功したことを確認しています。一方、Driver 580と同梱CUDA 13.3の組み合わせについて、すべてのCUDA機能や別のアプリケーションまで互換性を検証したわけではありません。動作確認済みの範囲と、一般的な互換性の保証を分けて扱います。 6. GPUで動いたことを、何で確かめたか シリコンの小さなSCF入力はモデルが作成し、擬ポテンシャルはQEに同梱されたSi_r.upfを使いました。当初試したSSSPの取得が失敗し、配布物に含まれるファイルに切り替えています。「公式のテスト入力を変更せずそのまま実行した」という説明は正確ではありません。 &CONTROL calculation = "scf" prefix = "si" outdir = "./tmp" pseudo_dir = "../qe-7.6/pseudo" wf_collect = .true. / &SYSTEM ibrav = 2 celldm(1) = 10.26 nat = 2 ntyp = 1 ecutwfc = 60.0 ecutrho = 480.0 nbnd = 8 / &ELECTRONS / ATOMIC_SPECIES Si 28.0855 Si_r.upf ATOMIC_POSITIONS alat Si 0.00 0.00 0.00 Si 0.25 0.25 0.25 K_POINTS automatic 8 8 8 1 1 1 入力はecutwfc=60 Ry、ecutrho=480 Ry、k点は8×8×8です。モデル回答にはカットオフを8 Ryと書く誤記がありましたが、記事では実ファイルの値を採用しています。途中に別のk点数の追加試行もありました。ここで示す入力と最終2ジョブの結果を基準に説明しています。 GPU acceleration is ACTIVE. 1 visible GPUs per MPI rank convergence has been achieved in 4 iterations ! total energy = -16.92461072 Ry JOB DONE. 確認は三段階です。第一にQEが正常終了したこと、第二にSCFが収束したこと、第三に計算中のGPUにpw.xプロセスが存在したこと。GPU使用率の単発の表示だけでは、計算が短くて見逃す可能性があるため、実行中の記録と組み合わせます。 ログにはGPU oversubscriptionやIEEEの警告が残っています。今回の結果は環境構築の機能確認で、研究用の数値精度検証や性能チューニングの完了を意味しません。CPUとの速度比較も成立したベンチマークとして扱っていません。 7. SlurmでGPUを1枚ずつ割り当てる 05：Slurmの構成と検証方法を相談 このサーバーのH100を1枚ずつ割り当て、先ほどのQEテスト計算を独立した2つのジョブとして同時に実行したいです。Slurmの導入・設定と、GPUの割り当て、同時実行、両方の正常終了を確認する方法を説明してください。利用者が同じプロンプトで再現できる構成にしたいです。公式資料と現在の状態を確認し、まだインストール・設定変更・ジョブ投入はしないでください。 説明は、選定理由・変更範囲・確認方法・出典を中心に800字程度で簡潔にまとめてください。詳細なコマンド列は実行を依頼した段階で示してください。調査段階では、作業用ディレクトリやファイルの作成も行わないでください。 Slurmの目的は、計算の受付と資源の割り当てを管理することです。今回の要求は「1台にある2枚のGPUを、独立した2つのQEジョブに1枚ずつ割り当てる」です。1つの計算を2GPUで分散して高速化する要求ではありません。 SlurmではGPUをGRESとして登録し、ジョブが必要数を要求します。この仕組みはSlurm公式のGRES Schedulingで説明されています。登録数と実機が一致していること、各ジョブの割り当て、実際の使用を別々に確認します。 06：Slurm導入と2ジョブの実行 説明した構成でSlurmをインストール・設定し、QEのテストジョブを2つ実行してください。各ジョブにGPUを1枚ずつ割り当て、別々の物理GPUで同時に動いたことと、両方が正常終了したことをログから確認してください。小さな計算がすぐ終わる場合は、デモとして重なりを確認できるようにしてください。計算の入力・出力はジョブごとに分けてください。エラーは原因を調べて修正し、確認できた事実と未確認の点を区別して報告してください。 実行中には、古い設定パス、不正な設定項目、スプールの所有権、GPU登録、DRAIN状態などの修正が必要でした。NVMLを使った自動検出が機能せず、モデルは/dev/nvidia[0-1]を明示する登録に変更しています。最終的にノードはidle、GPUは2枚と認識されました。 各ジョブの入力・出力を分離し、GPUを1枚要求するバッチスクリプトを作成しました。今回の計算では各GPUを複数のMPIランクで利用する構成となり、MPI起動には--oversubscribeも使用しています。これは本検証で動いた構成であり、H100の性能を最大化する推奨設定として提示するものではありません。 8. 計算が失敗しても、Slurmは成功になっていた 初回のジョブ1・2はMPIのスロット条件などで計算に失敗し、ログにはpw_exit=1がありました。一方、SlurmはCOMPLETED、ExitCode=0:0と記録していました。バッチスクリプトが計算後も処理を続け、計算の失敗を終了コードとして返していなかったためです。 モデルは計算の起動条件と擬ポテンシャルの場所を修正し、その後の計算を成功させました。また、初めは計算後にしか採っていなかったGPU監視を、計算と並行して行うように修正しています。ただし、不要な90秒待機や、監視ログに他方のジョブのプロセスも混ざる点は残っていました。 ここで利用者役から、二回目の追加確認を行いました。 07：失敗判定・同時実行の証拠を改善 先ほどの最初の試行は pw_exit=1 でしたが、SlurmではCOMPLETED・終了コード0と表示されていました。これでは計算失敗を成功と誤解しそうなので、計算の失敗がジョブの失敗として分かるように見直してください。 計算中のGPU監視に直した点は確認しました。計算終了後に残っている90秒の待機は不要なので取り除き、実際の計算時間の重なりで同時実行を示してください。監視には両ジョブのプロセスが混ざっているので、ジョブIDと物理GPUの対応も明確にしてください。 既存の成功・失敗ログを残し、失敗が正しく検出されることの確認と、独立した2つのGPUジョブの正常終了の確認まで進めてください。シリコン計算は今の小さな条件で十分です。不要なソフトの追加やCPU版の追加ビルドはせず、確認した事実と未確認事項を簡潔に報告してください。 修正の中心は「何を成功とするか」 モデルはpw.xの終了コードを記録し、exit $RCでジョブへ返す形にしました。計算後の90秒待機は削除し、cgroup内のジョブIDを使って自ジョブのPIDを抽出し、物理GPUとの対応を記録する監視へ変更しています。利用者役から渡したのは要件であり、この修正コマンドを外部で作って渡したわけではありません。 計算プロセスの所属を監視に使えたことと、他利用者のGPUアクセスをOSレベルで確実に遮断できることは別です。今回、マルチユーザーの強制的な分離を検証したわけではありません。 意図的な失敗と、正常な2ジョブを再検証 ジョブ | 検証内容 | 結果 10 | 擬ポテンシャルの場所を意図的に誤る | FAILED／ExitCode=1:0 11 | 正常なSCF、物理GPU 0 | COMPLETED／ExitCode=0:0／25秒 12 | 正常なSCF、物理GPU 1 | COMPLETED／ExitCode=0:0／27秒 失敗テストでSlurmのFAILEDを確認したあと、正常な2ジョブを投入しました。両方とも4回で収束し、総エネルギーは−16.92461072 Ryでした。ジョブ番号はこの実行固有のもので、再現時に11・12になる必要はありません。 9. 「同時に動いた」の証拠を確認する キュー上で2ジョブがRUNNINGと表示されるだけでは、GPU計算が同時に動いたとまでは断定できません。計算後に待機しているジョブでもRUNNINGは続きます。そこで、各ジョブの計算プロセスが別々の物理GPUに存在した時刻を確認しました。 監視対象 | モデル側ログの観測区間（UTC） Job 11 → PCI Bus 01:00.0 | 04:01:01.682〜04:01:22.169 Job 12 → PCI Bus 02:00.0 | 04:01:01.685〜04:01:24.215 共通する区間 | 約20.484秒 制作側の独立した読み取り監視では、別々のGPU UUIDとジョブIDの対応、約22.366秒の観測上の重なりも確認できました。モデル側と独立監視側は採取間隔が異なるため、秒数は完全には一致しません。いずれも20秒以上の重なりを確認した点で整合しています。 これは独立した2計算の同時実行の検証です。1つの計算を2GPUで実行したときの高速化率や、理論性能に対する効率は測定していません。 10. 所要時間と、確認できていないこと 段階 | LLMターンの所要時間 ドライバーの調査 | 7.6分 ドライバー導入 | 9.0分 QEの計画調査 | 6.7分 計画への追加確認 | 9.3分 HPC SDK・MPI・QE構築と計算 | 40.4分 Slurmの計画調査 | 12.2分 Slurm導入・ジョブ実行 | 39.2分 失敗判定と監視の改善 | 22.0分 合計は146.2分で、OS準備や独立監査、記録整理の時間を含みません。シェル実行154回、Tavily呼び出し25回でした。今回の測定は利用者の各ターンをcodex exec resumeで再開する方式なので、常駐する対話CLIでの待ち時間と一致するとは限りません。約10万トークンの履歴を読む処理だけで約3分半かかった例もありました。動画の長さは、実際の構築所要時間を意味しません。 成功した範囲 初回のドライバー導入と再起動なしの有効化、HPC SDK導入、QEのGPUビルドとSCF計算、Slurm設定、別々のGPUでの2ジョブ同時実行、計算失敗のSlurmへの伝播を確認しました。 今後の用途ごとに確認する範囲 同じプロンプトで毎回同じコマンドになること、本番マルチユーザー環境の分離、科学的な精度、GPU間のスケーリング、長期運用の安定性は今回の検証範囲外です。Slurmの会計データベースは導入しておらず、sacctによる永続履歴はありません。完了状態はscontrolで確認し、MinJobAgeを1日に設定しています。これはデータベースによる履歴保存の代わりではありません。 ログ保存にも改善余地がありました。モデルは古いログもすべて残したと回答しましたが、実際には初期の一部出力が対象ディレクトリからなくなっていました。制作側で上書き前の記録を採取しており、この説明も保存記録と照合しています。AIの回答文だけで保存完了を判断しないことも、今回分かった点です。 11. 自分の用途で相談を始めるには 最初は「目的」「対象」「変更範囲」「成功の確認方法」を伝え、調査と実行を分けると進めやすくなります。今回の原文は記事内の青い枠にすべて掲載し、テキストでも提供しています。SSHの接続先や作業場所は、自分の環境に合わせて読み替えてください。 目的：何を計算したいか 対象：どのサーバーで行うか 制約：変更してよい範囲、再起動の可否 まず：手順と選定理由を説明してもらう 次に：説明を確認して実行を依頼する 最後：実行ログと結果の根拠を確かめる この検証では、説明の不整合や成功判定の問題を日本語で問い直し、ローカルモデルが作業を修正しました。特定の未知の問題にも対応できた一例として示せますが、あらゆる未検証の問題を自動で解決できるという主張にはしていません。 動画を視聴して全体の流れをつかみ、記事で各判断と入力を確認する、という使い方を想定しています。GPU Configuratorによる購入前の機種選定は別の機能であり、この動画・記事で検証した初回環境構築とは分けて紹介できます。 参照した実行記録：2026年10月1日のクリーン基準環境での一連の検証。記事・動画の技術的な値は、最終状態と保存ログを照合したものです。公式文書は導入方法や用語の参照先として掲載し、今回の実測結果とは区別しています。