事業紹介 事業紹介トップ 経営データ分析基盤 Claude / MCP 導入 育つ業務アプリ 複雑な SaaS を専用 UI に Shopify Plus 移行・拡張 生成AI 活用(Multi AI) SEO / AIO / 広告運用 顧問・アドバイザリ インフラ構築 自社メディア投資・開発
Claude Claude / MCP 総合 Claude Cowork Claude Code 導入支援 Claude Code 使いこなし支援 Claude Design MCP 開発・サーバー構築
Shopify Plus Shopify Plus トップ EC-CUBE からの移行 大手カートからの移行 Shopify 通常プラン EC サイト構築
実績
業界ニュース 業界ニュース トップ AI ニュース └ Claude └ ChatGPT・Codex └ Gemini └ その他 Shopify ニュース SaaS ニュース お知らせ(自社発信)
会社情報 お問い合わせ
2026.08.18

同一クラスタでGPU稼働率を33ポイント改善——Dharma AIの制約対応アロケーターが変えたのは「順番」だった

記事のサマリー(TL;DR)

  • Dharma AIの制約対応アロケーターがFIFO比で稼働率を最大33ポイント向上、優先度加重出力は最大105%増
  • 変更したのはハードウェアではなくジョブの割り当て順序とリアルタイム需要の扱い方のみ
  • 64GPU・30ジョブのスケールテストでも15ミリ秒以内に応答し、15.9%の価値向上を達成

国内エンタープライズAI基盤担当者が押さえるべきGPU管理の実装ポイント

日本の大手製造業・金融機関・通信キャリアがオンプレミスまたはプライベートクラウドにGPUクラスターを保有・調達するケースが増えている。このとき多くの組織がFIFO的な「申請順」スケジューリングを慣例的に採用するが、本記事が示す通り、FIFOはリアルタイム推論の「最大ピーク確保」と「到着順コミット」の二重コストによって稼働率を50%台に押し込む。GPUはすでに購入・償却が進む固定資産であるため、稼働率の差はそのまま機会損失に直結する。特にトレーニング・バッチ推論・量子化・リアルタイム推論の4ワークロードが混在するマルチテナント基盤では、制約を数理的に定式化した優先度スケジューラーの導入効果が際立つ。需要予測精度(本記事では22特徴量・10訓練バリアント区別)がスケジューリング品質に直結するため、ワークロードタイプ別の専用推定器を整備することが前提条件となる。

詳細

解かれている問題の定義

「GPUを稼働させる」という目標は、システムが実行できる粒度の命令ではありません。実際に解かなければならない問題は「どのGPUが、どのジョブを、どのタイムステップに、どの優先度で処理するか」という二値選択の組み合わせであり、出力は GPU × スケジューリング全期間のグリッドです。

このグリッドを争う4種類のワークロードが存在します。

  • トレーニング(Training): 開始から終了まで連続したGPUブロックを占有するバッチ型
  • リアルタイム推論(Real-time Inference): トラフィックに連動して毎タイムステップ増減するエラスティック型
  • バッチ推論(Batch Inference): トレーニングと同じく連続ブロックが必要なバッチ型
  • 量子化(Quantization): 同じくバッチ型で、大規模モデルでは数時間のGPU時間を消費

「連続ブロックが必要なバッチ型」と「需要曲線で動くエラスティック型」という互いに相容れない2形状が同一タイムステップに同一ハードウェアを奪い合う点が本質的な困難です。さらにトレーニングは、数時間〜数日、1GPU〜数十GPUという2軸で自由に組み合わさるため、単一カテゴリ内でも異質性が高くなります。

FIFOが競合状態で払うコスト

比較対象のFIFOスケジューラーはリアルタイム推論を固定予約で確保し、その他のジョブを優先度を無視して到着順に配置します。クラスターに余裕があればこの方針は機能しますが、競合が発生した途端に2種類のコストが顕在化します。

予約コスト: リアルタイム推論はキャパシティが即座に必要なため、FIFOでは1日の最大ピーク需要分のGPUを終日確保するしかありません。深夜に2GPUしか必要ない推論サービスが、昼間のピーク(6GPU)を基準に24時間分の6GPUを押さえてしまいます。その結果、午前4時の4GPUはバッチジョブにとって「使用中ではないが空いてもいない」状態に置かれます。これがベースライン稼働率が51.6%〜53.6%に留まる主因です。

順序コスト: 競合下では「何が入るか」は「何が先に来るか」で決まります。優先度の低いジョブが先着しているせいで、高優先度ジョブが待機させられ、後から来た高価値ジョブが必要な形状のGPUブロックを見つけられずにスケジュール不可となります。使われなかったGPU時間は回収不能です。

この2つが複合すると、航空会社が「最初に電話してきたチャーター」に機材を割り当てた結果、実際に利益を生む路線に飛行機がなくなる状況と同じことが起きます。

5つの競合シナリオでの結果

5つの本格的な競合シナリオで、アロケーターは稼働率と優先度加重価値の両方を同時に改善しました。

  • 稼働率の帯域: 52〜85% → 72〜88%
  • 優先度加重価値の向上幅: 24.6%〜105.1%、平均52%
  • 最強ケース(8GPU・16ジョブのトレーニング重視): 稼働率 53.6% → 87.0%、価値 +105.1%

いかなるシナリオでもトレードオフは発生せず、両指標が同時に改善しています。

アロケーターのアーキテクチャ

アロケーターはリアルタイム需要を「上限(ceiling)」ではなく「曲線(curve)」として扱い、各タイムステップの実需要に対して割り当てを行います。トラフの時間帯はバッチ系ジョブがその空き枠を利用し、連続タイムステップ間のGPU入れ替え上限で過剰なチャーンを抑制します。バッチ系ジョブは到着順ではなく、スケジューリング全期間を俯瞰した優先度順で配置されます。

法的配置の5制約条件:

  1. 1GPUは1タイムステップに1ジョブのみ
  2. 各ジョブはその需要範囲を遵守し、既に稼働中のジョブは継承・保持される
  3. バッチ系ジョブのGPUブロックサイズは2の冪乗
  4. リアルタイムジョブは連続タイムステップ間でスワップできるGPU数に上限あり
  5. 開始済みジョブは中断不可

目的関数の2項:

  • バッチ系ジョブへのGPU割り当て: 優先度 × 時間減衰ウェイトの報酬
  • リアルタイム需要の未達: 不足量に比例するペナルティ(ペナルティウェイトはアロケーションウェイトの5〜10倍)

この非対称性により、レイテンシ義務はバッチ配置の最適化と同一の最適化内部で執行されます。「静的予約ではなくペナルティが可用性を守る」という設計がリアルタイム需要をエラスティックに扱うことを安全にしています。

稼働率と価値の分離

スケールテスト(64GPU・30ジョブ)では、FIFOとアロケーターの稼働率は同値(44.9%)でした。しかし優先度加重価値はアロケーターが15.9%高い結果となりました。同じダッシュボード表示、異なるアウトプット。占有率を最適化しても価値は最大化されないことを定量的に示すケースです。

均一優先度テスト(全ジョブを同一優先度に設定)でも、アロケーターは稼働率を76.8% → 87.5%、価値を+23.1%改善しました。利得は優先度順序付けだけのアーティファクトではなく、全期間を見通した計画配置そのものが稼働率を押し上げることを示しています。

ベンチマーク結果一覧

シナリオ 稼働率(変化) 価値向上率 レイテンシ
混合コントロール(8GPU・10ジョブ) 51.6% → 72.4% +54.8% 1 ms
リアルタイム競合(8GPU・8ジョブ) 75.0% → 80.2% +24.6% 1 ms
トレーニング重視(8GPU・16ジョブ) 53.6% → 87.0% +105.1% 2 ms
大規模混合(14GPU・16ジョブ) 76.8% → 82.7% +43.8% 2 ms
オーバーサブスクライブ(8GPU・9ジョブ) 85.4% → 87.5% +33.6% 1 ms
スケールテスト(64GPU・30ジョブ) 44.9% → 44.9% +15.9% 15 ms
均一優先度(14GPU・16ジョブ) 76.8% → 87.5% +23.1% 2 ms

需要予測がスケジューリング品質を決める

上記の結果はスケジューラーが各ジョブのGPU時間とリアルタイムトラフィックを正確に把握していることが前提です。両者は推測値であり、予測精度がスケジューリング品質を規定します。

ワークロードタイプ別の専用推定器が必要な理由は以下の通りです。

トレーニング: 戦略(フルファインチューニング vs. LoRAなど)と手法(SFT・DPO・RLHF・RLVR・CPT)の2軸が独立して組み合わさります。LoRAはフルファインチューニングと比べて学習可能パラメータを最大10,000倍削減、GPUメモリを約3倍削減します。モデルサイズだけで推定すると、桁が異なるランを平均してしまいます。Dharma AIのトレーニング予測器は22特徴量(10種類の訓練バリアントを区別するカテゴリ変数を含む)を入力として用います。

量子化: パラメータ数によるキャリブレーションティアと、アルゴリズム(bitsandbytes・AWQ・GPTQ)別の処理を持つ専用予測器で推定します。

リアルタイム推論: ジョブ単位では推定せず、時間別トラフィック履歴から毎週再キャリブレーションする需要プロファイルとして予測します。この曲線予測が「ピーク時最大予約」を不要にします。

最適化の範囲とホライズン設計

スケジューラーは24時間ホライズンを最適化しますが、コミットするのは現在のタイムステップのみで、30〜60分ごとに再実行します。これにより予測誤差は再最適化で吸収され、計画が連続してスラッシングすることを防ぎます。ホライズン計画は「稼働中のジョブを引き継ぐ」ため、後続プランは前計画を上書きするのではなく更新します。

「エンドオブワールド効果(end-of-world effect)」——ホライズン末端直後のタイムステップを破壊する決定をオプティマイザーが行う問題——もこのアーキテクチャで回避されています。時間減衰ウェイトは、次回実行時には新たなジョブが到着しているという現実を反映し、現在のキャパシティを将来の約束より高く評価します。

ホライズン計画自体が副次的な予測産物にもなります。リアルタイムカバレッジリスクと予測可能なアイドル枠を事前に可視化でき、これらの特定割り当てが実際にコミットされるかどうかにかかわらず有用な情報です。

この設計が一般化すること

航空会社が稼働率を解いたのは最適なスケジュールを計算したからではありません。折り返し手順・整備ウィンドウ・乗員ローテーションという運用規律を「順番」に落とし込み、その規律を複利的に機能させたからです。同じことがここで起きています。クラスターが物理的に許可することを割り当て決定の順序に埋め込むことで、同一ハードウェア・同一ワークロード・数ミリ秒の処理で33ポイントの稼働率改善と平均52%の優先度加重出力向上が実現されました。GPUはすでに設置され、コミットされ、償却が進んでいます。利得はその使い方の選択の中にありました。