Apple SiliconでハイブリッドQwenを動かすための最適化チェーンは依然として不完全：MLX変換ではMTPが完全に保持されない

現在のApple Siliconにおけるローカル推論に欠けているのは、単一の高速kernelではなく、モデル重みの変換、状態キャッシュ、投機的デコーディングを連携させる完全な経路だ。最新のコミュニティ調査では、Qwen3.8-27Bなどのハイブリッドモデルが例として挙げられている。これらのモデルは、attention KV cache、recurrent state、組み込みのmulti-token prediction（MTP）headを同時に備えるが、`mlx-lm`の標準的な変換・読み込みフローは、MTPの重み一式と実行ロジックをまだネイティブに処理できない。既存のGitHub上の議論でも、通常のMLX変換／量子化経路ではMTPコンポーネントが保持されない可能性があることが確認されている。また、再現事例では、`qwen3_5_mtp`タイプが未登録であるため、サーバーの読み込み段階で失敗することさえ示されている。

代替手段にもトレードオフがある。`vllm-metal`はすでにpaged KV、continuous batching、一部のautomatic prefix cachingを提供しているが、公式のサポート表では、Qwen3.5／3.6のようなハイブリッドGDNモデルはautomatic prefix cacheを利用できないとされている。投機的デコーディングでdraftが拒否された際にロールバックするには、KVを取り消すだけでなくrecurrent stateも復元しなければならない。さらに、複数のdraft tokenを検証する際、Metal kernelがキャッシュ全体を繰り返し読み込む可能性もある。このため、一部のフレームワークは短いpromptではMTPによる高速化を実証できても、長い対話、共有system prompt、複数エージェントの同時実行で同等の効果が得られるとは保証できない。

エンジニアリングチームがMac上の推論を評価する際は、単一ターンのtokens/sだけを見るのではなく、複数ターンでのTTFT、32Kを超えるcontext、キャッシュヒット後のTPOT、MTP acceptance rateを併せて測定すべきだ。今後注目すべきなのは、`mlx-lm`がMTP重みのネイティブな保持とbatched generationのサポートを統合するか、そして`vllm-metal`がハイブリッドrecurrent stateに対してprefix cachingと投機的デコーディングを同時に有効化できるかどうかだ。現時点の結論は主にコミュニティによるテストと急速に更新されているドキュメントに基づいており、複数のマシンやフレームワークを横断した統制比較ではない。