80Bモデルを14インチMacBook Pro（M5 Max）で使い倒す — 「動く」と「使える」の間にあるもの

M5 Max 14インチ、128GBモデルが届いた。開封してセットアップを進めつつ、ひたすらローカルLLMの環境構築と検証も回している。

やりたかったのは、手元のマシンでLLMを動かし、端末内で自律的に処理が進む環境。クラウドAPIに毎月払い続けるのではなく、試行錯誤を何度でも回せる環境。コードを外部に送らずに済む。回線が切れても動く。もちろん有事の際に外部リソースにアクセスできなくても電源があれば動く。その魅力は前から感じていて、128GBのUnified Memoryが現実的（？）な価格で手に入るようになった今、試さない理由がなかった。というか、手元のマシンは現役16GBながらM1 Airだし、言うなればiPhoneだけでManusや自分で作ってるVPSなどクラウド側に処理を振れば済む事も多いのだが、目先のメモリー高騰や端末自体の入手困難性など考えると現行世代の筐体の最終型なら長く使えると考えた。

RedditやMacRumorsでは「14インチは100度超える」「サーマルスロットルで性能が出ない」という声がある。NotebookCheckのレビューでも「14インチの筐体と冷却ではM5 Maxを十分に扱えない」と指摘されている。結論から言えば、私の環境では100度は超えていない。サーマルスロットルは確かに起きるが、LLM推論への影響はほぼない。その理由を、実測データで説明する。

検証環境

マシン：MacBook Pro 14" M5 Max / 128GB Unified Memory モデル：Qwen3-Coder-Next 80B MoE（3B active）, MLX 4bit, 42GB 推論バックエンド：LM Studio（MLX）/ Ollama（GGUF Q4_K_M） エージェントフレームワーク：OpenCode v1.3.3 比較対象：Claude Opus 4.6（クラウドAPI） 計測ツール：macOS powermetrics（GPU電力・周波数・サーマル状態）

MLXはApple Silicon向けに最適化された機械学習フレームワークで、Unified Memoryを効率的に使える。同じモデルをOllama（llama.cppバックエンド）でも動かしたが、体感でMLXのほうが明らかに速かった。

GPU実測: 14インチのサーマル問題に決着をつける

まず、LLM推論中にGPUが何をしているかを正確に把握する。ここが全ての議論の前提になる。

macOSには powermetrics というコマンドがある。sudo powermetrics --samplers gpu_power -i 2000 で2秒間隔でGPUの周波数・電力・サーマル状態を記録した。以下は推論中の生ログの一部だ。

*** Sampled system activity (Sat Mar 28 17:02:49 2026 +0900) ***

**** Thermal pressure ****
Current pressure level: Nominal

**** GPU usage ****
GPU HW active frequency: 338 MHz
GPU HW active residency:   2.89%
  (338 MHz: 2.9% 486 MHz: 0% ... 1620 MHz: 0%)
GPU idle residency:  97.11%
GPU Power: 43 mW

推論中のGPUは、最低クロックの338MHzで稼働率2.89%。電力はわずか43mW。idle residencyが97%。つまりGPUの97%の時間はアイドル状態にある。この計測を30サンプル（60秒分）繰り返した。

推論中のGPUは、ほぼ寝ているみたい。

GPU周波数：ロード時 1,314.5 MHz → 推論時 338.0 MHz（4倍の差） GPU電力：ロード時 20.9 W → 推論時 0.1 W（156倍の差） GPU Active：ロード時 65.9% → 推論時 7.9%（8倍の差）

ロード時と推論時で電力が156倍違う。推論中のGPUは文字通りほぼ何もしていない。

理由はシンプルだ。LLM推論のボトルネックはGPU演算ではなく、メモリ帯域にある。42GBのモデルウェイトを、トークンを1つ生成するたびにメモリから読み出す。Apple SiliconのUnified Memoryは高速だが、それでもGPU演算器の処理速度よりメモリの読み出しのほうがずっと遅い。GPUは「メモリからデータが届くのを待っている」時間のほうが長い。

だからOSはGPUクロックを最低の338MHzまで落とす。電力を節約しつつ、推論速度には影響しない。賢い制御だと思う。

mactopとpowermetricsの罠

ここで一つ、引っかかりやすいポイントがある。

mactopで見ると、推論中のGPU利用率は95%に張り付く。一方、powermetricsで見ると7.9%。同じ推論中なのに、数字が12倍違う。

理由は「利用率」の定義が違うからだ。mactopはGPUへのタスク投入率を表示している。powermetricsはGPU演算器の実稼働率を返す。タスクは投入されているが、演算器はメモリ待ちでほとんど動いていない。この違いを知らないと「GPUが限界まで使われている」と誤解する。

ネットの「14インチはGPU使用率100%で熱暴走する」という報告の一部は、この誤認が原因ではないかと推測している。

サーマルスロットルは起きる。でも推論には影響しない

別の計測セッションでは、MLX推論を連続稼働させて60秒間（30サンプル）のデータを取った。サーマル状態の遷移が記録されている。

# 開始直後（サンプル1）
Thermal pressure: Nominal
GPU HW active frequency: 675 MHz
GPU HW active residency:  95.83%
GPU Power: 12750 mW

# 22秒後（サンプル12）— ここでModerateに遷移
Thermal pressure: Moderate
GPU HW active frequency: 619 MHz
GPU Power: 10538 mW

# 24秒後（サンプル13）— Heavyに突入
Thermal pressure: Heavy
GPU HW active frequency: 563 MHz
GPU Power: 10034 mW

# 54秒後（サンプル28）— 最低値
Thermal pressure: Heavy
GPU HW active frequency: 498 MHz
GPU Power: 8125 mW

30サンプルを3フェーズに分けて集計すると:

開始フェーズ（11サンプル）：Thermal Pressure = Nominal（正常）、GPU平均 約630 MHz / 約11.5 W 過渡フェーズ（1サンプル）：Thermal Pressure = Moderate（中程度）、GPU 619 MHz / 10.5 W スロットルフェーズ（18サンプル）：Thermal Pressure = Heavy（高負荷）、GPU平均 約548 MHz / 約9.1 W

サーマルスロットルは確かに起きる。GPU周波数は675MHzから498MHzまで、約26%低下した。

しかし、推論安定時のGPUは338MHz固定だ。548MHzに落ちようが、338MHzで動いている推論には影響しない。サーマルスロットルが実害を持つのは、GPU演算がボトルネックになるワークロード（画像生成、動画エンコード等）だけだ。

ただし注意点が一つ。サーマルHeavy状態が続いた後にMLXバックエンドがクラッシュする事象が1件発生した。推論速度には影響しなくても、システム安定性には影響しうる。長時間の連続稼働なら外部冷却は検討したほうがいい。

Qwen3-Coder-Nextの実力: コード分析は評判通り強い

ここからはモデルの話に入る。Qwen3-Coder-Next 80B MoEは、MoE（Mixture of Experts）アーキテクチャを採用している。80Bパラメータの全てが毎回使われるわけではなく、入力に応じて「専門家」の組み合わせが選ばれ、実際に計算するのは3B分だけ。80Bの知識量を持ちながら、3Bの計算コストで動く。ローカルで大規模モデルを現実的に動かすための、今一番合理的なアーキテクチャだ。

最初に与えたタスクは、既存のWebアプリケーションのセッション管理機構の分析だった。

「このコードベースのセッション管理の仕組みを分析して、保存先、ライフサイクル、復元の仕組みを整理してほしい」

結果は的確だった。セッションキーの生成ロジック、ファイルベースの永続化、TTL管理まで、ソースコードから正確に抽出してきた。関数の呼び出し関係を追跡し、設定値の参照箇所を特定し、データフローを構造的に整理する。クラウドAPIの大規模モデルと比べても引けを取らない。

コード分析は、ローカルLLMが最も得意とする領域の一つだ。ソースコードは構造が明確で曖昧さが少なく、関数名・変数名・制御構造というシグナルが豊富にある。モデルにとって「何を見ればいいか」が分かりやすい。

ここまでは評判通りだった。

ここまでが「M5 Max 14インチでローカルLLMは動くのか？」に対する回答だ。動く。コード分析は評判通り強い。

ではなぜ、これだけでは「使える」にならないのか。クラウドのAIサービスが裏で勝手にやってくれていることを、ローカルでは自分で埋める必要がある。その構造的な理由と、具体的な埋め方をここから先に書く。