作者在 ARM (Neoverse-N1) 和 AVX2 x86 CPU 上对比了多个低比特（1-bit/三值/2-bit）GGUF 模型运行时的正确性与速度：bitnet.cpp main 在 CPU 上仍输出错误结果（需 #588/#642 补丁），Bonsai 1.7B 在所有能加载的运行时中均正确，而 ik_llama.cpp 配合 -rtr 通常最快。附带可复现脚本与 Kaggle/Colab 验证笔记本。
我想弄清楚哪些低比特（1-bit / 三值 / 2-bit）GGUF 文件在 CPU 上能真正给出正确输出，以及运行速度如何，因此我把每个运行时都与参考实现进行了对比，而不是凭文本看起来是否正常来判断。测试机器：一台 ARM 服务器（Neoverse-N1），以及配备 AVX2 的 x86 虚拟机（Intel Xeon、AMD EPYC）。
**BitNet b1.58 2B4T** bitnet.cpp main（0b341e5）在 CPU 上输出错误。在 x86 上文本看起来正常，但在相同 token 上困惑度约为 HF transformers 参考的 6 倍。在 ARM 上则打印 ????. 这些问题早已被报告（#588：模型使用 ReLU² 而代码用了 SiLU；#470 针对 ARM）。我补充的是：将每个提议的修复逐一对参考实现进行了测试。有效的是 #588 中的激活函数修复（一行改动，或 #605 加一个运行时键），以及 ARM 上的 isHuangXin/llama.cpp#2。#642 的第三个版本（10 月 15 日）将该一行改动与同一个 ARM kernel 打包在一起，在 ARM 和 x86 上均正确。
不打补丁的当前方案：ik_llama.cpp，先把文件转换为 iq2_bn_r4（在两种 CPU 上均正确）。
**Bonsai / Ternary-Bonsai（PrismML）** 1.7B 文件在所有能加载的运行时中输出均正确——llama.cpp、Prism 分支和 ik_llama.cpp（与精确 F16 参考计算 KL，在 ARM 和 x86 上验证）。对于 27B，Prism 和 ik_llama.cpp 的结果相互一致。速度取决于文件 × 运行时 × CPU 的组合，而非文件大小。
Ternary-Bonsai 1.7B 在 x86 上的 prompt 处理速度：ik_llama.cpp 配合 -rtr 使用 PQ2_0 为 71 t/s，Prism 中为 28 t/s，Prism 中 Q2_0 g64 仅为 2 t/s（尚无对应 SIMD kernel）。llama.cpp 于 10 月 13 日合入 AVX2 kernel（约 6 倍提速），ik_llama.cpp 同日加入 Q2_0（比 Prism 快约 15 倍，在 ARM 和 x86 上均正确）。-rtr 默认关闭，不开启时 ik_llama.cpp 往往是最慢的。
27B：在 AVX2 上的 Prism 中，较小的 PTQ1_0 文件在 prompt 处理上比 PQ2_0 慢约 4.4 倍。Ternary-Bonsai-1.7B 卡片上标记为 "recommended" 的 Q2_0 文件在三个运行时中均无法加载。请使用 PQ2_0（Prism、ik_llama.cpp）或 Q2_0_g64（llama.cpp、Prism，以及 10 月 13 日之后的 ik_llama.cpp）。
每个数据点都标注了运行时 commit、文件 sha256 和参数，有一个脚本可重新运行主要测量。笔记本可在免费的 Kaggle 或 Colab 虚拟机上运行一个子集（约 30 分钟到 1 小时），并与已发布数据进行对比。
我只有 Neoverse-N1 和 AVX2 x86。AVX-512 / Zen 4、Graviton 3/4 或 Raspberry Pi 5 的结果将填补最大的空白；Apple Silicon 也一样，但目前脚本仅支持 Linux。
报告地址：https://github.com/matheus-c-feitosa/lowbit-atlas 欢迎指正。我已经修正了一处：早前关于 27B PTQ1_0 文件 "慢约 6 倍" 的结论来自粗略计时，llama-bench 显示为 4.4 倍。（英语不是我的母语。我使用 Claude Code 协助分析和措辞；运行是在我的 ARM 服务器和免费 Kaggle/Colab 虚拟机上完成的，数据由我亲自核对。）