MTPLX：不用外部 Drafter 的推測解碼，讓 Qwen3.6-27B 在 M5 Max 跑到 63 tok/s
MTPLX 是 Apple Silicon / MLX 上的 native MTP speculative decoding 專案，利用 Qwen3.6 模型內建 MTP heads 當 drafter，避免外部小模型佔記憶體。README 與 LargitData 測試都指向 M5 Max 上約 63 tok/s、temp=0.6 約 2.24 倍加速，但生產採用仍需自行重現。
Threads 知識萃取｜Local LLM / Apple Silicon
MTPLX：不用外部 Drafter 的推測解碼，讓 Qwen3.6-27B 在 M5 Max 跑到 63 tok/s
這則 Threads 值得收錄，因為它點出 Apple Silicon 本地 LLM 的一個實務方向：不是只看顯存大小，而是用模型內建的多 token 預測能力，降低推測解碼的額外記憶體與部署複雜度。
專案事實核對
- GitHub repo：youssofal/MTPLX。
- 定位：Native MTP speculative decoding on Apple Silicon。
- License：Apache-2.0。
- 抓取時 GitHub stars：約 474。
- 模型：Youssofal/Qwen3.6-27B-MTPLX-Optimized-Speed。
- 安裝：README 提供 Homebrew 與 pip 安裝路徑，例如 brew install youssofal/mtplx/mtplx。
它和傳統 speculative decoding 差在哪？
傳統推測解碼常用一個外部小模型當 drafter：小模型先猜幾個 token，大模型再批次驗證。這可以加速，但會多一個模型、多一份記憶體與版本管理成本。
MTPLX 的路線是使用 Qwen3.6 類模型本身的 MTP heads 作為內部 drafter，因此不需要另外載入外部 drafter。對 Apple Silicon 這種 unified memory 架構來說，少一個模型就可能換來更長上下文或更穩定的本地部署空間。
為什麼它強調 temp=0.6 下仍要數學正確
很多加速工具在溫度大於 0 的採樣場景，若用過度簡化的草稿接受方式，可能讓輸出分佈偏離標準逐 token 解碼。MTPLX README 強調使用 probability-ratio rejection sampling 與 residual correction，目標是在加速同時維持和標準自回歸採樣一致的機率分佈。
Threads 與 README 提到的數字
- M5 Max 公開紀錄：README 顯示 D3 約 63.056 / 62.886 tok/s。
- 加速幅度：README 主張在 Qwen3.6-27B、temp=0.6 下約 2.24× over no-MTP AR。
- LargitData 測試：文中提到 M5 Max 64G 上短上下文約 59.8 tok/s，16K 約 41，32K 約 31；峰值記憶體從約 15.6GB 緩升到 22GB。
- 適用設定：README 建議 coding 設定可用 temperature=0.6、top_p=0.95、top_k=20。
為什麼這對本地 AI 服務有意義
若 27B 等級模型能在 Mac Studio / MacBook Pro 等 Apple Silicon 機器上穩定提供 30–60 tok/s 區間，本地 RAG、客服、內部文件問答與輕量 agent 服務會更有想像空間。尤其是中小企業或資料不能外流的場景，Apple Silicon + MLX 的部署成本與維運複雜度，可能比 GPU server 更容易被接受。