 | TLDR: MacBook Pro M5 Maxで、Qwen3.6-27Bの28 tok/s → 63 tok/s。実温度0.6で2.24×高速。コーディング、創作の文章作成、チャットに対応 https://i.redd.it/i9x794c0q7zg1.gif
MTPLXとは？MTPLXは、モデルに内蔵されたMTPヘッドを推測用のドラフタ（drafters）として使い、LLMのデコード速度を最大2.25倍に高めます。しかも、モデルのデフォルトの推論設定は維持されるため、コーディングや創作の文章作成といった作業が可能です。 QWEN 3.6 27B（MacBook Pro M5 Maxで63 TPS）MTPLXを使って、Qwen 3.6 27B 4-bit MLXのデコード速度を、MacBook Pro M5 Max上で温度0.6、top_p 0.95、top_k 20の条件にて28 tok/s → 63 tok/sに引き上げました。コーディング向けにQwenが推奨する、正確なサンプリング設定です。 Qwen 3.6 27Bには、最大深さ5まで対応する内蔵MTPヘッドが付属しています。私はこのモデルがこのハードウェア上で最適になる深さを見つけるため、D2、D3、D4、D5をスイープして確認しました: D3が最適なポイントでした。受容（acceptance）が十分高く、検証時間の比率に対して、TPSが最も伸びたためです。D4とD5は序盤の位置で受容が良いものの、より深い位置では、保存できた受容トークン数以上に検証時間のコストが増え始めます。 これらの結果は、実温度0.6において、確率比の厳密な棄却サンプリングと残差補正を行ったものです。 つまり、出力品質を犠牲にせず、2.25倍の速度向上を得ながら、Qwen 3.6 27Bを実際のコーディング作業に本当に使えるということです。 これはDFlash / DDTreeと何が違うの？DFlash MLXは絶対的な速度はより高いのですが、サンプリングが貪欲（temp 0）のみに制限されており、実世界での利用ケースを大幅に狭めています。また外部ドラフタモデルが必要で、追加のメモリが要り、リリースされる各モデルごとに作成する必要があります。 DDTreeはDFlashの上にツリー構造で検証を追加するため、同じ制限を引き継ぎます。つまり、貪欲のみで、外部ドラフタが必要です。 これが起きる理由は、それぞれのシステムがどのようにドラフトするかにあります。MTPヘッドは逐次的にドラフトします。つまり、各トークンは前にドラフトされたトークンを見ます。そのため、すべての位置で実際の確率分布が生成されます。DFlashは拡散（diffusion）パスで16個のトークンを同時にドラフトします。トークン8はトークン7が何だったかを知りません。この逐次依存がなければ、温度が機能するための、トークンごとの棄却サンプリングの数学はできません。 MTPLXは、MTPヘッドを保持する任意のモデルで動作し、ユーザーがMTPヘッドの数を選び、ローカル保存済みまたはHuggingFaceのMTPヘッド付きモデルを何でも実行できるよう、完全なカスタマイズ性を提供します。 アーキテクチャLayer 0: MLXランタイム MTPLXはパッチ済みMLXフォーク上で動作します。標準MLXの量子化済み行列-ベクトルカーネルは、大きなM（prefill）向けにチューニングされています。MTPの検証（verify）では、Mは3〜6で、1つのドラフトトークンにつき1位置です。標準の実装では、この形状でスタック（待ち）が発生します。パッチ内容: より広いsimdgroups、ループアンローリング、Metalの10行分。標準実装との差分は0.0（完全一致）です。 フォークの上に、MLXプリミティブとして登録された4つのカスタムMetalカーネルがあります:
Layer 1: 単一モデルのランタイム チェックポイントは1つです。ターゲットモデルとドラフタは同じモデルです。Qwen3.6-27BにはネイティブMTPヘッドが同梱されており、MTPLXはそれを使用します。2つ目のモデルのためのRAMはゼロです。トランクのKVキャッシュは、コミット履歴（committed-history）契約を使います。これは、vLLMのCUDAリファレンスに対して、コサインが> 0.9998で深さ5まで検証されています。 Layer 2: 推測サイクル（ホットループ） サイクルごとに: MTPヘッドがKトークンをドラフトします。各ドラフトは直前のドラフトを参照します。ターゲット側は、コンパイル済みGraphBankパスを通じて、1回のバッチ順伝播でKすべてを検証します。確率比の受容（Leviathan-Chen）が、fp32の各位置で可否を決定します。残差補正（p - q)+ は、棄却時にクリーンな置換を出力します。すべてのKが受容された場合は、ボーナストークンが無料で得られます。イノベーションテープは、受容されたGDN状態デルタをコミットし、棄却されたものをロールバックします。 Layer 3: 提供スタック 実際のAPIサーバー。ストリーミングSSE付きの、OpenAI互換の /v1/chat/completions および /v1/completions。Anthropic互換の /v1/messages。/v1/models、/health、/metrics。チャットごとのKV状態を持つエンジンセッション。Session Bank は、ターン間でウォーム・プレフィックスの“完全な状態”を保持し、fresh forwards に対して logits max_abs_diff = 0.0 で検証済み。localhost上のブラウザチャットUIで、ライブ tok/s、Markdownレンダリング、コードブロックのコピー、停止ボタン。mtplx chat によるターミナルチャット。 私が解決しなければならなかったことApple Silicon上でのネイティブMTPは、デフォルトでは動きませんでした。問題は4つ、積み重なっていました 1) 再帰的な深さの崩壊 MTPを再帰的に実行すると、深さ1の後に精度が崩壊します：91% → 63% → 44% → 27% → 17%。 ネイティブMTPを試した誰もがこれを見て諦めました。私は、MTP-5でvLLMを動かしている自分の2x3090 PCにSSHし、MTPの実行を正確に追跡して、MLXとトークンごとに比較しました。結論：MLXは、推論（speculative）サイクルのたびにMTPのattention KVキャッシュをリセットしていました。vLLMはしません。MTPの履歴をサイクルをまたいで保持します。契約（コントラクト）上の修正として、深さ2の受け入れが49%から74%にジャンプしました。 2) 精度の不一致 どのプロジェクトも、量子化された4-bitトランク（幹）に対してBF16のMTPヘッドを使っていました。MTPヘッドは、受け取る隠れ状態よりも精度が高く、再帰的な予測を通じて量子化ノイズを増幅してしまいます。私は、校正済みのINT4 MTP重みをトランクに移植し、MTP精度がトランク精度と一致するようにしました。深さ3は30%から88%にジャンプしました。 3) MLXのverifyボトルネック 受け入れ（acceptance）が高くても、標準のMLXのverifyパスがあまりに高コストで、MTPはプレーンな自己回帰デコードより遅くなっていました。MLP演算がverify時間の51%を占めていました。 私は、MTPが生成する小さなverify形状向けに、MLXのMetal qmvシェーダをパッチしました（10行、より大きいsimdgroup＋ループアンローリング）。さらに、効率的な状態ロールバックのためのイノベーション・テープのGDNキャプチャシステムを作り、目標（target）の確率分布を1つのMLX eval境界にバッチ化し、MTP履歴の具現化（materialisation）を後回しにしました。 verifyサイクル時間を、1回あたり約90msから約47msまで削減する4つの積み重なる最適化により、MTPはプレーンな自己回帰より遅い状態から、2.24×高速へ持っていけました。 4) TPSの減衰 長い応答（8k+トークン）ではスループットが崩壊しました。TPSが50から25へ（50%減）減衰する理由を突き止めるのに16時間を費やし、24種類のプロファイルを調べました：lazy-evalのグラフ蓄積、キャッシュ増加、状態の由来（provenance）、paged attention、所有するリカレントキャッシュ、2パスのMetal SDPA。 どれも解決しませんでした。 問題はあまりに単純でした。推論（speculative）デコードのループは、通常の自己回帰よりも大幅に重いGPU負荷を維持することが判明しました。毎サイクルで、フルのバッチ化されたverify forwardに加えて、ドラフト計算、そしてMTP履歴のメンテナンスが走ります。 追加で維持される負荷によってM5 MaxのSoCが103°Cまで上がり、macOSのデフォルトのファンカーブは反応が遅すぎました。ファンが応答する頃には、GPUはすでにダウンクロックされています。 私はCLIにMAXモードを導入しました。ThermalForgeを使い、生成開始前にファンを最大回転で固定します。さらに、プロセスが何らかの理由で死んだ場合にファンを自動へ戻す、分離型のウォッチドッグを付けます。TPSの減衰は50%から6.7%に低下し、GPUクロック保持は85.6%から97.1%に向上しました。 ファンコントローラで解決した16時間のカーネルデバッグ。 注意点
その間は、私の公式の Qwen 3.6 27B MTPLX Optimised を実行できます。 。CLIがセットアップとダウンロードを簡単にします。 MLXクオントを公開する場合は、MTPヘッドを残してください。27Bモデルだと約200MBで、メモリコストはほとんどゼロで、いまや2.25×の高速化価値があります。 このプロジェクトに対する皆さんの考えや貢献をとても楽しみにしています。MLX上でローカルLLMを、より速く、より誰にとっても現実的にするために。 [link] [comments] |
MTPLX | Apple Silicon向けネイティブMTP推論エンジン（TPS最大2.24倍高速）
Reddit r/LocalLLaMA / 2026/5/5
💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage
要点
- MTPLXはApple Silicon向けのネイティブMTP（スペキュラティブデコーディング）推論エンジンで、モデルのデフォルト推論挙動を維持したままデコードを最大約2.25倍高速化できるとされています。
- 外部のドラフターを追加せず、余計なメモリ負荷も増やさない方針で、各モデルに内蔵されたMTPヘッドを使うため幅広い互換性をうたっています。
- Apple Silicon上の他のスペキュラティブデコーディング手法と異なり、「greedy-only」ではなく、拒否サンプリング付きの数学的に正確な温度サンプリングを用いることで、タスクに応じた温度設定を可能にします。
- ベンチマークでは、MacBook Pro M5 Max上でQwen3.6-27Bが、温度0.6・コーディング向けの推奨サンプリング設定で、28 tok/sから63 tok/sへ改善したと報告されています（MTP深さの最適化も実施）。
- MTPLXにはCLI一式と、OpenAI/Anthropic互換のAPIに対応した提供（サービング）スタックに加え、ベンチマークや診断など実運用向けの機能も含まれます。
