Laya 杀上 Apple Silicon7.4ms 端侧决策Mac 玩家开始自己跑快思考【免费下载链接】layaNon-autoregressive System 1 decision engine. Typed choice, score and yes/no decisions over any text in a single forward pass, in 100 languages, with a router that picks the right checkpoint per request.项目地址: https://gitcode.com/gh_mirrors/lay/laya2026 年 9 月底开源社区出现了一则被反复转载的消息Laya 决策模型推出面向 Apple Silicon 的 MLX 原生移植版本laya-mlx多语言检查点端到端延迟低至7.4ms并且被演示为一个以每秒 60 步的速度自己玩贪吃蛇的打字决策模型。与之几乎同时主仓库 README.md 的社区工具清单中收录了 laya-apple——一个用MLX GPU Apple Neural Engine 双引擎异构服务的 Apple Silicon 运行时。这两件事放在一起意味着System 1 快思考正在从云端 GPU 服务T4 上单次前向 33ms下沉到 Mac 本地并且走了一条与 PyTorch/MPS 完全不同的原生路径。本文结合社区发布信息与仓库源码回答三个问题laya-mlx 的去 PyTorch 依赖到底意味着什么7.4ms 与 60 步/秒背后的 Apple Silicon 能力边界在哪以及它对做本地 Agent 的 Mac 开发者意味着什么。一、去 PyTorch 依赖从MPS 能跑到原生 MLX 推理社区发布信息对 laya-mlx 的描述很直接彻底移除 PyTorch 与 Transformers 依赖基于 MLX 做原生推理支持本地离线、接口兼容迁移并已通过静态工程审计。要理解这一步的分量需要先看主仓库里Mac 上跑 Laya原本的账。在标准 PyTorch 路径下Mac 用的是 MPSMetal Performance Shaders设备。仓库实测数据BENCHMARKS.md 的 M1 Pro 章节复现脚本 benchmarks/bench_mps_autocast.py给出了非常具体的数字M1 Pro16GBmacOS 26.1torch 2.14.0上English 检查点421MModernBERT-large单问题 fp32 中位延迟58.2ms多语言检查点322MmmBERT-base单问题25.5ms。更值得注意的是 MPS 混合精度fp16 autocast在 M1 Pro 上几乎全面跑输 fp32——fp16 在每个请求上要多付约 1030ms唯一的例外是长文本、8 行问题的 English 检查点。这也是为什么 0.3.26 把mps_amp_min_rows触发 autocast 的最小问题行数默认设为 5并建议LAYA_MPS_AMP_MIN_ROWS1000000直接关闭。这组数据说明一个工程现实PyTorch 的 MPS 路径解决的是能跑不是快。小 batch、单问题恰恰是 System 1 决策负载的典型形态而 torch 前向的启动与调度开销在这一形态下占比极高。Docker 场景更明显——docs/docker-platforms.md 明确指出Docker Desktop 跑的是 Linux 容器没有 MPS 后端Apple Silicon 上容器内只能用 CPU。原生 MLX 路径的意义正在于此把运行时开销压到单次前向本身的算力极限同时去掉 torch/transformers 的依赖链条让本地离线成为默认而非例外。仓库里其实已经存在一条无 PyTorch推理的先行路径TypeScript 移植 laya-ts/README.md 通过 ONNX Runtime 在 Node 和浏览器WebGPU→WASM 回退里跑encoder.onnx head.onnx导出脚本在 laya-ts/scripts/export_onnx.py并带 1e-4 量级的 torch-vs-ONNX 一致性校验。laya-mlx 走的是同一哲学在 Apple 硬件上的深化不导出到通用格式而是直接在 MLX 的数组与算子语义上重建前向从而吃满 Metal GPU。顺带一提被主仓库收录的 laya-apple 在异构方向上走得更远它同时维护 MLX GPU 与 Apple Neural Engine 两条执行路径并且只在 ANE 产物通过本机 parity gate 后才启用它——原因是普通 Core ML 导出在 ANE 上快但不准在测试机上最多与上游相差 85 个决策。这个细节很重要快思考模型的价值前提是快且一致而不是快但偶尔换个答案。二、7.4ms 与 60 步/秒Apple Silicon 端侧能做到什么把数字放在一起看端侧决策的能力边界就清晰了主仓库基线README.mdT4 GPU 单问题 33msbatch 后摊到7.2ms/问题M1 Pro MPS fp32 实测English 58.2ms / multilingual 25.5ms单问题laya-mlx 发布信息多语言检查点端到端7.4mslaya-apple 在 M4 Max 上的引擎对照单问题 ≤128 token 时 ANE 前向 9.9ms、MLX 12.2ms长上下文则反转为 MLX 更快L256 19.2ms、L1024 71.0ms。这些数字拼在一起说明 Apple Silicon 端侧的真实水平是短输入、单问题的结构化决策可以压到 10ms 上下而这恰好是 System 1 决策负载的形态。多语言检查点322M 参数是端侧的主力——它更小、更快且 100 语言路由由内置 Router 在 0.5ms 的纯 Python 检测后完成路由本身不加载权重毫秒级返回见 README.md 的 Why Route 章节。60 步/秒玩贪吃蛇则是这组延迟数字最直观的注脚。仓库中对应机制的参考实现是 laya-ts/examples/snake.mjs每一 tick模型对四个移动方向各问一个noul问题Will the snake die if it moves X next?把模型给出的死亡概率与食物引力启发式融合后决定方向模型连续出错 5 次自动回退到纯启发式防止决策引擎崩溃拖垮游戏主循环。这个 demo 的工程形态很有代表性——模型当裁判、启发式当选手、置信度当熔断开关——正是端侧实时控制场景的标准分工。README 中还有一个 4000 token 级别的参考多语言检查点在 Apple GPU 上处理约 4000 token 的长文本约需 1.7sREADME.md 长文档章节说明短输入极快、长输入线性变慢的边界是诚实的。值得一提的是Laya 这类 System 1 模型能跑到这个量级的根本原因是它不做自回归生成选择choice、评分score、是非noul三类问题共享一次双向编码前向输出即结构化答案与校准概率没有 token 生成、没有解析、没有幻觉空间。官方对比图完整展示了这条路线与通用决策 API 在准确率、多语言、延迟、校准上的差异三、对 Mac 开发者Agent 本地控制场景的新可能7.4ms 这个量级的端侧延迟真正打开的是 Agent 架构里控制回路本地化的空间。过去一个本地 Agent 的意图路由、工具选择、布尔守卫这类高频低延迟判断要么依赖云端大模型 API有网络与 token 成本要么用正则/规则硬编码不可扩展。Laya 的choice / score / noul原语加上多语言 Router让这些判断变成了一次本地前向——社区实践已经覆盖工单分流、邮件分类、内容审核、Guardrails、意图路由等场景也有开发者用约 740 条中文家电语料微调后把决策准确率从 0.36 提升到 0.837 的公开案例。对 Mac 开发者而言本地闭环是完整的仓库给出了三个可落地的环节推理除了 laya-mlx 与 laya-apple 的 MLX/ANE 路径主仓库的 MPS 路径devicemps与 laya-ts 的 Node/浏览器 ONNX 路径都可以直接跑且Router()首次下载后即可离线使用。微调notebooks/laya_finetune_typed_decisions_mps.py 是专门为 Apple Silicon 写的单进程训练脚本PyTorch MPS CPU 回退替代 DDP支持梯度累积README 给出的 16GB MacBook 参数是--micro-batch 1 --grad-accum 32——也就是说端侧决策 端侧微调可以在同一台 Mac 上完成且微调后的提升幅度通常是质变的typed-decisions 基准上从 0.362 到 0.766。编排决策模型作为控制层与本地 LLM 协作的模式已经出现——laya-apple 提供了POST /v1/systemone的本地 Jev 兼容服务用 7 个未修改的官方 Jev 客户端实测通过792/792 请求与上游一致性校验通过配合其 GPUANE 双引擎短决策不再排队等待长请求Switchyard 压力演示中 P99 决策延迟从 GPU-only 的约 3.1s 降到 54.5ms。当然端侧化不等于没有边界。主仓库的诚实数据值得复述一遍33ms 是 T4 的实测、M1 Pro 的 MPS fp32 是 25.5~58.2ms、fp16 autocast 在 M1 Pro 上多数时候更慢、ANE 路径必须通过本机 parity gate 才可信7.4ms 是 laya-mlx 在特定配置多语言检查点、短输入下的端到端数字不是普适承诺。但这些数字已经足够说明趋势当一次结构化判断降到 10ms 量级且完全离线时Mac 不再是只能调用云端决策 API 的瘦客户端而是一个能自己跑快思考的控制节点——这也正是 Agent 从演示走向实时控制所缺的那块拼图。【免费下载链接】layaNon-autoregressive System 1 decision engine. Typed choice, score and yes/no decisions over any text in a single forward pass, in 100 languages, with a router that picks the right checkpoint per request.项目地址: https://gitcode.com/gh_mirrors/lay/laya创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Laya 杀上 Apple Silicon：7.4ms 端侧决策，Mac 玩家开始自己跑“快思考“
Laya 杀上 Apple Silicon7.4ms 端侧决策Mac 玩家开始自己跑快思考【免费下载链接】layaNon-autoregressive System 1 decision engine. Typed choice, score and yes/no decisions over any text in a single forward pass, in 100 languages, with a router that picks the right checkpoint per request.项目地址: https://gitcode.com/gh_mirrors/lay/laya2026 年 9 月底开源社区出现了一则被反复转载的消息Laya 决策模型推出面向 Apple Silicon 的 MLX 原生移植版本laya-mlx多语言检查点端到端延迟低至7.4ms并且被演示为一个以每秒 60 步的速度自己玩贪吃蛇的打字决策模型。与之几乎同时主仓库 README.md 的社区工具清单中收录了 laya-apple——一个用MLX GPU Apple Neural Engine 双引擎异构服务的 Apple Silicon 运行时。这两件事放在一起意味着System 1 快思考正在从云端 GPU 服务T4 上单次前向 33ms下沉到 Mac 本地并且走了一条与 PyTorch/MPS 完全不同的原生路径。本文结合社区发布信息与仓库源码回答三个问题laya-mlx 的去 PyTorch 依赖到底意味着什么7.4ms 与 60 步/秒背后的 Apple Silicon 能力边界在哪以及它对做本地 Agent 的 Mac 开发者意味着什么。一、去 PyTorch 依赖从MPS 能跑到原生 MLX 推理社区发布信息对 laya-mlx 的描述很直接彻底移除 PyTorch 与 Transformers 依赖基于 MLX 做原生推理支持本地离线、接口兼容迁移并已通过静态工程审计。要理解这一步的分量需要先看主仓库里Mac 上跑 Laya原本的账。在标准 PyTorch 路径下Mac 用的是 MPSMetal Performance Shaders设备。仓库实测数据BENCHMARKS.md 的 M1 Pro 章节复现脚本 benchmarks/bench_mps_autocast.py给出了非常具体的数字M1 Pro16GBmacOS 26.1torch 2.14.0上English 检查点421MModernBERT-large单问题 fp32 中位延迟58.2ms多语言检查点322MmmBERT-base单问题25.5ms。更值得注意的是 MPS 混合精度fp16 autocast在 M1 Pro 上几乎全面跑输 fp32——fp16 在每个请求上要多付约 1030ms唯一的例外是长文本、8 行问题的 English 检查点。这也是为什么 0.3.26 把mps_amp_min_rows触发 autocast 的最小问题行数默认设为 5并建议LAYA_MPS_AMP_MIN_ROWS1000000直接关闭。这组数据说明一个工程现实PyTorch 的 MPS 路径解决的是能跑不是快。小 batch、单问题恰恰是 System 1 决策负载的典型形态而 torch 前向的启动与调度开销在这一形态下占比极高。Docker 场景更明显——docs/docker-platforms.md 明确指出Docker Desktop 跑的是 Linux 容器没有 MPS 后端Apple Silicon 上容器内只能用 CPU。原生 MLX 路径的意义正在于此把运行时开销压到单次前向本身的算力极限同时去掉 torch/transformers 的依赖链条让本地离线成为默认而非例外。仓库里其实已经存在一条无 PyTorch推理的先行路径TypeScript 移植 laya-ts/README.md 通过 ONNX Runtime 在 Node 和浏览器WebGPU→WASM 回退里跑encoder.onnx head.onnx导出脚本在 laya-ts/scripts/export_onnx.py并带 1e-4 量级的 torch-vs-ONNX 一致性校验。laya-mlx 走的是同一哲学在 Apple 硬件上的深化不导出到通用格式而是直接在 MLX 的数组与算子语义上重建前向从而吃满 Metal GPU。顺带一提被主仓库收录的 laya-apple 在异构方向上走得更远它同时维护 MLX GPU 与 Apple Neural Engine 两条执行路径并且只在 ANE 产物通过本机 parity gate 后才启用它——原因是普通 Core ML 导出在 ANE 上快但不准在测试机上最多与上游相差 85 个决策。这个细节很重要快思考模型的价值前提是快且一致而不是快但偶尔换个答案。二、7.4ms 与 60 步/秒Apple Silicon 端侧能做到什么把数字放在一起看端侧决策的能力边界就清晰了主仓库基线README.mdT4 GPU 单问题 33msbatch 后摊到7.2ms/问题M1 Pro MPS fp32 实测English 58.2ms / multilingual 25.5ms单问题laya-mlx 发布信息多语言检查点端到端7.4mslaya-apple 在 M4 Max 上的引擎对照单问题 ≤128 token 时 ANE 前向 9.9ms、MLX 12.2ms长上下文则反转为 MLX 更快L256 19.2ms、L1024 71.0ms。这些数字拼在一起说明 Apple Silicon 端侧的真实水平是短输入、单问题的结构化决策可以压到 10ms 上下而这恰好是 System 1 决策负载的形态。多语言检查点322M 参数是端侧的主力——它更小、更快且 100 语言路由由内置 Router 在 0.5ms 的纯 Python 检测后完成路由本身不加载权重毫秒级返回见 README.md 的 Why Route 章节。60 步/秒玩贪吃蛇则是这组延迟数字最直观的注脚。仓库中对应机制的参考实现是 laya-ts/examples/snake.mjs每一 tick模型对四个移动方向各问一个noul问题Will the snake die if it moves X next?把模型给出的死亡概率与食物引力启发式融合后决定方向模型连续出错 5 次自动回退到纯启发式防止决策引擎崩溃拖垮游戏主循环。这个 demo 的工程形态很有代表性——模型当裁判、启发式当选手、置信度当熔断开关——正是端侧实时控制场景的标准分工。README 中还有一个 4000 token 级别的参考多语言检查点在 Apple GPU 上处理约 4000 token 的长文本约需 1.7sREADME.md 长文档章节说明短输入极快、长输入线性变慢的边界是诚实的。值得一提的是Laya 这类 System 1 模型能跑到这个量级的根本原因是它不做自回归生成选择choice、评分score、是非noul三类问题共享一次双向编码前向输出即结构化答案与校准概率没有 token 生成、没有解析、没有幻觉空间。官方对比图完整展示了这条路线与通用决策 API 在准确率、多语言、延迟、校准上的差异三、对 Mac 开发者Agent 本地控制场景的新可能7.4ms 这个量级的端侧延迟真正打开的是 Agent 架构里控制回路本地化的空间。过去一个本地 Agent 的意图路由、工具选择、布尔守卫这类高频低延迟判断要么依赖云端大模型 API有网络与 token 成本要么用正则/规则硬编码不可扩展。Laya 的choice / score / noul原语加上多语言 Router让这些判断变成了一次本地前向——社区实践已经覆盖工单分流、邮件分类、内容审核、Guardrails、意图路由等场景也有开发者用约 740 条中文家电语料微调后把决策准确率从 0.36 提升到 0.837 的公开案例。对 Mac 开发者而言本地闭环是完整的仓库给出了三个可落地的环节推理除了 laya-mlx 与 laya-apple 的 MLX/ANE 路径主仓库的 MPS 路径devicemps与 laya-ts 的 Node/浏览器 ONNX 路径都可以直接跑且Router()首次下载后即可离线使用。微调notebooks/laya_finetune_typed_decisions_mps.py 是专门为 Apple Silicon 写的单进程训练脚本PyTorch MPS CPU 回退替代 DDP支持梯度累积README 给出的 16GB MacBook 参数是--micro-batch 1 --grad-accum 32——也就是说端侧决策 端侧微调可以在同一台 Mac 上完成且微调后的提升幅度通常是质变的typed-decisions 基准上从 0.362 到 0.766。编排决策模型作为控制层与本地 LLM 协作的模式已经出现——laya-apple 提供了POST /v1/systemone的本地 Jev 兼容服务用 7 个未修改的官方 Jev 客户端实测通过792/792 请求与上游一致性校验通过配合其 GPUANE 双引擎短决策不再排队等待长请求Switchyard 压力演示中 P99 决策延迟从 GPU-only 的约 3.1s 降到 54.5ms。当然端侧化不等于没有边界。主仓库的诚实数据值得复述一遍33ms 是 T4 的实测、M1 Pro 的 MPS fp32 是 25.5~58.2ms、fp16 autocast 在 M1 Pro 上多数时候更慢、ANE 路径必须通过本机 parity gate 才可信7.4ms 是 laya-mlx 在特定配置多语言检查点、短输入下的端到端数字不是普适承诺。但这些数字已经足够说明趋势当一次结构化判断降到 10ms 量级且完全离线时Mac 不再是只能调用云端决策 API 的瘦客户端而是一个能自己跑快思考的控制节点——这也正是 Agent 从演示走向实时控制所缺的那块拼图。【免费下载链接】layaNon-autoregressive System 1 decision engine. Typed choice, score and yes/no decisions over any text in a single forward pass, in 100 languages, with a router that picks the right checkpoint per request.项目地址: https://gitcode.com/gh_mirrors/lay/laya创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考