> [!abstract] 概要 > グラフィックス処理装置(GPU)は高価であり、ほぼすべての研究機関で需要が高い。本稿では、新たな財政コストを発生させずに機関がGPUへの投資を最大化する4つの方法を提示する。第一に、GPU利用率が0またはそれ以下のSlurmジョブを自動的にキャンセルするツールについて議論する。我々の調査では、これらのツールを現在活用している9大学を特定し、そのうちの1校は自動キャンセルによって全GPU時間の6%を節約している。第二に、GPU分割(GPU fractionalization、例: Multi-instance GPUつまりMIG)の利点を示し、クラスタ上の実効GPU数を15%増加させた1つの事例を取り上げる。第三に、streaming multiprocessor利用率・Tensor Core利用率・NVLink転送速度などの詳細なGPUメトリクスをどのように測定し、効率的に見えるが実際には性能が不足しているコードを識別するために使えるかを示す。最後に、GPU共有のためのSlurmプラグインのプレビューを提示する。 ## 論文情報 - タイトル: Getting the Most Out of Your GPUs: Automatic Cancellation of Low Efficiency Jobs, GPU Fractionalization, Detailed Metrics, and GPU Sharing - 著者・所属: Jonathan Halverson([[Princeton University|Princeton University]] Research Computing)、Josko Plazonic(同)、Johnathan Lee(Arizona State University Research Computing)、Samyak Gupta(Princeton University Computer Science) - 媒体: Practice and Experience in Advanced Research Computing (PEARC '26)、2026年7月26–30日、Minneapolis, MN, USA - DOI: 10.1145/3785462.3815871 - コード: `github.com/PrincetonUniversity/jobstats`(スライドQRコード)、[[Job Defense Shield]] リポジトリ ## 概要 本論文は、Princeton大学とArizona State大学のリサーチコンピューティング部門が、追加の資金投入なしにGPUクラスタの実効利用率を高めるために実践している4つの手法をまとめたサーベイ論文である。GPUアイドルジョブの自動キャンセル、GPU分割(MIG)によるハードウェアの粒度最適化、DCGM由来の詳細GPUメトリクスによる「見た目は効率的だが実際は非効率」なコードの検出、そしてGPU共有のためのSlurmプラグイン開発の4本柱で構成される。5ページの短い実践報告(practice paper)であり、新規アルゴリズムの提案ではなく、複数大学への調査結果と自施設の運用データに基づく知見の共有が主眼である。 ## 問題設定 GPU(特にNVIDIA Blackwell B200のような最新世代)は1台あたり30,000〜40,000ドルを超える高価なハードウェアであるにもかかわらず、共有HPCクラスタでは頻繁に低利用率のまま放置される。原因は、誤設定されたジョブスクリプト、ボトルネックのあるデータパイプライン、計算を行わずに保持され続けるインタラクティブセッションなどである。入力は、SlurmジョブスケジューラとDCGM/Prometheusベースのテレメトリが収集するCPU/GPU利用率・メモリ使用量・ジョブメタデータであり、出力は「浪費されているGPU時間をどう検出し、どう削減するか」に関する運用上の判断・自動化ルールである。 ## 提案手法 ### 1. GPUアイドルジョブの自動キャンセル - **動機**: (1)高価なGPUを、実際に使う待機中ジョブへ解放できる、(2)ユーザーが問題に即座に気づき、ジョブ完了を待たずに修正・再投入できる、(3)fairshare値の不要な低下を避けられる、(4)スタッフがアイドルGPUジョブに気づくたびに個別メールを書く手間を省ける。 - **調査**: 主に米国の20大学に連絡し、自動キャンセルを利用していると確認できた9大学(Arizona State University、Boston University、Clemson University、George Mason University、KAUST、Princeton University、University of Hawaii at Hilo、University of Virginia、Yale University)を列挙した。1校は今後導入予定、3校は検討中と回答した。 - **4つのソフトウェアツール**: - **Jobstats**(Princeton Research Computing開発): SlurmクラスタのCPU/GPU性能メトリクスを提供するオープンソースの監視プラットフォームで、PrometheusエクスポータとGrafana、Slurmデータベースを統合し、CLIとWebダッシュボードの両方を提供する。100以上の機関で利用されている。効率レポートと実行可能なフィードバック(メモリ・コア割当削減の提案)を自動生成し、Open OnDemandと完全統合されている。[[Job Defense Shield]] 機能により、低利用リソースの検出・GPUジョブの自動キャンセル・メールアラート送信を行う。バッチジョブとインタラクティブジョブを異なる規則で扱えるほか、除外ユーザーリストを設定できる。上記9大学のうち6大学がこのツールを使用。 - **HPC Dashboard**(Arizona State University Johnathan Lee開発、別名Slurm Node Dashboard): Next.jsで構築されたリアルタイム監視・可視化プラットフォームで、Sol supercomputerなどのSlurmクラスタ管理に用いられる。Prometheusメトリクス、履歴レポート、OpenAIを用いたチャットアシスタントを統合する。ジョブキャンセルのワークフローは、キャンセルポリシーと表示を分離した専用サービス`gpuseff`が担う。`gpuseff`は薄いGo製CLIクライアントと、Python(FastAPI)製のバックエンドAPIサービスで構成され、単一のGPU効率エンドポイントを公開する。このエンドポイントはダッシュボードとCLIの両方から利用されるため、両者は常に同一の性能・キャンセル状態を報告する。バックエンドはジョブ単位のDCGM GPUメトリクスから計算されたPrometheusのrecording rule(ウィンドウ平均利用率・サンプルカバレッジ・推定浪費GPU時間など)を評価し、Slurmジョブ詳細と結合する。既定では、4時間の移動平均GPU利用率が5%未満のジョブをキャンセル候補としてフラグする(十分なサンプルが集まるまでは「calculating」と表示)。ポリシーをAPI側に集約することで、ダッシュボード・CLI・その上に構築される自動化のすべてが単一の一貫した「低利用ジョブ」定義を共有する。 - **GPU-Watch**(George Mason University Abhinav Tummapudi開発): Slurmクラスタ向けの自律的なノードレベルGPU利用率強制フレームワーク。Pythonベースの監視コア、2分ごとに実行されるsystemd駆動の実行層、Ansibleベースのクラスタヘルス検証層という3層構成を持つ。プロセスIDをSlurmジョブへマッピングすることで、JupyterノートブックやアレイジョブのようなワークロードでもGPU利用率を正確に計算できる。低利用ジョブを自動検出し、カウントダウン付き警告メールを送信し、改善がなければジョブを終了する。 - **カスタムスクリプト**: フルプラットフォームを構築せずに済ませたい機関向けに、5分ごとに`nvidia-smi`を呼び出し、2時間連続でGPU利用率が0であればジョブをキャンセルするシンプルな独自スクリプトを使う大学も1校確認された。 **発表スライドで示されたJobstats設定例** ![[_attachments/getting-most-out-of-your-gpus-pearc2026/slide-jobstats-autocancel-email-example.png]] (PEARC 2026発表スライド p.7。`cancel-zero-gpu-jobs`のYAML設定例(15分間隔でサンプリング、45分で警告メール、90分でキャンセル、インタラクティブジョブは最大6時間/1GPUまで許容、`aturing`を除外ユーザーに指定)と、実際に送信されるキャンセル通知メールの文面(JobID・Cluster・Partition・State・GPUs-Allocated・GPU-Util・Hoursを列挙し、返信すると自動でサポートチケットが開く)を示す。論文本文にはこの具体的な設定・メール文面の記載はない。) - **補足: 投入時点でのジョブ拒否(スライドのみで言及)**: 発表スライドでは、自動キャンセル(実行中ジョブの事後対応)を補完する仕組みとして、Slurmの`job_submit.lua`プラグインを使いジョブ投入時点で不適切なリクエストを拒否する手法が紹介されている。例えば「AI Labノードに対しGPU 1台あたり8コアを超えるCPUコアを要求している」ジョブは`salloc`の時点でエラーメッセージとともに拒否される。対象はCPUコア過剰要求・ノードあたりGPU不足・GPUあたりCPUメモリ過剰の3パターンで、[Job Submit Plugin API](https://slurm.schedmd.com/job_submit_plugins.html)を利用する。この手法は論文本文には記載がなく、スライドでのみ言及されている。 **発表スライドで示された投入時ジョブ拒否の例** ![[_attachments/getting-most-out-of-your-gpus-pearc2026/slide-reject-jobs-at-submission.png]] (PEARC 2026発表スライド p.11。`salloc -N 1 -n 32 -t 1 --gres=gpu:1`のようなCPUコア過剰要求を、投入時点で`job_submit.lua`がエラーメッセージ付きで拒否する例を示す。) - **導入の実際**: Princetonでの2024年初頭のロールアウトはユーザーからほぼ無反応で受け入れられた。2025年時点でDellaクラスタの1000人超のユーザーのうち、除外リストに追加が必要だったのはわずか2名(JAXとAlphaFoldを使うユーザー)だった。一度、キャンセル閾値を0%から9%以下へ引き上げたところ、ユーザーから強い反発が起き、2日後に元へ戻された(スライドでは、10%/1時間の閾値変更を要求されて実施したが、複数の予期しない低利用率化の手口が判明したため0%へ戻したという経緯が示されている)。一般に、0%利用率での自動キャンセル導入はユーザー・スタッフの双方から好意的に受け止められる。 ### 2. GPU分割(GPU Fractionalization) - NVIDIA Multi-Instance GPU(MIG)は、H100やA100のような高性能アクセラレータを、ハードウェアレベルで分離された独立インスタンスへ分割する技術であり、軽量な推論からHPCシミュレーションまで異種混在ワークロードを、性能干渉なく同一GPU上で並行実行できるようにする。 - JobstatsなどのジョブモニタリングプラットフォームはCPU/GPU利用率・メモリ使用量・割当ノード数・CPUコア数・GPU数をジョブ単位で記録しており、これらのデータからクラスタがMIGから利益を得るかどうかを計算できる。JobstatsユーザーのためのJupyterノートブック([[Job Defense Shield]] リポジトリ内のMIG計算スクリプト)が公開されている。 - Princetonでは汎用GPUクラスタに2段階でMIGを導入した: 2023年初頭に80GB A100を8台変換し、10GB MIGインスタンス56個を作成。2025年中頃には80GB A100を40台変換し、40GB MIGインスタンス80個を作成。いずれも変換すべきGPU数はJobstatsデータから明示的に計算された。この変更でクラスタの実効GPU数が15%増加し、サポートチケットは5件未満で、いずれも容易に解決された。 **発表スライドで示されたMIG推奨メールの例** ![[_attachments/getting-most-out-of-your-gpus-pearc2026/slide-mig-suggestion-email-example.png]] (PEARC 2026発表スライド p.16。`gpu-model-too-powerful`という名前の設定(最小実行時間61分、GPU時間閾値24時間、GPU利用率閾値15%、GPUメモリ使用量上限10GB、CPUメモリ上限32GB/GPU)と、実際に送られるメール文面を示す。フルA100 GPUを使ったが利用率8〜10%・メモリ使用量3GBだった4件のジョブを列挙し、MIG GPU(A100の1/7の性能・メモリ)への切替を提案し、`#SBATCH --partition=mig`という具体的な設定変更方法を示す。) ### 3. 詳細GPUメトリクス - `nvidia-smi`によるGPU利用率は、GPUカーネルが動作している時間の割合のみを示し、使用中のスレッド数やSM数についての情報は提供しない。 - DCGM Prometheusエクスポータおよびプリンストン版NVIDIA GPUエクスポータは、SM利用率・occupancy・Tensor Core利用率・NVLinkの受信/転送レート・PCIeの受信/転送レートに加え、FP16/FP32/FP64コアの利用率などの追加メトリクスを提供する。JobstatsはこれらのメトリクスをまもなくAPIに追加予定であり、TACCのRemoraツールも同様のメトリクスを提供している。 - これらの詳細メトリクスは、性能不足・誤設定のコードを識別するために使える。例として、GPU利用率は高いがSM利用率が低いコード(多数の小さなカーネルを起動している可能性)、あるいはFP64利用率が高いか、Tensor Core利用率が低いAIコードが挙げられる。継続的なジョブ監視プラットフォームにとって、こうしたデータは性能チューニングエンジニアだけでなく、プロファイリングツールで再実行せずに性能を定期チェックしたい一般ユーザーにも有用である。 **発表スライドで示されたLLMクラスタの詳細GPUメトリクス例** ![[_attachments/getting-most-out-of-your-gpus-pearc2026/slide-detailed-gpu-metrics-llm-cluster.png]] (PEARC 2026発表スライド p.19。5人のユーザー(u23764・u78330・u41425・u39096・u81242)について、GPU時間・GPU利用率(UTIL)・SM利用率(SM)・両者の差(UTIL−SM)・FP64利用率・Tensor Core利用率を並べた表。例えばu23764はGPU利用率56%に対しSM利用率38%(差18ポイント)、Tensor Core利用率13.9%であり、GPU利用率だけでは見えない性能特性の違いが定量的に示されている。論文本文にはこの具体的な数値例の記載はない。) ### 4. GPU共有のためのSlurmプラグイン(プレビュー) - 現在のGPU共有機構(Multi-Process Service、MIG、time-slicing)は複雑なトレードオフを伴い、3つの中核的な課題を抱える。 1. **リソースの見積り誤り(Resource Mismatch)**: ユーザーはジョブ投入時にリソース需要を過大・過小評価しがちであり、既存の共有手法はアプリケーションのGPUメモリ・計算要求を事前に知っている必要があるため、Jupyterノートブックのように需要が時間変動するジョブでは柔軟性が低い。 2. **障害分離の弱さ(Poor Fault Isolation)**: MPSやtime-slicingはメモリ・性能の厳密な分離を欠き、誤動作したジョブが容易にOOM障害を引き起こしたり、同居するワークロードの性能を劣化させたりする。Slurmは現時点でこれらの手法下での分離を強制する仕組みを持たず、手動のユーザー管理に依存している。 3. **ハードウェア上の制約(Hardware Limitations)**: MIGのようなハードウェア分割手法はNVLinkのような高速GPU相互接続機能を無効化するため、共有MIG GPUを利用できないワークロードが多く存在する。 - これらの課題に対応するため、著者らはSlurmのプラグインとして構築される動的スケジューリングシステムを実験中である。メモリまたは計算を低利用している主ジョブ(primary job)を特定し、余剰キャパシティ上に自動的にセカンダリジョブ(secondary job)を共スケジューリングする。これにより、開発・デバッグジョブがほぼ即時にGPUへアクセスできるようになり、待ち時間が最小化される。NVIDIA Unified Virtual Memory(UVM)を活用してOOM障害を防止し、MPSの利用をセカンダリジョブに厳しく限定することで、障害の影響を分離・限定する。 - スライドによれば、この開発はPrinceton Computer ScienceのSamyak Gupta・Andrew Sheinberg・Kai Liによって進められている。 ## 新規性 既存のGPU利用率監視は`nvidia-smi`ベースの単純な利用率(GPUカーネルが動作している時間の割合)に留まることが多いが、本論文はDCGM由来のSM利用率・Tensor Core利用率・NVLink転送速度といった多次元メトリクスを組み合わせることで、「利用率は高いが実際には非効率」なワークロードを見抹すアプローチを示す点、および複数大学の実運用データ(9大学の自動キャンセル導入事例、15%のGPU増加事例)を横断的に集約して定量的な説得材料を提示する点が特徴である。GPU共有については、MPS・MIG・time-slicingの既知の限界を明示的に整理し、UVMベースのOOM防止とセカンダリジョブへのMPS限定という組み合わせで障害分離を改善しようとする方向性を示すが、この部分は完成した手法ではなくプレビュー段階の記述である。 ## 実験設定 本論文は新規の統制実験を行うサーベイ/実践報告であり、厳密な比較実験は含まれない。データはPrincetonおよび他大学の実運用クラスタから収集された観測データである。 - **調査**: 米国の主要大学等20機関へ連絡し、自動キャンセルの利用状況を聞き取り(選択バイアスのあるサンプル)。 - **Princeton LLM研究用クラスタ**: H100 GPU 336台。過去6ヶ月間のユーザーの自動キャンセル実績を分析。 - **Princeton汎用GPUクラスタ(MIG分析)**: 40GB A100 GPU 40台のクラスタから、150日間、実行時間1時間以上のジョブのGPU利用率・GPUメモリ使用量・GPU時間のヒートマップを作成(Figure 1)。 **Figure 1: GPU利用率とGPUメモリ使用量の関数としてのGPU時間ヒートマップ** ![[_attachments/getting-most-out-of-your-gpus-pearc2026/fig01-heatmap-gpu-hours-utilization-memory.png]] (Figure 1. GPU利用率(縦軸、0〜100%)とGPU per-job平均メモリ使用量(横軸、0〜40 GB)の2次元グリッドで、各セルの色がその区間に属するジョブの累計GPU時間を表す。最大値は12,000時間超(濃い赤)。) ## 実験結果 - **自動キャンセルの効果**: Princeton LLM研究用クラスタ(H100 336台)では、過去6ヶ月間で少なくとも1つのジョブが自動キャンセルされたユーザーは全体の52%に達した。自動キャンセルがなければ、全GPU時間の推定6%がアイドルGPUのジョブに消費されていたはずであり、この推定はキャンセルされたジョブが実行時間上限の半分まで走っていたと仮定した計算である。別の1大学は3ヶ月間で「数千GPU時間」の節約を報告した。スライドでは、汎用GPUクラスタ(A100 320台)でも自動キャンセルなしでは全GPU時間の1%が失われる計算になると示されている。 - **MIG導入の効果**: Figure 1のヒートマップから、GPU利用率20%未満・GPUメモリ使用量10GB未満のジョブが全GPU時間の8%を占めることが読み取れる。このデータから、12台のA100を36台の10GB MIG GPUへ変換すべきという結論が導かれた。実際の導入(2023年に8台→56台、2025年に40台→80台)では、クラスタの実効GPU数が15%増加し、サポートチケットは5件未満に抑えられた。[[Job Defense Shield]] によって、フルGPUで実行されたがMIG GPUでも実行可能だったジョブについて、スタッフの手間なしで自動メールアラートを送る運用が可能になっている。 - **2026年時点の知見(スライドのみ)**: 336台のH100クラスタ(LLM研究用)ではGPU利用率・メモリ使用量がいずれも高いため、MIGへの変換は有効ではないと判明した。この点は、MIGの効果がワークロードの利用率・メモリ使用特性に強く依存することを示唆する。 ## 考察 本論文の主張の骨格は、「大きな追加投資なしに既存GPUクラスタの実効容量を引き出す」という一貫した方針にある。自動キャンセルは即効性のある運用改善であり、GPU分割はデータ駆動的な容量再配分であり、詳細メトリクスは「隠れた非効率」を可視化する診断ツールであり、GPU共有プラグインは将来的な容量最大化の方向性である。4つの取り組みは技術的な連続性を持ち、いずれもJobstatsのようなジョブ単位メトリクス収集基盤があって初めて実現可能になっている点が共通している。 一方で、自動キャンセルの調査は意図的に偏ったサンプル(自動キャンセルを使っていると予想された大学)を対象にしているため、「9/20校」という数字自体を米国全体の普及率と解釈してはならないと著者ら自身が明記している。またMIGの効果は個別クラスタのワークロード特性(特にGPU利用率・メモリ使用量の分布)に強く依存し、LLM研究用の高利用率クラスタでは効果が乏しいとスライドで示されており、MIG導入判断は事前のJobstatsデータ分析が前提になる。 ## 強み / 弱点・課題 **強み** - 複数大学への実際の聞き取り調査に基づき、単一機関の経験に留まらない横断的な実践知を提示している。 - Jobstats・HPC Dashboard・GPU-Watchという独立に開発された3つの監視プラットフォームを比較し、いずれも同様の自動キャンセルという結論に到達している点を示すことで、手法の一般性を補強している。 - 具体的な数値(6%の節約、15%のGPU増加、5件未満のサポートチケット)を示し、他機関が導入を正当化する際の説得材料を提供している。 **弱点・課題** - 調査対象20大学は「自動キャンセルを使っていると予想された」機関に限定された偏ったサンプルであり、著者ら自身が9/20という比率を米国全体の実態より低く見積もるべきと注記している。 - GPU共有のためのSlurmプラグインはまだプレビュー段階であり、定量的な性能評価やベンチマーク結果は本稿に含まれていない。 - 詳細GPUメトリクス(SM利用率・Tensor Core利用率等)を用いた性能不足コードの識別は、具体的な閾値や検出アルゴリズムの提示がなく、定性的な事例紹介に留まる。 - 5ページの短い実践報告であり、各手法の内部実装(例: `gpuseff`のPrometheus recording ruleの詳細、GPU共有プラグインのスケジューリングアルゴリズム)は詳述されていない。