- GPUを1枚も買い増さず、実行する順番を変えただけで稼働率が53.6%→87.0%(33.3ポイント改善)
- 原因は「先に来たジョブから処理する」FIFO方式の2つの弱点
- 24時間先を計算して直近の1コマだけ実行し、30〜60分ごとに計算し直す仕組み
- 遊休H100は1枚で月約133万円の損失。稼働率こそが実質コストを決める
- さくらインターネットが売上予想を158億円→85億円に下方修正した理由も稼働率
「GPUが足りない」と言われ続けています。でも、すでに持っているGPUは本当に働いているでしょうか。ある検証チームが、ハードもワークロードも一切変えずに実行順序だけを組み替えたところ、稼働率が33ポイント上がりました。買い増しゼロで、です。
同じGPUで稼働率が33ポイント改善した
2026年8月17日、Dharma-AIのチームがHugging Faceのブログで実測レポートを公開しました。
内容はシンプルです。同じハードウェアで、同じジョブを流し、スケジューラ(どの仕事をいつ実行するか決めるプログラム)だけを入れ替えた。それだけです。
結果、学習ジョブ中心のシナリオ(GPU8枚)で稼働率が53.6%から87.0%へ、33.3ポイント改善しました。
なぜGPUは「遊ぶ」のか
多くの現場はFIFO(First In, First Out=先に来た仕事から順に処理する方式)でGPUを割り当てています。行列に並んだ順番どおり、というやり方です。
弱点1:ピークに備えて一日中空けてしまう
チャットボットのようなリアルタイム推論(ユーザーの操作にその場で応答する処理)には、混雑時に耐えられるだけの余裕が必要です。
そこで多くの現場は、ピーク時に必要な枚数を24時間ずっと確保し続けます。
結果どうなるか。深夜3時、アクセスがほとんどない時間帯にも、その枠は空いたまま温存されます。朝のラッシュのために高速道路の車線を深夜も封鎖しておくようなものです。
弱点2:価値ではなく到着順で決めてしまう
FIFOは仕事の重要度を見ません。先に投入された軽い実験ジョブの後ろに、事業に直結する重要な学習ジョブが並んでしまうことが起きます。
社内で共有GPUを使っている方なら、心当たりがあるのではないでしょうか。急ぎの検証を流したいのに、誰かが朝一番に投げた長時間ジョブが列を塞いでいる。あの状態です。
新しいスケジューラは何をしたのか
今回入れ替えられたのは制約認識型アロケータと呼ばれる仕組みです。難しそうな名前ですが、やっていることは3つに整理できます。
1つ目は、リアルタイム需要を「固定の天井」ではなく「時間で動く曲線」として扱うことです。深夜は需要が下がると予測できるなら、その分を他の仕事に回します。
2つ目は、バッチ系のジョブ(学習・一括推論・量子化など、すぐ応答しなくていい処理)を価値の順に並べ直すことです。到着順ではなく、優先度と時間による価値の減衰を掛け合わせて評価します。
3つ目が、この仕組みの肝です。24時間先までの割り当てを計算するのに、実際に実行するのは直近の1コマだけ。そして30〜60分ごとに計算をやり直します。
予測は必ず外れます。だから長期の計画は立てるけれど、コミットは短く刻む。予測誤差を吸収するための設計です。
さらに、リアルタイム需要を取りこぼしたときのペナルティは、バッチジョブを詰め込む報酬より5〜10倍重く設定されています。ユーザー体験を犠牲にして稼働率だけを上げる、という本末転倒を防ぐためです。
気になる計算コストですが、割り当ての計算は1〜15ミリ秒で終わります。スケジューラ自体がGPUを食い潰す心配はありません。
7つのシナリオの実測結果
レポートでは7つのシナリオが検証されました。主な結果を見てみます。
- 学習中心(GPU8枚):53.6% → 87.0%(+33.3ポイント)
- 混在ワークロード(GPU8枚):51.6% → 72.4%(+20.8ポイント)
- リアルタイム競合あり:75.0% → 80.2%(+5.2ポイント)
- スケールテスト(GPU64枚):44.9% → 44.9%(変化なし)
正直な数字だと感じます。64枚のスケールテストでは稼働率がまったく改善していません。都合の良い結果だけを並べていない点は評価できます。
ただし64枚のケースでも、稼働率は同じまま「優先度で重み付けした成果」は向上しました。同じ忙しさで、より価値の高い仕事を先に片付けたということです。
この優先度重み付き成果は、シナリオ全体で15.9%〜105.1%の改善、平均52%という結果でした。
もともと稼働率が高い環境(75%スタート)では伸びしろが5.2ポイントどまりです。効果が大きいのは、低〜中程度の稼働率で悩んでいる現場と言えます。
コストに直すと何が起きているのか
稼働率の話がなぜここまで重要なのか。金額に直すとはっきりします。
H100のクラウドレンタル価格は2026年時点で1時間あたり2.00〜10.00ドル、中央値で2.69ドルほどです。1ドル150円換算で1枚を1年間借り続けると約354万円になります。
AWSのオンデマンド価格で計算すると、遊んでいるH100は1枚あたり月約8,850ドル(約133万円)を垂れ流している計算です。
さらに衝撃的な調査もあります。Kubernetesクラスタ全体でのGPU平均利用率がわずか5%だったという報告です。この水準だと、実際に使えた計算1時間あたりの実質コストは名目価格の20倍に跳ね上がります。
実際、ClearMLの調査ではFortune 1000企業のIT責任者の49.2%が「既存ハードウェアでのGPU効率の最大化」を今後12〜18カ月の最優先課題に挙げています。買い増しより使い切り、という流れは業界全体のものです。
既存のGPUスケジューラと何が違うのか
GPUのスケジューリングツールはすでにいくつもあります。今回の手法がどこに位置づくのか整理します。
主要ツールの棲み分け
- Slurm:HPC(スーパーコンピュータ分野)で長年使われる定番。決定的な挙動とハードウェアの直接制御に強く、専有クラスタ向き
- NVIDIA Run:ai:商用で最も洗練された選択肢。GPUを分割して複数ジョブで共有する機能とサポート契約が売り
- Volcano:大規模分散学習向け。ギャングスケジューリング(必要なGPUが揃うまで起動しない方式)で共有クラスタの学習完了時間を40%短縮した実績
- Kueue:軽量でKubernetesネイティブ。チーム間のクォータ管理が得意で、ベンダーロックインがない
実務では16枚未満のクラスタや稼働率60%以下の環境なら、KueueやKAI Schedulerで十分とされています。しかも無料です。
今回の手法の立ち位置
既存ツールの多くは「どう公平に配るか」「どう待たせるか」を解きます。対して今回の制約認識型アロケータは需要予測と価値の最適化に踏み込んでいる点が違います。
なお今回のレポートは特定チームによる自社手法の検証です。第三者の追試はまだありません。数字はあくまで参考値として見るのが妥当でしょう。
日本市場への影響
この話は日本にとって他人事ではありません。むしろ、直撃しているテーマです。
象徴的なのがさくらインターネットの事例です。同社は経済産業省の「クラウドプログラム」で投資額の50%の助成を受け、H100/H200を計2,000基規模で導入。総投資は約659億円が計画されていました。
ところが2025年7月、大型案件の終了によりGPUクラウドの売上予想を158億円から85億円へ、約47%下方修正します。営業利益は91.6%減という厳しい数字でした。
原因は需要の消滅ではなく、特定顧客に依存した結果としての稼働率低下です。GPUは物理的にそこにあるのに、動いていない。これがどれだけ経営を揺らすかを示した事例と言えます。
日本企業は「GPU買い負け」と呼ばれる調達難にも直面しています。手に入らないなら、手元のものを使い切るしかない。スケジューリング改善の価値は、GPUが潤沢な国よりむしろ日本で高いはずです。
社内の共有GPU環境を思い浮かべてください。研究部門が日中に対話型で使い、夜間は誰も触らない。その夜間帯に学習ジョブを自動で流し込めているでしょうか。多くの企業でここは手動運用のままです。
よくある質問(FAQ)
Q1. このスケジューラはすぐ使えますか?
いいえ。今回公開されたのは手法と検証結果のレポートであり、誰でも導入できる製品として配布されているわけではありません。まずは考え方を自社環境に当てはめて検討する段階です。
Q2. GPUが少なくても効果はありますか?
検証は8枚から始まっており、小規模でも効果は出ています。ただしすでに稼働率が高い環境では伸びしろが小さい(75%→80.2%)ため、まずは自社の現在値を測ることをおすすめします。
Q3. リアルタイムの応答速度は犠牲になりませんか?
そこは設計で手当てされています。リアルタイム需要の取りこぼしへのペナルティが、バッチジョブを詰める報酬の5〜10倍に重み付けされているためです。
Q4. まず何から手をつけるべきですか?
現在のGPU稼働率を実測することです。多くの現場は自社の数字を把握していません。60%を下回っているなら、KueueやVolcanoといった無料ツールの導入検討から始める価値があります。
Q5. 稼働率100%を目指すべきですか?
いいえ。急な需要増に備えた余裕は必要ですし、64枚の検証のように稼働率が同じでも成果が上がるケースもあります。追うべきは稼働率そのものより「価値ある仕事がどれだけ進んだか」です。
まとめ
- ハードを変えず実行順序だけを変え、GPU稼働率が53.6%→87.0%(33.3ポイント改善)
- 原因はFIFOの2つの弱点。ピーク用の枠を一日中空ける、価値でなく到着順で決める
- 24時間先を計算し直近1コマだけ実行、30〜60分ごとに再計算する設計
- 64枚環境では稼働率が変わらないなど、効果は環境に依存する
- 遊休H100は1枚で月約133万円。稼働率が実質コストを決める
- さくらインターネットの売上47%下方修正も、突き詰めれば稼働率の問題
まずは自社のGPU稼働率を測ってみてください。数字がわからないままでは、買い増すべきか使い方を直すべきかの判断もできません。
参考文献
- Dharma-AI「GPU Management Part 2」(Hugging Face Blog、2026年8月17日)
- CloudZero「H100 GPU Cost In 2026」
- ClearML「Managing Across Schedulers: HPC Meets Kubernetes」
- 「The National Research Platform: Stretched, Multi-Tenant, Scientific Kubernetes Cluster」(arXiv)
- 「日本のGPUデータセンターに陰り?さくらインターネット下方修正から読み解く」
- 日経クロステック「GPUとガバクラで目指す『国産クラウド最強』」

