
エネルギー効率:AIワークロードにおけるCPU vs GPU
学習、推論、動画AIにわたってCPUとGPUのタスクあたりエネルギーを比較し、ワークロード、バッチサイズ、稼働率でハードウェアを選ぶ。
手短な答えはこうです。GPU は通常、学習と大量推論で使うエネルギーが少なく、CPU は小さいモデル、バッチサイズ1、バースト的なトラフィックで使うエネルギーが少なくなりえます。 ピークワット数だけを見ると、要点を見逃すことがあります。重要なのは 完了タスクあたりのエネルギー です。
この記事を、まず知っておくべき必須のAIコストのヒントに絞り込むなら、私はこう表現します。
-
学習: GPU は並列計算をビジー状態に保つため、通常は有利です。
-
推論: リクエストが1件ずつ来る場合、CPU の方が適していることがあります。
-
動画AI: ボトルネックはしばしばモデルではなく デコードと前処理 です。
-
アイドル電力が重要: 約 $0.22/kWh では、アイドル状態のシステムでもコストが積み上がります。
-
稼働率がすべてを変える: CPU を待っている GPU は、急速に電力を浪費しえます。
いくつかの数字がそれを明確にします。
-
あるテストセットで、GPU 電力は使用状況に応じて 33 W から 199 W に変動しました。
-
同じケースでの CPU 電力は 12 W から 14 W 付近に留まりました。
-
ARM Cortex-A78AE は ResNet50v1.5 を 102 ms で、2.58 J を使って実行しました。
-
RTX 4060 Ti を備えた GPU システムは 41 W でアイドルし、Mac mini M4 は 7.8 W でアイドルしました。
-
あるビジョンテストでは、A100 が 46.7 kJ を使ったのに対し、CPU のみの Xeon ノードは 213.5 kJ を使いました。

CPU vs GPU | Why AI Data Centers Use GPUs Instead of CPUs
クイック比較
| 領域 | CPU | GPU |
|---|---|---|
| 学習効率 | 通常は劣る | 通常は優れる |
| バッチサイズ1の推論 | 強いことがある | 転送オーバーヘッドでしばしば損なわれる |
| 小さいモデル | しばしば好適 | 使いこなせないことがある |
| 大きいモデル / 高スループット | しばしば劣る | 通常は優れる |
| アイドル電力 | 低い | 高い |
| 動画の前処理 | しばしば処理できる | うまく供給されないと待機しがち |
| 判断に最適な指標 | タスク、フレーム、トークンあたりのジュール | タスク、フレーム、トークンあたりのジュール |
ですからハードウェアを選ぶなら、私はシンプルに保ちます。チップを、モデルだけでなく、トラフィックパターン、バッチサイズ、パイプライン全体に合わせる。 それがこの記事の要点です。
AIシステムにおけるCPUとGPUの電力プロファイル
これらのベンチマークの数字は、各プロセッサが実際にどこで電力を消費するか を示します。CPU と GPU はワットの使い方が同じではなく、AI ジョブは作業がどこで起こるかによって、一方に強く傾くことがあります。GPU はストリーミングマルチプロセッサで並列タスクを処理し、CPU の電力はコア負荷とともに動く傾向があります。だからこそ 同じ ワークロードでも、各チップで非常に異なる電力消費になりえます [6]。
アーキテクチャがワット、稼働率、スループットに与える影響
ここでの大きな要因は 稼働率 です。
GPU 中心のワークロードでは、GPU 電力は SM 稼働率に応じて 33 W から 199 W に跳ね上がることがある一方、CPU 電力は 12 W から 14 W 付近ではるかに安定しています [6]。この幅は、GPU 稼働率の変化が同じタスクで 3〜5倍のエネルギー使用の差 につながりうる理由を説明する助けになります [8]。
推論中にも似た分岐が見られます。計算律速のフェーズは、より高い GPU 周波数から恩恵を受ける傾向があります。メモリ律速のフェーズは異なります。周波数を高くしてもあまり効果がありません。そうしたフェーズでは、周波数を下げると、レイテンシへの影響をほとんど与えずにエネルギー使用を削減できます [7]。
AI実行中にシステム電力がどこへ行くか
GPU 中心のワークロードでは、GPU が通常、システム電力消費の主な源です。CPU 電力は、データローディングのパイプラインがボトルネックにならない限り、しばしばかなり平坦なままです。CPU が前処理済みデータを GPU に十分速く供給できないと、SM 稼働率が落ちます。そしてそれは、GPU が依然として電力を消費していても、エネルギー効率を損ないます [6]。
対照的に DRAM のフットプリントは、プロセッサ稼働率に比べて総システム電力のわずかな割合しか加えません [6]。
以下の表は、これらの研究で報告された測定範囲と稼働率への感度を要約したものです [6][7]。
| ワークロードのタイプ | 主な電力ドライバー | 測定された電力範囲 | 周波数への反応 |
|---|---|---|---|
| GPU 支配 | SM 稼働率 | 33 W – 199 W | 高(計算律速)/ 低(メモリ律速) |
| CPU 支配 | CPU コア稼働率 | 10 W – 33 W | 高 |
動画 AI のパイプラインでは、その分岐はしばしば CPU 前処理 と GPU モデル実行 の間を行き来します。これが最も重要なのは動画ワークフローで、前処理と推論がボトルネックを CPU から GPU へ、あるいはその逆へと移すことがあります。
研究の知見:CPUとGPUのどちらがより効率的にエネルギーを使うか
ベンチマークは、CPU と GPU の差がジョブに基づいて変化することを示します。学習、推論、バッチサイズ、ハードウェアの使用がすべて重要です。動画パイプラインでは、フレームの移動と前処理が主要なボトルネックになりうるため、このシフトはさらに際立ちます。
学習ワークロード:GPUは通常、学習ステップあたりのエネルギーで先行する
大規模なニューラルネットワークの学習では、GPU は通常、学習ステップあたりのエネルギーで勝ちます [4]。それは理にかなっています。学習は多くの並列計算を同時にビジー状態に保ち、それこそ GPU が輝く傾向のある領域です。
ネイティブの FP8 サポートを備えた現代の GPU は、この種の作業で FP16 より約 1.9倍効率的 です [1]。そしてハードウェアがすべてではありません。ソフトウェアのチューニングだけで、ハードウェアが同じままでもエネルギー効率を 15〜30% シフトさせられます [1]。ですから2つのチームが同じマシンで同じモデルを実行しても、かなり異なる電力プロファイルを見ることがあります。
推論ワークロード:CPUは低バッチサイズで競争できる
GPU は、スループットが高くバッチサイズが大きいときにリードします。しかしその優位は、バッチサイズが小さくハードウェアの使用が落ちると、縮まり、消えることさえあります [5]。
10億パラメータ未満 のモデルでは、INT8 量子化を用いた CPU 推論は通常 10〜50 ms の範囲に収まり、ホストからデバイスへの転送オーバーヘッドを含めても、バッチサイズ1では GPU と競争できます。そのオーバーヘッドは通常 0.5〜2 ms です [5]。平たく言えば、一度に1件のリクエストしか処理していないなら、GPU の速さの一部はデータを移動させるだけで食われてしまいます。
良い例が ARM Cortex-A78AE CPU で、ResNet50v1.5 の推論を 102 ms で、平均 25.3 W の消費で 2.58 J だけ使って実行しました [2]。これは、システムが常時重い負荷にさらされていない、エッジデプロイやバースト的で低同時実行のサービングにしっかり合います。
主要なベンチマーク:
| ワークロードのタイプ | ハードウェア構成 | スループット/レイテンシ指標 | 平均電力消費 | 推論/タスクあたりのエネルギー |
|---|---|---|---|---|
| CNN 推論(ResNet50v1.5) | ARM Cortex-A78AE CPU | 102 ms レイテンシ | 25.3 W | 2.58 J [2] |
| LLM 推論(7B、Batch 32) | NVIDIA H100(FP8) | 6.00 Tokens/J | 記載なし | 約 0.167 J/Token [1] |
| LLM デコードフェーズ(1B–32B) | NVIDIA RTX PRO 6000(DVFS) | 1〜6% のレイテンシ増加 | 180 MHz(最低周波数) | 42% のエネルギー削減 [7] |
もう一つの知見が目を引きます。LLM クエリの 44.5% は「常に簡単」 であり、意味のある品質低下なしに、より小さい 1B〜3B パラメータのモデルで処理できます [7]。同じ考え方は動画 AI にも引き継がれます。すべてのフレームが最大のモデルや最も重いパスを必要とするわけではありません。より賢い手は、より単純なフレーム、前処理ステップ、あるいは軽いシーンを、より小さいセットアップにルーティングすることであることもあります。
動画AI処理:フレームあたりのエネルギー、パイプラインのボトルネック、モデルインフラ
なぜ動画ワークロードがCPU vs GPUのエネルギー方程式を変えるのか
動画パイプラインは、CPU vs GPU のトレードオフをはるかに鋭くします。デコード、前処理、推論はそれぞれ異なるハードウェアで実行できるため、同じモデルでも作業がどこに落ちるかによって、非常に異なる電力使用になりえます。モーション検出や基本的な分類のような軽量ジョブは、CPU 向けにチューニングされたモデルで今やより実現可能になっている一方、深いシーン理解やマルチモーダル分析のようなより重い作業は、依然として GPU に傾いています [10]。
これには単純な理由があります。GPU はピーク時により多くの電力を消費できますが、しばしば仕事をはるかに速く終わらせます。そしてそうなると、その瞬間のワット数が高く見えても、フレームあたりの総ジュールは下がりえます [6][9]。
VGG-19 のベンチマークがこれを分かりやすくします。一般的なビジョンテストでは、CPU のみの Intel Xeon ノードが推論に 213.5 kJ を使いました。NVIDIA A100 GPU は同じジョブに 46.7 kJ を使いました。これは約 4.5倍 の差です [9]。しかしその優位は、前処理が GPU を待機状態に放置すると急速に縮まります。
これがパイプラインのボトルネックにとって意味すること
実際には、モデルがしばしば主なボトルネックではなくなります。データパイプラインがその座を引き継ぎます。
CPU 側の前処理とデータローディングは、GPU 中心のセットアップでよくあるボトルネックです。CPU が GPU に十分速く供給できないと、GPU の SM 稼働率は約 89% から 50% に落ちることがあります [6][9]。そしてつらいのはここです。ハードウェアは待っている間も電力を消費します。CPU-GPU システムのアイドル状態の NVIDIA A100 は、依然として約 55 W を使い続けます [6][9]。
YOLO のワークロードも同じパターンを示します。GPU 電力は 33 W から 199 W に振れることがある一方、CPU の消費は 12 W から 14 W 付近に留まります [6]。ですから CPU 電力が平坦に見えても、それがライン全体を遅らせる要因になりえます。
これがマルチモデル動画APIにとって意味すること
マルチモデル動画 API にとって、アイドル状態のアクセラレータ容量は単なる性能問題ではありません。エネルギー問題でもあります。CPU-GPU システムでは、使われていないアクセラレータのハードウェアが、総エネルギー使用を CPU のみのノードの 1.7倍 まで押し上げることがあります [9]。
APIMart にとってのすっきりした手は、デコード、前処理、オーケストレーションを CPU パスに保ち、それから GPU を生成と深い分析に使うことです。その分割は、有用な作業をしていないアクセラレータの時間に電力を燃やすのを避けるのに役立ちます。
結論:CPU vs GPUのエネルギー効率における主なパターン
レビューした研究からの重要ポイント
レビューした研究全体で、AI と動画パイプラインの両方で同じパターンが現れます。効率は、ピーク電力消費ではなく、完了した作業に関するもの です。重要なのは、ピークワット数ではなく、完了タスクあたりのエネルギーです。
GPU が抜きん出るのは、ワークロードと稼働率がその電力使用を見合うものにするときだけです。学習や大バッチ推論のような並列で大量のジョブでは、GPU は通常、完了タスクあたりのエネルギーが少なくなります。しかし、小さいモデル、低バッチサイズ、あるいは断続的なトラフィックでは、状況は変わりえます。
あるベンチマークがそれをかなり明確にします。RTX 4060 Ti を備えた GPU システムは 41 W でアイドルし、Mac mini M4 は 7.8 W でアイドルしました。同じテストで、Mac mini は 1Bパラメータの単一リクエスト分類 で約 3倍効率的 でした [3]。
それはデプロイのための3つの実践的なルールにつながります。
-
指標を正規化する。 完了タスクあたりのエネルギー(ジュール)、ジュールあたりのトークン、あるいは動画ワークロードのフレームあたりのエネルギーを使ってシステムを比較します。それがハードウェアをまたいだ公平な比較の視点を与えます [1][5]。
-
学習と推論を分ける。 GPU は通常、学習効率でリードします。推論はそれほど明快ではありません。CPU はバッチサイズ1と小さいモデルで、なお自力で持ちこたえられます [3][5]。
-
動画AIでは、パイプライン全体を含める。 デコード、前処理、推論はすべてエネルギー使用を形作ります。CPU 側の作業が GPU のボトルネックになると、効率が損なわれます [5]。
ハードウェアの選択は、ワークロードのプロファイルに合わせるべきです。稼働率が高く保たれるなら、GPU の高いワット数はそれ自体では問題ではありません。そして CPU は単なるバックアッププランではありません。適切なジョブには、より低電力の選択肢です。
FAQ
::: faq
AIのエネルギー効率をどう公平に測定すべきですか?
GPU の指標を単独で見ないでください。CPU と GPU の稼働率を一緒に 測定します。
なぜか? モデルが実行される前に起こる作業—前処理、トークン化、画像デコードのような—は、パイプライン全体を遅らせ、GPU を待機状態に放置しうるからです。その場合、GPU の数字だけでは何が起きているか分かりません。
Nsight Systems や PyTorch Profiler のようなツールは、ハードウェアが何をしているかを示せます。
公平な比較のために、実行をまたいでセットアップを同じに保ってください。
-
一貫したパイプラインを使う
-
ハイパーパラメータを固定する
-
実行を繰り返す
-
同じモデル、動作点、データパイプラインを合わせる
これらの要素が変わると、比較はあっという間に乱雑になりえます。 :::
::: faq
CPUがGPUより効率的なのはいつですか?
CPU は一部の AI ワークロードやデプロイのセットアップで、特に コスト効率 が最高速度より重要なときに、より良い選択肢になりえます。
また、GPU にしばしば伴うメモリアクセスのオーバーヘッドの一部を避けるため、ドット積のような並列性の低いタスクでもうまくやる傾向があります。
セルフホストや断続的な AI ジョブでは、CPU は低いアイドル電力のおかげで、ワット時あたりのトークンでもより良い結果を出せます。それにより CPU は、電力、熱、予算の制約が生のスループットより重要な、最適化・圧縮されたモデルを実行するエッジや組み込みのデプロイに強く合います。 :::
::: faq
なぜ動画の前処理はGPU効率にそれほど影響するのですか?
動画の前処理は急速に ボトルネック になりえます。動画デコードやフレーム拡張のようなジョブは、しばしば CPU に強く負荷をかけます。そしてデータパイプラインが追いつけないと、GPU は有用な作業をする代わりに待機することになります。
マルチモーダル入力はこれをさらに難しくします。動画はビジョントークンに変換されなければならず、それがより多くのメモリと計算の負荷を加えるからです。前処理が遅れると、GPU 稼働率は落ちますが、電力使用は高いままです。つまり、支払った出力を得られないまま、エネルギーを燃やしているということです。 :::
モデルマーケットで使いたいモデルを選ぶ
APIMart のモデルマーケットでチャット、画像、動画モデルを試し、統一 API でモデルの能力をすばやく体験できます。