• AI
  • MLX
  • Apple Silicon
  • ローカルLLM
  • 高速化
  • ツール

mtplx——M5 Maxで63tok/s、Apple SiliconのローカルLLMが2倍以上速くなる日

MTPヘッドを使った投機的デコードでMacの推論速度が2.24倍に。M4 Maxでも試せる？熱問題はシリコンの限界か、エンジニアリングの余地か。

カテゴリー: AI · MLX · Apple Silicon · ローカルLLM · 高速化 · ツール | 公開: 2026年5月5日

この記事は、以前noteに書いた文章を葉桜ラボ用に少し整理したものです。

こんにちは、チカちゃんです。

今日は、Apple Siliconユーザーにとって胸熱な話。

ローカルLLMの推論速度が、2倍以上になるかもしれない——

しかも追加のGPUも、外部のドラフターモデルも要らない。モデルに最初から内蔵されているMTP（Multi-Token Prediction）ヘッドを使うだけ。

そのツールの名は mtplx。

先日リリースされたばかりのプレビュー版ですが、M5 Max上で Qwen 3.6 27Bが63 tok/s という数字を叩き出して、一部の界隈で話題になっています。

でも——ちょっと待って。話はそんなに単純じゃなさそうなんです。

投機的デコードって何？

まず基本から。

普通のLLMはトークンを1つずつ生成します。「今日」の次に「は」、その次に「いい」…と、芋づる式。

投機的デコードはこれを効率化する方法です。

  1. 安くて速い「ドラフター（下書き役）」が、ざっくり未来のトークンを予測する
  2. 本物のモデルがそれらをまとめて検証する
  3. 合ってたトークンはそのまま採用、間違いだけ訂正

一見遠回りですが、まとめて検証できる分、全体のスループットが上がる——これが投機的デコードのカラクリです。

従来はこの「ドラフター」に別の小さなモデルを使う必要がありました。でも、最近のモデル（Qwen 3.6など）は自分自身の中にMTPヘッドという予測用の補助回路を内蔵している。

mtplxは、まさにそのMTPヘッドを「内蔵ドラフター」として使うツールです。

mtplxの数字——本当なの？

条件速度
通常（AR、M5 Max）28 tok/s
mtplx適用（D3、M5 Max）63 tok/s
速度向上率約2.24倍
分布の一致精度完全一致（max_diff = 0.0）

著者の Youssof Altoukhi（20歳！ロンドンのモバイルゲーム開発者）によると、この2.24倍という数字はハードウェア非依存の倍率だそうです。つまり、メモリ帯域が大きいM4 MaxやM3 Maxでも、理論上は同程度の倍率が期待できる。

しかも「温度0.6でgreedyじゃない」というのが大事なポイント。greedy（温度0）限定の投機的デコード手法（DFlashなど）と違い、mtplxは確率比棄却サンプリング（Leviathan-Chen） を使っているので、クリエイティブなタスクでも正確な分布を保つ。

4層のアーキテクチャ——ただのラッパーじゃない

mtplxが面白いのは、ただMLXの上に乗ったラッパーではないこと。4層構造になっています。

Layer 0: カスタムMLXフォーク

  • MLXをフォークして、小さい行列（M=3〜6）向けにMetalシェーダーを10行書き換え
  • 検証用のコンパイル済みグラフをキャッシュする GraphBank（キャプチャ0.073ms vs 検証47ms）
  • 下書き専用の4ビットLMヘッド（本物の精度は維持しつつ、下書きだけ29%高速化）

Layer 1: 単一モデル・ランタイム

ターゲットとドラフターは同一チェックポイント。余分なRAMはゼロ。KVキャッシュもvLLM CUDA版と照合済み（cosine > 0.9998）。

Layer 2: 投機的サイクル

Draft → 並列Verify → 確率比受理 → 残差補正 → ボーナストークン このループが高速に回る。

Layer 3: サーバー

OpenAI互換API、Anthropic互換API、ブラウザチャットUI、端末チャット——実用的な構成。

そして問題の「熱」

ここからが、特に気になるポイント。

mtplxの記事で一番面白いのは、この話かもしれません。

著者は、投機的デコードのサイクルを最適化していて、ある問題にぶつかります。長い応答（8kトークン超え）でTPSが50%も落ちる。

16時間かけてカーネルをデバッグし、24種類のプロファイルを試した——

  • 遅延評価のグラフ蓄積？
  • キャッシュの成長？
  • ページドアテンション？
  • 所有されたリカレントキャッシュ？

ぜんぶ違った。

原因は驚くほど単純でした。投機的デコードのループは、通常の自己回帰生成よりはるかに重いGPU負荷を継続的にかけます。その追加のワークロードでM5 MaxのSoCが 103℃ に達し、macOSのデフォルトファンカーブが追いつかず、GPUがクロックダウンしていた——ただそれだけ。

16時間のカーネルデバッグ、解決策はファンコンだった。

彼は ThermalForge というツールを作り、生成前にファンを100%固定。それだけでTPS低下が 50%→6.7% に改善し、GPUクロック維持率が 85.6%→97.1% に向上しました。

シリコンの問題なのか、エンジニアリングの問題なのか

ここが本題です。

M5 Maxで103℃。これはApple Siliconの熱設計の限界なのでしょうか？それとも、冷却の工夫で乗り越えられる問題なのでしょうか？

シリコン限界説

M4 MaxのMac Studioでも、CPUコアが109℃に達してサーマルスロットリングするという報告があります（YouTube実測あり）。これは、M4の高性能コアが電力密度が高すぎて、アルミヒートシンクだけでは放熱しきれない——という構造的な問題かもしれない。

GPUよりもCPUの方が電力密度が高く、冷却が難しい。そして投機的デコードは、CPUだけでなくGPUもフル稼働させる。

エンジニアリング余地説

一方で、著者のアプローチは「ファンをちゃんと回せば解決する」という方向を示しています。macOSの標準ファンカーブがオフィス用途前提で緩すぎるだけ——という見方です。

実際、ファンを回しただけでGPUクロック維持率が97.1%まで回復した。つまり、冷却さえしっかりすれば、シリコン自体はもっと戦える可能性がある。

さらに、著者は今後「カーネル自体の最適化で熱問題を改善する」とも言っています。つまり、ソフトウェア側の工夫で負荷を減らす余地も残っている。

チカちゃん的には、両方正解な気がします。

Apple Siliconの放熱設計には確かに余裕がない。でも、ソフトウェア側である程度カバーできる余地もある——というのが、mtplxが示した現実です。

M4 Maxではどうなのか

気になるのは、M4 Maxでどうなるかですよね。

M5 Max（63 tok/s）とM4 Maxの差は、主にメモリ帯域とGPUコア数によるものです。M4 Maxも決して遅くはない。むしろ、メモリ帯域はM4 Maxもかなり高い（400GB/s超）。

倍率としての2.24倍はハードウェア非依存なので、M4 Maxでも相応の速度向上が期待できると考えられます。

ただし、熱問題はM4 MaxのMac Studioでも報告されているので、ファン制御は必須でしょう。ノート型MacBook Proの場合はさらに放熱が厳しいので、同じ方法では難しいかもしれません。

試すなら、冷却をしっかり確保した上で、短めのプロンプトから始めるのが良さそうです。

導入方法と現状の制約

brew install youssofal/mtplx/mtplx
mtplx start

これだけで、ウィザードが起動してモデル選択→チャットまでいけるようになっています。

システム要件

項目条件
ハードウェアApple Siliconのみ（arm64）
OSmacOS 14.0+
Pythonarm64ネイティブ 3.10+
メモリ48GB以上推奨（27Bモデル想定）

現状の注意点

  1. プレビュー版（v0.1.0-preview.3）— まだバグあるかも
  2. 対応モデルが限られる — 多くのMLX量子化モデルはMTPヘッドを削っている。今遊べる実質的な選択肢は著者提供の Qwen 3.6 27B（HuggingFace公開）
  3. 熱対策が必須 — mtplx max --install でThermalForgeを入れてから使うのが現実的
  4. 「トークン生成以外」は考慮されていない — embeddingやtool callingの性能は未知数

それでも——このツールが示す未来

mtplxはStar 7の超初期プロジェクトです。でも、このツールが示した方向性は重要です。

  • モデルが内蔵するMTPヘッドを活用すれば、追加コストゼロで2倍以上の速度向上が可能
  • Apple Siliconでも、ソフトウェアの工夫で性能を引き出せる余地がまだある
  • ファンコンひとつで話が変わる——という事実は、“熱問題”の捉え方を変えるかもしれない

そして何より、20歳の開発者が趣味で作り、オープンソースで公開した——という背景が、このプロジェクトを特別にしています。

すでにmlx-lm本体やvllm-mlxにもMTP対応のIssueが立っていて、標準機能として取り込まれる流れができつつあります。

つまり、mtplx自体が広く使われるかどうかは別として、「Apple Silicon + MTP」の波はもう来ている——ということです。

数ヶ月後には、mlx-lm の標準機能としてMTPが動くようになっているかもしれません。そのとき、今この記事を読んでいるあなたのMacも、ちょっとだけ速くなっている——そんな未来が、すぐそこにあります。

📎 参考：