MTPLX：让模型用上自己的 MTP 头——Apple Silicon 上的原生投机解码

现代旗舰模型（Qwen 3.5/3.6/3.8、部分 Gemma）出厂自带 MTP（Multi-Token Prediction，多 token 预测）头：模型能一次草拟多个 token，而不是逐个蹦。但这套能力在绝大多数推理运行时里是沉睡的——要么没人实现，要么用外部小模型做草稿（draft）模型，白白吃掉内存。MTPLX 做的是另一件事：在 Apple Silicon 上，让模型用自己带的 MTP 头做投机解码，不引入任何外部草稿模型。

这篇文章讲清三件事：MTP 投机解码为什么能快、MTPLX 怎么做到"精确"（不改变模型输出分布）、以及它的 Turbo/Sustained 两种模式各在什么场景下有用。

一、先给判断

MTPLX 不是又一个"套壳推理引擎"。它的核心价值在于两点：

1. 原生 MTP 投机解码：利用模型自带的 MTP 头，配合精确拒绝采样（exact rejection sampling），在保持输出分布不变的前提下加速解码。
2. MLX 优先、Apple Silicon 第一：不依赖 CUDA，不碰外部草稿模型，专门为 Mac 的统一内存架构设计。

它解决的问题是真实的：本地跑 LLM，最大的瓶颈是内存带宽（memory bandwidth）——逐 token 解码时，计算量不大，但每个 token 都要把权重从内存搬一遍。投机解码的思路是"一次搬运，验证多个 token"，从而摊薄每次搬运的成本。

二、系统地图：两条主线

MTPLX 里有两条容易混淆的主线，先拆开：

MTP 投机解码是引擎的数学核心；模式选择是工程层面对"快"的定义的区分。下面分别展开。

三、核心机制：MTP 头 + 精确拒绝采样

3.1 MTP 头草拟

普通解码每一步只产生一个 token。MTP 头让模型在生成第 N 个 token 时，顺带预测第 N+1、N+2……个 token，形成一条草稿序列。关键在于：这些预测来自模型自身，不是外部小模型，所以不额外占内存。

3.2 单次前向验证

MTPLX 把草稿序列放进一次批量前向传播（batched forward pass）里验证，一次读权重、验证多个 token。相比逐 token 解码的多次权重搬运，这就是加速的来源。

3.3 精确拒绝采样（数学保证）

这里是最容易踩坑的地方。投机解码最常见的错误实现是"贪心接受草稿"——这会悄悄改变模型输出分布。MTPLX 用的是 Leviathan 与 Chen 的拒绝采样定理（2023）：

• 对草稿 token，以 min(1, p/q) 的概率接受（p 为目标模型概率，q 为草稿概率）。
• 拒绝时，从剩余分布 (p − q)+ 中采样替换。

这套数学保证：输出分布与普通解码完全一致。README 明确写到，temperature=0.6, top_p=0.95 的行为和普通解码一模一样，只是更快。没有"greedy-only 才精确"的缩水——这是它区别于很多实现的点。

3.4 接受率与深度

实际加速取决于接受率（acceptance rate）——草稿被验证通过的比例。MTPLX 用 mtplx tune 在用户自己的机器上实测各深度（depth）的接受率，只保留真正比普通解码快的深度。这是一条诚实的路径：不看厂商吹的峰值，而在你的芯片上量。

四、两条模式主线：Turbo 与 Sustained

两个模式本质是"延迟 vs 吞吐"的取舍：Turbo 更偏向短提示的即时响应，Sustained 面向大上下文的长对话。配套的风扇控制（通过 ThermalForge）会在引擎异常退出时自动把风扇交还给系统——这是工程细节，但对长时间跑本地模型的人很关键。

五、一次请求怎么流过系统

以一个"打开 MTPLX 服务，问模型一个多轮问题"为例：

1. mtplx start（或 App 的播放键）启动一个 OpenAI 兼容的 API 服务在 127.0.0.1:8000。
2. 请求到达后，根据所选模式进入解码路径：短上下文走 Turbo，长上下文走 Sustained 的分块预填充。
3. 每步解码：MTP 头草拟多个 token → 一次前向批量验证 → 精确拒绝采样接受/替换。
4. 多轮对话由"warm-prefix session bank"保持前缀缓存，第二次及以后的轮次不用重新预填充。
5. 会话持久化：默认开启 SSD 会话缓存，重启后近即时恢复（--ssd-session-cache off 可关）。

这条链路把"MTP 投机解码 + 前缀缓存 + 会话持久化"串成一个完整服务，而不仅是命令行跑一个模型。

六、Benchmark 解读：这些数字能说明什么

README 给出两组关键数字：

• 16GB M4 Mac mini：实测 1.6x 加速。
• M5 Max：2.24x 加速。
• 9B 模型调优示例：深度 1 下，14.4 tok/s 基线 → 23.0 tok/s。

解读这组数字必须回答三个问题：

1. 测的是什么：tok/s 吞吐，特定硬件 + 特定深度下的单模型结果。
2. 反映系统的哪部分：MTP 接受率 + 验证核效率 + 内存带宽利用——加速主要来自"一次搬运验证多个 token"摊薄了带宽成本。
3. 不能推出什么：这些数字不能推广到所有模型、所有 Mac、所有上下文长度。加速倍数随芯片带宽、模型规模、深度、提示词长度变化。mtplx tune 的意义就在于此——在你自己机器上重新量一遍。

七、采用建议与适用边界

谁适合先上：

• 用 Apple Silicon（M1 及以上）、macOS 14+ 跑本地 LLM 的人。
• 想给本地模型配 OpenAI/Anthropic 兼容 API 服务（Claude Code、Cline、Open WebUI 等都能接）的人。
• 想要"多 token 预测 + 精确采样"但不想被外部草稿模型占内存的人。

谁可以等：

• Linux / CUDA 用户——这是 MLX 原生项目，README 明确说 Linux 请用 vLLM。
• 不需要长上下文、只偶尔跑一下模型的人——装一个引擎的成本未必划算。
• 对"不改变输出分布"无感、只想要最快峰值的人——Turbo 模式是性能向，但追求绝对峰值可能更适合其它赛道。

边界提醒：

• 不支持挂载外部 MTP sidecar 到任意 MLX 主干权重（README 明确说明：形状/来源无法证明 head 与权重匹配）。要么用官方目录里完整含 MTP 权重的模型，要么用 Forge 从源 checkpoint 构建并验证。
• 检索模型（embedding/rerank）不走 MTP 路径——那对 token 流没有意义，属于另一条服务线。

八、一句话总结

MTPLX 的价值不在于"又一个本地 LLM 引擎"，而在于它把"模型自带的 MTP 头"从沉睡状态激活，用数学上精确的拒绝采样做成真实加速，并且是 Apple Silicon 原生。它的判断值得留意：投机解码不一定需要外部草稿模型，模型自己带的 MTP 头就够了——前提是有一个愿意把它跑起来的运行时。