本地LLM提速4倍，不靠硬件，靠投机解码

同一台 M5 MacBook Pro，同一个 Qwen3.5 9B 4-bit 模型，llama.cpp 跑出 22.0 tokens/s，MLX 跑出 25.1 tokens/s，一个叫 uzu 的引擎跑出 92.1 tokens/s。Avi Chawla 在 X 上贴了三个引擎并排运行的视频，差距肉眼可见。

这个差距背后的物理限制，Karpathy 在 2023 年就解释过。LLM 每生成一个 token，就要把全部权重从内存读一遍，做一次完整前向传播。M5 的内存带宽约 153 GB/s，一个 4-bit 9B 模型约占 5.2 GB。153 ÷ 5.2 ≈ 29。也就是说，每秒最多产出约 29 个 token，跟 GPU 算力无关。llama.cpp 和 MLX 都贴着这条线上限。它们没有写错，只是普通解码每次只产出一个 token。

uzu 换了个思路：让一次前向传播多产出几个 token。它用一个小模型 DFlash 草拟未来 16 个 token，再用一个 56.7M 参数的 adapter Weaver 把草稿整理成连贯的候选分支，最后让 9B 主模型一次性验证整棵树，接受其中最长的合理路径。主模型仍然是最终决策者，每个输出 token 都经过它确认。在 Avi 的实测中，9B 模型每次前向传播平均产生 7.5 个 token，普通解码是 1 个。所以它能跑过带宽上限，因为每个 token 摊到的权重读取量只有原来的七分之一左右。

uzu 是 Mirai Labs 开源的推理引擎，Rust 编写，Metal kernel，支持 Swift、Python、TypeScript 绑定。它还自带 4-bit checkpoint，并用随机 Hadamard 变换处理量化中的异常值，在 M5 上跑在 GPU 的 int8 矩阵路径上。Akshay 写了一篇深度拆解（https://x.com/i/article/2108246386538094592），完整解释了这些技术细节。

想自己验证，一条命令就够了：

brew install mirai
mirai --model trymirai/Qwen3.5-9B-M -m "Write a python function to merge two sorted lists"

Avi 跑出来的 CLI 统计：time to first token 0.12s，generation speed 98.10 tok/s，tokens per forward pass 8.39，内存占用 5.77GB。也就是说，每次前向传播平均产出 8.39 个 token，所以生成速度接近 100 tok/s。uzu 也提供 OpenAI 兼容的本地 server，现有应用改一下 endpoint 就能切换。

但 4 倍不是免费午餐。投机解码的收益取决于文本可预测性。代码和数学这类确定性强的内容，草稿接受率高；开放闲聊经常被拒绝，速度优势会缩水。有网友在 M2 MacBook Air 上复现，uzu、MLX、llama.cpp 速度几乎一样——uzu 的投机配置目前只针对 M5 系列，旧芯片上会退化成普通解码。另外，三个引擎的量化格式并不完全一致，所以这是完整引擎路径的对比，不只是 kernel 对比。Avi 也承认，7.5 tokens/pass 是平均，实际值在代码和开放文本之间波动。

本地推理的瓶颈是内存带宽，这已经是共识。uzu 的价值在于把绕过瓶颈的工程方案做成了普通开发者能直接用的工具。硬件升级很贵，软件升级免费。这可能是目前最划算的本地 LLM 提速方式。