9月3日消息,Perplexity 开源了本地推理引擎 Lily,代码放在其推理技术仓库 pplx-garden 的 lily 目录下,采用 Apache 2.0 协议。Lily 的用途非常专一:在 Apple 芯片上运行阿里通义的 Qwen3.6-35B-A3B 模型,为 9 月 2 日刚上线的 Computer 混合计算功能提供端侧推理速度。 一台只为单一 checkpoint 服务的服务器
Lily 的定位写在仓库 README 的第一行:一台小型的 Metal 推理服务器,只服务一个 checkpoint——Qwen3.6-35B-A3B 经 MLX affine 4bit 量化(group size 64)的版本。加载时它会校验模型的确切架构和量化格式,稠密版 Qwen、更小尺寸的 Qwen、BF16、GGUF、AWQ、GPTQ、int8、fp8 等格式一律拒绝。
接口同样刻意收窄。Lily 只提供 OpenAI chat completions 的最小子集:仅接受文本消息,固定贪心解码,不支持流式输出、工具调用、采样参数和推测解码,思考模式默认关闭。它唯一保留的性能特性是会话前缀缓存:一个两格的 LRU 缓存,新 prompt 与已有 token 序列严格前缀匹配时复用解码状态,并在响应里报告命中的缓存 token 数。上下文容量上限为 262,144 token。
Qwen3.6-35B-A3B 是阿里通义 2026 年 4 月开源的稀疏 MoE 模型,总参数 350 亿、每次推理仅激活约 30 亿,主打智能体编程场景,采用 Apache 2.0 协议。
为什么存在:混合计算的端侧不能成为瓶颈
Lily 的直接背景是 Perplexity 9 月 2 日在 Mac 版 Computer 上线的 Hybrid Compute(混合计算):同一项任务由云端前沿模型和运行在用户 Mac 上的本地模型接力完成,涉及私密信息的步骤留在本地处理。这个架构里,本地模型承担的是用户体验链条上的一环——它慢,整个混合计算就慢。
Perplexity 官方给出的性能报告显示,在 M5 Max 上,Lily 相对 MLX-LM 的 prefill 吞吐约为 1.23 倍、decode 约为 1.35 倍。这组数字是厂商口径,测试条件与复现步骤写在仓库的性能报告中,目前尚无第三方复测。对比对象的选择本身说明问题:MLX-LM 是 Apple 芯片上最常被使用的通用本地推理框架,Perplexity 没有在它的基础上做优化,而是重写了一个只支持一种模型的引擎。
使用门槛:M5 起步,macOS 26 起步
Lily 的硬件要求不低:Apple GPU family 10 及以后,即 M5 及更新的机型;系统需要 macOS 26 及以上;构建工具链锁定 Rust 1.92。模型侧必须下载指定的 4bit checkpoint,仓库给出了不可变的 Hugging Face revision 号,基准测试和测试套件都基于这个固定版本。
所以它既不适合旧款 Mac,也不适合想换模型试用的开发者。Lily 目前更像一个产品配套组件,而非通用工具。
放在 pplx-garden 里看:从云端集群到端侧单模型
pplx-garden 是 Perplexity 2025 年 11 月开始维护的推理技术开源仓库,此前发布的组件都面向云端,例如让万亿参数 MoE 模型跑在现有 GPU 集群上的 TransferEngine。Lily 是这个仓库伸向端侧的第一块。
两端放在一起,能看到同一条思路:不为通用场景造工具,而是围绕自家产品的真实瓶颈写专用组件——云端要解的是多节点专家路由的通信延迟,端侧要解的是单一模型的解码吞吐。对 Mac 用户而言,混合计算加专用引擎的组合有好处也有代价:敏感步骤留在本地、端侧更快是好处,但只有最新一代机型能用是代价。对端侧推理生态来说,Lily 与 MLX-LM 这类通用引擎并不构成直接竞争——它只在一个 checkpoint 上成立。它能否走出「只为 Computer 服务」的处境,取决于 Perplexity 后续是否支持更多模型,这一点目前没有官方说法。