## 定義 自動ジョブキャンセルとは、SlurmのようなHPCクラスタスケジューラ上で、GPU利用率が一定期間ゼロまたは低いままのジョブを自動的に検出し、警告後に強制終了する運用手法である。目的は、(1)高価なGPUを実際に利用する待機中ジョブへ即座に解放する、(2)ユーザーに問題を即座に通知し、ジョブ完了を待たずに修正・再投入させる、(3)ユーザーのfairshare値の不要な低下を避ける、(4)スタッフがアイドルGPUジョブに気づくたびに個別対応する手間を省く、の4点にまとめられる。[[@2026__PEARC__Getting the Most Out of Your GPUs]] は、Princeton大学を含む米国の主要大学への調査から、Arizona State University・Boston University・Clemson University・George Mason University・KAUST・Princeton University・University of Hawaii at Hilo・University of Virginia・Yale Universityの9大学がこの手法を実運用していることを確認した。(Source: [[@2026__PEARC__Getting the Most Out of Your GPUs]]) 自動ジョブキャンセルを実現する代表的なソフトウェアには、[[Jobstats]]/[[Job Defense Shield]](Princeton)、[[HPC Dashboard]](Arizona State University、`gpuseff`サービスによりGPU利用率が4時間平均で5%未満のジョブをキャンセル候補とする)、[[GPU-Watch]](George Mason University、3層アーキテクチャで2分ごとに利用率を評価)がある。いずれも独立に開発されながら、GPU利用率のウィンドウ平均を閾値として判定するという共通のアプローチに到達している。フルプラットフォームを導入せず、`nvidia-smi`を定期的に呼び出すだけの単純な独自スクリプトで同じ目的を達成する運用も報告されている。(Source: [[@2026__PEARC__Getting the Most Out of Your GPUs]]) ## 横断的知見 - **自動キャンセルは複数大学・複数の独立実装で同じ閾値設計(GPU利用率のウィンドウ平均が既定で0%近傍)に収束している**: [[Jobstats]]/[[Job Defense Shield]]・[[HPC Dashboard]]・[[GPU-Watch]]は互いに独立に開発されたが、いずれも「一定時間窓でのGPU利用率平均が閾値未満のジョブをキャンセル対象とする」という同一の判定モデルに到達している。Princetonでは一度閾値を0%から9%以下へ引き上げたところ強い反発が起き2日後に撤回された事例が報告されており、0%という閾値は「ユーザーの許容度」と「検出漏れの回避」のバランス点として経験的に支持されていると考えられる。(Source: [[@2026__PEARC__Getting the Most Out of Your GPUs]]) - **自動キャンセルの節約効果はクラスタのワークロード特性に依存し、LLM研究用の高負荷クラスタでも無視できない規模になる**: Princetonの336台のH100 LLM研究用クラスタでは、過去6ヶ月間に52%のユーザーが少なくとも1回自動キャンセルされ、対策なしでは全GPU時間の6%が浪費されていたと推定される。汎用GPUクラスタ(A100 320台)では推定1%とより小さい。GPU利用率が総じて高いワークロード(LLM学習)でも、少数の設定ミス・放置ジョブが無視できない割合のGPU時間を消費し得ることを示す。(Source: [[@2026__PEARC__Getting the Most Out of Your GPUs]]) ## 未解決の問い - GPU利用率のウィンドウ幅(4時間・90分等)や閾値(0%・5%等)の最適値は、ワークロードの種類(バッチ/インタラクティブ、LLM学習/推論)ごとにどう変わるべきか。定量的な感度分析は本ソースには無い。 - 自動キャンセルの偽陽性(実際には有用な計算をしているが検出上は低利用に見えるジョブ、例: JAXやAlphaFoldのような一部大学で除外リストに入ったケース)を、除外リストへの手動追加ではなく自動的に判別する方法はあるか。 - [[Jobstats]]がDCGM由来の詳細メトリクス(SM利用率・Tensor Core利用率等)をAPIに追加した場合、キャンセル判定はGPU利用率単独からSM利用率等を組み合わせた多次元判定へ進化するのか。その際の判定閾値設計はどう変わるか。