Conifer 把 Apple Silicon 本地推理压到了 llama.cpp 之下
普林斯顿计算机系几位博士生主导的开源项目 Conifer 5 月 26 日上 GitHub Trending 第一名，star 数从一周前的 4.2k 跳到 12.3k。项目用纯 Rust 写本地大模型推理引擎，主打 Apple Silicon。在 M3 Max 上跑 Qwen 2.5 32B Q4，单 token 延迟比 llama.cpp 同等量化方案低 28%，比 MLX 低 14%。这是过去一年苹果生态本地推理工具里第一个能在 benchmark 上同时压过两个标杆的项目。
项目主作者 Edward Liu 在 README 里把核心思路写得很白：”llama.cpp 是 C++ 历史包袱太重，MLX 是 Python 调度成本太高，我们想要的是 Rust 编译期把内存布局和 Metal kernel 调度全部静态化”。这个判断在 issue 区被反复验证——一个 32B 模型推理时 llama.cpp 运行时调度开销占总耗时 11%，Conifer 把这部分压到了 1.6%。
Metal 上的内核手写到了什么程度
Conifer 不复用 Apple 官方的 MPSGraph，自己写了一套 Metal 4 shading language 的 attention kernel。M3 Ultra 上 64K 上下文的 prefill 阶段，flash attention 风格的 kernel 让 KV cache 内存峰值降低 35%，prefill 速度从 llama.cpp 的 168 tokens/s 提到 244 tokens/s。这个数字在 Apple Silicon 上属于第一档表现——之前 MLX-LM 团队 benchmark 也只到 215 tokens/s。
Decode 阶段的优化更激进。Conifer 把 Q/K/V 的矩阵乘合并成一个 fused kernel，把 weight matrix 的内存读取从三次合并成一次。M3 Max（128GB）跑 Qwen 2.5 32B Q4 的 decode 速度是 38.4 tokens/s，对比 llama.cpp 的 30.1 tokens/s 和 MLX 的 33.7 tokens/s。这是数字层面 Conifer 真正的卖点——在同款硬件上让本地推理多挤出 25% 的吞吐。
和 llama.cpp、MLX 的边界
三者的目标用户是错开的。llama.cpp 跨平台、跨 GPU 厂商、模型支持最多，是事实上的本地推理基础设施。MLX 是 Apple 官方押的研究流水线，长板在和 PyTorch 工作流的兼容。Conifer 砍掉了跨平台和研究兼容这两条线，只做 Apple Silicon 上的最佳推理引擎，目标是给 macOS 客户端开发者一个能集成进 app 的 Rust crate。
这个定位决定了它的真实用户。已经有三个 macOS AI 客户端在过去一周宣布把推理后端从 llama.cpp 切到 Conifer——Witsy、Enchanted、Pico AI Server。切换原因都很类似：Rust 写的库在 Tauri、Swift FFI 里集成成本远低于 C++，crash 率也低一个数量级。这一档应用层切换本身比 star 数更说明 Conifer 的市场位置。
项目活跃度和真正的护城河
仓库当前数据：12.3k star，430 个 issue（其中 380 已解决），118 位 contributor，最近一周合并了 47 个 PR。维护者从最初的 3 人扩到现在的 9 人核心团队，包括 1 位前 Apple Metal 工程师和 2 位前 Cerebras 编译器工程师。这个团队结构是项目能压过 llama.cpp 的关键——既懂底层 GPU kernel 又懂 Rust 编译期优化的人非常少，普林斯顿这个圈子刚好把两边人聚齐了。
苹果生态本地推理这一档赛道过去两年一直没出”赢家”——MLX 太学院、llama.cpp 太通用、Ollama 是 wrapper 层、LM Studio 是闭源 GUI。Conifer 找到了窄缝：Apple Silicon 专属、Rust 写的工程级库、面向 app 集成。这种定位不是要打败 llama.cpp，是要在 macOS app 集成场景里把 llama.cpp 替掉。窄缝里跑出来的工具往往比通用工具活得更久——React 当年也是这么从 jQuery 的窄缝里跑出来的。
参考：Conifer 官网 · 内测申请
