BitNet 推理内核优化：单测 29 倍加速，端到端仅 6-10%

一位独立开发者在 Reddit r/LocalLLaMA 分享了自己用纯 C99（无 Python、无 BLAS，仅 gcc 与 make）从零编写的 BitNet 三值模型 CPU 推理引擎的优化经历。核心结论是：在矩阵乘法内核单测中拿到 29 倍加速的「漂亮数字」，在实际端到端推理中只换来了 6-10% 的吞吐提升，因为 BitNet 解码阶段早已撞上 DRAM 带宽天花板。

内核单测结果与「假性胜利」

作者重点优化了 matmul 内核，借助 AVX-512BW 的 vpermt2w 指令将每个字节打包 5 个三值权重（而非常规 4 个），在隔离测试中达到 74.6 Gop/s，对照标量基线 2.5 Gop/s，提速 29 倍。他一度将这个数字发布到多处，并准备合入主干。

然而 PR 评审中一个被忽略的问题被翻出来：在他们使用的 Xeon 测试机上，BitNet decode 阶段已经跑到约 95% 的 DRAM 带宽上限。也就是说，推理是内存受限（memory-bound）而非计算受限（compute-bound），更快的内核只是让 CPU 把更多空闲时间花在等内存上，而不是真正多算多少 token。按其自述的「诚实换算」，内核真正接入调度路径后，端到端收益只有 6-10%，而截至发帖该内核尚未完成接入，仅在与标量参考做正确性比对后「闲置」在仓库里。

引擎本体表现与适用场景

抛开这次内核实验，引擎本身是能跑的：BitNet b1.58-2B-4T 在同一台 Xeon、4 线程、无 GPU 的条件下达到 36 tok/s；如果不需要三值量化，它也能跑常规 GGUF 稠密模型。

• 仓库：github.com/shifulegend/project-zero
• 预编译二进制：随 Release 提供，免编译即可试用
• 源码构建：仅依赖 gcc 与 make

这件事给工程优化带来的启示

作者自己也承认结果有点「泄气」，但强调宁愿现在知道，也好过把 29 倍标题数字端出去，等别人用 tok/s 而不是 Gop/s 一测就翻车。他在帖子最后抛出两个开放问题：

• 还有没有人在自己的栈上「测错层」踩过类似坑？
• 这个 DRAM 带宽天花板在其它硬件（尤其是非 Xeon 内存控制器）上是否依然成立？

帖子底下也引出了一条对低资源 LLM 部署社区有参考意义的隐含经验：在评估 1-bit / 三值模型这种参数极小的推理优化时，先看 memory roofline 再决定要不要继续堆算力。

本文为对原帖核心事实的编辑整理；具体数字与仓库地址以原帖及 GitHub Release 为准。