『峰值102』和『同配置只有6t/s』都是真的：Mac本地党想复制MTP加速，先过三道关——头部、runtime、风扇

这几天Mac本地大模型的时间线被一组速度数字刷屏：知乎10月2日一篇MTPLX深拆文，标题直接写"让Qwen3.8-27B干到87.6 tok/s"；小红书8月一条166收藏的实测帖，博主在M5 Max 128G上晒出"最高102 tk/s"；作者官网headline写着125 tok/s。知乎小红书GitHub

但同一个帖子的评论区，是另一番景象：有人"M5 Pro 64G也才20t/s"，有人"同配置，GGUF跑出6t/s"，有人泼冷水"实际上全程曲线拉出来都不好看"，还有人因此反问"那岂不是本地根本没必要上Mac"。B站8月那条把Mac、MTPLX、oMLX放同一框对比的27B部署实测视频，2.4万播放、177条评论，吵的也是这件事。知乎10月8日刚开的新提问更直接：macbook跑本地模型为什么长上下文decode速度掉这么多？哔哩哔哩知乎

从6 tok/s到102 tok/s，中间差的真不是钱。我把官方模型卡、GitHub仓库文档、权重文件元数据、博主彻夜实测和评论区自报数字摆在一起对了一遍账，发现Mac本地党复现"官方加速"卡在三道关上——每一道都有一批人踩空。MTPLX官方仓库首页那张App截图，其实是这本账最直观的形态：decode 43.6 tok/s、上下文14/262K、内存15.4/128GB，和专门留给MTP计数器的Acceptance栏，全在同一屏里。知乎

第一关：你下的模型权重里，到底有没有MTP头

先说一个刚发生的翻车现场。最近蚂蚁旗下inclusionAI发布推理模型Ring-mini-2.0，16B总参数、只激活1.4B，官方模型卡白纸黑字写着靠"1/32专家激活比和MTP层"做出媲美7~8B密集模型的表现。一堆Mac用户兴冲冲拉下社区转换包mlx-community的4-bit版，结果发现：代码里写着MTP专用类和分支逻辑，权重文件里"连个毛都找不着"。

知乎"太平洋的水"10月7日做了次地毯式溯源：查Hugging Face官方API的Safetensors元数据，社区转换并没有转错——官方发布的Ring-mini-2.0 Chat版权重里，压根没带MTP。翻遍inclusionAI旗下200多个模型仓库后真相浮出：MTP头（第21层BailingMoeV2MTPLayer，约8.28亿参数，含完整256专家稀疏MoE块）只存在于Base基础模型里。而这句话，官方其实写在SGLang部署文档的深处，原话是MTP is supported for base model, and not yet for chat model——言下之意，Chat版想用MTP还得再等。知乎

那把Base的Layer 20抽出来硬塞给Chat版行不行？文章给的答案是：技术上能拼，但因为数据分布漂移，效果大打折扣，甚至反向减速——这正是官方不把MTP头打包进Chat版的根本原因。

给准备装模型的人一个名单（出自MTPLX仓库文档，检索快照10月2日）：出厂带MTP头、且被Mac端侧实际用到的，是Qwen3-Next家族——基于hybrid GatedDeltaNet架构的Qwen3.5/3.6/3.8，125B-A6B的Qwen3.8 Flash Next，带vision+MTP的Ternary Bonsai 2 27B，以及以"assistant pair"形式跑的Gemma 4。名单外的Llama、Mistral这些，没头可加速。

行动项：先验货再下载。MTPLX的`inspect`命令会在运行前把模型分成verified、family-compatible、architecture-compatible、AR-only、incompatible、no MTP heads at all六档——"no MTP heads at all"就是Ring-mini-2.0 Chat版的处境。

第二关：有头，你的runtime用不用得上

MTPLX对自己核心主张的表述很扎心：现代模型出厂自带MTP头，但几乎没有runtime真正使用它们。这个5月才建仓库、10月初已攒下2400多星的macOS原生应用（Apache-2.0协议），做的就是"把头用上"：让模型自己向前起草若干token，一次批量前向传播验证，再用带残差修正的精确拒绝采样提交——数学上保证任何temperature/top-p/top_k下输出分布与普通解码完全一致。作者的佐证实测：2.11.3版本在temperature 1下对加速路径与普通路径各跑1000个4-token样本比对，差异落在普通路径自身噪声范围内。知乎

反过来说，“装了、启动了"也不等于"在加速”。8月中旬一位M3 Max用户的避坑帖很有代表性：装MTPLX App后速度直接掉一半——不是报错，是模型能启动、接口能通，但MTP加速没了；查下来是App下载的模型目录缺了CLI版本才有的JSON和runtime文件，最后删掉App改用`mtplx pull`重新拉模型才恢复。这类App/CLI路径差异官方后续changelog里也修过若干次，装完最好跑一次验证而不是凭感觉。小红书

这里还有个容易被"提速宣传"掩盖的坑：不是所有投机解码都保分布。同类方案里用greedy-argmax前缀匹配做接受判断的（MTPLX在仓库里点名过DFlash这类做法），在temperature>0时其实悄悄改变了采样分布——知乎10月8日一篇讲NSD验收边界的文章，讨论的正是"接受率更高了，输出分布却可能已经变了"。你本地跑coding agent要的是"快且还是那个模型"，不是"快出一个性格变了的新模型"，选型时值得多问一句它的接受判据是什么。知乎

Mac端的选项不止一个：Ollama、LM Studio、MTPLX、oMLX、LM Studio家的Splash各有阵营。路线之争也在这里：另一条2.2万星的开源runtime oMLX走"外挂草稿模型"配对——下载Qwen3.8-27B-MTP-4bit草稿包，在Model Settings里打开MTP开关、选定drafter即可。一位8月下旬晒设置页的用户实测同一模型从17-18 tok/s提到25-26，接近+47%。而MTPLX的文档则明确拒绝"把外部MTP sidecar硬挂到任意MLX主干上"，坚持只吃模型自带的头。同一个"MTP加速"，两种接法，数字和脾气都不一样。oMLX官网还维护着公开的社区基准页，各机型各模型自报的PP/TG速度表挂在那儿——换阵营之前，先看数。小红书GitHub

换runtime的收益也有人算过账：8月底一位科研党说，老机器上用Ollama跑Qwen3.8-27B"速度慢得让人崩溃"，换MTPLX后128K上下文档突破20+ tok/s。同一晚博主Howell的横向数字也留了底：3.6老版59.9~60.1，oMLX的3.8 MTP版63.3，MTPLX的Bare Speed 65.2。换runtime只是过第二关，真正的分水岭在第三关。小红书小红书

第三关：官方数字是在什么条件下测的

把headline数字逐条拆开看，账目就清楚了（条件全部出自MTPLX官方仓库与benchmark页）：

也就是说：缓存命中率、风扇档位、上下文长度、量化包，四个变量随便动一个，数字就换一个量级。Howell那晚同时开着生图工具、截图里72.6GB内存占用，模型包本身峰值其实是23.6GB；他测的聊天负载MTP接受率深度1/2/3是80%/68.9%/57.8%，而作者官方coding任务测的是95%/88%/80%——负载不整齐，加速就打折。这也是"M5 Pro 64G才20t/s""长context速度就下来了"两条评论的成因：统一内存带宽定decode下限，agent长会话的曲线比峰值诚实得多。小红书

还有第五个变量，出在你自己的prompt上。一位M3 Max 64GB用户9月拿Splash跑了150+次对照请求，把"速度光谱"钉了出来：紧凑代码125 tok/s、JSON 109、英文47、中文散文只有25——同一颗模型差5倍，投机解码只加速"好猜"的内容；他甚至量化了另一个没人提的开销：本地跑7分钟的任务，41%时间花在"读题"（prefill）上。oMLX社区维护的benchmark视图也是同一本账的图表版：prefill速度按芯片（M4 Max/M3 Ultra/M5 Max）和上下文长度切成箱线图，换机器前先对一眼，比抄峰值靠谱。小红书GitHub

长上下文还有一笔容易忽略的内存账。同一位博主8月底跟进MTPLX 2.10.1时引了组官方对比：同一台M5 Max 128GB跑262,144 token冷启动，2.10.0内存一路冲到119GB、最后一个字都没吐出来；2.10.1用355秒跑完，峰值87.4GB。98K提示词从175.7秒缩到114.5秒，背后是新的Sparse Prefill——不再每块重扫整段上下文，M4/M5在超过32K后自动开启。"理论支持26万上下文"和"你这台机器真跑得完"之间，往往隔着一个版本号的距离。小红书

包的选择也有明码账（官方模型卡）：Qwen3.8-27B三个包，Bare Speed纯4-bit权重16.0GB，爆发聊天最快；Optimized Speed动态4-bit 20.4GB，与bf16原模型top-1一致率96.0%，是默认coding档；Optimized Quality 8-bit 29.4GB，一致率99.3%，需要36GB以上内存。内存紧的16~32GB机器，官方首选其实是只有8.85GB的Ternary Bonsai 2 27B（M5 Max上4K上下文64.4 tok/s、16K降到57.1；16GB机器窗口只开得到8192 token，且挂OpenCode/Hermes这类agent客户端要18GB+起步）。知乎

要不要换：把两列清单抄回去

值得换MTPLX的情况：主力模型在Qwen3.5/3.6/3.8家族（自带MTP头）；在Mac上跑coding agent、在意"加速但分布精确"的保证；16~32GB内存想跑27B级别（走Bonsai三元包）；或者想亲手把HF模型做成MTP加速版（`mtplx forge`转MLX→训adapter→本机实测前后对比给verdict，不会假装一定更快）。GitHub

不值得折腾的情况：跑Llama/Mistral等非MTP模型；用Linux；图最广泛模型库的一键下载体验（LM Studio更省心）；只要Qwen3.8-27B且机器是M3+/48GB+，官方也承认Splash值得并行实测。另两笔成本账别漏看：Apache-2.0之外还有署名条款，基于MTPLX发布产品要在用户可见处标注"Powered by MTPLX"，仅在仓库提及不算数；125B的Flash Next三个包均要求96GB+统一内存，普通Mac直接出局。

最后一个动作建议：别看宣传倍数，看自己机器的数。`mtplx tune --retune`会拿真实模型在你这台机器上逐depth实测，以自回归解码为基线，没有depth胜过基线就明说不保存——16GB M4 mini上9B模型调出的真实数字是14.4→23.0 tok/s。GitHub Copilot的CLI已经能从跑着的Ollama里发现支持的本地模型，本地推理正式进入工具链。这样的当下，Mac党该关心的不是"能不能用本地"，而是"这台机器诚实的速度是多少"。拉一遍全程曲线再决定换不换，比抄任何人的峰值都稳。知乎知乎

你是什么芯片、多大内存、跑哪家的包？评论区把decode曲线数字报一下，这道题的答案本来就因机器而异。