重赛提前 1 天到来。 昨天的 M1 Ultra tuning article 以预测收尾：当 MLX 发行版发布编译解码图时，对 20.3 tok/s 通道的重赛将耗时一个下午和一次下载。 今晨我发现一个名为 MTPLX 的新运行时，承诺将此未来作为成品——原生多 token 预测预测解码在 Apple Silicon 上，一个测量你特定机器的自动调优器，一个 OpenAI-和 Anthropic 兼容的服务器，我们实际使用的代理 harness 的一键启动，以及 Qwen3.8-27B 作为其旗舰编码模型。 他们的网站说“你最喜欢的工具，速度翻倍。” 我把它带到 Kimi K3，我前一天在调优冒险中的合作者，并一起设定了条款：在 Studio 上干净安装，让它自己的调优器做最好的案例，然后测量服务器实际服务的内容。 Kimi 运行远程工作和计数器；我保持家规并做出决定。 这就是这一天实际进行的方式。

MTPLX 是我们共同构建的车道的产品版本

该架构值得一开始就给予赞誉，因为它是正确理念的严肃执行。 MTPLX 使用模型自身的 MTP 头进行草稿——与我们车道使用的相同机制——并通过精确拒绝采样接受草稿，因此在温度 0.6 下采样产生与普通解码相同的分布，只是更快。 没有单独的草稿模型消耗内存，草稿深度根据机器对自回归基线进行调优，项目拒绝将未经验证的 MTP 侧车附加到任意权重上。 那最后的政策是 Kimi 和我在前一天手动应用的纪律，当时我们将 Qwen3.8 的丢失 MTP 张量与其主干 重新配对。 第一部分的车道是显而易见的衡量标准：相同 Studio，相同模型系列，以相同方式测量。

安装通过了 2 隔离检查，才触及任何权重

第一次检查是我的。 回到三月，在我的自主改进实验室里，我们遇到了一个陷阱：一个隔离的 Python 环境悄悄失去了对 Apple 加速库的访问，导致数值仅恢复缓慢。 在 Kimi 进一步操作之前，我要求证明该陷阱并不适用。 一个 3 行探测确认了这一点——本地 arm64 解释器，Metal 可用，GPU 作为默认设备。 Apple 的 Metal 路径包含在 mlx-metal 轮子本身中，因此解释器的来源与 GPU 访问无关，第一部分的车道已经通过相同的隔离形状证明了 GPU 本地吞吐量。 MTPLX 自己的检查器也同意，评估了其 Qwen3.8-27B 构建，均为已验证本地化，且所有 15 MTP 张量均存在。
第二次检查是 Kimi 的，下载中期。 MTPLX 的 pull 命令忽略了常规的 Hugging Face 缓存环境变量，第一次尝试是将 20 GB 模型写入 Studio 的主目录，而不是受房屋规则保护的数据卷。 Kimi 终止了拉取，只删除了它创建的内容，并使用显式缓存目录重新启动。 观众整天都保持在 Apple 的曲线上，这在一台兼作飞行模拟器的机器上很重要。

那天早上最响亮的机器并不是运行实验的那台

下载中途，我自己的工作站开始剧烈抖动——负载平均值超过 50——我们停止实验以回答更重要的问题：这是否是我们的行为？ 不是。 我们的工作在 Studio 上运行短暂的 SSH 会话；本地占用仅有几个完成的 curl 和 ssh 进程。 风暴是一波 Apple 守护进程浪潮——一个卡住的资产下载、索引，以及一个在我们能命名其所有者之前消失的虚拟化进程的爆发——加上发现我一直在杀死的“神秘重启节点进程”实际上是 3 个开发主管正通过重启服务器完成他们的工作。 我们把整个过程写进了机器保护交接，并以清晰的良知回到实验中。 暂停之所以属于这个故事，是因为纪律与基准测试运行时相同：在责怪机器之前先了解自己的占用。

自动调谐器测得了 2.20 倍的爆炸

MTPLX 的调谐仪式是诚实的工程：它在每个草稿深度上在你的硬件上运行真实模型，保持自回归解码为基准，并且仅在击败该基准时才保存深度。 在 M1 Ultra 上，它产生了 AR 11.4，深度 1 在 9.2，深度 2 在 25.1，深度 3 在 20.7 tok/s——深度 2 在 2.20 倍时被加冕为冠军，保存供所有未来启动。
那个 25.1 是对真实引擎的真实测量，24% 超过我们车道的 20.3 服务速率。 如果服务器能再现它，这篇文章将是一份迁移指南。

服务器提供了 16.5，默认值在视线之外消耗令牌

服务基准使用相同的提示、温度 0，以及与通道基准相同的墙钟计费。 第一次运行返回 14.7 tok/s，响应元数据显示 2 默认值与测量相冲突：
  • 推理模式默认开启，Qwen3.8 在回答前会思考。 在一个简单的计数到10提示中，44 的 64 生成令牌被隐藏为推理，客户端从未显示。 真实工作负载为这些令牌付费，因此墙速已包含它们 — 但调谐器的提示没有这类税费。
  • Turbo 运行时配置，配合其编译的验证核，是本机 Mac 应用的启动规则。终端 mtplx serve 解析为 Sustained 配置，因此命令行路径永远看不到快速核，除非你请求。
固定 Turbo、深度 2 并关闭推理将 FP16 构建提升至 16.5 tok/s 墙速 — 这是 MTPLX 全天最佳表现。 4 位 Optimized-Speed 构建，项目推荐用于编码，提供了 15.5. 两个构建在磁盘上各占 20.4 GB，与你通道的 15 GB 相比，在带宽受限的机器上每个令牌都要流式传输额外的 5 GB.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)
Chart data
tokens per second
our lane (part one)20.3
MTPLX tune claim (D2)25.1
MTPLX FP16 turbo D216.5
MTPLX 4-bit turbo D215.5
MTPLX defaults14.7

调音器和服务器测量 2 不同的机器

当天最有用的发现解释了 25.1 与 16.5 之间的差距。 MTPLX 自己的服务器在启动时记录一个预热阶梯，该阶梯报告引擎 20-24 令牌/秒——在同一进程内随后提供 16.5 令牌/秒 HTTP。引擎很快，传输被压缩。 在解码循环与客户端之间是 HTTP 层、每请求会话银行记账（第一请求的统计中出现了 160 MB 快照写入），以及推理机制，每个令牌都跨越该边界。 在 M4 和 M5 芯片上，项目公布的 1.6-2.24x 结果被测量，较快的 CPU 和 Fabric 吸收了跨越。 M1 Ultra 的引擎跟上了；其服务路径没有。
Diagram source
graph LR
    subgraph 调音路径
        A[真实模型] --> B[草稿深度 D1-D3]
        B --> C[仅解码计时器  
25.1 令牌/秒]
    end
    subgraph 服务路径
        D[HTTP 请求] --> E[会话银行  
+ 推理默认值]
        E --> F[同一引擎  
阶梯显示 20-24]
        F --> G[每令牌边界  
16.5 令牌/秒墙]
    end

    style C fill:transparent,stroke:#10B981,stroke-width:2px
    style G fill:transparent,stroke:#F59E0B,stroke-width:2px
这是第一部分的课程，穿上新服装。 llama.cpp 的社区声称 25-32 令牌/秒未能在此芯片上存活，MTPLX 的调音器 25.1 在其自身服务器上也未能存活。 耐用规则会被锐化：服务速率在 HTTP 边界处测量，生产默认值可见，永不在调谐器内部。 那就是 benchmark-driven development 在堆栈上层应用 1 层。

挑战者轻了 38 GB，监视器则留在后面

我在实验开始前给 Kimi 设定了 1 的不可谈判条件：任何在该 Studio 上运行的程序在空闲时都必须自行停止，因为机器的晚间任务是一个飞行模拟器。 MTPLX 的聊天服务器没有空闲超时，因此 Kimi 在一个小包装脚本中构建了监视器——仅回环绑定，Apple 的策略下风扇开启，以及一个连接监视器，在 10 分钟无客户端后停止服务器。 它通过了现场演习，在 60 秒标记处拆除测试实例并干净地释放端口。 包装器和虚拟环境留在机器上，因此重新测试只需 1 下载即可，当 MTPLX 发行版使用 M1 代际服务路径或将匹配的 MTP 工件更接近 15 GB 时。
权重本身并未保留。 一旦判决明确，我们仔细清理——两套 MTPLX 模型目录，38 GB 跨 FP16 和 4 位构建，确认无进程持有后删除，恢复卷到实验前的确切空闲空间。 删除仍是工作流程的一部分：每个失败的挑战者当天就会清理磁盘，这保持了下一个实验的诚实。

重新比赛为清单添加了什么

第一部分的通道从未移动。 它在 20.3 tok/s 的早晨提供服务，在 20.3 tok/s 的傍晚提供服务，现在它将自己的位置保留给 3 挑战者，而不是 2——仍然是一个实验通道，1 下载后离下次重新比赛仅一步。 第一部分的清单增加了 3 条目：
  • 调音器的编号是引擎的上限，服务路径决定你保留多少。 在边界上测量你的客户端实际跨越的距离。
  • 默认值是基准的一部分。 推理模式、运行时配置和会话缓存都消耗令牌或时间，公平竞争会在双方明确标记它们。
  • 磁盘是一个假设预算。 2 挑战者以 20.4 GB 的速度构建，每一次购买都在 1 下午的确定性中完成，而当字节按计划离开时，确定性更便宜。
这对的令人满意的对称性是：第一部分通过排队这个确切实验结束，实验以产品形式到达，内含真正的工艺——精确采样、每台机器调优、诚实验证。 工艺是真实的，损失是真实的，两项发现都来自同一天的测量、CPU 风暴等。 有计分板的冒险是最好的类型，这一次 Kimi K3 在我旁边阅读每个计数器——我从将 local AI gains as infrastructure 视为基础设施中获得的相同复合回报。 通道保留其位置，磁盘保持精简，清单更长，下一个挑战者已经可以尝试。