MoEモデルとは、活性パラメータだけを演算する混合エキスパート型LLMである。
RTX 5080で複数のLLMを連続計測したところ、密モデルは例外なく200〜300Wの範囲で推移した一方、MoE構成のgemma4:26bとqwen3.5:35b-a3bだけが47〜73Wまで電力が落ち込みました。VRAMは14.8GBとほぼ使い切っている状態。なのにGPU温度も42〜45°Cまで下がるという、直感と逆の挙動を観測したのです。
- 密モデルは200〜300W帯で安定、MoEは47〜73Wと1/4〜1/6まで低下
- VRAM使用量は14.8GBで密モデル並みに確保されているのに低電力
- 電気代重視のバッチ運用はMoE、対話速度重視なら密モデルが有利
密モデル280W級 vs MoEモデル50〜70W級｜RTX 5080で観測された電力差
同じRTX 5080上で、Ollama 0.20.7・NVIDIAドライバ 595.97・Windows 11（25H2, build 26200）という完全に同一の条件で複数モデルを流した結果、消費電力が明確に2つのクラスタに分かれました。密モデル群は200〜300Wに収束し、MoE構成の2モデルだけが50〜70W帯へ落ちる。
この差は、モデルサイズや量子化方式の違いでは説明できません。同じ14GB前後のVRAMを埋めるモデル同士でも、密モデルなら300W近く、MoEなら50W前後という開きが出ています。
検証環境と計測条件
当サイトの検証環境は以下の通り。
| GPU | NVIDIA GeForce RTX 5080（VRAM 15.9GB） |
|---|---|
| CPU | Intel Core i7-14700F |
| RAM | 96GB |
| NVIDIAドライバ | 595.97 |
| Ollamaバージョン | 0.20.7 |
| OS | Windows 11（25H2, build 26200） |
| 計測日 | 2026年4月19日 |
tokens/sec・VRAM使用量・GPU温度・消費電力は推論定常状態での観測値。TTFT（最初のトークンまでの時間）は初回入力を含む往復時間で計測しました。
密モデル群の消費電力プロファイル（200〜300W帯で安定）
まず密モデル側のデータから整理します。パラメータ数が3Bから14Bまで大きく変動するにもかかわらず、消費電力は驚くほど狭いレンジに収まりました。
| モデル | tokens/sec | VRAM使用量 | GPU温度 | 消費電力 |
|---|---|---|---|---|
| phi4-mini:3.8b | 237.8 | 4.7GB | 56.0°C | 242W |
| llama3.2:3b | 278.7 | 4.0GB | 57.0°C | 239W |
| gemma3:4b | 189.1 | 4.7GB | 59.0°C | 217W |
| mistral:7b | 155.2 | 6.2GB | 62.0°C | 279W |
| llama3.1:8b | 140.5 | 6.6GB | 60.0°C | 267W |
| deepseek-r1:8b | 132.7 | 6.8GB | 60.0°C | 268W |
| qwen3.5:9b | 107.8 | 8.7GB | 59.0°C | 248W |
| gemma3:12b | 85.9 | 9.8GB | 58.0°C | 261W |
| phi4:14b | 82.6 | 11.0GB | 62.0°C | 301W |
| qwen3:14b | 79.1 | 10.7GB | 62.0°C | 287W |
モデルサイズと消費電力の関係
3Bクラスで239W、14Bクラスで301W。パラメータが約5倍に増えても電力の増分は20〜25%程度しかありません。GPUのTDP（360W）に対して常時80%前後を使っており、演算器も行列演算で忙しく動いている状態。
小型モデルほどtokens/secは速く、llama3.2:3bで278.7 tok/sと240超、phi4-mini:3.8bも237.8 tok/sと近接した高速域を記録。推論が高速な分、単位時間あたりの演算量が増えて電力もしっかり引く、という自然な挙動が出ています。
GPU温度から見るサーマル挙動
温度も56〜62°C帯でほぼ一定でした。ファンが十分回っているケース内であれば、長時間推論でも発熱は安定。RTX 5080のTBP 360Wを考えると、このクラスは余裕のある熱設計といえます。
MoEモデルで観測された特異な電力低下
ここからが本題。gemma4:26bとqwen3.5:35b-a3bの2モデルは、同じRTX 5080上で明らかに異質な挙動を示しました。
| モデル | tokens/sec | VRAM使用量 | GPU温度 | 消費電力 |
|---|---|---|---|---|
| gemma4:26b（MoE, A4B） | 36.6 | 14.8GB | 45.0°C | 73W |
| qwen3.5:35b-a3b（MoE, A3B） | 18.4 | 14.8GB | 42.0°C | 47W |
gemma4:26b（A4B）の挙動
gemma4:26bは総パラメータ26Bに対し活性パラメータ3.8B（A4B表記）の構成。当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM）では36.6 tok/s・73Wでした。密モデルのphi4:14b（82.6 tok/s・301W）と比較すると、速度は半分以下ですが電力は1/4。
総パラメータは26Bで、実際に演算に回るのは3.8B相当というのがA4Bアーキテクチャの特徴です。外部報告ではvLLMで131 tok/s・Ollamaで181 tok/sといった計測例もあり、当サイトのWindows 11＋Ollama 0.20.7環境では電力制限寄りの挙動が支配的でした。
qwen3.5:35b-a3bの挙動
qwen3.5:35b-a3bはさらに振り切った構成。総35Bに対し活性3B（A3B）と活性量がgemma4よりさらに小さく、消費電力は47Wまで低下しました。
18.4 tok/sと速度は密モデル帯の1/4〜1/5に落ち込みますが、ノートPC向けGPUでも珍しくない電力レンジで35Bクラスの総パラメータを抱えるモデルが動く、というのは注目すべき挙動。
当サイトの検証環境で生成したAI動画サンプル。
なぜMoEだけ電力が落ちるのか｜活性パラメータとメモリ帯域の非対称利用
ここからは推定を含む考察です。観測された「VRAM満タン×低電力×低速度」という組み合わせは、MoEの構造的な性質で説明できると考えています。
活性パラメータ（A3B・A4B）の意味
MoEは複数の専門家サブネットを内部に持ち、入力トークンごとにその中の一部だけを選んで演算する仕組み。gemma4:26bの表記「A4B」は活性パラメータ約4B（実際は3.8B）を意味し、qwen3.5:35b-a3bの「A3B」は活性3Bを示します。
総26B・35Bぶんの重みはすべてVRAMに載せておく必要があり、だからVRAM使用量は14.8GBと密モデル並みに膨らむわけですね。一方で、実際に演算に流れるのは3〜4B相当のみ。
メモリ帯域ボトルネックとSM遊休のトレードオフ
ここが消費電力低下の核心。RTX 5080のSM（Streaming Multiprocessor、演算器）は、密モデルの推論中はほぼフル稼働で行列演算を回しています。ところがMoEでは、毎トークンごとに経路判定を行い、選ばれた活性パラメータぶんだけを演算。結果として演算器の稼働率が下がり、電力の大部分を占めるSMの消費が落ちると推定されます。
一方でメモリ帯域は別事情。全エキスパートの重みがVRAM上に置かれ、必要なものをその都度引き出して演算器に流すため、帯域は密モデル同等かそれ以上に使われている可能性が高い。VRAMが14.8GBまで埋まる理由もここ。つまり「メモリ帯域は忙しい・演算器は余裕」という非対称な状態がMoEの電力プロファイルを作っていると考えられます。
この見立ては外部検証では確認できておらず推測の域を出ませんが、観測データ（VRAM満タン・温度低下・電力1/4・速度半減）と整合性は取れています。
電力削減とスループットのトレードオフ｜運用上の判断基準
MoEを採用するかどうかは、用途次第で答えが変わります。電気代とサーマル余裕を取るか、応答速度を取るか。
電気代試算の考え方
仮に24時間推論を回す常駐用途を想定すると、密モデル280W運用では月間電力量が約200kWh、MoE 60W運用なら約43kWh。電気代単価30円/kWh（2026年時点の参考値）で計算すると、月間6000円 vs 1300円と差は月額4700円ほど。年額では5万円超の差が出る計算です。
どちらを選ぶかの判断軸
対話レスポンス重視のローカルアシスタント用途なら、tokens/secで3〜7倍速い密モデル（llama3.1:8bなど）が優位。返答が即座に返ってくる体験は、電気代以上の価値があります。
一方、夜間バッチ処理・長文要約・大量データの下書き生成のように、待てる用途では遅いけれど電力の安いMoEが効く場面。GPU温度が42〜45°Cに収まるため、サーマル面の余裕が生まれて他プロセスとの同時実行もしやすくなるのです。
ちなみにComfyUIなど別のAIソフトで「GPU使用率が途中から落ちてCPUに処理が移る」挙動に遭遇することがあります。あれは不具合寄りの現象。一方、MoEの電力低下は設計通りの挙動という点で性質が違います。
よくある質問
Q. MoEモデルなら必ず消費電力が下がりますか？
いいえ。電力が下がる条件は「総パラメータは大きいが活性パラメータが小さい」構成で、かつモデル全体がVRAMに収まる場合です。VRAMに入り切らずCPU側へ分割されると、PCI Express経由の転送が発生して別の速度制約が生じます。
Q. RTX 5060 Tiでも同じ電力低下が起きますか？
RTX 5060 Tiは16GB VRAM・TDP 180Wの構成。gemma4:26bやqwen3.5:35b-a3bはVRAMに載る範囲なので、同様のメモリ帯域優勢な挙動は出やすいと推測されます。ただし当サイトではRTX 5060 Tiでの同条件実測は未計測で、断定はできません。
Q. VRAMに載り切らないMoEを動かすとどうなりますか？
一部の重みがメインメモリ（RAM）に退避され、トークンごとに転送が発生します。結果として速度は大きく落ち、電力はむしろ不規則に上下する傾向。当サイトではqwen3.5:27bやgemma4:31bがRTX 5080のVRAM 15.9GBでは載り切らず計測スキップとなりました。
Q. 推論速度を落とさずに電力だけ下げる方法はありますか？
NVIDIAドライバのPower Management ModeをAdaptiveに設定するか、nvidia-smiで消費電力上限を手動調整する方法があります。ただし電力を絞ると演算器の動作周波数が落ち、結果として密モデルのtokens/secも低下する仕組み。「速度を維持しつつ電力だけ」という削減は現実的ではありません。
まとめ
RTX 5080で密モデル群は200〜300W帯に収束し、MoE構成のgemma4:26b・qwen3.5:35b-a3bだけが47〜73Wまで落ちました。VRAM使用量は14.8GBと密モデル並みなのに電力は1/4。原因は活性パラメータぶんしかSMが使われない一方、全エキスパートの重みがVRAMを埋めるためメモリ帯域だけが忙しくなる非対称な消費構造にあると推定されます。
用途別の選び分けはシンプル。対話レスポンス重視なら密モデル、長時間バッチや電気代重視ならMoE。両方を手元に置いて切り替えるのが最も実用的な運用でしょう。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
