@akshay_pachaar: 这个推理引擎运行 LLM 比 llama.cpp 快 4 倍：（Qwen3.5-9B 在 16GB Mac 上达到 92 tokens/s）我在一台…

这个推理引擎运行 LLM 比 llama.cpp 快 4 倍： （Qwen3.5-9B 在 16GB Mac 上达到 92 tokens/s） 我在一台基础款 M5 MacBook Pro 上使用三个本地推理引擎逐一运行 Qwen3.5 9B。 → llama.cpp 达到 22.0 tokens/s → MLX 达到 25.1 tokens/s → Uzu 达到 92.1 tokens/s 视频展示了三次运行的并排对比。 前两个结果并不意味着 llama.cpp 或 MLX 优化不好。它们都已接近普通本地解码的物理极限。 正常生成每个新 token 都需要再遍历一次模型。每次遍历约有 5.2 GB 的权重需要通过内存传输。 基础款 M5 的内存带宽约为 153 GB/s。 每次遍历只产出一个 token 的情况下，理论上限约为 153 ÷ 5.2，即 29 tokens/s，无论 GPU 计算多快。 Uzu 通过针对 Apple Silicon 优化的投机解码突破了这一上限。 投机解码使用一个较小的草稿系统来预测多个未来的 token。然后由完整的 9B 模型一次性校验这些预测，而不是为每个 token 单独遍历模型来生成。 Uzu 在两个方面更进一步： → 它一次草拟最多 16 个位置，并使用 Weaver 将独立的猜测转化为连贯的序列。 → 它以树状结构校验多个可能的序列，然后只为完整模型接受的路径提交状态。 9B 模型仍然控制着最终输出。Uzu 只是在每次遍历中给它提供了更多有价值的待批准工作。 在我的运行中，9B 模型每次遍历平均产出 7.5 个输出 token。 普通解码每次遍历恰好产出 1 个。 这就是 Uzu 在每次遍历上限仅约 29 个 token 的硬件上达到 92.1 tokens/s 的原因。 引擎的其他部分也是围绕这条路径设计的。Uzu 自带量化的检查点，在 M5 芯片上其 Metal 内核通过 GPU 的加速 int8 矩阵路径执行校验。 它是 Mirai 开源的推理引擎，提供 Rust、Swift、Python 和 TypeScript 的绑定。 仓库地址：https://github.com/trymirai/uzu （别忘了点星 🌟） 我撰写了完整的深度分析，解释为什么本地推理受限于内存带宽，以及 Uzu 如何突破这一限制，附有可复现的结果和代码。 文章引述如下。