Apple SiliconでLLMを回すとどれだけ省エネか？——M4 Pro実測で見えた「データセンターGPU比30〜40倍」のエネルギー効率

はじめに：LLMの環境負荷と「ローカルで回す」ことの価値

大規模言語モデル（LLM）の環境負荷をめぐる議論は、これまで「訓練（トレーニング）」のコストばかりに注目が集まってきました。しかしLuccioniらの研究によれば、実は推論（inference）＝学習済みモデルに質問して回答を生成する処理が、ライフサイクル全体のエネルギー消費の60〜90%を占めるといいます。訓練は一度きりでも、推論はモデルが運用されている間、毎日繰り返し実行され続けるためです。

訓練コストが大きいのも事実です。GPT-3の訓練には1,287MWhの電力が使われたと報告され（Patterson et al.）、Transformerモデルを1回訓練するだけで「車5台の生涯CO2排出量に相当する」という試算（Strubell et al.）もあります。ただし、こうした訓練への関心の一方で、毎日数百万件のクエリを処理する推論側の累積インパクトは近年急速に増大しています。

データセンター向けGPU（NVIDIA H100など）は1枚で数百Wを消費する高消費電力デバイスですが、大量のリクエストをバッチ処理して稼働率を高めることでコストを回収する設計になっています。ところが個人利用・低ボリューム用途ではこの前提が崩れます。「自分のために1件ずつ応答を生成する」使い方ではバッチ処理の恩恵を受けられず、アイドル時の電力まで含めると効率が大きく落ちるためです。

こうした背景から、ローカル推論の需要が広がっています。医療・金融などデータ主権（データを自組織・自国内で管理する要件）やプライバシー保護が求められる領域、オフライン環境での利用、そしてOllamaやllama.cppのようなツールによるローカル試作の一般化が主な要因です。Macをはじめとする個人向けハードウェアでLLMを動かす選択肢が、現実味を帯びています。

本記事では、2026年8月に公開されたGreenBench（arXiv:2608.28667）の実測データをもとに、「Mac＋ローカルLLMは環境負荷の観点でどれだけ優位か」「どのモデルを選ぶべきか」を、単一ユーザー利用という前提を明確にしながら解説します。

なぜApple Siliconなのか：統一メモリ（UMA）の仕組み

Apple Siliconとは、M1/M2/M3/M4系に代表されるApple製SoC（System on a Chip）の総称です。CPU・GPU・Neural Engine（機械学習専用回路）を1つのチップに統合し、これらすべてが1つの物理メモリプールを共有する設計を採用しています。この仕組みをUMA（Unified Memory Architecture、統一メモリアーキテクチャ）と呼びます。従来のPCのように「CPU用メモリ」と「GPU用VRAM」が別々に存在するのではなく、モデルの重みも推論の中間データも、すべて同じメモリ上に載るのが最大の特徴です。

ディスクリートGPU（専用グラフィックスカード）との違いは、データ経路にあります。従来構成ではGPUで推論するために、モデルの重みをCPUメモリからPCIeバス経由でGPU VRAMへコピーする必要があります。例えば9Bモデルなら約5.4GBの転送が毎回発生し、推論開始までの待ち時間や帯域の消費につながります。一方UMAはCPUとGPUが同じメモリを直接参照できるため、このコピーが一切不要になります。これをゼロコピーと呼び、転送にまつわる遅延と電力がそっくり省かれます。

flowchart LR
    subgraph Discrete["ディスクリートGPU構成"]
        A["CPUメモリ<br/>（モデルの重み）"] -->|"PCIeバス経由で<br/>コピーが必要"| B["GPU VRAM"]
        B --> C["GPUで推論"]
    end
    subgraph Uma["Apple Silicon（UMA）"]
        D["CPU・GPU・<br/>Neural Engine"] -->|"ゼロコピー<br/>（転送不要）"| E["48GB 統一メモリ<br/>（重み・KVキャッシュ）"]
    end

なぜこれがLLM（大規模言語モデル）の実行に効くのでしょうか。LLMの推論は、プロンプトを一括処理する「プリフィル」と、トークンを1つずつ生成する「デコード」に分かれます。デコードでは毎回モデルの全重みをメモリから読み出すため、処理時間はほぼメモリ帯域幅で決まります（メモリ帯域幅律速）。M4 Proは273 GB/sという高い帯域を持ち、UMAならその帯域を転送オーバーヘッドなしにそのまま推論へ投入できます。転送待ちが発生しない点こそ、Apple SiliconがLLM実行に最も効果を発揮する理由です。

容量の面でもUMAは有利です。Q4_K_M量子化された9Bモデルは約5.4GBですが、8GB VRAMのディスクリートGPUでは、これに加えて推論用のKVキャッシュを確保するのが難しく、ロードすらままならない場合があります。一方、48GBの統一メモリを持つM4 Proなら余裕で動作し、複数のモデルを切り替えながら保持することも可能です。下表のとおり、UMAは「転送しない・帯域を活かす・容量が大きい」という3点で、ローカルLLMのプラットフォームとして理にかなっています。

GreenBenchとは：何を・どう測ったのか

GreenBenchは、Apple Silicon上で動作するオープンソースLLMの推論について、エネルギー効率・スループット（1秒あたりの生成トークン数）・CO2排出量を初めて体系的に実測したベンチマークフレームワークです。IEEE ICCUBEA 2026（国際会議）に採録された論文（arXiv:2608.28667）として2026年8月に公開され、実装コードはGitHub上でMITライセンスにより公開されています。従来のGreen AI研究はデータセンターGPUや組み込みボードを対象にしていましたが、数千万台が普及するApple SiliconのLLM推論エネルギーを実測した点が最大の新規性です。

測定環境はMacBook Pro（Apple M4 Pro / 12コアCPU / 16コアGPU / 48GB統一メモリ / macOS 15.4）で、推論エンジンにはOllama v0.21.2（llama.cppベースのローカルLLM実行ツール）を使用しています。48GBの統一メモリ（UMA）はモデルの重みと推論データを1つのメモリプールに載せられるため、8GB VRAMのGPUではロードが難しい9B量子化モデルも余裕で実行できます。

対象モデルは、オープンソース系譜を広くカバーする3〜9Bの5ファミリーです。すべてQ4_K_M量子化（4ビット量子化の一種で、Ollamaのデフォルト設定）を用いており、多くの実ユーザーが実際に動かしている構成と同一です。

ベンチマークタスクは、出力長が異なる3パターンです。短答の知識問題「MMLU」（100問）、中長文の「CNN/DailyMail要約」（50件）、長文構造化出力の「HumanEvalコード生成」（164問）を実行し、合計1,500以上の推論レコードを収集しました。

再現性の確保も徹底しています。すべての実験でtemperature=0（サンプリングを決定的にし、同じ入力には常に同じ出力を返す設定）を採用し、各バッチ前にウォームアップ推論を1回実施。モデルは1つずつメモリに保持し、次のモデルをロードする前にアンロードすることで、メモリ競合や熱の持ち越し（サーマルキャリーオーバー）による測定値のブレを排除しています。誰が・いつ実行しても同じ結果が得られるよう制御されている点が、GreenBenchの信頼性の根幹です。

どうやって電力を測ったのか：powermetrics × Ollamaタイミングの二重測定

LLMの消費電力を測るのは、実は簡単ではありません。壁面電力計はMacBook本体の引き込み電力は教えてくれますが、「CPUなのかGPUなのか、メモリなのか」という内訳は分かりません。メーカー公称のTDP（熱設計電力）も最大負荷時の目安であり、実際の推論負荷での消費電力は分からないため、実測が不可欠です。GreenBenchはこの課題に対し、デュアルソース測定という2つの独立した測定源を組み合わせる手法で答えました。

1つ目の測定源は、macOS標準のpowermetricsコマンドです。これはIOReportフレームワーク経由でCPUとGPUのパッケージ電力を2秒間隔で直接サンプリングします（実行にはsudo権限が必要）。2つ目の測定源は、Ollama APIが返すナノ秒精度のタイミング情報です。出力トークンの生成時間（eval_duration）と生成トークン数（eval_count）から、1トークンあたりの生成時間ℓ = eval_duration ÷ eval_countを算出します。

sequenceDiagram
    participant PM as powermetrics
    participant M as MacBook Pro (M4 Pro)
    participant OA as Ollama API
    participant CALC as エネルギー計算
    PM->>M: 2秒間隔でCPU+GPUパッケージ電力をサンプリング
    OA->>M: 推論リクエスト送信
    M-->>OA: eval_duration / eval_count を返却
    OA->>CALC: 1トークンあたり時間 ℓ を渡す
    PM->>CALC: 推論時の電力 P を渡す
    CALC->>CALC: E = P × ℓ でエネルギーを算出

この二重測定からは、GreenBenchの興味深い省エネぶりが浮かび上がります。アイドル時はCPU 237mW + GPU 30mW = 267mWでしたが、LLM推論時は平均413mW（CPU 298mW + GPU 115mW）、ピークでも474mW（CPU 411mW + GPU 167mW、約0.47W）しか増えていません。GPUはアイドル時の338MHzからクロックアップして115〜167mWを消費します。ただし、この数字はCPU+GPUパッケージのみの測定値であり、DRAMや周辺機器の電力は含まれない点に注意が必要です。

1トークンあたりのエネルギーは、電力とタイミングを掛け合わせて計算します。パッケージレベルでは E = 0.47W × トークン時間ℓ、システムレベルでは E = 10W × トークン時間ℓです。システム電力の10Wは、Appleの熱設計仕様と先行研究の実測値（6.5〜8.2W）から推定したものであり、確定値ではありません。

CO2排出量への換算も同じ測定パイプラインの中で行われます。消費電力にグリッド炭素強度（電力1kWhあたりのCO2排出量。インドは708g、米国は390gなど）を掛けることで、同じハードウェアでも電力の「出自」によって炭素フットプリントが変わることを地域別に示せるのです。このように、電力（powermetrics）と時間（Ollama API）という異なる2つの測定を並走させることで、「どこで・どのくらい」電力を消費しているかを分解し、モデル間の公平な比較が可能になっています。

実測結果その1：M4 Proは本当に「0.47W」で推論できるのか

結論から言えば、「0.47W」は事実です。ただし、その内訳を正確に読む必要があります。GreenBenchの測定では、アイドル時のCPU+GPUパッケージ電力が267mW（CPU 237mW + GPU 30mW）だったのに対し、LLM推論時は平均413mW（CPU 298mW + GPU 115mW）、ピークでも474mW（CPU 411mW + GPU 167mW）にしかなりませんでした。推論による電力の増分は約0.15〜0.21Wで、丸めて「約0.47W」と表現されています。GPUがアイドル時の338MHzからクロックアップして115〜167mWを消費することを踏まえても、これは「ほぼ誤差」レベルの増分です。

ただし、この数字はCPU+GPUパッケージのみを対象にした測定値です。powermetricsで計測される範囲には、DRAM（メモリ本体）やメモリコントローラ、ディスプレイやWi-Fiなどの周辺機器が含まれていません。LLMの推論はメモリ帯域幅律速のため、実はDRAMがエネルギーのかなりの部分を占める可能性があり、システム全体の消費電力は8〜12W程度と見積もられています（Appleの熱設計仕様と先行研究の実測値6.5〜8.2Wから推定した値であり、確定値ではありません）。

データセンターGPUと比べると、この数字の意味が際立ちます。NVIDIA H100は1枚あたり約400Wを消費しますが、M4 Proのシステム全体は8〜12W。ノートPCの充電器1つで余裕を持って賄える水準であり、単一ユーザーがローカルで推論する用途には桁違いに小さな電力で済むことを示しています。

電力に加えて、1トークンあたりのエネルギーも見てみましょう。システムレベルではモデルにより0.09〜0.25 J/tokenとなり、これは1ワットあたり4〜12トークンを生成できることを意味します。最も効率的なLlama 3.2（3B）は0.09 J/tokenで約11トークン/W、最大のGemma 2（9B）でも0.25 J/tokenで約4トークン/Wという計算です。

家庭での体感に換算すると、次のようになります。システム10Wで24時間ぶっ通しで推論を回しても消費電力は0.24 kWh/日です。日本の電気代（目安40円/kWh）で計算すると1日あたり10円前後、月額300円程度に収まります。「自宅サーバーでAIを常時稼働させる」という選択肢が、電気代の観点からは十分に現実味を持つ数字です。

実測結果その2：データセンターGPUと比べてどれだけ効率がいいか

M4 Proの省エネぶりは「絶対値」だけでなく、他のプラットフォームとの比較でも際立ちます。GreenBenchは論文の表VIとして、M4 Pro・Raspberry Pi 4・NVIDIA H100の実測値を「システムレベル1トークンあたりのエネルギー（J/token）」に揃えて並べています。基準になるのは、M4 ProでLlama 3.2（3B・Q4_K_M量子化）を動かしたときの0.09 J/tokenです。

まず小型エッジデバイスとの比較です。Raspberry Pi 4でQwen 0.5Bを動かすと2.61 J/tokenで、M4 Proの29倍ものエネルギーを消費します。注目すべきは、Pi 4が実行しているモデルが0.5BとM4 Proの3〜9Bモデルより6〜18倍小さいにもかかわらず、この結果だという点です。モデルが小さいほど1トークンあたりのエネルギーは下がるため、同じモデルサイズで比べれば差はさらに開くと考えられます。

一方、データセンターGPUの代表格であるNVIDIA H100（消費電力約400W）で7Bモデルを動かした場合の実測値は約4.0 J/token。M4 ProのLlama 3.2（3B）の約44倍で、M4 Proで最も電力を食うGemma 2（9B・0.25 J/token）と比べても約16倍です。これを総合して論文が導いた結論は、「単一ユーザー・単一リクエストのローカル展開では、M4 ProはデータセンターGPU比で1トークンあたり30〜40倍のエネルギー効率」というものです。この前提が崩れるのは、データセンターGPUが「大量リクエストをバッチ処理して稼働率を高める」ことで高消費電力を回収する設計だからです。個人の逐次利用では過剰スペックとなり、アイドル時の電力まで含めると効率は大きく落ちます。

xychart-beta
    title "1トークンあたりのエネルギー比較（J/token）"
    x-axis ["M4 Pro (Llama 3.2)", "RPi 4 (Qwen 0.5B)", "H100 (7B)"]
    y-axis "J/token" 0 --> 4.5
    bar [0.09, 2.61, 4.0]

最後に、この比較を「ハードウェア性能」と「実効効率」の違いとして捉える視点も重要です。同じH100でも、推論エンジン（vLLM / TensorRT-LLM / DeepSpeedなど）の選択によってエネルギー/トークンが25〜55%変動するという研究があります。つまり、30〜40倍という数字はあくまで現時点の実測構成での差であり、ソフトウェア側の最適化次第でデータセンター側の効率が向上する余地も残されていることを意味します。

実測結果その3：モデルサイズとスループット・エネルギー

モデルサイズは、スループット（1秒あたりに生成できるトークン数）と1トークンあたりのエネルギーにどう影響するのか。GreenBenchは3〜9Bの5モデルを、同じM4 Pro・同じ量子化（Q4_K_M）・同じ3タスクで動かし、サイズと性能の関係を定量的に切り分けました。ここから見えてきたのは、「小さいモデルほど速く、かつ省エネ」というある意味で予想どおりの傾向でありながら、その度合いを数式で予測できるほど規則的だという点です。

まず、スループットはモデルサイズに対して冪乗則（スケーリング則）に従って低下します。実測値から導かれた式は θ ≈ 340 × N^-0.85（θ=スループット、N=パラメータ数、R²=0.94）です。R²=0.94という高い決定係数は、この関係がほぼ例外なく成り立つことを示しています。背景にあるのは「メモリ帯域幅律速」というLLM推論の本質です。トークン生成（デコード）は重みをメモリから読み出す処理が支配的で、モデルが大きいほど読み出す重みの総量が増えるため、スループットは予測可能な形で落ちていきます。逆に言えば、この式があれば未測定のモデルサイズでも速度を推定でき、サーバー選定などのキャパシティプランニングに応用できます。

実際の数値でも、小モデル（3〜3.8B）は大モデル（7〜9B）より2.6〜4.2倍高いスループットを示し、1トークンあたりのエネルギーは最大62%少なくなりました。

最も極端な例がLlama 3.2（3B）です。MMLUで175.9 tok/sを記録し、これは最大モデルであるGemma 2（9B・42.0 tok/s）の4.2倍に相当します。コード生成でも91.3 tok/sを維持しており、小モデルが「速度の武器」になることを如実に示しています。

一方、スループットはタスクによっても変動します。短い回答を返すMMLU（出力約15トークン）は、長いコードを生成するタスク（出力約200トークン）より1.5〜2倍高速でした。これは、出力が長くなるほどKVキャッシュ（生成済みトークンのkey/value情報を保持するメモリ領域）が肥大化し、デコード時のメモリトラフィックを増やすためです。同じモデルでも「何を生成させるか」で実効速度は変わる、という点は実運用上の重要な知見です。

最後に注意すべき例外があります。Qwen 2.5（7B）はMMLUで96.9 tok/sと高速な一方、要約タスクでは46.2 tok/sまで52%も低下し、タスク間の差が他モデルより顕著でした。原因と推定されているのは、SwiGLU+GQAというアーキテクチャがMetalバックエンドでカーネルディスパッチ（処理単位の投入オーバーヘッド）を生じやすいことです。つまり「7Bだから同じような特性」とは限らず、同じサイズでもアーキテクチャ次第で性能の顔つきが変わることを示しています。

どのモデルを選ぶべきか：Pareto分析の実践的読み解き

ベンチマークで測った精度・スループット・エネルギーを、いざ「どのモデルを自分のMacで動かすか」という選定に落とし込むにはどうすればよいでしょうか。ここで有効なのがPareto分析です。Pareto分析とは、精度と効率（スループット・エネルギー）という複数の軸の上で、どのモデルも「他よりすべての面で優れる」とは言い切れない中、どの軸でも他に負けない候補（Paretoフロント）を特定し、トレードオフを可視化する手法です。5モデルの実測結果を、横軸にMMLU精度、縦軸にスループットを取ってプロットすると、選定の論点が一目で分かります。

%%{init: {'theme':'neutral'}}%%
quadrantChart
    title MMLU精度 × スループット（M4 Pro / Q4_K_M）
    x-axis "精度が低い" --> "精度が高い"
    y-axis "遅い" --> "速い"
    quadrant-1 "高精度・高速"
    quadrant-2 "低精度・高速"
    quadrant-3 "低精度・低速"
    quadrant-4 "高精度・低速"
    "Llama 3.2 (3B) 41% / 115.2 tok/s": [0.41, 1.0]
    "Phi-3 (3.8B) 29% / 91.1 tok/s": [0.29, 0.79]
    "Qwen 2.5 (7B) 57% / 59.0 tok/s": [0.57, 0.51]
    "Mistral (7B) 24% / 45.8 tok/s": [0.24, 0.40]
    "Gemma 2 (9B) 61% / 42.0 tok/s": [0.61, 0.36]

この散布図からParetoフロントを引くと、右上方向（高精度・高速）に位置するのはQwen 2.5（7B）とGemma 2（9B）の2つだけです。Gemma 2は精度61%と最高ですがスループットは42 tok/s、一方のQwen 2.5は精度57%で59 tok/sと、精度では最大モデルの93%を維持しながらスループットで40%上回り、1トークンあたりのエネルギーも19%少なく抑えています。つまり両者の差は「精度4ポイント」か「速度4割＋省エネ2割」かの選択であり、特にエッジ端末での逐次利用を考えるとQwen 2.5（7B）がバランスの最適解になります。一方、Llama 3.2（3B）は精度41%と低いものの115.2 tok/sと最速で、これは「速さ最優先」という別の使い方を示唆します。

対照的なのがMistral（7B）です。精度24%・スループット45.8 tok/sと両軸で他モデルに劣り、Pareto分析では「支配的（Dominated）」、すなわち選ぶ理由のないモデルと判定されます。MMLU精度24%は4択問題のランダム回答（25%）すれすれであり、これはQ4_K_M量子化とzero-shotプロンプトの相性が悪かったためと推定されています。量子化やプロンプト手法を変えれば結果は変わりうるため、この結果は「Mistral 7Bは使えない」という断定ではなく、「この構成では支配的だった」という条件付きの知見として読むべきです。

実践的な選び方は、用途に応じた3パターンに整理できます。精度と効率のバランスを取るならQwen 2.5（7B）で、最大モデルの93%の精度を、40%高いスループットと19%低いエネルギーで実現します。低遅延・リアルタイム用途（チャットUIや対話型エージェントなど応答速度が体感に直結する場面）ならLlama 3.2（3B）で、Qwen 2.5の精度の2/3を維持しながら3倍の速度・半分以下のエネルギーで動きます。最高精度重視ならGemma 2（9B）ですが、Qwen 2.5との精度差はわずか4ポイントなので、48GBのメモリを余裕で使える場合や精度が最優先のタスクに限定するのが賢明です。いずれにせよ、モデル選定の基準に「精度」だけでなく「1秒あたりのトークン数」と「1トークンあたりのエネルギー」を並べることで、速く・省エネなローカルLLM運用の設計が可能になります。

炭素フットプリント：1,000トークンあたりのCO2はどれだけか

電力量が分かれば、次に気になるのはCO2排出量（炭素フットプリント）です。GreenBenchは、システムレベルのエネルギー消費（J/token）にグリッド炭素強度（その地域の電力1kWhを生み出す際に排出されるCO2量、単位はg CO2/kWh）を掛け合わせて排出量を推定しました。M4 Proの実測では、モデルにより1,000トークンあたり0.18〜0.48 mg CO2。最小のLlama 3.2（3B）で0.18 mg、最大のGemma 2（9B）で0.48 mgです。内訳は以下の通りです（インド・グリッド708 g/kWh適用時）。

見落とせないのがグリッド炭素強度の地域差です。同じハードウェアを同じように動かしても、電力の「出自」によって排出量は大きく変わります。インドは708、米国は390、EU平均は295、フランスは55 g CO2/kWhで、フランスならインドの約13分の1の排出で済みます。環境負荷を論じる際に地域別の比較が欠かせない理由がここにあります。

解釈の注意も必要です。この数値は実行時の排出（scope 2）の推定であり、チップ製造や輸送などの間接排出（scope 3）は含まれていません。とはいえ、単一ユーザーが一台のMacを使い続ける用途では実行時の排出が全体の大部分を占めるため、指標として十分に意味を持ちます。

最後に、クラウドのGPUを借りる場合との比較視点です。クラウド側では、データセンターのPUE（電力使用効率。PUE 1.5ならIT機器の消費電力の1.5倍の電力が施設全体で必要になるという意味）や、その立地のグリッド構成も排出量に加わるため、単純に「GPUの定格電力」だけで比較するのは不正確です。ただし、利用頻度が低い個人用途では、アイドル時の消費まで含めるとローカル実行のほうが総排出量は小さくなる傾向にあります。「どちらが環境にいいか」は、利用頻度・地域・施設効率の3点を組み合わせて判断するのが妥当です。

自分のMacで再現するには：GreenBenchの使い方

GreenBenchの測定は、Apple Silicon Macを持っていれば誰でも追試できます。コードはGitHub（rajfirke/GreenBench）でMITライセンス公開されており、Pythonスクリプトとシェルスクリプトで構成されています。前提環境はApple Silicon搭載Mac（M1〜M4、16GB以上の統一メモリ）、macOS 13以降、そしてOllama（llama.cppベースのローカルLLM実行ツール）のインストールです。

再現の流れは次のとおりです。まずリポジトリをクローンし、ollama pullでLlama 3.2（3B）・Phi-3・Qwen 2.5（7B）・Mistral・Gemma 2（9B）の5モデルを取得します。続いてscripts/setup.pyがMMLUやCNN/DailyMail、HumanEvalのデータセットをダウンロードし、scripts/run.pyでベンチマークを実行、最後にscripts/analyze.pyでサマリーテーブルを生成します。

flowchart LR
    A[リポジトリをクローン] --> B[ollama pull で5モデル取得]
    B --> C[scripts/setup.py<br/>データセットDL]
    C --> D[scripts/run.py<br/>ベンチマーク実行]
    D --> E[scripts/analyze.py<br/>結果集計]
    B --> F[sudo scripts/measure_power.sh<br/>powermetricsで電力測定]

電力測定にはsudo bash scripts/measure_power.sh <モデル名>を使います。このスクリプトはpowermetrics（macOS標準の電力計測コマンド）を2秒間隔で駆動し、アイドル→推論→クールダウンの3フェーズで電力の推移を記録します。sudoが必要なのは、powermetricsが管理者権限を要求するためです。

自分の環境に合わせて値を変えたい場合は、.envファイルで3つの定数を上書きできます。デフォルト値は論文の測定環境（M4 Pro）に基づきます。

グリッド炭素強度は「電力1kWhあたりのCO2排出量」で、インド708・米国390・EU平均295・フランス55（いずれもg CO2/kWh）などが参考値として用意されています。自分の電気の出自に合わせて書き換えればCO2換算の精度が上がります。モデルを追加したい場合はconfig.pyのリストに追記するだけでよいです。

実行結果はJSONL形式（JSON Lines、1行に1件のデータを並べたテキスト形式）で出力され、モデル名・タスク・トークン数・スループットに加え、1トークンあたりのエネルギー（パッケージ/システム別）とCO2排出量が記録されます。再現性への配慮も徹底しており、温度0で決定論的な出力に固定し、各タスク前にウォームアップ推論を1回挟み、モデルは1つずつロードしてメモリ競合を防ぎます。途中失敗時のレジューム（再開）機能と乱数シード固定も備わるため、同じ手順を踏めば論文と同じ数値が手元で再現できるはずです。

この研究の限界：数字を正しく読むために

ここまで「0.47W」「30〜40倍効率」といったインパクトの大きい数字を見てきましたが、これらはすべて特定の測定条件のもとで得られたものです。結論を過大評価しないために、GreenBenchが論文内で明示している限界を整理しておきます。

まず最も重要な注意点が、DRAM電力が未計測であることです。今回の0.47Wは、macOSのpowermetricsが報告するCPU+GPUパッケージのみの電力で、メモリ（DRAM）・メモリコントローラ・周辺機器は含まれていません。LLMの推論はメモリ帯域幅律速（メモリから重みを読み出す速度が処理時間を決める特性）であるため、実はDRAMが全体のエネルギーのかなりの部分を占める可能性があります。本記事で使ったシステム全体8〜12Wという値も推定値であり、先行研究（Jareño et al.の実測6.5〜8.2W）とは整合するものの確定値ではありません。

二つ目は、Q4_K_M量子化のみで測定している点です。量子化とはモデルの重みを低精度の数値に圧縮する手法で、Q4_K_MはOllamaのデフォルト設定（4ビット精度）を指します。量子化レベルを変える（Q3やQ5、FP16など）と、モデルの精度とエネルギー消費のバランスは変わります。したがって「このモデルはこれだけ効率的」という結論は、あくまでQ4_K_Mという特定の設定下での話です。また、精度評価に使ったMMLUは100問のサブセット（フルセットは14,042問）であり、統計的なばらつきを含む点にも注意が必要です。層化抽出で代表性は確保されていますが、数ポイントの精度差は誤差の範囲と見るべきでしょう。

三つ目は測定シナリオの限定性です。測定は単一ユーザー・単一リクエストの逐次推論であり、複数リクエストをまとめて処理するバッチ推論や同時実行では、メモリ競合の影響で特性が変わります。さらに対象はM4 Pro 48GBモデルの1台のみ。M4やM4 Max、iPadのM系列はコア数・メモリ帯域幅・熱設計が異なるため、今回の数値をそのまま外挿（当てはめ）することはできません。

まとめると、本記事の数字を読むときは「0.47Wはフルシステムの消費電力ではない」という一点を常に意識してください。パッケージ測定値（0.47W）とシステム推定値（8〜12W）の区別を明確にしたうえで比較するのが、この研究を公平に活用するための正しい作法です。限界はあるものの、単一ユーザーのローカル推論という典型的な用途に対しては、データセンターGPU比のエネルギー優位という定性的な結論は十分に頑健だといえます。

まとめ：ローカルLLMの「省エネ優位」は本物か

結論から言えば、ローカルLLMの省エネ優位は「本物」です。ただし、その優位が成り立つのは単一ユーザー・逐次推論という典型的なローカル利用の前提の下であり、この条件を外すと話は変わります。本記事で見てきた実測データを、3つの主要な発見として整理します。

一つ目はエネルギー効率の圧倒的な差です。M4 ProはCPU+GPUパッケージ約0.47W・システム全体8〜12Wという消費電力で3〜9BのLLMを推論できます。システムレベルの1トークンあたりエネルギー（J/token。トークン＝LLMが扱う最小のテキスト単位を1つ生成するのに必要なエネルギー）は0.09〜0.25 Jで、データセンター向けGPUのH100（約4.0 J/token）と比べると、単一ユーザー用途では30〜40倍のエネルギー効率に相当します。

二つ目は、モデルサイズと効率の関係が予測可能なスケーリング則に従うという発見です。スループット（1秒あたりの生成トークン数）はθ ≈ 340 × N^-0.85（Nはパラメータ数、R²=0.94）で近似でき、小モデル（3〜3.8B）は大モデル（7〜9B）より最大4.2倍高速で、エネルギーは最大62%少なくて済みます。つまり「小さなモデルほど省エネ」は体感ではなく、数式で裏付けられた傾向です。

三つ目はモデル選定の指針です。精度と効率のバランスではQwen 2.5（7B、MMLU 57% @ 59 tok/s）が最適解、低遅延・リアルタイム用途ではLlama 3.2（3B、175 tok/s超）が最適解となり、用途に応じて使い分けるのが合理的です。

この研究の意義は、Green AI（環境負荷を考慮したAI開発・評価の潮流）の文献がデータセンターGPUや組み込みボードに偏っていた中で、Apple Siliconという消費者ハードウェアのエネルギー特性を体系化した初のベースラインを提供した点にあります。併せて論文が示唆するのは、J/tokenを精度・スループットと並ぶ標準指標として採用すべきだということです。推論がMLシステムのライフサイクルエネルギーの60〜90%を占めるという前提に立てば、「自宅サーバーでAIを回す」選択は、環境負荷の観点からも十分に理にかなっています。

もっとも、課題も残っています。測定はM4 Pro 48GBの1台・Q4_K_M量子化・単一リクエストに限定されており、今後の展望としてM4 Maxでの測定、Q3〜FP16の量子化スイープ（量子化レベルの網羅的な比較評価）、バッチワークロードの評価が挙げられています。数字を読む際は「0.47Wはパッケージのみ」「30〜40倍は単一ユーザー前提」という条件を常に意識してください。それを踏まえても、「ローカルLLMは環境に優しい選択肢である」という定性的な結論は、今回の実測によって十分に裏付けられたと言えるでしょう。

よくある質問

0.47Wという数字は「Mac全体」の消費電力ですか？

いいえ。0.47WはCPU+GPUパッケージのみの測定値で、powermetricsが報告するCPUとGPUの電力増分だけを合計したものです。DRAM（メモリ）やメモリコントローラ、ディスプレイ・Wi-Fiなどの周辺機器は含まれていません。システム全体の消費電力は推定8〜12Wで、他社の実測値（6.5〜8.2W）とも整合する水準ですが、あくまで推定値です。記事内の比較では、このシステムレベル（J/token）を使うのが正確です。

MacでLLMを動かすと電気代はどのくらいかかりますか？

システム消費電力を10Wと仮定すると、24時間稼働させても0.24 kWh/日です。日本の電気代を1 kWhあたり40円（目安）とすると1日約10円、月に換算しても300円前後というオーダーになります。モデルや利用頻度によって多少変わりますが、数百Wを消費するデータセンターGPU（例：H100は約400W）と比べると桁違いに小さなコストです。

データセンターGPUより本当に30〜40倍効率がいいのですか？

条件付きで「はい」です。単一ユーザー・逐次推論というローカル利用の前提で比較すると、M4 Proは1トークンあたりのエネルギーでH100比16〜44倍（代表値として30〜40倍）、Raspberry Pi 4比10〜29倍の効率を示しています。ただし、データセンターGPUは多数のリクエストをバッチ処理して稼働率を高めることで高消費電力を回収する設計であり、混雑したサーバーで大量の推論を裁く用途では比較の前提そのものが変わります。「30〜40倍」は個人が1台のMacで使う場面に限定された数字だと理解してください。

どのモデルを選べばいいですか？

用途によって最適解は変わります。精度と効率のバランスを重視するならQwen 2.5（7B）が第一候補で、MMLU 57% @ 59 tok/sと、最大モデル（Gemma 2 9B）の精度の93%を維持しつつ、スループットは40%高く、エネルギーは19%少なく済みます。低遅延・リアルタイム用途ならLlama 3.2（3B）が適しており、175 tok/s超の速度でQwen 2.5の精度の3分の2を保ちながら、エネルギーは半分以下です。最高精度だけを求めるならGemma 2（9B、MMLU 61%）ですが、Qwen 2.5との精度差は4ポイント程度に過ぎません。

このベンチマークを自分のMacで再現できますか？

できます。GreenBenchはGitHub（rajfirke/GreenBench）でMITライセンス公開されており、OllamaとmacOS標準のpowermetricsを使うため、特別な測定機器は不要です。Apple Silicon Mac（M1〜M4、16GB以上の統一メモリ）+ macOS 13以降 + Ollamaが前提条件で、自分のマシンの実測電力と地域のグリッド炭素強度を設定ファイルで指定すれば再実行できます。再現性を高める工夫（温度0での決定論的出力、ウォームアップ、モデルを1つずつロード）も組み込まれているため、手順に沿えば同じ結果を追試できます。

参考資料

• GreenBench 論文（arXiv Abstract）: https://arxiv.org/abs/2608.28667
• GreenBench 論文（HTML全文・CC BY 4.0）: https://arxiv.org/html/2608.28667v1
• GreenBench 公式リポジトリ: https://github.com/rajfirke/GreenBench
• Patterson et al., "Carbon emissions and large neural network training": https://arxiv.org/abs/2104.10350
• "Scaling Behavior of Energy per Token in LLM Inference on Apple Silicon"（IEEE）: https://ieeexplore.ieee.org/document/11569440/
• "Information-Geometric Energy Efficiency in Local Large Language Model Inference..."（preprints.org）: https://www.preprints.org/manuscript/202605.0855/v1
• "Sovereign LLM Inference in the Era of Digital Sobriety..."（IEEE）: https://ieeexplore.ieee.org/document/11633138/
• "Offline Energy-Optimal LLM Serving..."（ACM）: https://dl.acm.org/doi/10.1145/3727200.3727217
• "DynamoLLM: Designing LLM Inference Clusters..."（IEEE）: https://ieeexplore.ieee.org/document/10946802/
• "Weight-Only Quantization Does Not Always Save Energy..."（SSRN）: https://www.ssrn.com/abstract=6854700

関連記事

• 3BエージェントモデルをApple Siliconで本当に動かす──Nanbeige4.2-3Bの5つの落とし穴とメモリ2.7倍化テクニック
• ホームラボでローカルLLMを動かす構成例——12GB・24GB・48GB VRAM別のモデル、速度、消費電力、費用