Laya 在 Apple Silicon 上：MLX 移植能为你带来什么，又不能带来什么

Laya是一个从不写出句子的决策模型。Convai Innovations 于 2026-09-18 将其权重发布到 Hugging Face 上，第二天，一位名叫 mizorewww 的开发者发布了Laya-MLX——一个独立移植版，它通过 MLX 在 Apple Silicon 上原生运行全部三个 Laya 检查点，无需 PyTorch、无需 Transformers 运行时，也不进行云端调用。该移植版报告称，在 M3 Max 上，421M 检查点上单个简短英文问题的中位数为 13.42 毫秒，322M 多语言检查点上为 7.39 毫秒，并且输出 token 数为零。与此同时 Kev，另一个追求相同类型化决策理念的开源家族，构建在 Qwen3.5-4B-Base 之上，在 Mac 上可用之前还需要一整套第二后端，因为 PyTorch 在 Apple GPU 上没有针对其 DeltaNet 层的内核。两个项目，同一周，同一目标，而其中只有一个干净地完成了移植。这种差异才是故事所在，而且这是一个运行时故事，而不是模型故事。

这篇文章之所以今天值得一写，并不是因为 Laya 是新的。而是因为在 2026-09-19 之前，在 Mac 上运行类型化决策模型时，无法不把一整套 PyTorch 技术栈一起拖进来；而读者真正关心的问题——我能在自己的笔记本电脑上运行它吗？我会放弃什么？——终于有了可量化的答案。所以这篇文章讲的是服务路径、其背后的数字，以及那些数字不再具有它们表面上看起来的含义的地方。

首先，Laya不是什么

Laya 不是 LLM。它是非自回归的：对状态和你的问题进行一次双向前向传播，然后输出类型化答案。没有逐 token 解码，没有思维链，没有需要解析的生成 JSON，也没有输出 token 计费。三种答案原语是choice（从 N 个命名选项中选择一个）、score（一个有序评分等级）以及noul（某件事为真的校准概率）。

这对你如何理解本文中的每一个数字都至关重要。当该端口报告 13.42 ms 时，它并不是在像生成基准测试那样，报告生成几百个 token 所需的 13.42 ms。它报告的是整个操作。将决策模型的延迟与 LLM 的每秒 token 数相比，是在比较两种不同的工作，任何这样做的文章——包括发布后流传的那篇爆火的“比 Jev 快 50 倍”的帖子——都在提出一个其底层工作实际并不支持的说法。

端口实际测量的是什么

这些数字是移植作者自己的，在已注明的机器上测得，解读时应连同机器和方法一并考虑。Laya-MLX 是在一台配备 40 个 GPU 核心和 128 GiB 统一内存的 M3 Max 上、以 FP16 精度测得这些数字的，且不包含模型加载时间。

• 一道简短问题，P50 —— 在 421M 英语检查点上为 13.42 毫秒，在 322M 多语言检查点上为 7.39 毫秒。

• 一个简短的问题，P95 —— 分别为 13.92 毫秒和 7.79 毫秒。

• 50 题吞吐量——146.8 题/秒和 395.0 题/秒。

• MLX 峰值分配量 — 943.6 MiB 和 687.6 MiB。

计时边界是值得反复阅读的部分。它包括提示词准备、分词、张量构建、同步推理、校准和结果格式化。它不包括模型加载。50 个问题的吞吐量测试使用了 batch_size=64，而 API 默认值为 16，因此这两个数字描述的是一种刻意批处理的负载，而不是单次交互式调用的成本。不同的输入长度、不同的问题数量和不同的运行时条件都会影响结果。这些说明正是数字与基准测试之间的区别，而移植版本本身也说明了这些。

内存下限是大多数读者会据此行动的数字，也是这组数据中歧义最小的一个：针对单个简短问题，在两个检查点上，MLX 的峰值分配量都不到 1 GB。这并不是关于你的 Mac 总占用量的说法——操作系统、你的终端和 Python 进程都与之并存——但它是一个真实的下限，并且大约比在本地运行一个中等规模生成式模型所需的量低三个数量级。

保真度检查是更有趣的结果

一个快速的移植版如果给出的答案与它所移植的模型不同，那就毫无价值，而这正是该项目做了真正重要工作的地方。三个检查点在 FP32 和 FP16 下都在 63 个验证问题中的 63 个上与上游选定的答案一致——即 378 次比较中的 378 次。每种配置还运行了 100 次重复的确定性调用，未测得活动内存增长，并且所有 36 个已发布的权重文件都通过了严格的远程校验和验证。

诚实地看待这一范围：它衡量的是在那些测试夹具上的保真度，而不是对所有可能问题的准确性。它只说明这个移植版忠实于 Laya，却丝毫没有说明 Laya 本身是否正确。

独立、由社区维护，却仍未列入名单

这个移植版这样介绍自己，而且说了两遍：它是一个独立的 MLX 移植版，并非 Convai Innovations 的官方发布。RLCD 训练与微调仍留在上游。权重归于 Convai Innovations。双方均采用 Apache-2.0 许可。

上游如何对待它，比任何免责声明都更能说明问题。Laya README 中有一个 Community Tools 列表，截至 2026-09-23，该列表包含四个条目：omp-laya-judge、laya-adk-toolkit、laya-Ascend（用于华为昇腾 NPU），以及laya-apple——一个使用 MLX GPU 和神经引擎的 Apple Silicon 运行时。第四个条目通过拉取请求 #260 加入，并于 2026-09-23 合并。本文讨论的移植不在四者之中。上游的列表现在将 Apple Silicon 读者引向另一个社区项目，而不是那个最先发布并带有基准测试的项目。

上游自己的问题跟踪器说明了其余情况。议题 #50“Apple silicon 移植”于 2026-09-21 创建，目前仍未关闭；维护者当天回复称 Apple Silicon 支持正在跟踪中，并且像 Laya-MLX 这样的社区移植版正在探索原生 Metal 推理，随后又在 2026-09-23 回复了一句值得原样引用的话：“MLX 移植版仍由社区维护。”PyTorch 侧的修复——MPS 自动转换（autocast）以及 transformers 4.x 的 RoPE 校正——作为拉取请求 #273 落地，并于 2026-09-23 合并；该讨论串中的一位审查者指出，它仍需与 #109 中单独的 autocast 重构结合，而后者仍未关闭。此外，于 2026-09-21 创建的议题 #52 报告称，一个 Laya-MLX sidecar 在运行数小时后增长至约 21.7 GB 的 Metal 内存，其中vmmap将约 21.4 GB 归因于图形子系统，而非 Python 堆；该议题建议限制分配器缓存，并在每次推理后清空缓存，而该议题仍未关闭。

把这些放在一起，实际的答案是：这个运行时并未获得上游的官方认可，按维护者自己的说法，它是由社区维护的，而唯一对长期运行的边车来说真正重要的内存问题，目前是在公开场合推进处理，而不是在某个版本中修复。

我能在笔记本电脑上运行它吗？需要牺牲什么？

安装只需一条 pip 命令，而且该移植项目已发布预先转换好的 FP16 权重，因此你无需自行进行任何转换：

pip install laya-mlx

然后 import laya_mlx as laya，agent = laya.load("aac6fef/laya-mlx")，并调用 agent.predict(state, questions)。要求为 Apple Silicon、Python 3.11+ 和 macOS 14+。测得环境为 macOS 27.2、Python 3.12.13 和 MLX 0.32.2——并且移植说明指出，它使用的 MLX 发行版提供了 macOS 14、15 和 26 的 wheel，而安装程序选择了 26 那个，并且较旧的受支持 macOS 版本未在那台机器上测试。

你所放弃的，逐个维度来看：

• FP16 与 FP32——FP16 是默认值，也是上述所有主要数字的来源。FP32 与上游的数值一致性更接近，即使所选标签一致，不同精度下的概率也可能略有差异。可以请求 BF16，但它不属于已发布的验证矩阵，因此请将其视为未测试。

• 内存下限与余量——对于短问题，MLX 峰值分配低于 1 GiB 在任何 M 系列 Mac 上都很从容。这并不是关于持续服务器负载的陈述，而如果你打算将其作为长期运行的 sidecar 而不是库调用来运行，issue #52 就是要小心谨慎的原因。

• 多语言版本与英语版本 — 322M 多语言检查点是两者中更快的那个，也是覆盖 100 多种语言的那个，但此移植版本有意沿用了上游的警告：英语检查点无法替代多语言检查点。在两者之间进行路由才是预期模式，而非可有可无的附加功能。

• 上游官方认可与社区维护——答案是后者。上游发布说明中没有任何内容承诺该移植版本能在上游变更后继续保持可用。

• 速度与校准——快速移植并不能修复一个出厂时过度自信的校准分桶。上游会将拟合温度钳制在 [0.5, 5.0]，而出厂的 choice:11+分桶为 0.1006，这会把 logits 大约锐化十倍，并把一次抛硬币般的结果报告成近乎确定。拟合校准温度的存在自有其道理；在依据某个概率做分支之前，先在你自己的留出数据上把它们拟合好。

还有两个限制值得记住，二者都来自上游自己的跟踪器。action.act_probability 目前不携带可用信号——它对几乎所有输入都读为 1.0，而且在 396 个有标签的决策中，其原始 logits 相对于正确性的 AUROC 为 0.30（issue #185）。应改为以 confidence 作为门控，它在相同条目上达到 0.77。并且 noul 问题可能会跟随其选项标签而不是状态（issue #156）——上游自己的模型卡在明显正面的输入上报告了自信的“no”，在英文检查点上最为明显。它建议的变通方法不是换一个模型，而是重塑问题：将其作为一个两选项的 choice 提出，带有中性键（A/B），并将你的 yes/no 措辞作为选项描述。

为什么一个决策模型能干净地移植，而另一个却不能

这里的对比是架构层面的，对于任何要在这两个系列之间做选择的人来说，这是本文中最有用的内容。

Laya 的主干是 ModernBERT-large，一个完全由注意力构建的双向编码器。注意力正是 Apple 的 GPU 技术栈最擅长的地方，也正是 MLX 投入精力的方向。因此这次移植是对那些本就有快速路径的层所做的重新实现：编码器、决策头的 Transformer 层、评分头和动作头都在 MLX 中运行，而分词仍然经由 Hugging Face 的 Rust 分词器处理。

Kev 的骨干网络基于 Qwen3.5 基座，而 Qwen3.5 将注意力层与 Gated DeltaNet 层混合在一起。DeltaNet 是循环式的，会忽略注意力掩码。这带来两个后果。首先，每个问题都必须作为独立的一行来运行，而不能共享同一个被掩码的序列；Kev 项目对此的处理方式是只计算一次状态，然后按行复用其缓存。第二——而这正是在 Mac 上带来麻烦的地方——Apple GPU 上没有针对这些层的 PyTorch 内核，因此 PyTorch 回退到了参考代码。jaredpalmer/kev-4b的模型卡仍然用直白的语言标明了由此产生的限制：在 Kev-4B 的 Qwen3 版本上耗时 0.17 秒的五个问题请求，在 M5 上以 bf16 运行需要 0.78 秒。

在引用那句话之前，请先核对当前的措辞，因为它已经改过了。Kev 仓库的 README 现在称，服务器改为在 Apple Silicon 上通过 MLX 运行 Qwen3.5 模型，并公布了自己的 M5 数据：在一个约 270 token 的状态下、针对五个各含三个选项的问题请求，Kev-4B 在新状态下为 721 ms，在重复状态下通过前缀缓存为 136 ms，而 PyTorch bf16 MPS 路径上则为 3,302 ms 和 847 ms。Kev-0.8B 则为 149 ms 和 28 ms。上一代 Qwen3 模型仍在普通 PyTorch MPS 上运行，该项目称它们是在 Mac 上的不错选择。

注意别把这当成一场竞速的结果。这些并不是正面交锋式的对比测量。Laya-MLX 的 13.42 毫秒，是在 M3 Max 上回答一个简短问题；Kev 的 721 毫秒，是在 M5 上针对约 270 个 token 的状态，回答五个各含三个选项的问题。问题数量不同，选项数量不同，状态长度不同，机器不同，运行时也不同。真正可验证、也值得比较的是问题的形态，而不是谁胜出：纯注意力编码器移植到 Apple Silicon 毫无阻力，而混合线性注意力模型则需要一整套第二后端，才能在那里可用。

决策模型究竟有什么用

抛开那些基准测试的光环，诚实的适用场景其实很窄，项目自己也承认这一点：Laya 是一个便于快速做专门化的基座，而不是一个零样本决策引擎。在 Convai 自己的 typed-decisions 基准测试上，两个基础检查点的零样本得分分别为 0.362 和 0.342，而多数类基线为 0.461，随机基线为 0.318。它们的表现低于始终回答最常见标签所能达到的水平。那个醒目的 0.766 属于laya-typed-decisions——一个在该基准测试自身训练集上微调得到的检查点，绝不应被当作通用能力来引用。

Convai 发布的与 TypeSafe Jev 1.13.0 的对比正因如此值得一读，而他们在自己那边标注得很谨慎：每一个 Laya 数字都是路由器实际返回的结果，而 Jev 的数字是第三方已发布的数值，Convai 从未测量过，因为它没有 TypeSafe API 访问权限。在那份对比中，经路由的 Laya 在类型化决策上得分为 0.766，而 Jev 为 0.727；温度后 ECE 为 0.081，对 0.246；在 Tesla T4 上 p50 延迟为 32.8 ms，对 236–276 ms——同一个问题上相差 7.8 倍。这才是应该引用的数字。社交媒体上流传的“比 Jev 快 50 倍”这一数字并未出现在该项目的文档或其基准测试中，而且该项目自己发布的对比也不支持这一说法。Jev 在它领先的地方也领先：在 Banking77 上，Jev 得分为 0.870，而 Laya 为 0.425，因为 Laya 的选项共享固定的 token 预算，而 77 个标签每个只剩大约三到四个 token。

所以，真实部署的形态是一个便宜、本地、范围窄的决策头——负责路由工单、给紧急程度打分、回答是/否门控——其背后有一个生成式的东西来处理需要撰写内容的部分。决策模型在毫秒内做出类型化的判断并升级。生成式的那一半是运行在不同运行时上的另一个模型，而这正是路由器体现价值的地方：一个密钥背后接入 200 多个模型，按提供商标价计费、不加价，因此供应商调价当天即可生效，并且当某家提供商在运行中途性能下降时自动故障转移。OrcaRouter 不提供 Laya，也不提供 Kev 或 Jev——Qwen3.5 系列在我们的模型列表中，而决策模型本身不在。我们覆盖的是这套技术栈中生成式的那一半，也就是决策头每次升级请求时你都会调用的那一半。

还有另一个理由要将这两部分保持独立，而不是寻求一个模型来完成两者。一个本地决策头，其输出令牌成本为零且从不接触网络，与API调用属于不同类型的依赖：当网络不可用时它仍能工作，并且其成本不随其读取的文本量而增加。这才是值得付出代价的特性。本文其余部分讨论的是你在保真度、内存和维护方面为此付出的代价。

谁应该运行它，谁应该等待？

如果你使用的是 M 系列 Mac，并且你的决策是受限的——在具名选项之间做选择、一个评分标准打分、一个是/否门控——同时你要么有可用于微调的标签，要么准备好自行拟合校准温度，那就运行 Laya-MLX。安装只需一条命令，内存下限不到 1 GB，而且保真度工作已经完成并发表。

等等，如果你需要上游支持保证，如果你运行的是一个长期存活的 sidecar，并且希望内存增长问题在某个发布版中解决，而不是停留在一个开放 issue 上，或者如果你的问题是开放式的。一个非自回归编码器回答“我接下来该做什么”，并不是做同一件事的 LLM 的缩小版。它是一种不同的工具，只有当问题已经为它塑造好时，它才读得顺。