AI・テクノロジー

AIデータセンターの「電力」を強化学習で制御する——GPUからフリートまで計測された新手法

docker agent

• 23 min read
Share

導入：AIの電力問題という「見えていないコスト」

AIの普及を語るうえで、演算性能やモデル精度ばかりが注目されがちですが、その背後で深刻化しているのが「電力」の問題です。国際エネルギー機関（IEA）の報告書「Energy and AI」は、AIデータセンターが世界の電力需要を急拡大させる要因になると警鐘を鳴らし、Goldman Sachsも「AIと米国電力需要急増」と題したレポートで、米国の電力需要が今後大きく伸びると予測しています。AIの学習・推論に使われるGPUサーバーは消費電力が大きく、その需要増加が各国の送配電網に直接の負荷としてのしかかっています。

問題の本質は、「供給が需要に追いつかない」という構造にあります。データセンターを新設するには、100MWあたり約2億ドルもの設備投資が必要なうえ、系統連系（グリッド接続）の許可を得るまでに数年単位の待ち時間が発生します。つまり電力は「今すぐ作りたくても作れない」資源であり、AIの拡大はこの供給制約と正面から向き合わざるを得ない段階に来ているのです。

こうした状況に対して注目されるのが、強化学習（RL）をはじめとするAIの「ポストトレーニング」工程です。ChatGPTなどに代表される対話型モデルは、事前学習に続いてRLHF（人間のフィードバックからの強化学習）やGRPOといった手法で調整されますが、実はこの工程は、電力の「計測可能で制御可能な構造」を備えています。本稿で紹介する研究は、この電力構造に着目し、強化学習を使った新しい制御手法を提案しています。

この研究の革新性は、電力制御の捉え方そのものを変えた点にあります。従来の対策はGPUへの静的キャップや反応的なスロットリングなど「ハードウェアを無差別に抑制する」ものでした。これに対し本研究は、学習ワークロード自体（生成するトークン数やバッチサイズなど）を電力状況に応じて適応させることで、違反を減らしつつ出力も増やす「選択的制御」を実現しています。「測る」ところから始まるこのアプローチは、AIデータセンターの電力運用に新たな選択肢をもたらします。

AIの学習には「強化学習（RL）」と「GRPO」が使われている

最新の大規模言語モデル（LLM）がここまで賢くなった背景には、一つの共通した学習手順があります。データセンターで何百枚ものGPUが「電力」という観点から見逃されてきた理由も、実はこの学習手順の中に隠れています。まずはその構造を整理しましょう。

学習の3ステージ：事前学習・事後調整・強化学習

LLMは大きく分けて3つの段階を経て作られます。第一段階は「事前学習」で、膨大なテキストから言語の一般的な能力を獲得します。第二段階は「ポストトレーニング」と呼ばれる事後調整で、モデルを「役に立つ」「指示に従う」「安全である」方向へ整えます。そして第三段階が「強化学習（RL）」です。

flowchart LR
    A[事前学習<br/>一般能力の獲得] --> B[事後調整<br/>指示・整合性] --> C[強化学習 RL<br/>報酬に基づく最適化]

強化学習（Reinforcement Learning, RL）とは、モデルが行動の結果得られる「報酬」を手掛かりに、方策を繰り返し改善していく学習手法です。現在のモデル開発を支配しているのはまさにこの第三段階であり、本研究が電力制御の対象にしたのもこの強化学習フェーズです。というのも、このフェーズだけが「実行時にパラメータを変える」ことで電力消費を制御できる構造を持っているからです。

PPOとGRPOの違いとは

強化学習の中でも、ポストトレーニングを支える代表的なアルゴリズムがPPOとGRPOです。両者を理解することは、なぜ電力制御の対象としてGRPOが選ばれたかを知る鍵になります。

項目 PPO GRPO
正式名称 Proximal Policy Optimization Group Relative Policy Optimization
特徴 クリッピングで更新幅を安定化 価値ネットワークを廃止
ベースライン 価値ネットワーク（critic）から推定 同じ質問への回答群の報酬平均
メモリ・計算 大きい 比較的小さい

PPO（Proximal Policy Optimization）は、方策の更新幅を一定範囲に「クリップ」することで、学習の暴走を防ぐ基礎的なアルゴリズムです。一方、GRPO（Group Relative Policy Optimization）は、PPOが持つ「価値ネットワーク」を捨て、代わりに同じ質問へ複数の回答を生成し、その回答グループ内の報酬平均を基準にして優劣を比較します（DeepSeekMath、DeepSeek-R1で広く採用されました）。グループ内の相対比較で済むため、メモリ消費が少なく、大規模モデルの強化学習に適しています。

なぜGRPOが「電力制御」の格好の対象なのか

GRPOの学習は「rollout（生成）フェーズ」と「update（更新）フェーズ」の二つに分かれます。生成フェーズではモデルが実際にトークンを出力し、更新フェーズではパラメータを調整します。計測によれば、この生成フェーズがエネルギー消費の大半を占めます。72Bモデルでは生成フェーズが壁時計時間の99.9%を占め、7Bモデルでは生成時に平均253Wを消費するのに対し、アイドル時はわずか86Wです。

重要なのは、この生成フェーズの規模が実行時のパラメータ「グループサイズG」や「バッチサイズ」で制御できる点です。つまり、電力消費の主役が、学習終了後に固定されてしまうものではなく、実行中に手で調整できるノブを持つのです。この「計測可能で制御可能な電力構造」こそが、強化学習を電力制御の理想的なターゲットにしています。

GPUの電力の「正体」を知る——測定がすべての出発点

GPUが実際にどれだけ電力を消費するのか。この基本を押さえない限り、いかなる省電力制御も的外れになります。ここでの最大の誤解が「名目電力（nameplate）」と実測のギャップです。

名目電力（nameplate）と実測のギャップ

名目電力とは仕様書に記載された最大定格で、NVIDIA A100の場合は400Wとされています。しかしこの値は実際の動作点ではなく、あくまで「サーマルシーリング（熱的制限値）」です。実測ではA100はアイドル時約86W、生成時約250〜315W、ピーク時でも約410Wと、状態によって消費電力が4倍以上も変動します。測定にはNVIDIA Management Library（NVML）を用い、0.5秒間隔で電力テレメトリを記録しました。対象は7B/1台・14B/2台・72B/4台のA100構成で、総計38万以上のサンプルを取得しています。

計測で明らかになった電力の「フェーズ構造」

計測データから、強化学習の消費電力には明確な「フェーズ構造」があることがわかります。GRPOの学習は生成フェーズと更新フェーズに分かれ、前者で消費電力が大きく上昇します。特に72Bではパイプライン分割（sharding）により各GPUが交代で動作し、電力の推移に負の相関（-0.13）が確認されました。

timeline
    title GPU電力のフェーズ構造
    生成フェーズ : トークン出力で電力上昇
    更新フェーズ : 計算切替で電力下落
    パイプライン分割 : 各GPUが交代で動作

電力が一定でない以上、固定的なキャップでの一律抑制は非効率です。電力が下がる瞬間には仕事を割り当て、上がる瞬間には抑制する「選択的制御」が有効で、この測定結果が以降の強化学習ベースのコントローラ設計の土台となっています。

提案手法：電力を見るPPO「メタ・コントローラ」

計測で電力のフェーズ構造が分かった以上、次は「どう制御するか」です。本研究が提案するのは、ワークロード自身の生成パラメータをリアルタイムに調整する強化学習エージェント、PPOベースの「メタ・コントローラ」です。GPUのピーク電力をハードウェアで抑える従来型の抑制ではなく、GRPO訓練の「生成フェーズ」というソフトウェア側のノブを、その時々の電力状況に応じて動かす点が特徴です。

制御問題の定式化（MDP化）

まず、電力制御を強化学習の枠組み（マルコフ決定過程＝MDP）として定式化します。状態（state）は8次元ベクトルで、直近5回の電力値、電力キャップに対する相対ヘッドルーム、現在のフェーズ（生成／更新）、現在のグループサイズなどを含みます。ここでポイントになるのが「キャップ相対化」です。電力値をそのままのワット数ではなく「設定上限との比率」に正規化することで、規模の異なるハードウェアへ1つの方策がそのまま転移できるようになります。行動（action）空間は、グループサイズGとバッチサイズの「増減・維持」という5つの離散操作に限定しました。

flowchart LR
  A[電力テレメトリ<br/>NVML 0.5秒] --> B[状態 8次元<br/>キャップ相対化]
  B --> C[PPO メタ・コントローラ]
  C --> D[行動: Gとバッチサイズの増減・維持]
  D --> E[GRPO生成パラメータ]
  E --> A

コントローラ設計の進化（G1→G4）

このメタ・コントローラは試行錯誤の末に4段階（G1〜G4）で改良されてきました。まずG1では「生のワット数」を状態に使いましたが、モデル規模が変わると学習が転移しない失敗に終わりました。続くG2でキャップ相対化とドメインランダム化を導入し、複数スケールへの拡張転移を達成します。G3では後述のラグランジュ乗数法（制約付きRL）を実装し、違反ペナルティ重みの手動調整を排除しました。G4で学習信号を保護する仕組み（グループサイズ下限3を行動空間に強制）を構造的に組み込んでいます。実装はStable-Baselines3とGymnasiumで、ラップトップのCPUだけで約10分で学習が完了するほど軽量です（GPU不要）。

なぜ「ラグランジュ乗数法」なのか

電力制御は「スループットを最大化しつつ、違反率は一定以下に保つ」という2つの相反する目的を持ちます。素朴な方法では報酬に違反ペナルティを重み付きで足しますが、この重みは手動調整に依存し、過剰にも過少にも振れます。ラグランジュ乗数法（安全制約付きRL）では、このペナルティ係数を学習中に自動調整します。結果として、違反が減りすぎればスループット方向へ、違反が増えれば制約方向へ、重みが自律的にバランスを取るため、人手を介さずに「出力を最大化しつつ上限を守る」制御が実現できます。

世代 改善内容 目的
G1 生ワット数の状態化 失敗（非転移）
G2 キャップ相対化＋ドメインランダム化 複数スケールへ転移
G3 ラグランジュ乗数法 ペナルティ重みの自動調整
G4 学習信号保護（行動空間の下限） グループサイズ下限3を強制

主要結果：7Bで違反89.8%減・出力18.1%増

前セクションで設計したPPOメタ・コントローラが、実際にどのような成果を上げたのか。最も明確な結果が出たのが、A100を1台使う7Bスケール（単一GPU）での検証です。ここでは電力上限違反が216回から22回へと89.8%減少し、同時にトークン出力は18.1%増加しました。さらにエネルギー効率（トークン/MWh）は26.2%向上し、平均電力は19.3W、ピーク電力は35.8W下がっています。ここで注目すべきは「出力も上がって、電力も下がる」という一見相反する結果が同時に起きた点です。これは、電力予算を「出力が最も買える瞬間」に集中的に配分し、それ以外の場面では積極的に抑える「選択的制御」が機能している証拠といえます。

コスト・炭素・エネルギーの台帳

制御の効果は電力の数値だけにとどまりません。7Bの計測結果をエネルギーの帳簿として整理すると、訓練に要したエネルギーは1.777kWhから1.662kWhへ減少し、100万トークンあたりの生成コストは$0.082から$0.065へ（-20.8%）、炭素強度は256.5から203.2 g CO₂/100万トークンへ低下しました。この水準を施設規模へ拡大すると、100MWデータセンターでは年間約63,800MWh・510万ドル・15,900トンのCO₂削減に相当する試算になります。

指標（7B） 制御前 制御後 変化
電力上限違反 216回 22回 -89.8%
トークン出力 — — +18.1%
エネルギー効率 — — +26.2%
生成コスト $0.082 $0.065 -20.8% /100万トークン
炭素強度 256.5 203.2 g CO₂/100万トークン
平均電力 — — -19.3W
ピーク電力 — — -35.8W

この「違反を減らしつつスループットと効率が同時に上がる」という結果は、電力制御を単なる省エネではなく、設備投資（プロビジョニング）の削減やカーボンフットプリントの低減という経営指標へ直接つなげられることを示しています。ただし注意点として、これらのヘッドライン数値は実測トレース上での評価であり、ライブ実行そのものの結果ではない、という限界があります。次のセクションでは、この手法を2台・4台へスケールした際に現れた「壁」について見ていきます。

スケールで「壁」に当たる——14Bと72Bのヌル結果

2台・4台へスケールすると制御が効かなくなる

単一GPUの7Bで大きな成果を出したメタ・コントローラは、GPU台数を増やした途端に「壁」に直面します。14Bモデルを2台のA100に載せた場合、電力上限違反率は8.0%→8.1%とほぼ変化せず、72B（4台構成）では学習させた3種類の方策すべてが「ヌル結果」（制御による効果が統計的にゼロ）に終わりました。

このとき制御自体は嘘をついていないことに注意が必要です。行動空間であるグループサイズGは、トレース上で5→6→5→4→3→2と実際に変化していました。つまりコントローラは「指示を出しているのに、電力が応答しない」状態だったのです。7Bで成立した因果関係が、規模を上げると失われてしまう——この不気味な静けさが、次の節で述べる「アクチュエータ権限の喪失」という根本原因へとつながります。

原因：グループサイズという「アクチュエータの権限喪失」

なぜグループサイズを動かしても電力が動かなかったのか。答えはパイプライン分割（sharding）にあります。GRPOはパイプライン分割では、モデルを複数のGPUに縦に分割し、各GPUが担当レイヤー分だけを順番に計算します。この構造では、グループサイズ（＝1つの質問にまとめて生成する回答の個数）を変えても、シャーディングされたパイプラインの実行速度は変わりません。GPUは「自分の担当分を流し続ける」ため、作業量の増減が電力に現れないのです。

さらに時間スケールのミスマッチも致命的でした。電力の揺らぎは0.5秒（サブ秒）オーダーで発生する一方、この制御ループは学習ステップごと（約55秒）にしか介入できません。55秒間隔の調整で、0.5秒単位で上下するピーク電力を抑えることは構造的に困難です。

ここで得られた教訓を整理すると、次のとおりです。「制御の権限（authority）」はハードウェアの物理量で一意に決まるのではなく、実装に依存します。同じ「グループサイズ」というノブでも、単一GPUでは作業量に直結して権限を持つのに対し、パイプライン分割下では無力になります。権限を持つのは「パイプライン占有度（occupancy）」—すなわち同時に実行する生成の並列度—を変えるノブだけであり、それ以外は見かけ上の操作にすぎません。この洞察が、次のセクションで述べる「占有度アクチュエータ」による再構築の土台となります。

flowchart LR
    A[単一GPU 7B] -->|グループサイズ=作業量<br/>権限あり| B[電力が応答]
    C[シャーディング 14B/72B] -->|グループサイズを変えても<br/>パイプライン速度不変| D[アクチュエータ権限喪失]
    D --> E[電力が動かない<br/>ヌル結果]
    E --> F[解決策:占有度アクチュエータ]

壁を越える：占有度アクチュエータで再構築

前節で見た通り、72Bではグループサイズという「作業量」のノブがパイプライン分割（モデルを複数GPUに分割して並列実行する方式）下で権限を失いました。壁を越える鍵は「制御の権限（authority）は実装依存である」という認識にあります。つまり、何を変えれば電力が実際に動くのかを、実測のスイープで特定し直せばよいのです。

アクチュエータ権限スイープ（AWQ生成プロキシで測定）

どのノブが本当に電力を動かすのかを、量子化モデルの生成プロキシを回しながら体系的に調べたのが「アクチュエータ権限スイープ」です。結果は明確な順位を示しました。

ノブ 平均電力の変動 スループットへの影響
生成バッチサイズ（同時実行度） 22.5% 5.2倍
グループサイズ（同時実行として） 16.9% 3.3倍
完了長・一時停止 ほぼなし（権限なし） — 
flowchart LR
    A[ノブ操作] --> B{実測で電力は動くか}
    B -->|Yes| C[同時実行度/バッチサイズ<br/>22.5%変動]
    B -->|Yes 一部| D[グループサイズ<br/>16.9%変動]
    B -->|No| E[完了長・一時停止]
    B -->|No※| F[ファームウェア電力リミット<br/>※クラウドでは権限なし]

ここで重要なのは、電力への影響は「作業量の総量」ではなく「同時に実行されるワークの数（パイプライン占有度）」が決める、という点です。また、ファームウェアの電力リミットは強力なノブですが、クラウドコンテナではオペレータレベルのホストアクセスを持たないため「デプロイ境界」として測定され、利用できませんでした。

占有度コントローラのライブ実証（72B）

この知見を基に、生成バッチサイズを「占有度アクチュエータ」として用いるコントローラを再設計し、72Bでライブ実証を行いました。実験は20分間×4アーム（静的バッチ8・静的バッチ4・ヒステリシス・PPO）×3レプリケーションで実施されました。

アーム トークン出力 違反率
静的バッチ4 基準 —
PPO（占有度） +35.7% 2.27±1.08%

PPOコントローラは静的バッチ4比で35.7%多くのトークンを出力しました。違反率は2.27±1.08%で、事前に指定した1%のバーはわずかに超過したものの、制御なし（フル占有）比では違反を87.2%、超過積分を91.8%削減しました。さらに、学習の貢献は静的ルールと比べて違反削減効果が約4倍に達し、電力余裕があるときにそれを自動的にスループットへ変換できる点が、ルールベース制御との本質的な違いです。

この再構築により、単一GPUで成功した選択的制御の原則（「出力の買える瞬間」に電力予算を配分する）が、シャーディングされた大規模モデルでも成立することがライブで示されたのです。

「電力違反」とは何か——計測窓の視点が答えを変える

違反はどの時間スケールで数えるべきか

「電力上限を違反した」という結果をどう解釈するかは、その違反をどの時間の窓で数えるかに大きく左右されます。計測上の違反とは、ある時刻の電力が設定した上限（キャップ）を超えた状況を指しますが、電気インフラ側は想定する監視の時間スケールがまったく異なります。

  • 遮断器や保護リレーは数十秒単位で過負荷を判定する
  • 需要料金（demand charge）の算定は5〜15分平均の電力に基づく
  • 論文の計測ではNVMLで0.5秒間隔のサンプルを取得するため、「瞬間の違反」が非常に多く検出される

この差は実測値に如実に現れます。72B構成（4台）では、制御をまったく行わない状態でも、違反率は0.5秒窓で23.6%に達しますが、30秒平均にすると1.6%まで下がり、5分平均ではゼロになります。つまり、サブ秒の瞬間電力が上限をまたいでも、インフラが実際に課金・保護判断する窓では十分に吸収されてしまうのです。

そこで論文は違反を2つのクラスに分類します。

  • プラトー違反（plateau violation）: 数秒〜数十秒にわたり持続的に上限を超える違反。インフラの窓でも見え、真に削減すべき対象
  • トランジェント違反（transient violation）: サブ秒の瞬間的な超過。計測上は見えるが、インフラの評価窓では消えて見えなくなる

この区別によって、前節の「14B・72Bで制御が効かなかった」というヌル結果も見え方が変わります。シャーディング環境の制御が「動かなかった」のは、実は削除すべきプラトー違反がほとんど存在しない「必要とされない場面」だった可能性があります。どの違反を減らしたいのかを先に定義しないと、改善の効果も正当に評価できません。

この分析が示す実務への示唆

計測窓の分析は、電力制御を「1つの層で全部やる」のではなく、妨害の時間スケールに合わせて層を分ける設計へと導きます。論文は次の3層アーキテクチャを提案しています。

flowchart TB
    A["第1層：ジョブレベルRL制御<br/>（ステップ毎/バッチ境界）"] --> B["生成パラメータを適応"]
    C["第2層：ファームウェア電力キャップ<br/>（ミリ秒・リザーブ用）"] --> D["過渡ピークの安全弁"]
    E["第3層：フリートスケジューラ<br/>（分単位）"] --> F["電力予算配分・位相ずらし"]
  • 第1層（ジョブレベルRL制御）: 単一GPUでは学習ステップごと、シャーディング構成ではバッチ境界ごとに生成パラメータ（グループサイズ・バッチサイズ）を調整し、プラトー違反を直接抑制します。
  • 第2層（ファームウェア電力キャップ）: ミリ秒オーダーの過渡ピークを吸収する「安全弁」として機能し、リザーブ用途に残されます。ただしクラウドコンテナではホストアクセス権が必要なため適用範囲が限られます。
  • 第3層（フリートスケジューラ）: 分単位で複数ジョブへ電力予算を配分し、位相をずらすことでフリート全体のピークを平準化します。

重要なのは、どの違反をどの層で消すかを時間スケールに応じて分担することです。サブ秒の小さな違反をジョブレベルRLで無理に消そうとすると、かえってスループットを損ないます。一方、プラトー違反をフリートスケジューラに任せると反応が遅すぎます。このように「計測窓」を起点に役割を分けることで、各層は自分の得意な時間スケールに集中でき、全体として電力を効率的に制御できます。これは単体GPUの成果だけを見るのではなく、実運用での電力管理を設計するうえで欠かせない視点です。

フリート規模の試算：名目電力の「2倍オーバーサブスクリプション」

16GPU構成フリートでの計測（6.4kW名目）

ここまでの成果は単一GPUや少数GPU単位の話でしたが、実際のデータセンターが気にするのは複数ジョブを同時に動かす「フリート全体」の需要です。論文は16GPU（名目電力計6.4kW）の混合構成フリートを想定し、実測トレースを重ね合わせてピーク需要を評価しています。構成は72B×2（各4台）、14B×2（各2台）、7B×4（各1台）で、それぞれ前節までの電力特性が異なる「異質な負荷」が同居する状況です。

ここでのポイントは、単一ジョブの挙動をモデル化して予測するのではなく、実際の計測トレースをそのまま重ね合わせて評価している点です。理論曲線や平均値ではなく、実測の時間波形を合成することで「現実に近い」ピーク需要が得られます。その結果、フリートの30秒ピーク需要は名目電力のおおよそ50%（論文では45〜50%の保守的バウンドとして報告）にとどまりました。つまり、複数の独立したジョブの電力ピークが時間的に分散する「統計的多重化（多様性原理）」により、個々の名目電力の合計よりもはるかに低い容量で済むことが計測上示されたのです。

この「名目電力の約半分の容量で足りる」状態を、購入容量の観点で言い換えるのがタイトルにもある**オーバーサブスクリプション（oversubscription）**です。これは物理的に存在する電力容量を超えて契約・予約できる仕組みを指し、ここでは「名目電力の約2倍を同じ容量で賄う」ことを意味します。位相ずらし（ジョブの開始タイミングをずらして同時ピークを避ける）やジョブレベル制御を組み合わせることで、統計的多重化だけでは残るピークの山をさらに平準化できると論じています。

経済・炭素・グリッド統合への含意

この「2倍オーバーサブスクリプション」が実運用で成立すれば、経済的・環境的な含意は大きくなります。データセンターの設備投資は「確保する容量」に比例するため、ピーク需要を半分に抑えられるということは、同じ計算能力に対して購入すべき容量を半減できることを意味します。論文は100MW規模の施設を例に、約2億ドルの設備投資を回避し、数年の系統連系待ちを短縮できると試算しています。

さらに、ニューヨーク州の複数GW級の計画を対象にした試算では、約2,300MWの建設回避、約92億ドルのコスト削減、年間約2.9TWh・235Mドル・約733,000トンCO₂（約159,000台の乗用車の年間排出に相当）の削減につながるとしています。電力インフラのボトルネック解消に加えて、訓練ジョブが「ディスパッチ可能な負荷（dispatchable resource）」—電力系統の指示に応じて消費を調整できる負荷—になれば、既存の米国グリッドで約100GWの追加需要を吸収できるとする研究の実証的補強にもなります。

flowchart LR
    A["混合フリート計測<br/>（16GPU / 6.4kW名目）"] --> B["ピーク需要 ≈ 名目50%"]
    B --> C["約2倍オーバーサブスクリプション"]
    C --> D["設備投資削減・連系待ち短縮"]
    C --> E["グリッドの需要吸収力向上"]

重要な留保は、この50%という比率が実際のフリート運用での計測ではなく、実測トレースの合成から得られたものだという点です。個々のジョブの孤立したピークが本当に重ならず分散してくれるかは、ジョブ数・実行タイミング・スケジューラの設計に依存します。そのため論文は、オペレータによる実証パイロット（30〜60日、約5万ドル規模）を次のステップとして位置づけ、「30%以上のプロビジョニング削減かつ30秒窓でゼロ違反」を成功基準に提案しています。この試算は有望な上限像を示すものであり、実運用での裏付けをもって初めて確定する「仮説」として扱うのが適切です。

技術的注意点と限界

これまで見た結果は魅力的に映りますが、実運用に持ち込む前に「どこまでが計測された事実で、どこが推定なのか」を正確に切り分けておく必要があります。本研究は単一GPUのライブ制御とフリート規模の経済試算を一つの論文で扱っているため、結果それぞれの実証レベルが異なる点に注意が必要です。

各結果の「実証レベル」を整理する

手法は複数の段階で検証されていますが、その粒度は結果ごとに大きく異なります。まず占有度コントローラ（72Bにおけるパイプライン分割下の同時実行度ノブに基づく制御）は、AWQ量子化された生成プロキシ上で検証されており、BF16で走る本来のGRPO訓練ループそのものではありません。つまり「生成の電力挙動」を代表する代理環境での評価であり、実訓練時の正確な再現は保証されていません。

次に、最も派手なヘッドライン数値である7Bでの「違反89.8%減・出力18.1%増」は、実測トレースに対するオフライン評価（シミュレーション）の結果であり、実際にGPUを回しながらのライブ実証ではありません。対して72Bのライブ実証では、事前に指定した1%の違反バーを達成できず、実際の違反率は2.27±1.08%に留まりました。つまり「単一GPUの破格の改善」と「マルチGPUの実システム」の間に、検証方法のギャップがあります。

さらに、フリート規模の「30秒ピーク需要が名目電力の約半分」という50%プロビジョニング比は、実測トレースを重ね合わせた合成から導かれており、実運用フリートでの計測結果ではありません。統計的多重化の恩恵がこの比率の大部分を占めるため、ジョブの同時性やバッチ境界の揃い方によって数字は左右されます。

学習そのものの安定性に関する限界

制御器の学習には3種類のランダムシード（乱数初期値）が試されており、そのうちただ1つだけが検証基準を通過しました。これは強化学習方策（policy）の再現性が限定的であることを意味し、同じ設定を再実行しても同等の性能が得られる保証がありません。実装上の制約として、この制御はラップトップのCPUで約10分で学習可能と軽量ですが、その分シード依存の分散も無視できません。

実運用への検証パス

著者らはこれらの限界を踏まえ、実際のデータセンターで使うための具体的な検証計画を提示しています。それが、約5万ドルの計測パイロットを30〜60日間実施し、30%以上のプロビジョニング削減かつ30秒窓でゼロ違反を成功基準とする計画です。この条件は、合成で導かれた50%削減から安全側に引き下げた保守的な目標であり、理念上のオーバーサブスクリプションを実現場で裏付けるための実証となります。

flowchart TD
    A[7Bヘッドライン<br/>オフライン実測トレース評価] -->|検証レベル高い| B[単一GPUの改善]
    C[72B占有度コントローラ<br/>AWQ生成プロキシ + ライブ実証] -->|1%バー未達 2.27%| D[マルチGPUの実システム]
    E[フリート50%比率<br/>実トレース合成] -->|実運用計測ではない| F[経済試算の前提]
    G[30-60日パイロット<br/>30%削減・30秒窓ゼロ違反] -->|次の検証ステップ| H[実運用適用]

この節のまとめ

要約すると、本手法は「計測された事実（7Bのオフライン改善、72Bのライブ実証、アクチュエータ権限の傾向）」と「推定値（フリート規模の50%プロビジョニング、大規模な経済・炭素削減）」を明確に分離して解釈すべきです。特に、シード依存の学習安定性とAWQプロキシ上の検証という二つの制約は、そのまま実装に持ち込む際のリスク要因となります。導入を判断する際は、提示された30〜60日の計測パイロットを自環境で再現し、自分の負荷パターンで違反率とプロビジョニング削減を確認するのが現実的な第一歩となります。

よくある質問

この手法は既存のインフラでそのまま使えますか？

はい、根本のところではソフトウェアのみで動作するため、既存ハードウェアにそのままデプロイできます。制御の主体はGPUのワークロード自体（グループサイズやバッチサイズ）を動かすメタ・コントローラで、OSやハイパーバイザーを交換する必要はありません。ただし例外があり、ファームウェアの電力キャップ（ミリ秒単位のハードウェア制限）を使う層はオペレータレベルのホストアクセスを要求するため、クラウドインスタンスのようにデバイス権限が制限された環境では利用できません。導入時の現実的な判断としては、まず「ワークロード側の制御」でどこまで削れるかを試し、権限のある環境でだけファームウェア層を併用するのが安全です。

強化学習で「電力」を制御するのと、従来の電力キャップは何が違うのですか？

大きな違いは「いつ抑制するか」を選べる点です。従来の静的キャップは全時間・全フェーズを一律に制限するため、実は出力が高く売れる（＝推論価値が高い）瞬間まで無差別に遅くしてしまいます。本研究の強化学習コントローラは電力予算を「出力が最も稼げる瞬間」に集中配分する選択的制御で、同じ電力上限の下でも違反を減らしつつトークン出力まで増えます。単一GPUの計測では、電力上限違反が89.8%減った一方で出力は18.1%増えており、「抑えながらも稼ぐ」ことを両立できた証拠といえます。

なぜ72Bでは最初うまくいかなかったのですか？

理由は「アクチュエータ権限」の喪失です。複数GPUへシャーディング（分割）すると、グループサイズを変えても実行速度＝電力がほとんど動かず、制御のノブとして機能しなくなりました。計測では制御は実際に動いていた（グループサイズが5→6→5→4→3→2と変化）のに、72Bの平均電力は制御前後で同一でした。明らかになったのは、パイプライン分割下で電力の揺らぎは0.5秒オーダーなのに対し制御ループは学習ステップごとに約55秒かかるという時間的なズレです。そこで「同時実行度（占有度）」という別のアクチュエータに切り替え、生成バッチサイズを操作することで電力が22.5%動くことを確認し、壁を越えました。

本当にデータセンターの電力を半分にできるのですか？

正確には「消費電力」ではなく「購入する容量（プロビジョニング）」を削減する話です。16GPU構成の混合フリート（6.4kW名目）に実際のトレースを重ね合わせた計測では、30秒ピーク需要は名目電力の約50%でした。これは各ジョブのピークが重ならない「統計的多重化」が主な要因で、位相ずらしやジョブレベル制御でさらに下げられます。ただしこの50%は実運用フリートの計測ではなく合成評価であり、次のステップとして約5万ドルの30〜60日パイロットで「30%以上のプロビジョニング削減かつ30秒窓でゼロ違反」を成功基準に検証することが計画されています。

学習自体の品質（モデル性能）は落ちませんか？

ここが本研究で最も慎重に扱われた点です。強化学習（GRPO）ではグループサイズを小さくするほど、グループ内の報酬分散から学習信号を推定する精度が崩れ、モデル性能が劣化します。そこで本研究はこの崩壊が起きる閾値を実測し、「グループサイズは最低3」というハードな下限をコントローラの行動空間に設定しました。つまり性能保護は報酬にペナルティを足す間接的な仕組みではなく、行動空間から外す構造的な制約として実装されており、制御が学習信号そのものを壊さないことを保証しています。

まとめ：測って、制御して、初めて「スケジュール可能な負荷」になる

強化学習ポストトレーニングは、これまでその正体が明らかにされてこなかった電力構造を持っていました。本稿で紹介した一連の計測は、GRPO型の学習ワークロードが「計測可能」であり「制御可能」であることを、7B・14B・72Bの3規模、総計38万以上の半秒サンプルから初めて示しました。電力値をキャップ相対に正規化した状態設計により、単一の方策が異なる規模のハードウェアへ転移する点も、測定ベースのアプローチだからこそ得られた知見です。

単一GPUでは成果は明確でした。電力上限違反を89.8%削減し、トークン出力は18.1%増加、エネルギー効率は26.2%改善しました。「出力が上がって電力も下がる」という結果は、全体を一律に抑制する静的キャップではなく、電力予算を最も出力効果の高い瞬間に配分する選択的制御の効果を裏付けます。一方、シャーディングされたマルチGPUでは、グループサイズというアクチュエータが権限を失い、いったん壁に突き当たりました。ですが、パイプライン占有度という別のノブへ制御対象を切り替えることで、72Bのライブ実証では静的バッチ比で35.7%多くのトークンを生成しつつ違反を抑えることに成功しました。

そしてフリート規模の試算は最も示唆に富みます。16GPU・6.4kW名目の混合構成で、実トレースの重ね合わせによる30秒ピーク需要は名目電力の約半分でした。つまり、名目電力の約2倍のオーバーサブスクリプションが計測上成立します。これは電力消費そのものの削減ではなく「購入する容量」の削減であり、100MW施設で約2億ドルの設備投資回避につながります。測って構造を理解し、制御して負荷を柔軟にしたとき、AI訓練は「グリッドが恐れる非柔軟な負荷」ではなく、提供される大負荷の中でも最もスケジュール可能な資源の一つになります。次のステップは、約5万ドルの30〜60日パイロットで、30%以上のプロビジョニング削減と30秒窓でのゼロ違反を実運用として検証することです。

参考資料

関連記事