RTX PRO 6000 Blackwell サーバーエディション 4GPUマシンでパワーリミットを落とすと、性能・電力・ファン回転数はどう変わるか

これまでは TDP 300W クラスの GPU（A100 や RTX 6000 Ada など）が「高性能 GPU」の代表でしたが、H200 NVL や RTX PRO 6000 Blackwell サーバーエディション 96GB 600W のように、TDP 600W 級の GPU がいよいよ現実的な選択肢になってきました。

Blackwell 世代では、TDP だけでなく GPU メモリ容量も 48GB → 96GB クラスへと一気に倍増 しており、「電力・発熱」と「メモリを使い切るような LLM 学習」をどう両立させるかが現場のテーマになりつつあります。

一方で、ここまで TDP が上がると、「消費電力」と「ファン騒音」 が一気に現実的な問題として立ち上がってきます。実際に当社でも、RTX PRO 6000 Blackwell サーバーエディション 4GPU マシンや H200 NVL 4GPU マシンをお客様に納品したところ、

• 「性能は素晴らしいけれど、全力で回すとファンの音がかなり気になる」
• 「ラック全体の電力枠が厳しく、電力をもう少し抑えたい」

といったご相談をいただくことが増えてきました。

そこで今回は、RTX PRO 6000 Blackwell サーバーエディション 96GB 600W を 4枚搭載したサーバーで、パワーリミットを 600W → 500W → 400W → 300W と段階的に落としていったときに、

• 学習性能（tokens/s）
• サーバー全体の消費電力
• GPU 温度
• GPU メモリ使用量
• ファン回転数（騒音の proxy）

がどのように変化するのかを計測しました。この記事では、その結果と簡単な考察を共有します。なお、ここで使用している GPU は RTX PRO 6000 Blackwell サーバーエディション 96GB 600W であり、RTX 6000 Ada などとは別物ですのでご注意ください。

テスト環境

ハードウェア構成

サーバーの構成は以下の通りです。

• シャーシ: Supermicro SYS-322GA-NR クラス 4GPU サーバー
• GPU: NVIDIA RTX PRO 6000 Blackwell Server Edition 96GB 600W × 4（パッシブ冷却）
• CPU: Intel Xeon 6944P × 2（合計 144 コア構成）
• メモリ: DDR5-6400 RDIMM 32GB × 16 = 512GB クラス
• ストレージ: KIOXIA NVMe SSD 7.68TB / 1.92TB 構成
• 電源: 冗長 PSU（3 系統）

GPU のパワーリミットは nvidia-smi -pl 経由で変更し、サーバー全体の消費電力は ipmitool dcmi power reading により取得しています。ファン回転数は ipmitool sdr type fan の出力を 1 秒ごとに記録しました。

ソフトウェア構成

• OS: Ubuntu Linux 24.04.3 LTS
• NVIDIA ドライバ: 580.105.08（nvidia-smi 上の表示では CUDA Version 13.0）
• Python: 3.11 系（conda 環境）
• PyTorch: 2.9.1 + CUDA 12.8（cu128 ビルド）
• 分散学習: torchrun + DistributedDataParallel (DDP)
• 計測ツール: nvidia-smi, ipmitool, pandas, matplotlib など

PyTorch 本体は、NVIDIA ドライバが対応している範囲で PyTorch 2.9.1 + cu128（CUDA 12.8 対応版） を pip からインストールしています。ドライバ側は「CUDA 13.0 対応」ですが、ユーザー空間の PyTorch / CUDA ランタイムとしては cu128 ビルドを利用しているイメージです。

ベンチマーク条件

ワークロード概要

テストには、PyTorch の Transformer をベースにした学習ベンチマークを使用しました。実際の文章データの代わりにランダムなトークン列を使い、モデルサイズとメモリ使用量、通信パターンが実際の LLM 学習に近くなるように設計しています。

• モデル: GPT 系 Transformer（約 2.6 億パラメータ）
• シーケンス長: 1280 tokens
• グローバルバッチサイズ: 256（4GPU なので GPU あたり 64）
• 精度: FP16（AMP + GradScaler）
• 分散: 4GPU のデータ並列（DDP）

学習スクリプトは、一定イテレーションごとに

• 現在のイテレーション数
• 損失（loss）
• 1秒あたりの処理トークン数（tokens/s）

をログ出力するようにしてあり、後述の Python スクリプトでログをパースして 平均 tokens/s を算出しています。

GPU メモリ使用量について

RTX PRO 6000 Blackwell サーバーエディションは、公称 96GB の GPU メモリを搭載しています（nvidia-smi では約 95.6GiB として表示されます）。今回は「96GB をほぼフルに使う LLM 学習負荷」を想定し、シーケンス長やバッチサイズを調整しています。

実際に、パワーリミットスイープ中に nvidia-smi のメモリ使用量を 1 秒ごとにサンプリングし、各ステップ 10 分間の平均値を計算すると、以下のようになりました。

見ての通り、どのパワーリミットでも各 GPU が約 93GiB（約 97%）のメモリを使っており、「メモリがスカスカなので電力が下がっている」という状況ではありません。Blackwell 96GB カードのメモリをほぼ使い切った状態で、パワーリミットだけを変えたときの挙動を見ている、というのが今回のポイントです。

パワーリミット・スイープ方法

パワーリミットを変えながら連続測定するために、以下のようなフローでスクリプトを組んでいます。

1. 学習スクリプトを 1 回だけ起動し、4GPU すべてに負荷をかけ続ける
2. 別プロセスの Python スクリプトから、nvidia-smi -pl を使って GPU のパワーリミットを 600 → 500 → 400 → 300 W と段階的に変更
3. 各ステップあたり 10 分間（600 秒） 計測
4. その間、1 秒おきに
   • GPU 利用率 / 温度 / メモリ使用量 / GPU 電力（NVML）
   • サーバー全体の電力（ipmitool dcmi power reading）
   • ファン回転数（ipmitool sdr type fan）
   を CSV に記録
5. 最後に学習プロセスを丁寧に停止し、全ステップのログを集計

この方式により、学習ジョブは一度も止めずにパワーリミットだけを変えたときの挙動を観察できます。

結果サマリ

パワーリミットごとの性能と電力

まずは、パワーリミットごとの tokens/s とサーバー全体の電力、および効率を整理した表です。

ポイントを箇条書きにすると、以下のようになります。

• 600W → 300W に下げると、性能は約 78% まで低下する（約 22% ダウン）。
• しかしサーバー全体の電力は 約 57% まで下がり、約 43% の省電力。
• tokens/s をサーバー電力で割った「1W あたり性能」は、400W 設定で約 1.4 倍（141.5%） と最大になる。
• 300W まで下げると電力はさらに減るものの、性能も大きく落ちるため、1W あたり性能は 400W よりやや悪化する（それでも 600W 比 136%）。

GPU 温度と GPU 電力・使用率

600W では GPU 温度が 66℃ 前後まで上がりますが、300W まで落とすと約 55℃ で頭打ちになり、だいぶ余裕が出てきます。いずれの設定でも GPU 使用率は ほぼ 99% で張り付き になっています。この理由は後半で説明します。

ファン回転数（騒音の proxy）

ipmitool sdr type fan の結果から、Front Fan / Rear Fan の RPM を 1 秒ごとに記録し、10 分間の平均値をまとめたものが以下です。BMC の仕様により絶対値は「ファン群の合計値」またはスケール済みの値になっている可能性がありますが、パワーリミット間の相対比較として見てください。

600W から 300W に下げると、全ファン平均でおおよそ 6〜7割程度の回転数 まで落ちています。騒音の体感は環境や耳にもよりますが、「600W 全開だとかなりうるさいが、300〜400W 辺りまで下げるとだいぶマイルドになる」という印象でした。

そもそもパワーリミットとは何をしているのか？

今回の検証で使っているのは、RTX PRO 6000 Blackwell サーバーエディション（TDP 600W・パッシブ冷却）です。カード自体にはファンは付いておらず、サーバー筐体側のフロントファンが GPU ヒートシンクに風を当てて冷やす構造になっています。

では NVML（nvidia-smi）で設定する「パワーリミット」は、内部で何をしているのでしょうか。ざっくり言うと「GPUボード全体として消費してよい電力の上限値」を決めておき、その上限に近づいてきたら GPUコアの動作クロックや電圧を自動的に下げる、という制御をしています。

• 上限が 600W のときは、可能な範囲でクロックを高く維持しようとする（＝性能が最大化される）
• 上限を 300W まで下げると、その範囲に収まるようにクロック・電圧を抑える（＝性能は落ちるが消費電力と発熱が減る）

重要なのは、パワーリミットは「GPU を遅くするブレーキ」であって、ファンを直接いじっているわけではないという点です。GPU の発熱が減る → 温度が下がる → それを見た BMC が筐体ファンの回転数を下げる、という間接的な結果としてファンが静かになるわけですね。

なぜ GPU 使用率はどのパワーリミットでも 99% なのか？

今回のログを確認すると、パワーリミットを 600W / 500W / 400W / 300W のどこに設定しても、GPU 使用率は常に 99% 前後で張り付いていました。

これは「GPU が常に仕事でいっぱいになっていて、CPU や I/O がボトルネックになっていない」ことを意味します。電力を絞るとクロックや電圧が下がるため、1秒あたりに処理できるトークン数は減りますが、「GPU の中で空き時間が増える」のではなく、「フル稼働のまま、クロックが落ちて処理速度だけが落ちる」という挙動になります。

そのため、GPU 使用率の観点ではどのパワーリミットでも 99% 付近のままで、性能差は tokens/s（1秒あたりのトークン数）の違いとして現れます。加えて、先ほどの表の通り、どの設定でも GPU メモリは約 93GiB 使われており、「VRAM の使用率が低いから電力が下がっている」というわけでもありません。

再現用スクリプトと GitHub リポジトリ

今回のベンチマークで使用した Python スクリプト一式（パワーリミットスイープ、DDP Transformer 学習、ログプロットなど）は、以下の GitHub リポジトリで公開しています。

• kenhanabusa/blackwell-power-limit-bench

README に、ハードウェア構成・ソフトウェア構成・実行手順（conda 環境の作成、run_power_sweep.sh の実行方法など）をまとめてありますので、ご自身の Blackwell / H200 NVL 環境などで同様の検証を行う際の参考にしていただければと思います。

結果の読み解きと実用上のおすすめ

1. 600W: とにかく性能が欲しいとき

• tokens/s は今回の中で最大（基準 100%）。
• GPU 温度は 66℃ 前後、サーバー全体の電力は約 3.4kW。
• ファン回転数・騒音ともに今回の設定の中では最大。

「学習をとにかく早く終わらせたい」「ベンチマークで数字を出したい」といった用途では 600W 一択ですが、電力枠や騒音に厳しい環境では常用しにくい設定でもあります。

2. 500W: 性能をほぼ維持しつつ、電力と騒音を軽くしたいとき

• 性能は 600W 比で約 97.7% と、ほぼ同等。
• サーバー電力は 約 13% 減。
• ファン回転数も一段階下がり、騒音も少しマイルドに。

ラック電力に若干の余裕を作りたい、オフィス内の検証環境で少し静かにしたい、といった場合にはかなりバランスの良い設定と感じました。「性能は落としたくないけれど、さすがに 600W 全開は…」というときの第一候補です。

3. 400W: 電力効率重視のスイートスポット

• 性能は 600W 比で約 91.2%。
• サーバー電力は 約 64.5% まで低下（約 35% 削減）。
• 1W あたり性能は 約 1.4 倍 と今回の最良値。
• ファン回転数も目に見えて下がり、騒音もかなり抑えられる。

電力コストやデータセンターの電力枠を意識するのであれば、400W は非常に美味しいポイントです。600W の 9割強の性能を維持しながら、サーバー全体の電力を大きく削れるので、長時間学習ジョブでの「電気代あたりの仕事量」を最大化したい用途に向いています。

4. 300W: とにかく静か＆省電力にしたいとき

• 性能は 600W 比で約 78% まで低下。
• サーバー電力は 約 57% まで低下。
• 1W あたり性能は 600W 比で 136% と、依然として高効率。
• ファン回転数は 600W 時の 6〜7割程度まで下がり、騒音もかなりマイルド。

静かなオフィスで、GPU サーバーを「人間が隣で作業しながら」回したいような場面では、300W まで下げるとかなり扱いやすくなります。ただし、性能は 400W と比べてもさらに落ちるので、本番学習ジョブというよりは 開発・検証環境向け と考えるのが良さそうです。

今回の実験の前提と注意点

• ワークロードは Transformer 学習（seq_len 1280, batch 256, FP16） に固定しており、推論系ワークロードや別のモデルではスケーリングが変わる可能性があります。
• パワーリミットの違いによる比較を明確にするため、各パワーリミットでの GPU メモリ使用量はほぼ同一（約 93GiB / 96GB ≒ 97%）になるように設定しています。
• ファン RPM は BMC の仕様上、絶対値が「ファン群の合計値」またはスケール済み値になっている可能性があり、今回は相対比較を重視しています。
• サーバー電力は ipmitool dcmi power reading の平均値で、PSU 損失やほかのコンポーネントも含んだ「サーバー筐体全体の電力」です。

とはいえ、同一環境でパワーリミットだけを変えたときの挙動としては、かなり素直で再現性のある結果になっていると感じています。

まとめ

• RTX PRO 6000 Blackwell サーバーエディション 4GPU マシンで、パワーリミットを 600W → 300W まで下げながら学習ベンチマークを実行し、性能・電力・GPU メモリ使用量・ファン回転数 を計測しました。
• 600W → 300W にすると性能は約 78% まで落ちるものの、サーバー全体の電力は約 57% まで低下し、1W あたり性能は依然として高い値を保ちます。
• 電力効率の観点では 400W 付近がスイートスポット で、600W の約 9割強の性能を維持しつつ、電力を大きく削減できます。
• ファン回転数もパワーリミットに応じて段階的に下がり、特に 300〜400W にすると騒音面でかなり扱いやすくなります。
• GPU 使用率がどの設定でも 99% 付近で張り付いているのは、「常に GPU がボトルネックで、電力制御によりクロックが変わっているだけ」という状態であることの反映です。また、どの設定でも VRAM を約 93GiB まで使っており、「メモリ使用量の差」で結果がブレているわけではありません。

今回使用したスクリプトや再現手順は、すでに GitHub リポジトリ（kenhanabusa/blackwell-power-limit-bench）で公開しています。今後は、実際に取得した生ログや、より細かいチューニング情報なども整理して追記していく予定です。ご自身の RTX PRO 6000 Blackwell / H200 NVL 環境などで同じ検証を試していただければと思います。