开源5天斩获6.4K Star！Jev开源平替，1G内存、7ms出结果！

前阵子 AI 圈里有个模型讨论度很高，TypeSafe 家的 Jev。

它不聊天、不写代码、不生成文章，你给它一段状态和一个问题，它只负责判断。选哪个选项，打几分，这件事为真的概率是多少。没有逐字生成，一次计算直接返回概率，代码拿到结果就能用。

这个只会回答选择题的模型，发布没多久就火了。很多场景本来就不需要大模型写一大段话。客服工单分给哪个部门，一条评论是正面还是负面，这个 bug 要不要立刻升级处理。这些事让大模型跑一遍要等几百毫秒，还得从文本里解析 JSON。Jev 直接返回结构化对象，毫秒级响应。

但 Jev 是闭源的，只卖 API。于是开源社区很快跟上了，平替叫 Laya，Apache 2.0 协议，思路和 Jev 基本一样，权重公开，谁都能下载自己跑，现在 star 数已经冲到2万上下。

这还没完，就在这几天，开发者 mizorewww 又往前推了一步，把 Laya 完整搬到了苹果的 MLX 框架上，项目叫 laya-mlx。PyTorch 不用装了，Transformers 运行时不用装了，云端 API 也不用调了，模型权重下载到 Mac 里，原生跑在 Apple Silicon 上。

laya-mlx开源一周，在 GitHub 上收获6k Star。

官方给出的数据是多语言版本单次短决策 P50 延迟 7.39 毫秒，峰值内存 687.6 MiB。1G 内存不到，7 毫秒出结果。

先理清三个名字的关系

Jev、Laya、laya-mlx，三个名字别搞混了：

Jev

Laya

laya-mlx

出处

TypeSafe 闭源 API

开源社区

mizorewww 移植版

推理后端

云端 API

PyTorch + Transformers

Apple MLX 原生

运行位置

TypeSafe 的服务器

本地 GPU 或云端 GPU

Apple Silicon 本地

协议

闭源

Apache 2.0

Apache 2.0

后两个本质上是同一个模型，laya-mlx 没有训练新模型，只是把 Laya 的推理栈从 PyTorch 换成了 MLX。三个检查点原封不动搬过来，FP32 和 FP16 两种精度都做了验证，63 个验证问题上 378 组对比全部和原版一致。如果已经在用 Laya，laya-mlx 就是同一个模型在 Mac 上更顺的跑法，不是另一个模型。

它能做什么：三种决策

它的 API 一共就三种任务类型，没有更多了。

choice，从几个选项里挑一个

给它几个候选答案，它返回每个选项的概率。比如客服路由，工单写着「发票被重复扣款」，让模型在账单、技术、销售三个部门里挑一个，顺便给出每个部门的概率。

score，按有序标准打分

比如「这条评论的情绪是正面、中性还是负面」，「这个 bug 的严重程度是低、中还是高」。返回的是各个等级的概率，可以直接算出期望得分。

noul，判断一件事为真的概率

说直白点就是回答是不是，但输出的是概率而不是简单的是或否。比如「这个客户是不是在要求退款」，模型返回 0.82，意思是有 82% 的把握认为是。

这三种任务的输入和输出都是结构化的，模型只做判断，不生成文本。一次调用还能把同一个状态下的多个问题一起塞进去，部门、紧急程度、是否退款，三个答案一起回来。

importlaya_mlx aslaya


agent = laya.load("aac6fef/laya-mlx")
result = agent.predict(
"I was billed twice. Please refund the duplicate today.",
{
"department": {
"type": "choice",
"instructions": "Which team should handle this request?",
"criteria": ["billing", "technical", "sales"],
},
"urgency": {
"type": "score",
"instructions": "How urgent is this request?",
"criteria": ["not urgent", "soon", "critical"],
},
"refund": {
"type": "noul",
"instructions": "Does the customer ask for money back?",
},
},
)
print(result["answers"])

主要是两件事叠加的结果。

一个是它压根不生成文字。 传统大模型哪怕只输出一个字，也要走一遍逐字生成的流程。laya-mlx 完全跳过这一步，一次前向计算直接给每个选项打分，没有 KV cache，没有采样。算力主要花在理解上，不花在生成文本上。

另一个是 MLX 原生推理。 MLX 是苹果给自家芯片做的框架，CPU 和 GPU 共享同一块内存，省掉了数据拷贝的开销。laya-mlx 没有用任何第三方推理引擎，就是纯 MLX 实现，没有 PyTorch 的运行时开销，启动直接加载权重开跑。

官方给的计时口径不算太失真。那个 7.39 毫秒是端到端延迟，包含 prompt 准备、分词、张量构建、模型执行、校准、结果格式化，只排除了模型加载时间。不是什么算子裸延迟，是一次短决策从进去到出来的完整时间。P95 也只有 7.79 毫秒，波动很小。

性能数据一览

数据都来自官方在 M3 Max 上的实测，40 核 GPU，128GB 统一内存：

指标

英文版 421M

多语言版 322M

短问题 P50 延迟

13.42 ms

7.39 ms

短问题 P95 延迟

13.92 ms

7.79 ms

50 题批量吞吐

146.8 题/秒

395.0 题/秒

峰值 MLX 内存

943.6 MiB

687.6 MiB

上下文窗口

512 tokens

1024 tokens

网上有些文章算过账，说它比 Jev 快几十倍。这个说法我建议大家听听就好，因为项目自己的 benchmark 里根本没有和 Jev 的对比，只有它自己在 M3 Max 上的数据。跨项目比速度，环境不一样，数字一点意义都没有。

贪吃蛇演示

仓库里还有个挺直观的演示，终端里的贪吃蛇，每走一步都真实调用一次模型做决策，外面套了一层安全层，模型给出危险动作时会被纠正。

开发者的演示视频是原速录的，按他推文里的说法大概每秒决策 60 次。开了编译和缓存优化之后，官方在 M3 Max 上的实测是每秒 75.40 步，连续 2400 步零死亡，安全层只介入了 2 次，绝大多数决策模型自己就能搞定。

快速开始

环境要求比较明确，Apple Silicon 的 Mac，macOS 14 以上，Python 3.11 以上。Intel Mac 跑不了，因为 MLX 就是给 Apple Silicon 做的。

我装的时候就一行：

pip install laya-mlx

第一次运行会自动下载权重，几百 MB，耐心等一下，之后就是纯本地了。没有 API Key，没有配置文件，没有模型服务器，拿前面那段代码改一改就能跑。

想玩贪吃蛇的话，装的时候带上 demo 依赖，先把多语言权重下好，再敲 laya-snake 就行：

pip install 'laya-mlx[demo]'
hf download aac6fef/laya-multilingual-mlx
laya-snake

终端窗口要至少 104 列 35 行。空格暂停，方向键调速，R 重开，Q 退出。

这些限制也要说清楚

这个东西好用，但局限性同样明显。

上下文很短，512 到 1024 个 token 的窗口，还要同时塞下状态、问题说明和选项。所以它只适合短输入、高频调用、输出结构明确的决策任务，长文档分析、多轮对话这些它干不了。

它不生成文本，写文章、写代码、聊天都不行，只做判断。需要通用大模型的场景，它不合适。

只支持 Apple Silicon。Intel Mac、Linux、Windows 都跑不了，目前也只测过 macOS。

内存数字也要看清楚：

687.6 MiB 是峰值 MLX 显存分配，不是整机占用。系统本身、Python 进程、分词器都要占内存。测试机是 128GB 的 M3 Max，普通 MacBook 跑起来没问题，但也不是零成本。

模型本身也有一些社区报告过的问题，比如上游仓库里有人提到 score 任务存在位置偏差，多语言检查点在某些小语种任务上表现一般。这些是模型训练层面的问题，和移植没关系，但用的时候要知道。

最后聊聊

从 Jev 火起来到 Laya 开源，再到 laya-mlx 搬上 Mac，前后也就一两周。

laya-mlx 就是把「不生成文字、只做判断」这条路线在 Mac 上跑通了本地部署。如果工作里有大量高频、结构化的判断任务，客服路由、意图识别、打分排序，这 1G 不到的模型可能会省下不少云端调用的费用。

项目刚出来没几天，代码、权重、benchmark 都是全开放的，感兴趣可以自己跑跑看。

开源地址

https://github.com/mizorewww/laya-mlx

关注AI技术前哨，随时掌握最新的AI动态