r/LocalLLaMAが注目したmlx-lmのQwen3.5 native MTPと1.5x推論改善の可能性

r/LocalLLaMAで注目されたポイント

r/LocalLLaMAのReddit postは、capture時点で99 points、17 commentsを集め、mlx-lmのopen PR #990、feat: native MTP speculative decoding for Qwen3.5を広く可視化した。このthreadが重要だったのは、単なるGitHubリンク共有ではなく、local inferenceを評価する実務者がすぐ判断できる数字を前面に出したことにある。投稿が示した中心データは、Qwen3.5-27B 4-bitをM4 Proで動かしたときの15.3 -> 23.3 tok/s (~1.5x throughput boost)と、~80.6% acceptance rateだった。Apple Siliconでinteractive generationを回す開発者にとって、これは新しいmodelの話ではなく、runtimeの改善だけで体感 latencyを下げられる可能性を示す材料だった。

Upstream PRが追加する内容

PR summaryによると、Qwen3.5 checkpointにはbuilt-in Multi-Token Prediction headがあり、その設定はmtp_num_hidden_layers: 1として表現されている。このheadはbackbone hidden state at tとembedding of token t+1からtoken t+2を予測する。重要なのは、mlx-lmがseparate draft modelなしでnative speculative decodingを実装できる点だ。一般的なtwo-model構成よりも運用が単純で、追加計算もone extra transformer layer of computeに抑えられる。

• model側の対応はqwen3_5.pyに入る。
• generate.pyでは--mtp flagが追加される。
• server.pyでも同じ--mtpの有効化経路が用意される。
• cache rollback supportと8 unit testsも含まれている。

実装面で見逃せないのはverification loopだ。draft tokenを先に出し、その後main pathで検証し、rejectされた場合はSSM stateをrollbackし、KV cacheをtrimする。speculative decodingは速度改善ばかりが注目されがちだが、reject時のstate整合性が崩れるなら実運用では使いにくい。このPRはそのcorrectnessコストまで扱っているため、単なるベンチマーク用パッチではなくruntime機能として見る価値がある。

実務で見るべきlatency tradeoff

利点は明確だ。native MTPなのでtwo-model speculative decodingより導入しやすく、CLIとserverの両方で試せるうえ、single-streamでは意味のある速度向上が見えている。ただし制約も重い。PRはまだopenで、MTP weightsを保持したconverted checkpointが必要であり、MTP有効時はbatchingが無効化され、PR summaryの範囲ではMoE variantsは未検証だ。つまり、この機能はinteractive local inference、developer workstation、low-concurrencyの用途には魅力的でも、shared server全体のthroughput最適화とは別の話になる。

• mlx_lm.generate --model <path> --mtpとmlx_lm.server --model <path> --mtpは試しやすいが、判断は簡単ではない。
• tok/sだけでなくacceptance rateも計測しないと、実際の利益は見えにくい。
• single-request latencyの改善とbatch serving喪失のコストを比較する必要がある。
• 最初の検証対象はdenseなQwen3.5系に寄せるのが無難だ。

なぜReddit threadが意味を持ったのか

このthreadはGitHubの内容を繰り返しただけではない。コミュニティが初期benchmarkを素早く解釈し、~80.6% acceptance rateがdefaultで有効にしたくなる水準かを議論し、さらにtop commentは類似するllama.cpp PR #20700を示した。これはMTPがmlx-lm固有の小さな最適화ではなく、local LLM runtime全体で重要性を増しているテーマだと示している。

実務者にとって大事なのは、速いかどうかだけではなく、どの workload shapeに対して速いのかを見極めることだ。単一セッションでは有利でも、batchingを失うshared serviceでは逆効果になり得る。Upstreamの詳細はhttps://github.com/ml-explore/mlx-lm/pull/990にあり、コミュニティ側の反応はhttps://www.reddit.com/r/LocalLLaMA/comments/1rzntv5/multitoken_prediction_mtp_for_qwen35_is_coming_to/で確認できる。