ローカルLLMの電力あたり生成速度を実測｜両GPU合算電力でMoEはdense型の何倍効率的か（RTX 5080＋5060 Ti）

電力あたり生成速度とは、消費電力1ワットで1秒間に生成できるトークン数です。本記事では、PC全体の壁コンセント消費電力ではなく、RTX 5080とRTX 5060 Tiの両GPUを合算した推論中ピークboard power（GPUボード単体の電力）を分母に比較します。

同じくらいのサイズに見えるローカルLLMでも、消費電力が60W以上違うことがあります。当サイトの検証環境（RTX 5080＋RTX 5060 Ti）で27B〜35Bクラスを回したところ、両GPU合算の推論中ピークboard powerで見ると、あるモデルは約198W、別のモデルは約261Wまで上がりました。tok/s（生成速度）だけ眺めていると、この差はまったく見えません。けれど24時間動かす常駐用途では、この差は、発熱やGPU側の消費電力差として現れます（後述のとおり今回のWはGPUボード電力で、電気代そのものを出すにはPC全体の壁コンセント測定が要ります）。

この記事の要点

・電力効率は「tok/s ÷ ワット」で比較できる指標。本記事ではRTX 5080＋5060 Tiの両GPU合算の推論中ピークboard power基準で見る
・今回比較したモデル群では、両GPU合算board power基準でMoEが同サイズ帯のdenseより高いtok/s/Wを記録した（速度・電力の両方でMoEが有利）
・GPUごとにTGPが違うため、速度だけでなく「ワットあたり」で見ると選び方が変わる

電力あたり生成速度（tok/s/W）とは何か
1. tok/sだけでは見えないローカル運用のコスト
2. MoEとdense型をこの指標で比べる意味
検証環境とテスト条件
1. 測定対象モデルと量子化条件
2. 消費電力の測り方（RTX 5080＋5060 Tiの両GPU合算board power・推論中ピーク）
MoEとdense型の実測結果｜数値で見る効率差
1. モデル別tok/s/W比較表
2. RTX 5080＋5060 Ti構成で電力値を読むときの注意点
なぜMoEは電力効率で有利なのか
1. 効率が良いことと省VRAMは別の話
2. 速度と電力は測れても、出力品質は別軸
用途別の選び方｜電力効率を優先すべきケース
まとめ
よくある質問
参考資料
関連記事

電力あたり生成速度（tok/s/W）とは何か

ローカルLLMの性能をひとことで語るとき、多くの人がtokens/sec（tok/s）を持ち出します。1秒間に何トークン吐けるか、という速度の指標。これは確かに体感に直結する数字です。ただ、速いGPUやモデルが「効率が良い」とは限りません。

ここで関わってくるのが消費電力。同じ50トークン/秒でも、150Wで出すのと100Wで出すのとでは、1トークンを生むために使った電気の量がまるで違います。この「電気の使い方」を数値化したのが、電力あたり生成速度です。

計算式はシンプルで、こうなります。

効率（tok/s/W）＝ tok/s ÷ 消費電力（W）

たとえば100 tok/sを100Wで出せば1.0 tok/s/W、同じ100 tok/sを50Wで出せれば2.0 tok/s/Wです。後者は前者の半分の電力で同じ仕事をこなしている、という読み方になります。

tok/sだけでは見えないローカル運用のコスト

クラウドのAPIを叩いているだけなら、電力はサービス側の問題です。けれど自分のPCでモデルを動かす以上、GPU側の消費電力差はPC全体の消費電力や排熱にも影響します。ここがローカルLLMならではの視点。

特に差が出るのが、長時間の連続稼働です。チャットを数往復するだけなら数十秒で終わりますが、大量の文書を要約させたり、エージェントにコードを書かせ続けたりすると、GPUは何時間も高負荷で動き続けます。このときGPU board powerで30W以上の差が続けば、長時間運用では発熱と消費電力の差として現れます（電気代換算にはPC全体の測定が必要です）。

MoEとdense型をこの指標で比べる意味

近年のローカルLLMには、大きく分けて2つの作り方があります。全パラメータを毎回フルに動かすdense型と、必要な「専門家（expert）」だけを選んで動かすMoE（Mixture of Experts）型。総パラメータ数が同じくらいでも、実際に計算する量が違うため、消費電力にも速度にも差が出ます。

つまりtok/sだけ見ても、なぜ差がつくのかは見えません。tok/s/Wという1本の物差しを当てると、「同じ出力トークン量に対して、GPU側でどれだけ電力を使ったか」が見えやすくなります。この記事では、当サイトの実機でMoEとdenseを同条件で回し、この物差しで何倍の差がついたかを数値で示します。

検証環境とテスト条件

数値の話に入る前に、どう測ったかを先に明らかにしておきます。当サイトの検証環境はRTX 5080（16GB）とRTX 5060 Ti（16GB）を組み合わせた構成で、5060 Ti側はOculink経由で接続しています。各GPUのVRAMはそれぞれ16GBで、合計を32GBのひとかたまりとして扱うわけではありません。CPUや電源を含む全体構成は検証環境ページにまとめてあるため、本文では測定に使ったGPUと設定だけを添えます。

測定に使ったのはOllama 0.30.7、ドライバはNVIDIA 610.47、計測日は2026年6月18日です。

測定対象モデルと量子化条件

比較したのは、MoE型のQwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）・qwen3-coder:30b、dense型のQwen3.5 27B（Ollama: qwen3.5:27b）・Gemma 4 31B（Ollama: gemma4:31b）・Qwen3 32B（Ollama: qwen3:32b）など、いずれもOllamaの既定タグで取得したモデルです。同名タグでも中身が更新されることがあるため、各モデルはdigest（sha256）と取得日を記録して同定しています。

thinking対応モデルでは、設定や出力形式によってthinking出力が混ざり、可視回答側のトークン数や速度比較が歪むことがあります。これを避けるため、全モデルをthink=falseに統一して計測しました。条件を揃えないと、推論モデルと非推論モデルの数字が同じ土俵に乗らないためです。

消費電力の測り方（RTX 5080＋5060 Tiの両GPU合算board power・推論中ピーク）

消費電力はnvidia-smiのpower.drawを推論実行中に両GPU同時にサンプリングし、RTX 5080とRTX 5060 Tiのboard power（GPUボード単体の電力）を同一サンプルで合算した推論中ピーク値を採用しています。今回の27B〜35Bクラスはいずれも16GBの1枚に収まらず両GPUにまたがってロードされるため、2枚分を合算して初めて推論で実際に使ったGPU電力になります。前提が3つあります。①これは2枚のGPUボード電力の合算で、CPU・電源を含むPC全体（壁コンセント）の消費電力は含みません。②アイドル時との差分ではなく、推論中の絶対値です。③これはGPUボードの合算電力であって、電気代そのものではありません（電気代は壁コンセント測定が必要）。実際に使ったのは次のようなコマンドです。

nvidia-smi --query-gpu=timestamp,index,power.draw,memory.used,temperature.gpu --format=csv,noheader,nounits -l 1  # 両GPUを毎秒サンプリングし、同一時刻のpower.drawを合算

tok/sは、Ollama APIが返す生成フェーズの計測フィールドから算出し、各モデル3回計測し、中央値を採用しました。本記事のtok/sは、プロンプト処理ではなく回答生成側（生成フェーズ）の速度を見ています。明らかな異常値が出た場合は追加で2回測定し、測定ログ上の外れ値を除いて確認しています。効率はこの2つを使い、tok/s ÷ ワットで求めます。

なお、nvidia-smiのpower.drawは手軽に比較できる一方、サンプリング間隔やGPU側センサーの仕様に左右されます。厳密な消費電力量や電気代を出す場合は、壁コンセント側のワットチェッカー測定が必要です。

ひとつ注意したいのが、VRAM使用量の読み方です。表に載せた値は、両GPUのnvidia-smi memory.usedを合算したものです（モデルが2枚にまたがるため）。デスクトップ表示などのベースラインを含んだGPU全体の使用量で、単位はGiB。モデル単体がロード時に増やした分とは別物なので、「このモデルだけで何GiB」という増分とは区別して見てください。合算値が16GBを超えるモデルは、1枚の16GBには収まらず2枚（または24GB超のGPU）が要るという読み方になります。

そしてこの検証で測ったのは、あくまで速度（tok/s）と消費電力（W）です。出力の品質や日本語の自然さは別の話で、tok/s/Wには含まれません。効率が高い＝賢い、ではない点は最初に断っておきます。

MoEとdense型の実測結果｜数値で見る効率差

ここからが本題です。当サイトの検証環境（RTX 5080＋5060 Ti・think=false・3回中央値）で、27B〜35Bクラスのモデルを同条件で回した結果を並べます。

モデル別tok/s/W比較表

モデル	種別	tok/s	両GPU合算ピーク電力(5080+5060Ti)	効率(tok/s/W・両GPU合算基準)	両GPU合算VRAM使用量
qwen3-coder:30b	MoE	145.3	202W	0.72	19.7GiB
Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）	MoE	122.4	198W	0.62	24.1GiB
qwen3.6:35b-a3b	MoE	123.8	198W	0.63	24.2GiB
Qwen3.5 27B（Ollama: qwen3.5:27b）	dense	29.2	250W	0.12	18.6GiB
Gemma 4 31B（Ollama: gemma4:31b）	dense	25.7	253W	0.10	23.0GiB
Qwen3 32B（Ollama: qwen3:32b）	dense	26.0	261W	0.10	22.7GiB

モデルの種別（MoE/dense、qwen3-coder:30bを含む）はOllamaのタグ情報と各モデルの公開情報をもとに整理し、各モデルのdigest（sha256）と取得日は測定ログに記録しています。タグの中身は更新される可能性があります。なお表中のモデル名は記事上の表示名で、括弧内（Ollama: …）は取得したタグ名です。

効率の列を見比べると、差は一目瞭然です。MoE型のQwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）が0.62 tok/s/Wなのに対し、同じqwenファミリーのdense型であるQwen3.5 27B（Ollama: qwen3.5:27b）は0.12、Qwen3 32B（Ollama: qwen3:32b）にいたっては0.10でした。前者を後者で割ると約5倍〜6倍。つまり今回のRTX 5080＋5060 Ti環境・Ollama 0.30.7・think=false・同一測定条件（両GPU合算board power基準）では、MoE型がdense型に対しておよそ6倍のtok/s/Wを記録しました。

注目したいのは、両GPU合算のピークboard power基準でも、MoEが速いだけでなく合算ピーク電力まで低かった点です。Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）は122.4 tok/s時に両GPU合算198Wだった一方、dense型のQwen3 32B（Ollama: qwen3:32b）は26.0 tok/s時に261Wでした。速度で約4.7倍の差がつき、なおかつ両GPU合算の推論中ピーク電力はMoE側が約63W低い。速度と電力の両方で離されているため、効率の差が一段と開きました。

MoE同士でも数字は割れます。qwen3-coder:30bは145.3 tok/sと最速で、効率も0.72 tok/s/Wでトップ。一方qwen3.6:35b-a3bは0.63、35b-a3bは0.62で、この2つはほぼ並びます。ただしこの差は測定のばらつき範囲に近く、どれが明確に上とは断定しません。

RTX 5080＋5060 Ti構成で電力値を読むときの注意点

この表の数値は、RTX 5080をメインに、Oculink接続のRTX 5060 Tiを組み合わせた環境での実測です。power.drawは両GPUを合算しているため、2枚で実際に引いたGPU電力を反映します。今回の27B〜35Bクラスはいずれも16GB単体に収まらず両GPUにまたがってロードされており、合算して初めて推論中のGPU電力が見えます。内訳を見ると、MoE型は5080側・5060 Ti側ともに100W前後（合算約198〜202W）に収まる一方、dense型の大型ほど両GPUとも電力が高く（合算約250〜261W）、合算ピーク電力でもdense側が高く出る傾向がありました。なお、Oculinkを介した2枚構成では転送待ちが入るため、1枚に収まるモデルを1枚で動かした場合とは速度・電力の出方が変わります。

TGP（Total Graphics Power）はRTX 5080が公称360W、RTX 5060 Ti 16GBがNVIDIA公式およびAIB製品仕様で180W級です。詳細は参考資料のNVIDIA公式仕様およびAIB製品仕様を参照してください。実測の合算power.drawを見ると、今回のモデルは2枚合算で約198W〜261Wの範囲で、2枚のTGP合計（360W＋180W＝540W級）に対してはかなり余裕がありました。少なくとも今回のOllama推論では、両GPUともTGP上限まで張り付かず、TGPの数字そのままに電力を使う結果にはなりませんでした。Oculink側のPCIe帯域による転送待ちで、両GPUとも上限手前にとどまっている可能性があります。

なぜMoEは電力効率で有利なのか

今回の測定条件では、MoE型がdense型を電力効率で大きく上回る場面が確認できました。では、なぜこの差が生まれるのか。仕組みを押さえておくと、モデル選びの判断がぶれにくくなります。

dense型は、推論時に各層の重みを広く使って計算します。32Bのモデルなら、1トークンを生成するたびに32B規模の重みに基づく行列演算が走る、というイメージです。これがそのまま計算量に直結し、GPUのコアを回し続けるぶん電力も時間もかかります。

一方のMoE（Mixture of Experts）は、内部を複数の「専門家（expert）」に分けておき、入力に応じてそのうちのごく一部だけを選んで動かす構造です。総パラメータが大きくても、1トークンあたりに実際に計算する量（アクティブパラメータ）は一部に絞られる。Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）の「a3b」は、総量35Bクラスに対してアクティブが3Bほど、という意味合いの表記です。計算する量が減れば、同じ1トークンを出すためのGPU側の計算負荷や消費電力は小さくなりやすいです。これが電力効率で有利になる理由。

効率が良いことと省VRAMは別の話

ここで誤解しやすいのが、「MoEは効率が良い＝VRAMも少なくて済む」という早合点。実際は逆方向の注意が要ります。

MoEは計算こそ一部の専門家だけで済ませますが、どの専門家が呼ばれるかは入力次第なので、計算は一部でも重み全体は保持する必要があります。Ollama/llama.cpp系のローカル推論ではGPUに載せる分の重みがVRAMを消費し、収まらない場合はCPUや別GPUへのオフロードが必要になります。当サイトの検証環境（RTX 5080＋5060 Ti・num_ctx=4096）でも、Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）の両GPU合算VRAM使用量は約24.1GiBに達し、16GBの1枚には収まりませんでした。実際、当サイトでRTX 5080単体（16GB）に載せたところ、GPUに載りきらず約4割がCPUにオフロードされ、速度は66 tok/s前後まで落ちました（2枚にフル常駐させた122 tok/sの半分強）。電力効率が良いからといってメモリが軽いわけではない、という点は分けて考えてください。

つまりMoEの利点は「速くて省電力」であって、「省メモリ」ではありません。今回のタグ・量子化・num_ctx条件では、35B-A3B級のMoEはフル常駐に16GB超を要し、フル速度を出すには2枚構成（合計32GB）や24GB級GPUが要りました。16GB単体でも動きはしますがCPUオフロードで速度が落ちるため、容量に対して余裕を見た構成が安全です。

速度と電力は測れても、出力品質は別軸

もう一点、見落とせないのが評価軸の切り分けです。tok/s/Wで測れるのはあくまで「どれだけ速く、どれだけ少ない電力で文字を吐けるか」であって、「その文字の中身が良いか」ではありません。

MoEがdense型より電力効率で勝っていても、特定の用途での回答精度やコードの正確さが同じとは限らない。品質は今回の実測の対象外であり、tok/s/Wの数字だけでモデルの優劣を決めるのは早計です。効率指標は「同じ品質帯のモデルが複数あるとき、どれが軽く回るか」を比べる物差しとして使うのが妥当な距離感。品質の比較は、別途それ専用の評価で見るべき領域になります。

用途別の選び方｜電力効率を優先すべきケース

電力効率を重視すべきか、それとも瞬間の速度や品質を優先すべきか。これは使い方で答えが変わります。自分の運用がどれに当たるかで選び分けてください。

常時稼働させるなら、tok/s/Wが効いてきます。要約や分類のバッチ処理をバックグラウンドで回し続ける、あるいは社内ツールとしてモデルを起動しっぱなしにする、といった使い方では、1日の積み上げでGPU側の消費電力差が発熱やPC全体の電力消費にも影響します。当サイトの検証環境では、Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）が両GPU合算198Wで122.4 tok/sを記録した一方、dense型のQwen3 32B（Ollama: qwen3:32b）は261Wで26.0 tok/s。長く回すほど、この差は無視できなくなります。常駐用途なら、MoE型は有力候補になります。

単発の対話が中心なら、効率より総合的な体感速度を優先して構いません。質問を投げて答えが返るまでを数回繰り返すだけの使い方では、24時間ぶんの電力差は誤差の範囲。それよりも、最初のひと文字が返るまでの間や、回答の中身の使い勝手のほうが体感を決めます。電気代を気にするより、自分の質問に対して納得できる答えを返すモデルを選ぶほうが合理的。

長文処理を回数こなすなら、効率の良いモデルが時間も節約します。大量の文章を要約・翻訳にかけるような処理では、tok/sが高くて消費電力が低いMoE型が、処理時間とGPU側の消費電力の両方で差を生む。qwen3-coder:30bが145.3 tok/sを両GPU合算202Wで出していたように、MoE型は「高いtok/sと、速度のわりに低い合算電力」を両立しやすく、まとまった量を捌く作業と相性が良好です。

GPUの選択についても触れておきます。ここでの数値はRTX 5080をメインにした検証環境のものですが、判断の主役はGPUの型番というより「VRAM 16GB級でどのモデルを回すか」。ただし35B-A3B級のMoEは既定タグだとフル常駐に16GB超を要し、16GB単体ではCPUオフロードで速度が落ちます。フル速度を狙うなら24GB級GPUか2枚構成（合計32GB）が前提。手持ちのVRAM容量から、フル常駐できるモデルの上限を先に決めると選定がぶれません。

同じ品質で足りるなら、電力効率を上げる近道は、用途に対して過剰なモデルを選ばないことです。分類や定型処理に大型dense型を充てると、電力も時間も無駄になります。必要十分なサイズのMoE型に、量子化と適切なnum_ctxを組み合わせるのが効率重視の基本形。

まとめ

ローカルLLMは、tok/sの速さだけでなく「ワットあたりどれだけ生成できるか」という軸でも選べます。当サイトの検証環境で同条件で回したところ、MoE型のQwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）は両GPU合算198Wで122.4 tok/s、dense型のQwen3 32B（Ollama: qwen3:32b）は261Wで26.0 tok/s。速度で約4.7倍、両GPU合算の推論中ピーク電力でも約63W低く、電力効率では一段と差が開きました（数値はいずれも両GPU合算board power基準・この実測条件）。

ただし、この優位は「同サイズ帯のモデルを比べたとき、MoE型が軽く回りやすい」という傾向であって、すべての場面で逆転がないわけではありません。モデルや量子化、コンテキスト長の条件しだいで結果は動きます。MoEは計算量が少なく電力効率で有利な一方、計算量は少なくても重み全体を保持する必要があり、GPUに載せる分の重みはVRAMを消費する点、そして速度・電力は測れても出力品質は別軸である点は、本記事の比較の前提として押さえておいてください。

常時稼働やバッチ処理など、長く回す運用ならMoE型を候補に入れ、電力効率も比較対象にする。単発の対話が中心なら効率より体感速度と品質を優先する。VRAMの容量から収まるモデルの上限を決め、用途に対して過剰なサイズを避ける。この3点を起点に、自分の使い方へ当てはめてみてください。

よくある質問

Q. 電力効率はどうやって測ればいい？

基本は、生成速度（tok/s）を推論中の消費電力（ワット）で割ります。本記事と同じ形式なら、Ollamaの生成速度を、RTX 5080と5060 Tiの両GPU合算の推論中ピークboard power（同一サンプルでpower.drawを合算）で割っています。multi-GPU環境では、どのGPUのpower.drawを使うか（または複数GPUを合算するか）を先に決める必要があります。本記事は2枚にまたがるため合算しています。PC全体の電力効率を見たい場合は、壁コンセント側の消費電力を測って割ります。

Q. MoEなら必ずdense型より省電力ですか？

傾向としては有利ですが、必ずとは言い切れません。モデルのアクティブパラメータ量、量子化方式、コンテキスト長によって結果は変わります。当サイトの検証環境では大きな差が出ましたが、これは同条件での一例。自分の使うモデルで実際に測るのが確実です。

Q. VRAMは16GBあれば足りますか？

用途次第です。今回の27B〜35Bクラスは既定タグだと16GB単体に収まらず、当サイトでRTX 5080単体（16GB）に載せたQwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）は約4割がCPUにオフロードされ66 tok/s前後まで落ちました。フル速度（122 tok/s）を出すには2枚構成（合計32GB）か24GB級GPUが要ります。14B級までのモデルなら16GB単体にフル常駐でき、軽快に回せます。手持ちのVRAMで「フル常駐できる上限」を先に決めるのが安全です。

Q. 電気代はどのくらい変わりますか？

電力単価は契約や地域で異なるため金額は一概に言えませんが、今回のWは両GPUのGPU board power合算なので、電気代そのもの（壁コンセント測定）ではありません。ただし同じ環境でGPU側の消費電力差が続く場合、PC全体の消費電力や発熱にも影響します。正確な電気代を出すには壁コンセント側のワットチェッカー測定が必要です。常駐用途ほど効率の良いモデルを選ぶ意味は大きくなります。

Q. dense型を選ぶ意味はありますか？

あります。電力効率はMoEが有利でも、回答の品質や特定タスクでの正確さは別の軸。用途によってはdense型のほうが扱いやすい場面もあります。効率指標は「軽く回るか」の物差しであって、出力の良し悪しまでは測っていません。品質はそれ専用の評価で見てください。