Ollama 解码慢 2.7 倍：Magnitude 把 kernel 调优搬到了本机

Akshay 发了一组本地推理对比：base M5 MacBook Pro，Qwen3.5 4B 4-bit，同一个 9.2k token prompt。Ollama 跑的是 MTP build，双方都有投机解码。结果 decode 从 22.6 tok/s 到 60.0 tok/s，差 2.7 倍；prefill 从 464 tok/s 到 755 tok/s，差 1.6 倍；端到端时间砍半。

Akshay 把两次运行并排录了下来：

Ollama 的数值不代表它做得差。它的 kernel 是提前调好的。kernel 是 GPU 上每个矩阵乘和 attention 步骤背后的小程序，速度取决于任务怎么分给 GPU 核心、数据怎么走内存。Apple Silicon 从 8 到 80 个 GPU 核心，带宽从不到 70 到超过 800 GB/s，每个模型的层大小又不同。预构建引擎得为所有芯片选一套设置，大多数本地环境就在这套折中里跑。

Magnitude 换了个做法：下载模型时，在本机编译这个模型的 kernel。它试不同 kernel 配置，保留在这块芯片上最快的那组；再给每个模型配一个它能找到的最快投机解码 drafter，让每次模型前向多吐几个 token。

这件事对 agent 更重要。每个文件和工具输出都要先被处理，模型才开始写东西，prefill 阶段的 kernel 效率会直接冒出来。并发会话还能共享 prefix cache，避免并行 agent 互相拖慢。

但评论区的问题也值得摆出来。有网友提到，16GB 内存放模型加长 prompt 很紧；8GB MacBook Air 上 4B 4-bit 会不会 swap；也有人想看 Qwen 3.8 27B Q8 在 M5 Max 128GB 上的同样测试。还有人问 2.7 倍里有多少来自 drafter、draft acceptance rate 如何、四路 agent 并发时共享内存带宽会不会成为瓶颈、首次调优要多久、内存峰值有没有变化。有人把 Magnitude 的做法比作 Gentoo：kernel 按你的芯片编译，老派做法赢了。这些追问没有否定结果，但把单次单流数字和 agent 日常使用区分开了。

Magnitude 是 Apache 2.0 开源，Rust 写，桌面 app 和 CLI 都有，能一键接 Claude Code、Codex、OpenCode、Pi 等 agent。支持 Apple Silicon、NVIDIA、AMD、Intel，也能只靠 CPU 跑。仓库在 GitHub：http://github.com/magnitudedev/magnitude

安装命令：

curl -fsSL https://magnitude.dev/install.sh | sh

Windows PowerShell：

irm https://magnitude.dev/install.ps1 | iex

本地推理的隐藏税，经常被说成模型大小，实际还有 kernel 和芯片匹配。预编译一刀切有代价，自动本机调优把代价挪到了下载时。别把单次单流数字当成 agent 全流程答案，等更大模型、并发和长 prompt 的测试。