LLM推論の電力の99.8%は計算に使われていない
LLM推論のボトルネックを議論するとき、帯域とVRAMの話が中心になる。だがLIMINAL（Davies et al., arXiv:2507.14397）が挙げた5つの壁のうち、最も突破困難なのは電力だ。
帯域は幅を広げれば増える（HBM4がそうした）。容量はスタック数を増やせば増える。だが電力は物理法則に直結している。半導体の微細化が消費電力を下げてくれた時代はDennard scalingとともに2006年頃に終わった。
# Dennard Scaling の崩壊
dennard_scaling = {
"1970-2006": {
"法則": "トランジスタが小さくなると電圧も下がり、面積あたりの消費電力は一定",
"結果": "微細化するだけで性能/W が向上",
"恩恵": "ムーアの法則とDennardの法則が同時に機能 → 指数関数的な性能向上",
},
"2006-現在": {
"現実": "電圧がこれ以上下がらない (サブスレッショルド・リーク)",
"結果": "微細化してもトランジスタあたりの消費電力が減らない",
"対策": "ダークシリコン、ヘテロジニアス設計、電力制約設計",
},
}
# 2006年以降、チップは「全トランジスタを同時に動かせない」状態
# 使わない部分を意図的にオフにする (ダークシリコン) ことで電力を管理
GPUの消費電力推移: 止まらない上昇
データセンターGPU
# NVIDIA GPU の TDP (Thermal Design Power) 推移
gpu_tdp = {
"V100 (2017)": {"tdp": 300, "unit": "W", "process": "12nm", "hbm": "HBM2"},
"A100 (2020)": {"tdp": 400, "unit": "W", "process": "7nm", "hbm": "HBM2E"},
"H100 (2022)": {"tdp": 700, "unit": "W", "process": "4nm", "hbm": "HBM3"},
"H200 (2024)": {"tdp": 700, "unit": "W", "process": "4nm", "hbm": "HBM3E"},
"B200 (2025)": {"tdp": 1000, "unit": "W", "process": "4nm", "hbm": "HBM3E"},
"次世代 (2026-27)": {"tdp": "1200-1500?", "unit": "W", "process": "3nm", "hbm": "HBM4"},
}
# V100→B200: 微細化は12nm→4nm (3世代) だがTDPは300W→1000W (3.3倍)
# 微細化で電力効率は上がったが、トランジスタ数を増やしすぎて相殺
# B200の1000Wは液冷必須。空冷の限界は約350W
電力効率の改善は追いついているか
# 性能/W の推移 (推論 throughput基準)
efficiency_trend = {
"V100": {"perf_per_watt": 1.0, "relative": "baseline"},
"A100": {"perf_per_watt": 2.5, "relative": "2.5x vs V100"},
"H100": {"perf_per_watt": 4.2, "relative": "4.2x vs V100"},
"B200": {"perf_per_watt": 6.0, "relative": "6.0x vs V100 (推定)"},
}
# 性能/W は8年で6倍
# 絶対的な性能は8年で30-50倍
# つまり、性能の伸びの大部分は「電力を増やした」ことで得られている
# 効率改善は性能向上の20%程度しか説明しない
これが意味するのは、LLM推論の性能向上は電力投入量の増加に依存しているということだ。効率改善だけでは追いつかない。
1トークンあたりの電力コスト
デコードの電力計算
# 70Bモデル (FP16) のデコードにおける電力分解
decode_power_breakdown = {
"重み読み出し (HBM)": {
"data": "140 GB per token",
"HBM_power": "HBM3E: ~20 pJ/bit → 140e9 * 8 * 20e-12 = 22.4 mJ/token",
"note": "HBMのエネルギーコストは帯域に比例",
},
"行列演算 (GPU cores)": {
"ops": "~140 GFLOP per token (weight matmul)",
"GPU_power": "H100: ~0.3 pJ/FLOP → 140e9 * 0.3e-12 = 0.042 mJ/token",
"note": "演算そのもののエネルギーは読み出しの500分の1",
},
"KVキャッシュ読み出し": {
"at_32K": "~8 GB per token (全レイヤー)",
"power": "8e9 * 8 * 20e-12 = 1.28 mJ/token",
"note": "コンテキスト長に比例して増加",
},
}
# 驚くべき比率:
# データ移動: 23.7 mJ/token (99.8%)
# 演算: 0.042 mJ/token (0.2%)
# LLM推論の電力はほぼ全てが「データを動かすコスト」
この比率は直感に反する。GPUは「計算する」装置だと思われているが、LLM推論において電力の99.8%は計算以外——データをメモリから読み出してチップ内を移動させるコスト——に費やされている。
データセンター規模での電力消費
# GPT-4クラスのサービスの電力試算
datacenter_power = {
"仮定": {
"model": "~1.8T parameters (MoE, 推定)",
"queries_per_day": 100_000_000, # 1億クエリ/日
"avg_tokens_per_query": 500,
"gpu": "H100 (700W)",
"throughput_per_gpu": "~150 tokens/s (推定, バッチ処理含む)",
},
"計算": {
"total_tokens_per_day": "50B tokens",
"tokens_per_second": "~578,703 t/s",
"gpus_needed": "578703 / 150 ≈ 3,858 GPUs",
"power": "3858 * 700W = 2.7 MW (GPUのみ)",
"with_cooling_network": "2.7 MW * 1.5 (PUE) ≈ 4.0 MW",
"annual_power": "4.0 MW * 8760h ≈ 35 GWh/year",
},
"コスト": {
"electricity": "35 GWh * $0.05/kWh ≈ $1.75M/year (電力のみ)",
"per_query": "$1.75M / 365 / 100M ≈ $0.000048/query",
"per_1k_tokens": "~$0.001 (電力コスト分のみ)",
},
}
GPUの電力だけで年間35 GWh。日本の一般世帯の年間消費電力が約4,300 kWhなので、約8,000世帯分に相当する。そしてこれは1サービスの推論だけの数字だ。学習はこの10倍以上。
電力の壁がLLM推論に与える3つの制約
制約1: スケールアウトの限界
# データセンターの電力制約
datacenter_constraints = {
"typical_rack_power": "20-30 kW per rack",
"h100_per_node": "8 GPUs (DGX H100ノード)",
"node_power_h100": "8 * 700W + CPU/NVSwitch/NIC = ~10 kW (1ノード)",
"b200_per_node": "8 GPUs (DGX B200ノード)",
"node_power_b200": "8 * 1000W + CPU/NVSwitch/NIC = ~14 kW (1ノード)",
"問題": "GPUを増やしても、データセンターの電力供給能力がボトルネック",
"現実": "既存のデータセンターの多くは20MW級。新規建設に3-5年",
"トレンド": "MicrosoftとOpenAIは1GW級データセンターを計画 (原発1基分)",
}
電力の問題は、「もっとGPUを買えばいい」という解決策に物理的な上限を設定する。
制約2: コンシューマデバイスの熱制約
# RTX 4060 8GB の電力・熱の現実
rtx4060_thermal = {
"TDP": "115W (ラップトップ版)",
"GPU_die_area": "~159 mm²",
"power_density": "115 / 159 = 0.72 W/mm²",
"LLM推論時": {
"typical_power": "60-80W (フル負荷ではないがメモリアクセスが多い)",
"memory_controller": "帯域272 GB/sを維持するだけで ~15W",
"note": "推論はGPU演算ユニットよりメモリコントローラが電力を消費",
},
"実用上の限界": {
"サーマルスロットリング": "GPU温度上昇時に発生し、推論速度が低下する",
"バッテリー駆動": "不可能 (60Wh バッテリーで1時間未満)",
"連続推論": "冷却が十分なら問題ないが、薄型ラップトップでは制約",
},
}
ローカルLLMの推論速度が「帯域で決まる」と言われるが、帯域を使う行為自体が電力を消費する。272 GB/sの帯域を維持するのにメモリコントローラだけで約15W。モデルが大きくなり帯域要求が上がれば、電力消費も比例する。
制約3: 電力あたりのトークン生成レート
# 電力効率で見たローカルLLM
tokens_per_watt = {
"RTX 4060 (Qwen2.5-32B Q4_K_M)": {
"speed": "10.8 t/s",
"power": "~70W",
"efficiency": "10.8 / 70 = 0.154 t/s/W",
},
"RTX 4060 (Qwen3.5-4B Q4_K_M)": {
"speed": "~50 t/s (推定)",
"power": "~65W (小モデルでもGPU+メモリコントローラで60-70W)",
"efficiency": "50 / 65 = 0.77 t/s/W",
},
"M4 Mac mini (Qwen2.5-32B Q4_K_M)": {
"speed": "~8 t/s",
"power": "~30W (Apple Silicon の電力効率)",
"efficiency": "8 / 30 = 0.27 t/s/W",
},
"H100 (Llama-3-70B FP16, batch=32)": {
"speed": "~768 t/s (32並列 × 24 t/s、重み読み出しをバッチで共有)",
"power": "700W",
"efficiency": "768 / 700 = 1.10 t/s/W",
},
}
# H100バッチ処理で1.10 t/s/W
# RTX 4060の小モデル (0.77 t/s/W) はH100バッチには及ばない
# だが単一リクエストではH100は24 t/s (帯域律速: 3.35TB/s / 140GB) → 0.034 t/s/W
# バッチ処理できない場合、RTX 4060の小モデルの方が電力効率が23倍高い
ここに面白い逆転がある。バッチ処理ができない用途（個人利用、リアルタイム対話）では、ローカルの小モデルがデータセンターGPUより電力効率で大幅に上回る。Qwen3.5 4B on RTX 4060の0.77 t/s/Wは、H100シングルリクエストの0.034 t/s/Wの23倍。バッチ処理ありのH100 (1.10 t/s/W) にはさすがに負けるが、それは32リクエストを同時に捌いている場合の話だ。個人利用で700WのGPUをフル稼働させるのは、エネルギーの浪費にほかならない。
電力の壁を攻める3つのアプローチ
HBM4記事（別記事）で帯域の壁に対する3層アプローチを書いた。電力の壁にも同じ構造がある。
Layer 1: チップレベルの電力効率改善
プロセス微細化 (5nm→3nm→2nm): 1世代で10-20%改善
電源回路の改善 (BSPDN裏面給電): IR降下30%削減 → 電圧マージン縮小 → 電力削減
→ 確実だが、Dennard scaling崩壊後は改善速度が鈍化
Layer 2: アーキテクチャレベルの電力効率改善
Sparse Attention: 不要な演算をスキップ → 電力削減
量子化 (INT8/INT4): ビット幅削減 → 演算電力を1/4-1/16に
MoE (Mixture of Experts): top-2-of-8で活性化パラメータを1/4に → メモリ帯域電力も1/4
→ ソフトウェアで即効性あり
Layer 3: 計算パラダイムの変更
PIM (Processing-In-Memory): データ移動を排除 → 電力の99.8%を攻撃
光演算 (Photonic computing): 光干渉で行列演算 → 電力消費がほぼゼロ
アナログ演算 (BrainScaleS-2等): デジタル変換を排除
→ 研究段階だが、最も根本的な解決
実効電力効率 = L1 × L2 × L3
Layer 2のMoE + INT4量子化だけで:
メモリ帯域電力を1/4 (MoE top-2-of-8) × 1/4 (INT4) = 1/16に
70Bモデルの実効電力が4.4Bモデル並みに
Layer 2が最も即効性がある。そしてこれは既にローカルLLMユーザーが実行可能だ。Q4_K_M量子化を使っている時点で、Layer 2の恩恵を受けている。MoEモデル（Mixtral、DeepSeek-V3）を選ぶことも、電力効率の観点では正しい選択だ。
ローカルLLMと電力効率
コンシューマGPUの優位性
# 電力効率の逆説
power_paradox = {
"通説": "データセンターGPUの方が電力効率が高い",
"現実": {
"バッチ処理あり": "H100 batch=32で1.10 t/s/W — RTX 4060小モデル (0.77) より上",
"シングルリクエスト": "RTX 4060 小モデルが23倍効率的 (0.77 vs 0.034 t/s/W)",
},
"理由": {
"H100の700W": "大半がアイドル状態のメモリとinterconnectに消費される",
"RTX 4060の65W": "モデルが小さいので帯域利用効率が高い",
},
"結論": "個人利用の文脈では、ローカルLLMは電力面でも合理的",
}
データセンターのGPUは「多数のリクエストを同時処理する」前提で設計されている。1人のユーザーが1つのリクエストを送る用途では、700Wの大半が無駄になる。RTX 4060で4Bモデルを動かす方が、シングルリクエストの電力効率では遥かに上だ。
RTX 4060で電力効率を最大化する実践
1. 小モデルを優先する
→ Qwen3.5 4B (3.4GB, ~65W) は Qwen2.5-32B (18GB, ~80W) の約4倍の t/s/W
→ タスクが許すなら、常に最小のモデルを使う
2. MoEモデルを選ぶ
→ 同じパラメータ数でも、活性化パラメータが少ないので電力が低い
→ Mixtral 8x7B は Dense 47B に対してパラメータ効率3-4倍
3. コンテキストを短く保つ
→ KVキャッシュの読み出しは電力を消費する
→ RAGで必要な部分だけ取得、全文を入れない
4. 推論が不要な時はGPUをアイドルにする
→ RTX 4060のアイドル消費は~10W
→ バックグラウンド推論を止めるだけで50-60W削減
参考文献
- "LIMINAL: Exploring The Frontiers of LLM Decode Performance" (2025) arXiv:2507.14397
- Dennard, R. H. et al. "Design of Ion-Implanted MOSFET's with Very Small Physical Dimensions" (1974) IEEE JSSC
- "The Efficiency Misnomer" — Patterson et al. (2021) arXiv:2110.11822
- NVIDIA B200 specifications (2025) — TDP 1000W, HBM3E 8TB/s