RTX 5080でMoEモデルだけ消費電力が1/4に落ちる｜gemma4:26b・qwen3.5:35b-a3b実測

MoEモデルとは、活性パラメータだけを演算する混合エキスパート型LLMである。

RTX 5080で複数のLLMを連続計測したところ、密モデルは例外なく200〜300Wの範囲で推移した一方、MoE構成のgemma4:26bとqwen3.5:35b-a3bだけが47〜73Wまで電力が落ち込みました。GPUメモリ使用量は約14.8GB。なのにGPU温度も42〜45°Cまで下がるという、直感と逆の挙動を観測したのです。

密モデル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前後という開きが出ています。

検証環境と計測条件

当サイトの検証環境は以下の通り。

RTX 5080 のスペックは VRAM 16GB GDDR7・TBP 360W・10752 CUDA コア・第 5 世代 Tensor Core 搭載の構成です。NVIDIA GeForce RTX 5080 公式仕様ページ

nvidia-smi による電力サンプリング手順

消費電力は nvidia-smi --query-gpu=power.draw,utilization.gpu,temperature.gpu,memory.used --format=csv -l 1 で 1 秒間隔のサンプリングを 60 秒継続し、推論定常状態の中央値を採用しました。tokens/sec は Ollama API レスポンスの eval_count / eval_duration から算出。VRAM 使用量はモデルロード完了後の安定値で、TTFT は prompt_eval_duration と最初のトークン到達時刻から集計しています。NVIDIA System Management Interface (nvidia-smi) 公式ドキュメント に準拠した計測手順です。

各モデルとも事前に短い warm-up プロンプトを 3 回流し、KV キャッシュとシェーダーコンパイルを安定させてから本計測に入っています。tokens/sec・VRAM 使用量・GPU 温度・消費電力は推論定常状態での観測値です。

密モデル群の消費電力プロファイル（200〜300W帯で安定）

まず密モデル側のデータから整理します。パラメータ数が3Bから14Bまで大きく変動するにもかかわらず、消費電力は驚くほど狭いレンジに収まりました。

モデルサイズと消費電力の関係

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上で明らかに異質な挙動を示しました。

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 構造の出自と各モデルの実装差

混合エキスパート（Mixture of Experts, MoE）の現代的実装は、Google Brain の Switch Transformer に遡ります。1 兆パラメータ規模でも、各トークンで参照するエキスパートを 1 つに絞ることで推論コストを大幅に削減する仕組みが提案されました。Fedus, Zoph, Shazeer “Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity” (arXiv:2101.03961)

その後 Mistral AI が Mixtral 8x7B でオープンウェイトの実用 MoE を投入し、活性 2 エキスパート構成で 12.9B 活性 / 46.7B 総パラメータの設計を公開しています。Jiang et al. “Mixtral of Experts” (arXiv:2401.04088) 今回検証した qwen3.5:35b-a3b は Alibaba Cloud の Qwen3 系列の MoE 変種で、活性パラメータ 3B（A3B 表記）を持つ系統です。Qwen Team “Qwen3 Technical Blog”

「スパース MoE モデルは、各トークンで一部のエキスパートのみを活性化するため、同等品質を密モデルの数分の一の推論 FLOPs で達成できる」— Switch Transformer 論文（Fedus et al. 2022）の中心的な主張を要約

Mixtral 8x7B は活性 12.9B と比較的多めですが、gemma4:26b と qwen3.5:35b-a3b はさらに細粒度の活性化で 3〜4B 帯まで落ちています。活性パラメータが小さいほど、後述する SM 稼働率の低下が顕著になる傾向。

なぜMoEだけ電力が落ちるのか｜活性パラメータとメモリ帯域の非対称利用

ここからは推定を含む考察です。観測された「高いGPUメモリ使用量×低電力×低速度」という組み合わせは、MoEの構造的な性質である程度説明できると考えています。

活性パラメータ（A3B・A4B）の意味

MoEは複数の専門家サブネットを内部に持ち、入力トークンごとにその中の一部だけを選んで演算する仕組み。gemma4:26bの表記「A4B」は活性パラメータ約4B（実際は3.8B）を意味し、qwen3.5:35b-a3bの「A3B」は活性3Bを示します。

今回の計測では nvidia-smi の GPU メモリ使用量が約14.8GBと密モデル並みだった。ただしこれだけでは「全重みがVRAMに常駐していた」とは言い切れない。qwen3.5:35b-a3b の q4_K_M 版は約24GBで RTX 5080 の16GBを超えるため、ランタイムのオフロード挙動次第で一部がVRAM外に置かれる可能性がある。よって本記事では14.8GBを「観測されたGPUメモリ使用量」として扱い、全量常駐の証拠とはしない。いずれにせよ、実際に演算に流れるのは3〜4B相当のみ。

メモリ帯域ボトルネックとSM遊休のトレードオフ

消費電力が下がる仕組みは、次のように推定できる。RTX 5080のSM（Streaming Multiprocessor、演算器）は、密モデルの推論中はほぼフル稼働で行列演算を回しています。ところがMoEでは、毎トークンごとに経路判定を行い、選ばれた活性パラメータぶんだけを演算。結果として演算器の稼働率が下がり、電力の大部分を占めるSMの消費が落ちると推定されます。

一方でメモリ帯域は別事情かもしれない。ロードされた重みは演算器に供給するため逐次読み出す必要があり、メモリ帯域の負荷は密モデル同等かそれ以上になり得る。ここで想定しているのは「メモリ帯域は忙しい・演算器は余裕」という非対称な状態だが、これは解釈であって直接測定したものではない。

Microsoft Research が公開した DeepSpeed-MoE の解説でも、MoE 推論時はメモリ帯域がボトルネックとなり、GPU 演算器の利用率が密モデル比で大きく下がる現象が指摘されています。Rajbhandari et al. “DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training” (arXiv:2201.05596) 今回観測した電力低下はこうした非対称なリソース利用と整合的だが、本計測で直接裏付けたわけではない。

これはあくまで仮説です。Nsight 等で SM 稼働率やメモリ帯域使用率を直接プロファイルしたわけではないため、観測された低電力・低温度・低スループットと整合する説明であって、直接測定した原因ではありません。

トークン当たり電力効率 (tokens/W) の比較

tokens/sec と消費電力を組み合わせると、1W あたりに生成できるトークン数（tokens/W）が比較可能になります。電気代やバッテリー駆動を念頭に置く場合、この指標が単純な tokens/sec より実用的です。

3B クラスの密モデル llama3.2:3b が 1.17 tokens/W で最高効率。一方、35B クラスの qwen3.5:35b-a3b は 0.39 tokens/W に留まりますが、14B 密モデル phi4:14b（0.27 tokens/W）より約 1.4 倍効率的です。総パラメータが 2.5 倍大きいモデルが、より少ない電力で動作している実装上の挙動が見て取れます。

tokens/W の高さは、夜間長時間バッチや電源容量に制約のある常駐用途で直接効きます。逆に対話 UI のレスポンス重視では、絶対 tokens/sec の高い 3-8B 密モデルが優位という二択になります。

電力削減とスループットのトレードオフ｜運用上の判断基準

MoEを採用するかどうかは、用途次第で答えが変わります。電気代とサーマル余裕を取るか、応答速度を取るか。

電気代試算の考え方

仮に24時間推論を回す常駐用途を想定すると、密モデル280W運用では月間電力量が約200kWh、MoE 60W運用なら約43kWh。電気代単価30円/kWh（2026年時点の参考値、東京電力従量電灯B 第3段階の概算）で計算すると、月間6000円 vs 1300円と差は月額4700円ほど。年額では5万円超の差が出る計算です。なお、これはGPUボード電力のみの概算で、CPU・マザーボード・ストレージ・ファン・電源の変換ロス・アイドル時の消費は含みません。東京電力エナジーパートナー 従量電灯B 料金プラン

どちらを選ぶかの判断軸

対話レスポンス重視のローカルアシスタント用途なら、tokens/secで3〜7倍速い密モデル（llama3.1:8bなど）が優位。返答が即座に返ってくる体験は、電気代以上の価値があります。

一方、夜間バッチ処理・長文要約・大量データの下書き生成のように、待てる用途では遅いけれど電力の安いMoEが効く場面。GPU温度が42〜45°Cに収まるため、サーマル面の余裕が生まれて他プロセスとの同時実行もしやすくなるのです。

ちなみにComfyUIなど別のAIソフトで「GPU使用率が途中から落ちてCPUに処理が移る」挙動に遭遇することがあります。あれは不具合寄りの現象。一方、MoEの電力低下は設計通りの挙動という点で性質が違います。

Ollama ランタイムのバージョン差

Ollama は v0.20 系で MoE モデルの GPU offloading を改善しています。特に Qwen3 MoE 系の活性パラメータルーティングは、ランタイム側のサポート状況で速度が変動。今回の計測では Ollama 0.20.7 を使用しましたが、後継版では gemma4 系のスループットがさらに改善されたと報告があります。ランタイム更新だけで tokens/sec が 20〜40% 変動するケースも珍しくありません。Ollama Releases (GitHub)

まとめ

RTX 5080で密モデル群は200〜300W帯に収束し、MoE構成のgemma4:26b・qwen3.5:35b-a3bだけが47〜73Wまで落ちました。VRAM使用量は14.8GBと密モデル並みなのに電力は1/4。活性パラメータぶんしかSMが使われず、メモリ帯域だけが忙しくなる非対称な消費構造が原因と推定していますが、直接測定したわけではありません。

tokens/W で見ると 3B 密モデルが 1.17 と最高、35B MoE が 0.39 で 14B 密モデル（0.27）を上回る効率。絶対 tokens/sec が必要な対話用途は密モデル、電気代と発熱を抑えたい長時間バッチは MoE、という二択が運用判断の中心です。両方を手元に置いて切り替えるのが最も実用的でしょう。

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。

参考資料

• NVIDIA 公式: GeForce RTX 5080 仕様ページ
• NVIDIA 公式: System Management Interface (nvidia-smi) ドキュメント
• arXiv: Switch Transformers – Scaling to Trillion Parameter Models with Simple and Efficient Sparsity
• arXiv: Mixtral of Experts
• arXiv: DeepSpeed-MoE – Advancing Mixture-of-Experts Inference and Training