Rapid-MLX 实测：框架提速是真的，MTP 推测解码是负的

一句话结论：框架本身对 Ollama 的提速成立（轻载最高 3.9 倍），但官方宣传排在最前面的 MTP 推测解码，在混合架构模型上实测吞吐反降三到四成——官方文档自己也承认这类场景「比关闭慢 20%」。这不是配置问题，是架构边界。

短视频平台刷到一个本地推理框架，宣传页写着 Mac 提速 2 倍。这类数字见得多，值得动手验证的其实只有一件事：把服务跑起来、接上工具调用、把它的高级功能逐个打开再关掉，看哪些数字是真的，哪些是负的。这篇是一次完整落地的记录——Rapid-MLX，一个构建在 Apple MLX 之上、面向 Apple Silicon 的本地推理服务框架。实测它最亮眼的两件事：对 Ollama 的提速，和 MTP 推测解码。结论是前者成立，后者在混合架构模型上不但不赚，反而倒贴。

提速的部分先说清楚

测试环境一句话：一台大内存 Apple Silicon 工作站（统一内存架构），主模型选 Qwen3.8-27B 的 4bit 量化档——一个线性注意力混合架构（hybrid，linear-attention 与 Mamba 系结构混合）模型，另配 Qwen3.5-4B 的 4bit 档做小档对照。

实测吞吐：27B 档轻载每秒 25 到 27 个 token，4B 档每秒 24 到 25 个。小模型几乎没有更快，因为瓶颈已经不在算力，而在调度和内存带宽——这也是统一内存机器跑本地模型的常见形态，不是框架的问题。

和 Ollama 跑同一个模型对比，数字如下：

提速是真实的，来源也讲得通：MLX 原生后端少了一层抽象，prompt cache 与调度都更贴硬件。倍数随负载下降也符合直觉——带载后大家都在等内存带宽，框架层的差距被物理上限吃掉。

这里顺带一个内存认知的坑，比提速数字本身更值得记住：27B-4bit 加载后的整体工作集约 23GB，但 macOS 的进程 RSS 里几乎看不到这个数字——统一内存架构下模型权重计在 GPU/wired 内存里，进程 RSS 显示得很小。用 RSS 判断「这个服务占了多少内存」会得出完全错误的结论，监控统一内存机器要看整体内存压力，不是进程 RSS。

打开 MTP，吞吐反而掉了

MTP（Multi-Token Prediction）推测解码，是这个框架宣传里排在最前面的高级能力：让模型自带的预测头一次起草多个候选 token，主模型一次前向验证多个，解码步数变少，吞吐理论上上升。听上去是纯赚的优化。

实测方式：同一模型、同一负载、只切换 MTP 配置，其余不动。

开得越激进，掉得越多。

这不是孤例。官方配置文档里就放着同一方向的数据：某个混合架构模型上，草稿接受率高达 0.857——drafter 相当优秀——但 2 位置前向的成本是单位置解码的 1.70 倍，理论收益上限 1.857 除以 1.70 约 1.09 倍；实际测出来，MTP 关闭每秒 59.0 token，固定 k=1 开启后 47.4，自动深度控制器 47.6——比关闭慢 20%。官方在这组数据前写的原话是：MTP is not free — measure before you enable it（MTP 不是免费的——先测量再启用）。

更关键的是 47.6 这个数字：自动深度控制器（auto-K）会动态调节起草深度，理论上能止损。但 47.6 对 47.4，几乎没挪——结构性负收益不是调参能救的。控制器只能在「小赚」和「小亏」之间选，选不了「负」和「正」之间。

一笔账：为什么混合架构吃不到这口饭

推测解码的经济学一句话就能说完：赢的是步数，输的是单步成本。一次前向验证 k 个候选，换回的是少跑 k-1 次解码步——前提有两个：候选大部分被接受，而且「一次验证 k 个」真的只比「一次解码 1 个」贵一点点。

官方文档把这笔账写得非常干净，值得整段复述：接受率是 drafter 的属性，成本比（cost_ratio）是芯片和架构的属性，只有两者的比值决定你是赚是亏。草稿头再优秀，0.857 的接受率已经接近天花板，架构建错了，本多的钱都是白搭。

架构差在哪？纯注意力模型做 2 个位置的前向时，注意力计算可以被摊销到接近 1 个位置的成本——KV 已经在缓存里，新增的只是增量部分；而线性注意力混合架构的状态传递按位置串行推进，第二个位置的前向摊不掉。官方的说法是：它的前向不能像纯注意力模型那样摊销第二个位置。验证成本比直接抬到 1.70 倍，超过接受率能补回的收益，净亏。

反过来说，MTP 不是伪技术，边界之内它是真金。独立项目 mlx-mtp 在特定的视觉语言模型推理栈上，实测原生 MTP 推测解码有 1.62 倍加速；传统「小模型起草 + 大模型验证」的推测解码，在纯注意力模型上 2 到 3 倍加速是公开可查的成熟结论。条件只有一个：架构吃得到这口饭。连框架官方自己都在用 A/B 说话——Gemma 4 的 sidecar MTP 在贪心无损 A/B 测试失败后，被直接禁用。

给读者的判断规则可以压缩成一句：在混合架构（linear-attention、Mamba 系）模型上打开 MTP 之前，先跑一组开关对照。大多数情况下，答案是别开。默认关闭、按需实测，是这个功能唯一的正确用法。

能力注册与推荐分离：一个值得抄的设计

这次实测里另一个值得注意的点，是官方文档对这类「有条件的好功能」的处理方式。文档原话直译过来是：这个框架把「能力」和「推荐」分开——注册表里的旗标标识的是「验证过正确性与性能的组合」，它们控制默认值，而不是操作者的权限。你想显式打开一个未验证的组合，框架允许，但会给出实验性警告，并在启动前跑一遍方法相关的结构与运行时预检。

这个设计比「直接禁用」或「随便开」都高明。禁用会让高级用户失去做 parity 基准测试的能力（官方自己就提供了禁用自动深度控制器的旗标，专门用于固定深度对照测试）；随便开则会让大多数用户在不知情的情况下吃下负收益。默认值承载推荐，权限保留能力，警告补足信息——三层各管一件事。

对自建推理服务的团队，这是个可以直接抄的模式：任何「在某些架构上是优化、在另一些架构上是负优化」的开关，都应该走这条路径——默认值保守、显式开启可行、开启时给出针对当前模型架构的预检结果。比这更重要的前提是官方那句话：先测量，再启用。深度可以钉死、负载可以固定、开关可以对照，一组 A/B 跑完的数字，比任何宣传页和直觉都可靠。

三个必踩的坑

落地过程中有三个坑，每一个都会让服务「看起来正常，实际上不对」：

1. 推测解码配置缺 model 字段，直接拒启。给推测解码配置只写方法不写 model 字段（挂载 sidecar 预测头的仓库路径），服务会硬失败拒绝启动，而不是回退到普通解码。sidecar 头不是一个能独立 serve 的模型——正确姿势是 serve 完整基座模型，把头仓库放进配置的 model 字段。报错信息里的 sidecar=None 说的就是这件事。

2. 工具调用自动检测可能失败。框架靠模型名自动推断工具调用的解析器，推断失败时解析器为空，客户端拿到的是纯文本而不是结构化调用。解决方式是手动指定解析器并显式开启自动工具选择；验证标准是响应里的 finish_reason 变成 tool_calls。这一步不验证，Agent 接入就是「聊天能跑，一调工具就装傻」。

3. 别名不等于 HuggingFace 仓库名。框架的模型别名要经一份映射文件转到真实的 HF 路径，而别名经常指向带 MTP 头的发布方变体，不是社区里大家常用的那个版本。下载前不查映射，可能白下十几 GB 的另一个变体。

服务化接入的几个小决策

跑通之后，还有几个接入层面的决策点，记录如下：

• 就绪判据用双重确认：日志出现启动完成与监听地址后，再请求一次模型列表端点探活，两关都过才切流量。
• 包管理器装的版本装不了视觉扩展，需要用 uv 走 extras 安装指定版本；且视觉通道与 MTP 互斥，二选一。
• 遥测默认开启。本地推理框架悄悄上报使用数据，隐私敏感场景记得关——环境变量 DO_NOT_TRACK 设为 1，或用框架自带命令关闭。
• 前缀缓存默认持久化在用户缓存目录，服务重启后命中仍在，多轮对话场景是免费红利。
• 接到任意 OpenAI 兼容客户端只要三件事：base_url 指向本地端口、api_key 留空、model 填服务端返回的模型 ID。有些客户端的配置文件有写保护，走它的 CLI 写入再用检查命令验证。

边界与数据声明

本文自己的实测数据（吞吐区间、MTP 负收益幅度、对 Ollama 的倍数）来自单机实测的笔记快照，模型为 Qwen3.8-27B 与 Qwen3.5-4B 的 4bit 量化档，采样用默认参数；不同模型、不同负载结构下数字会漂移。方向性结论「混合架构上 MTP 负收益」有两个独立来源互证（本文实测与官方文档数据同向），精确数值以各自环境实测为准。

官方文档的数字（接受率 0.857、成本比 1.70、59.0/47.4/47.6 tok/s、Gemma 4 sidecar 禁用）摘自 Rapid-MLX 官方配置文档 2026 年 10 月时点页面，属官方自报口径，本文未独立复现；mlx-mtp 的 1.62 倍来自该项目 README 的自报数据，同样未独立复现。

「MTP 在混合架构上负收益」的断言范围，限于 linear-attention、Mamba 系的混合架构；纯注意力稠密模型不在本文断言范围内，公开结论支持推测解码在纯注意力模型上有效。如果你的模型是稠密 Transformer，MTP 值得开——先测量，再相信任何一个数字。