IMAGE: AI生成ビジュアル
COMPUTE / INFRASTRUCTURE
同一クラスタでGPU利用率+33ポイント — Dharma-AIが「割当順序」を変えるだけで改善した制約認識型アロケータを公開
Dharma-AIは2026年8月17日、Hugging FaceブログでGPU管理の第2弾を公開した。同一ハードウェア・同一ワークロードで、FIFOスケジューラ比・GPU利用率が最大33ポイント、優先度重み付き出力が最大105%向上したと報告。変わったのはハードウェアではなく「どのGPUに、どのジョブを、どの順序で割り当てるか」という決定の順序だけという。
Dharma-AIは2026年8月17日、Hugging FaceブログでGPU管理に関する連載の第2弾「Same Cluster, 33 Points More Utilization: What Changed Was the Order」を公開した。制約認識型のGPUアロケータをFIFOスケジューラと比較し、同一ハードウェア・同一ワークロードのままGPU利用率が最大33ポイント、優先度重み付き出力が最大105%向上したと報告している。同社の主張の核心は「稼働率を上げるのに必要なのはハードウェアの追加ではなく、割当決定の順序」という点にある。以下の数値はすべてDharma-AIの自社シミュレーションによる公称値であり、独立機関による再現評価はまだ公表されていない。
FIFOスケジューラの2つのコスト
同ブログは比較の基準として、到着順に配置するFIFOスケジューラ（リアルタイム推論は固定予約枠で処理）を置く。クラスタに空きがあれば順序は利用率に影響しないが、競合が起きると2つのコストが顕在化するという。
- 予約のコスト: リアルタイム推論は待てないため、FIFO型の運用では各アプリの1日の最大需要を満たすGPUを終日確保する。需要の谷間でもGPUは遊休のまま保留され、バッチ系ジョブは使えない。予約が支配的なシナリオではベースラインが51.6%（混合制御）と53.6%（トレーニング主体）に張り付く
- 順序のコスト: 到着順配置は優先度を考慮せず、後から来た高優先ジョブが先着ジョブの後ろに並ぶ。さらに「ジョブの形（連続ブロックのサイズ）」に合う空きが残っているかもチェックしないため、後発のジョブが収まらず未スケジュールになり、GPU時間が使われないまま残る
- これらが複合すると、数時間のピークのために終日確保されたGPUがすべてのバッチジョブから締め出される。冒頭の指標で言えば、トレーニング主体（8 GPU・16ジョブ）のシナリオでは利用率が53.6%→87.0%へ、優先度重み付き出力が+105.1%と倍増した
制約を書き下したアロケータの設計
提案するアロケータは「どのGPUがどのジョブを、どのタイムステップで、どの優先度で実行するか」を1つの最適化問題として解く。合法な割当を定義する5つの制約は以下の通り。
- 1 GPUは1タイムステップにつき1ジョブのみ
- 各ジョブは需要レンジを守り、実行中ジョブは引き継いで保持
- バッチ系ジョブは2のべき乗サイズの連続GPUブロックを占有
- リアルタイムジョブは隣接タイムステップ間でスワップできるGPU数に上限がある
- 開始済みジョブは中断されない
目的関数は、バッチ系への割当に「優先度×時間減衰重み」の報酬を与え、リアルタイム需要の未達には不足規模に比例したペナルティを課す。ペナルティ重みは割当報酬の5〜10倍に設定され、レイテンシ義務がスケジューラ内部で価格付けされる点が設計の特徴だ。応答にはヒューリスティックがホットパスとして動作し、競合5シナリオで1〜2ms、64 GPU・30ジョブのスケールテストで15msと報告されている。形式モデルはそのヒューリスティックが満たすべき仕様として後段に置く。
7シナリオの結果（自社ベンチマーク）
| シナリオ | 利用率の変化 | 優先度重み付き出力の向上 | 応答時間 |
|---|---|---|---|
| 混合制御（8 GPU・10ジョブ） | 51.6% → 72.4% | +54.8% | 1ms |
| リアルタイム競合（8 GPU・8ジョブ） | 75.0% → 80.2% | +24.6% | 1ms |
| トレーニング主体（8 GPU・16ジョブ） | 53.6% → 87.0% | +105.1% | 2ms |
| 大規模混合（14 GPU・16ジョブ） | 76.8% → 82.7% | +43.8% | 2ms |
| オーバーサブスクライブ（8 GPU・9ジョブ） | 85.4% → 87.5% | +33.6% | 1ms |
| スケールテスト（64 GPU・30ジョブ） | 44.9% → 44.9% | +15.9% | 15ms |
| 均一優先度（14 GPU・16ジョブ） | 76.8% → 87.5% | +23.1% | 2ms |
利用率は6シナリオで改善し、1シナリオ（スケールテスト）はタイだった。このスケールテストでは利用率（44.9%）も完了ジョブ数（30件中27件）もFIFOと同一だった一方、優先度重み付き出力は15.9%向上しており、「利用率は占有を測るだけで価値は測らない」という主張の実証例になるとしている。均一優先度テストは「順序による優位は優先度の差の産物にすぎない」という反論への対抗で、全ジョブを同一優先度にしても利用率・出力とも改善したと報告する。
ただし改善効果の大半は前提となる需要予測の精度に依存しており、同社も「需要の数値が間違っていれば何も機能しない」と明記する。トレーニングは22特徴量で見積もり、量子化はアルゴリズム別（bitsandbytes、AWQ、GPTQ）のキャリブレーション階層で処理する。運用面では24時間のホライズンを最適化しながら現在のタイムステップのみをコミットし、30〜60分ごとに再実行する「Optimize the day, commit the hour」方式をとり、予測誤差を再最適化で吸収する。
