7月29日、mmmughが「How Much Does a Local LLM Actually Cost to Run? I Measured Every Watt on Apple Silicon」と題した記事を公開した。Apple Silicon(M3 Ultra)上でローカルLLMを動かす際の実電力消費と電気代を徹底実測した結果、「パラメータ数が多いほどコストが高い」という直感が現実には完全に裏切られるケースがあることが明らかになった。
最大の発見:120BモデルのトークンコストはQwen3.6-27Bの5分の1
Apple Siliconでローカル推論を使う理由の一つに「使い放題で事実上タダ」という感覚がある。しかし実際のところ、電気代はゼロではなく、しかもどのモデルを選ぶかで1桁変わる。
著者がM3 Ultra Mac Studio(統合メモリ96GB)で5つのモデルを測定した結果は以下の通りだ。電力測定には著者自作ツールTokenWattを使い、壁コンセントのスマートプラグ(Shelly Plug US Gen4)で実測値と照合済み。電気料金は$0.31/kWhで計算している。
※以下のモデル名・数値はすべて元記事の記載に基づく。
| モデル | パラメータ数 | タイプ | 速度 (tok/s) | 出力1Mトークンあたりコスト |
|---|---|---|---|---|
| Qwen3.5-4B | 4B | dense | 133.8 | $0.063 |
| Qwen3.6-35B-A3B | 35B | MoE(実効3B) | 76.0 | $0.087 |
| Qwen3-Coder-Next | 〜80B | MoE(実効3B) | 65.0 | $0.103 |
| gpt-oss-120b | 120B | MoE(実効5B) | 74.0 | $0.109 |
| Qwen3.6-27B | 27B | dense | 21.5 | $0.554 |
テーブルをコスト順に並べると、最も高コストなのは27BのdenseモデルであってMoEの120Bではない。しかもその差は約5倍。パラメータ数で選べば「27Bは120Bより小さいから安いはず」と判断するところだが、実際には逆だ。
![]()
なぜ大きいMoEモデルが安いのか
仕組みはシンプルだ。トークン1個あたりの電気代 = 消費電力 ÷ 生成速度(tok/s)。
denseモデルは1トークン生成するたびに全パラメータを読み出す必要がある。Qwen3.6-27Bは毎トークン約28GBのウェイトをメモリから読み出す計算になり、これが低速(21.5 tok/s)と高消費電力(138W)の両方を引き起こす。
一方、**MoE(Mixture of Experts)**は、トークンごとにルーターが一部のエキスパートのみを起動する構造だ。gpt-oss-120bは120Bのパラメータを持つが、1トークンあたり実際に活性化するのは約5B分のみ。さらに4〜6ビット量子化により、読み出すバイト数が一層少なくなる。結果として74 tok/s・94Wで動作し、同じ壁コンセントで計測した場合に27B denseより遥かに安く上がる。
Apple Silicon特有の「統合メモリ」アーキテクチャが、大きなMoEモデルをそもそも乗せられるようにしている点も重要だ。96GBの統合メモリがなければ、59GBを占有するgpt-oss-120bを展開することすらできない。
30日間の実トラフィックでも同じ傾向が出た
ベンチマーク(GPU飽和状態での連続生成)だけでなく、著者は1ヶ月間・約6,300リクエストの実際の利用ログも持っていた。
| モデル | リクエスト数 | 実トラフィック換算コスト(1Mトークン) |
|---|---|---|
| Qwen3.6-27B(dense) | 3,788件 | 〜$0.78 |
| Qwen3.6-35B-A3B(MoE) | 1,270件 | 〜$0.071 |
| Qwen3-Coder-Next(MoE) | 933件 | 〜$0.057 |
実運用では、アイドル時間やプロンプトトークンが加わるため、ベンチマークより1トークンあたりのコストは2〜3倍ほど高くなる。それでもdenseの27BはMoEの約10倍のコストという構図は崩れなかった。
測定ツールとApple Silicon固有の注意点
著者が公開したTokenWattは、OpenAI互換プロキシとしてローカル推論サーバーの前段に置くだけで動作する。Apple独自のIOReportインターフェースでSoC全体の電力を読み取り、アイドル電力を差し引いた「リクエスト増分コスト」を記録する。sudo不要、外部機材不要で動く。スマートプラグがあれば実測値に対するキャリブレーションも可能で、今回の測定では誤差±2.6〜4.5%を達成している。
uv tool install tokenwatt
tokenwatt serve --upstream http://127.0.0.1:8080 --rate 0.31
なお、いくつかApple Silicon特有の注意点がある。
- モデルを常駐させているだけで電力を消費する。大きなモデルを常時メモリに載せると、生成していなくても最大約21Wの常時電力がかかる。
- 96GBは物理的な上限。MoEは実効パラメータが少なくても、全エキスパートをメモリに乗せる必要があるため、フットプリントはモデル全体のサイズになる。
- この記事が計測しているのはあくまで「電気代のみ」。Mac Studio本体(現行モデルで$5,299〜)の償却コストは含まれない。クラウドAPIの価格と比較する場合も、ハードウェアコストが別途かかる点は考慮が必要だ。
まとめ:tok/sこそがコスト最適化の羅針盤
著者の結論は「品質基準を満たす中で最も速いモデルを選べ」に尽きる。Apple Siliconでは、統合メモリの広さとMoEアーキテクチャの組み合わせが、「大きいモデルの方がトークン単価が安い」という逆転現象を生む。
この視点で重要になるのがスループット(tok/s)という指標の使い方だ。tok/sは単なる「速さの快適さ」を示す数字ではなく、トークンあたりコストを決める直接の変数として機能する。上式(コスト = 消費電力 ÷ tok/s)が示す通り、同じ電力消費であれば tok/s が2倍になればコストは半分になる。モデルを選定する際には、まずベンチマークや公開されているモデルカードでtok/sの目安を確認し、次に実環境でTokenWattのような計測ツールを走らせてトークン単価を実測するというワークフローが、実コスト最小化への最短経路となる。パラメータ数でモデルを比較する習慣を、スループットで比較する習慣に切り替えることが、Apple Silicon上でのローカルLLM運用コストを抑える上で最も効果的な一手だ。
詳細はHow Much Does a Local LLM Actually Cost to Run? I Measured Every Watt on Apple Siliconを参照していただきたい。