RTX 5080でMoEの消費電力が低い理由｜Ollamaで16GBに載りきらないgemma4:26b・qwen3.5:35b-a3b実測

RTX 5080の消費電力は、待機中で55W、ローカルLLMの推論で104〜296W、画像生成で230〜279Wの範囲に収まりました。TGPは360Wですが、掲載した定常区間中央値のうち最も高かったのは296Wで、TGP 360Wの82%にあたります（瞬間的なピークや電力上限への到達有無は本計測では評価していません）。同じGPUでも動かすものによって5倍以上の幅が出ます。

RTX 5080の消費電力｜用途別の実測マップ

同一環境・同一セッションで測った用途別の消費電力です。GPUボード電力のみで、CPU・マザーボード・電源の変換ロスは含みません。

電力上限を絞るかどうかを検討している場合の参考として、掲載した定常区間中央値のうち最も高かったのはphi4:14bの296Wで、TGP 360Wの82%でした。画像生成のSDXLは278.7Wです。ただしこれらは1秒間隔サンプリングの中央値であり、瞬間的なピークは捉えていません。電力上限に到達したかどうかは本計測では評価していません。ただしこれは今回試したワークロードでの値で、未測定の負荷や瞬間的なピーク、カードメーカーごとの実装差は含みません。NVIDIAはRTX 5080のTGPを360W、参考システム電源を850Wとしており、電源容量や排熱の設計はカタログ値とメーカーの推奨に沿って見積もるのが安全です。なお電力上限を絞った場合に速度がどれだけ落ちるかは、本計測では測定していません（既定の360Wのまま計測）。

以下、この幅がどこから来るのかをモデルの種類と載り方で分解します。

Dense型250W級 vs MoEモデル110W級｜同じGPUで開く電力差

MoEモデルとは、トークンごとに一部のエキスパートだけを選んで動かす混合エキスパート型LLMです。重みは全エキスパートぶんを保持するため、メモリ占有は総パラメータ側で決まります。

同じRTX 5080上で、Ollama 0.32.1・NVIDIAドライバ 610.47・Windows 11 25H2（build 26200.8875）という同一条件・同一セッションで12モデルを連続して流した結果、消費電力が2つのクラスタに分かれました。MoEではない通常型のモデル（以下 Dense型）は196〜296Wに収束し、MoE構成の2モデルだけが104〜124W帯へ落ちました。

ただしこの差はMoEという構造だけで説明できるものではありません。MoEの2モデルはVRAMに載りきらず、一部がCPU側に退避した状態で動いていました。後述するDense型の対照計測によって、オフロード単独でもGPUボード電力が低下するかを確認します。

検証環境と計測条件

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

RTX 5080 のスペックは VRAM 16GB GDDR7・TGP 360W・10752 CUDA コア・第 5 世代 Tensor Core 搭載の構成です。

モデルの同一性を担保するため、主役2モデルのダイジェスト先頭12桁を残しておきます。gemma4:26b が 5571076f3d70、qwen3.5:35b-a3b が 3460ffeede54、オフロード比較に使った gemma4:12b が 4eb23ef187e2、qwen3.5:27b が 7653528ba5cb（いずれも2026年7月22日取得）。同名タグでも配布側の更新で中身が変わるため、再現を試す場合はここが一致するか確認してください。なおqwen3.5:35b-a3bは、当サイトの以前の計測と同一モデルで比べるために継続して採用しています。2026年7月時点では後継のqwen3.6:35b-a3bも公開されています。

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

消費電力は nvidia-smi --query-gpu=power.draw,utilization.gpu,temperature.gpu,memory.used --format=csv -l 1 で1秒間隔のサンプリングを行い、推論定常状態の中央値を採用しました。モデルのロード中と実行の合間はGPUが待機状態に入り電力が50W台まで落ちるため、これらの区間を除外したうえで中央値を取っています。クエリ項目の定義はnvidia-smi公式マニュアルに従っていますが、定常区間の抽出と中央値の採用は本記事の運用です。

tokens/sec は Ollama API レスポンスから eval_count / eval_duration × 10^9（eval_duration はナノ秒）で、GPU配置率は Ollama API が返すモデルの割当量とVRAM配置量の比（size_vram ÷ size に相当）から算出しており、層数や重みだけの比率ではありません。本記事ではこの比率を便宜上「GPU配置率」と呼びます。tokens/sec と GPU配置率はいずれも Ollama API 由来で、nvidia-smi の値ではありません。なお割当量には重みのほかKVキャッシュや計算バッファも含まれます。

12モデルの連続計測では、モデルごとに明示的なアンロードは挟んでおらず、Ollama 既定の保持動作に従っています。また seed と temperature も固定していません。生成内容が回ごとに変わるため、12モデルの並びは厳密な順位付けではなく傾向をつかむための参考比較として読んでください。後述するオフロード率別の追加計測では、条件を変えるたびにモデルをアンロードしてから読み込み直しています。

各表の「VRAM使用量」は nvidia-smi の memory.used で、GPU全体の使用済みメモリです。対象モデル単体の増分ではなく、常駐したままの他モデルや他プロセスの分も含みます。

各モデルとも事前に短い warm-up プロンプトを流し、KV キャッシュとシェーダーコンパイルを安定させてから本計測に入っています。ばらつきの目安として、Dense型で最も速い llama3.2:3b が3回で234.98〜246.10 tok/s、MoEの gemma4:26b が71.58〜74.08 tok/s の範囲に収まりました。

Dense型の消費電力プロファイル（196〜296Wで安定）

Dense型はパラメータ数が3Bから14Bまで大きく変動するにもかかわらず、消費電力は狭いレンジに収まりました。10本すべてGPU配置率100%です。

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

3Bから14Bまでパラメータが約5倍変わっても、電力は196〜296Wの範囲に収まりました。最小と最大で100W・34%の開きはありますが、サイズと単調に増える関係にはなっていません（7Bのmistralが272W、12Bのgemma3が250W）。

tokens/secとも対応していません。最速のllama3.2:3bが229W、最も遅いphi4:14bが296Wと、むしろ逆向きです。Dense型はサイズにかかわらずGPU利用率が90〜93%で、GPUカーネルがほぼ連続して実行されており、電力はTGPの5〜8割という狭い帯に収まる、というのが今回の観測範囲で言えることです。

つまり省電力を狙って小さいモデルに替えても、パラメータ数の比ほどには電力が下がりません。下がるのは合計の消費電力量のほうで、効くのは同じ仕事をどれだけ短時間で終えるか（後述のtokens/J）になります。

GPU温度から見るサーマル挙動

今回の計測（512トークン生成を各モデル3回以上、1本あたり数分以内）の範囲では、温度は54〜64°Cに収まりました。長時間連続稼働時の温度推移やケース内温度の上昇は本記事では測定していません。温度はカードのクーラー設計・ケースのエアフロー・室温で変わります。24時間稼働させる前提でのエアフローやケースサイズの決め方はAI用PCの冷却とケースの選び方で扱っています。

MoEモデルで観測された電力低下

gemma4:26bとqwen3.5:35b-a3bの2モデルは、同じRTX 5080上で異なる挙動を示しました。

gemma4:26b（A4B）の挙動

gemma4:26bは総パラメータ26Bに対し活性パラメータ約4B（A4B表記）の構成。当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM）では72.97 tok/s・124Wでした。Dense型のphi4:14b（76.60 tok/s・296W）と比較すると、速度はほぼ同等なのに電力は半分以下という結果です。

今回のOllama・Q4_K_M・コンテキスト長8192という条件では割当が16.97GiBとなり、GPUに載ったのは12.34GiB。重みだけのサイズはこれより小さく、全量常駐するかどうかはランタイムとコンテキスト設定に依存します。残る27%はCPU・システムRAM側に置かれています。Ollama（llama.cpp）はGPUに載らなかった層をCPU側で計算するため、1トークンごとにCPUの演算とGPU・CPU間の中間テンソルの受け渡しが挟まり、その間GPUは待つことになります。

qwen3.5:35b-a3bの挙動

qwen3.5:35b-a3bは総約35B（Ollamaのメタデータ表示は36B）に対し活性3B（A3B）。消費電力は104W、GPU利用率は31%と、gemma4:26bをさらに下回りました。

ただしこの2モデルは活性パラメータだけでなくGPU配置率も73%対58%と違っており、この差が活性量の違いによるものかオフロード量の違いによるものかは、この2本の比較だけでは切り分けられません。60.79 tok/sという速度も、42%がCPU側にある状態のものです。

低電力はオフロード由来か構造由来か｜同じモデルで切り分ける

ここまでの比較には条件のずれがあります。Dense型10本はすべてGPU配置率100%で、MoE 2本だけが73%・58%の部分オフロード状態でした。低電力の要因として、MoE構造そのものと、オフロードによるGPUの待ち時間の2つが同居しています。違うモデル同士を並べても、この2つは分けられません。

そこで、同じモデルのまま、GPUに載せる層数だけを変えて測りました。Ollama の生成リクエストで options.num_gpu に載せる層数を指定し、gemma4:12b は既定・24・16、gemma4:26b は既定・16 の条件で比較しています（下表のGPU配置率は、その指定の結果として Ollama が報告した割当のうちVRAMに載った割合）。モデルもプロンプトも量子化も固定し、設定上変更したのはオフロード率だけです。ただしseedは固定していないため、生成されたトークン列は試行ごとに異なります。条件を変えるたびにモデルをアンロードしてから読み込み直しています。

Dense型を段階的にオフロードする（gemma4:12b）

同じモデルでも、GPUへの載り方だけで消費電力は265.8Wから73.8Wへ、およそ3分の1に落ちました。GPU利用率も89%から13%へ下がります。つまりGPUボード電力の低下は、MoE構造を持ち出さなくてもオフロードだけで再現できます。

同じ操作をMoEに対して行う（gemma4:26b）

同じGemma 4ファミリのMoE版で、同じように層数を絞りました。

MoEでも電力とGPU利用率は同じように下がります。違ったのは速度の落ち方でした。

同じGPU配置率で並べる

GPU配置率がほぼ揃う条件同士を比べます。系列もアーキテクチャの系譜も同じGemma 4での比較です。

16GBをわずかに超えるDense型としては qwen3.5:27b（割当16.48GiB）も同じ条件で測っており、GPU配置率77.9%で111.6W・12.87 tok/s・GPU利用率22%でした。Dense型はモデルが違っても、オフロードされると同じ帯域に落ちています。

電力はほぼ同じ（73.8W対76.2W）なのに、速度は2.41倍、1ジュールあたりの生成量は2.33倍の開きが出ました。全量配置時からの落ち方でも、Dense型が0.18倍まで落ちるのに対しMoEは0.48倍にとどまります。

なぜそうなるのかについては、活性パラメータの少なさが効いていると考えられますが、どの層やエキスパートがCPU側に置かれ、それぞれが何回呼ばれたかまでは観測していません。Ollamaが返すのはGPUとCPUの割当比率までで、内訳は本計測では確認できていません。

16GB級のGPUで手元のモデルがどちらに転ぶかは、配布サイズを見ればおおよそ見当がつきます。Q4_K_Mで16GBに収まる規模（今回のDense型10本、〜14B）はGPUに100%載って196〜296Wの帯域。収まらない規模（今回のMoE 2本、16.97GiB・22.18GiB）は一部がCPU側に退避し、GPU利用率が31〜40%まで下がって104〜124Wの帯域になります。同じGPUでも収まるかどうかが電力帯を分ける境目です。

なお2枚目のGPUを足してオフロードを解消した場合の挙動は別途実測しており、そちらでは解消によって速度が大きく改善しています。ただしGPUが2枚になるとアイドル電力もPCIe構成も変わるため、その電力値を本記事の1枚構成とそのまま比べることはできません。

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

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

3B クラスの llama3.2:3b が 1.04 tokens/J で最高効率。14B級Dense型が 0.26〜0.27 まで落ちるのに対し、MoEの2モデルは 0.58〜0.59 でした。

この指標は tokens/sec を定常区間の電力中央値で割ったものです。W は J/s なので、次元は tokens/J（1ジュールあたりの生成トークン数）になります。厳密な処理あたり効率は各時点の電力を積分して求めるべきもので、本記事の値は定常生成中の近似 tokens/J です。測っているのは生成が定常に入った区間のGPUボード電力だけで、CPU側の消費・プロンプト評価・モデルロード・待機時間は含みません。オフロード量が違うモデル同士では、システム全体で見た電力差はこの比より小さくなります。

またこの表はGPU配置率が揃っていません。前節のとおりGPU配置率を50%前後に揃えて比べた1組では、MoE側が2.33倍でした。加えてここで割っているのはGPUボード電力だけで、MoE側は推論の一部をCPUが担っています。そのぶんの電力は計測に含まれていないため、システム全体で見た効率差はこの数字より小さくなります。

アイドルと画像生成の消費電力

アイドル時（モデル非常駐・常駐）

gemma4:26bをロードしたままにした場合の中央値差は1.8W（55.0W→56.8W）でしたが、両条件の分布は重なっており、今回の60秒測定では待機電力の明確な増加は確認できませんでした。サンプルの範囲は非常駐54.96〜56.60W、常駐52.98〜57.99Wです。ただし常駐の可否はVRAMの空き次第で、他のプロセスがVRAMを要求すれば退避が起きます。常駐と並列実行の設定はOllamaを常駐・並列運用する実運用設定にまとめています。

画像生成（ComfyUI）

生成時間は1ワークフローあたり3回実行し、1回目のコールドスタートを除いた2回の平均です（SDXLのコールドは12.3秒、Flux.1は30.7秒）。電力はその生成区間を1秒間隔でサンプリングした中央値です。測定条件は、SDXLがsd_xl_base_1.0・euler・normal・CFG 7.0、Flux.1 Dev FP8がflux1-dev-fp8・euler・simple・CFG 1.0です。生成時間はステップ数にほぼ比例するため、他の設定では時間比が変わります。

画像生成の電力は参考値として扱ってください。SDXLは1枚6.2秒で、1秒間隔のサンプリングでは1回あたり数点しか取れません。その前提で見ると、GPU利用率は98〜99%に張り付き、Dense型のLLM推論と同じ電力帯に入ります。ステップ数はSDXLの30に対しFlux.1が20と少ないにもかかわらず、1枚あたりの時間は約5倍。1ステップあたりではSDXL 0.21秒、Flux.1 1.49秒です。それでいて電力はSDXLより48W低い。今回取った指標（電力・利用率・温度・VRAM使用量）ではこの48Wの差を説明できず、原因は特定できていません。

なおこの2件は、GPU利用率が高いほど電力も高いとは限らないことを示しています。Flux.1は99%で230.4W、Dense型のphi4:14bは92%で296W。utilization.gpuはカーネルが動いていた時間の割合であって、そのあいだにどれだけの演算器と帯域が動いていたかまでは表しません。

電気代で比べるときは瞬間の電力ではなく1枚あたりの電力量で見るほうが実態に合います。Flux.1は瞬間電力が低くても生成時間が約5倍なので、1枚あたりではSDXLを上回ります。SDXLとFluxの精度設定はComfyUIのFP16/BF16精度ガイドで比較しています。

運用上の判断基準

電気代試算の考え方

24時間推論を回す常駐用途を想定し、速度が近い14B級Dense型（284〜296W）を280W、MoE 2モデルを110Wとして計算すると、月間電力量は約202kWh対約79kWh。一例として東京電力エナジーパートナー従量電灯Bの第3段階（月300kWh超）単価40.49円/kWh（2026年7月時点）で計算すると、月間約8,163円 vs 約3,207円で、差は月額約4,956円。30日を1か月として単純に12倍すると年額約59,472円（365日連続なら約60,298円）です。待機させておくだけのアイドル55Wなら月約40kWh・約1,603円で、常時稼働と待機の差のほうが大きいことも分かります。小型Dense型（196〜232W）で足りる用途なら、差はこれより小さくなります。

この単価は家庭全体の使用量が既に月300kWhを超えている場合の限界単価です。使用量が少ない家庭では第1段階29.80円・第2段階36.40円が適用されるため、実際の増分はこれより小さくなります。他エリア・他プランの場合は契約単価に読み替えてください。燃料費調整額と再生可能エネルギー発電促進賦課金も別途加わり、時期によっては国の支援による値引きが適用される場合もあります。いずれもGPUボード電力のみの概算で、CPU・マザーボード・ストレージ・ファン・電源の変換ロスは含みません。とくにオフロードが起きている場合はCPUが演算を担うため、計上外の電力はその状態のほうが大きくなります。したがってこの金額差はGPUボード電力だけを取り出した比較であって、コンセントで測る実際の電気料金の差ではありません。瞬間の消費電力が下がることと、処理あたりの消費電力量が下がることも別の話です。

どちらを選ぶかの判断軸

VRAMに収まるモデルで足りるなら、Dense型のほうが素直です。対話レスポンス重視なら、tokens/secで3倍前後速い小型Dense型（llama3.2:3bなど）が優位。

16GBに載りきらない規模を動かす必要がある場合、今回試した1組ではMoE側が有利でした。GPU配置率を50%前後に揃えるとDense型のgemma4:12bが14.53 tok/s、MoEのgemma4:26bが35.00 tok/s。ただし2モデルは規模も層数も異なり、出力品質も比べていないため、Dense型とMoEの一般的な優劣として読むことはできません。夜間バッチ処理や長文の一括処理のように連続稼働させる用途では、この差が効いてきます。

ただしVRAMの空きという観点では注意が要ります。今回のMoE 2モデルはVRAMを15GiB以上占有しており、GPU温度に余裕があっても、同じGPUで画像生成などを並行させる余地はほとんど残りません。温度の余裕とVRAMの余裕は別物として見る必要があります。

また本記事が測定したのは消費電力・速度・VRAM配置・温度で、出力品質や用途ごとの適性は評価していません。品質面は自分のタスクで別途比較が必要です。

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

MoEの数値はランタイムのバージョンに強く依存します。当サイトが以前に同じ2モデルを計測した際は、MoEの消費電力がDense型帯のおよそ4分の1まで落ちていました。今回の再計測では約半分にとどまっており、電力の絶対値は上がっています。ただし同時にtokens/secも大きく伸びており、qwen3.5:35b-a3bは3倍以上の速度になりました。ドライバとランタイムの組み合わせで推論速度がどれだけ動くかは当サイトでも以前の環境で扱っていますが、その計測は条件の記録が不十分だったため本記事では参照しません。

電力が上がりながら速度も上がったという動き方からは、以前の低消費電力がGPUの待機時間の長さを反映していた可能性が読み取れます。ただしこれも推定で、当時のGPU配置率を記録していないため確認はできません。

同名のモデルタグでも、配布側の更新で中身が入れ替わることがあります。本記事の数値は上表の環境・日付・ダイジェストでの観測値として扱ってください。公開されているベンチマーク数値が手元の環境で再現するかどうかの見極め方はベンチマーク数値の読み取り方で整理しています。

MoE 構造の出自と各モデルの実装差

スパースなMoE層の直接の系譜は、Shazeerらが2017年に提示したSparsely-Gated Mixture-of-Experts層に遡ります。訓練可能なゲートネットワークが入力ごとに使うエキスパートを選ぶことで、計算量をあまり増やさずにモデル容量を大きく伸ばせることが示されました。

その後2021年のSwitch Transformerが、各トークンで参照するエキスパートを1つに絞るtop-1ルーティングで仕組みを単純化し、大規模化の道筋をつけています。Mistral AIはMixtral 8x7Bでオープンウェイトの実用MoEを投入し、活性2エキスパート構成で12.9B活性 / 46.7B総パラメータの設計を公開しました。今回検証した qwen3.5:35b-a3b は Qwen3.5系列のMoEモデル（Qwen3系の後継）で、活性パラメータ3B（A3B表記）を持ちます。

低電力と低GPU利用率をどう説明するか｜活性パラメータとオフロードの2要因

ここからは推定を含む考察です。

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

MoEは複数の専門家サブネットを内部に持ち、入力トークンごとにその中の一部だけを選んで演算する仕組み。gemma4:26bの表記「A4B」は活性パラメータ約4Bを意味し、qwen3.5:35b-a3bの「A3B」は活性3Bを示します。この表記には、毎トークン動くAttentionやルーティング機構、共有エキスパートのぶんもすでに含まれています。

演算量は総パラメータより大きく減る一方、重みは全エキスパートぶんをどこかに置いておく必要があるため、メモリ占有は総パラメータ側で決まります。速度が活性比のぶんだけ上がるわけでもありません。

GPU利用率40%・31%の読み方｜カーネル実行率とSM遊休

RTX 5080のSM（Streaming Multiprocessor、演算器）は、Dense型がVRAMに全量載っている状態ではほぼ連続で行列演算を回しています。オフロードが起きるとカーネルが動いている時間の割合が下がりました。CPU側の演算待ち・データの受け渡し・ランタイムのスケジューリングのどれがどれだけ効いたかは、本計測では切り分けていません。

今回はこれをGPU利用率として観測しました。100%常駐のDense型が90〜93%で張り付くのに対し、73%常駐のgemma4:26bは40%、58%常駐のqwen3.5:35b-a3bは31%、77.9%常駐のqwen3.5:27b（Dense型）は22%。GPU配置率と対応して下がっています。

ただし nvidia-smi の utilization.gpu は「測定期間中にGPUカーネルが実行されていた時間の割合」であって、SM占有率やTensor Core稼働率そのものではありません。低いカーネル実行率が観測され、SM遊休の可能性と整合する、というのが正確な言い方です。

メモリ帯域については測定していません。重みを逐次読み出す必要があることから、メモリ帯域が先に上限に達している可能性はあります。ただし本計測では帯域使用率を取っていないため、可能性の指摘までにとどめます。DeepSpeed-MoE（Microsoft Research）は、MoE 推論の効率がモデルサイズと利用可能なメモリ帯域に強く依存し、演算量の削減がそのまま速度向上に結び付かないと指摘しています。

まとめ

RTX 5080の消費電力は、アイドル55W・LLM推論104〜296W・画像生成230〜279Wでした（いずれも定常区間の中央値）。最も高かったのはphi4:14bの296Wで、TGP 360Wの82%。瞬間的なピークと電力上限への到達有無は本計測では評価していません。

今回のデータで推論時の電力差と対応していたのは、モデル構造よりもVRAMに収まるかどうかでした。GPU配置率100%のDense型10本が196〜296W・GPU利用率90〜93%だったのに対し、オフロードが起きると電力もGPU利用率も下がります。これはMoEに限らずDense型でも同じで、GPU配置率77.9%のqwen3.5:27bは111.6W・22%と、GPU配置率73%のMoE（124W・40%）より低い値でした。

分かれたのは速度です。GPU配置率を50%前後に揃えた1組では、Dense型のgemma4:12bが14.53 tok/s、MoEは35.00 tok/sでした。1ジュールあたりの生成トークン数では2.33倍の差。今回の1組では、同じだけGPUから追い出されたときの速度の落ち方に差が出ました（全量配置時との比でDense型0.18倍に対しMoE 0.48倍）。ただし2モデルは規模も層数も異なるため、MoE全般に当てはまる性質として一般化はできません。16GB級のGPUで16GBを超えるモデルを動かす必要があるなら、ここが選択の分かれ目になります。

参考資料

• NVIDIA 公式: GeForce RTX 5080 仕様ページ
• NVIDIA 公式: System Management Interface (nvidia-smi) ドキュメント
• Ollama: API ドキュメント
• Ollama: リリースノート (GitHub)
• Google: Gemma モデル概要

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