Ternary Bonsai 2 27B 对比 Qwen3.8-27B IQ2_XXS GGUF：比特更少，分数更高

Ternary Bonsai 2 27B 比 Qwen3.8-27B 的 IQ2_XXS GGUF 版本更小，而且根据随其发布的数字，它也更好——如果两者之间的唯一区别只是比特预算，这本来是不可能的。Bonsai 版本在 5.93 GB 的文件中每权重承载 1.76 比特。同一基础模型的传统 2 比特量化在约 7.3 GB 的文件中每权重约承载 2.2 比特。Prism ML 于 2026 年 9 月 17 日发布了该三值版本，它报告其模型在 20 项基准测试中的平均分为 83.9，而 IQ2_XXS 对照点为 75.2——8.7 分的差距有利于使用更少比特的模型。

这种反转就是全部关键，而且它不是什么花招。这两个文件是在模型生命周期的不同阶段由不同过程生成的，而这些过程之间的差异，比位宽上的差异更重要。这也是那种对比：流行的建议——“随便拿个 2 比特量化版就行，它们现在没问题了”——在其中撞上了最明确的反例，而且这个反例背后有独立测量支撑，而不是厂商的说法。

悖论即是机制

IQ2_XXS 是一种训练后量化格式。模型以全精度训练至收敛，然后在此之后，其权重被舍入为由拟合过程选择的低位表示。模型从未有机会适应；它是在事后被测量并近似的。i-quant 系列通过使用重要性矩阵——一次校准过程，决定哪些权重应获得更多可用精度——改进了较旧的 k-quants，但基本的操作顺序没有改变。先训练，再压缩。

Bonsai 颠倒了这个顺序。Prism ML 对自身方法的描述是：它彻底放弃了训练后量化，并强制施加三元约束于训练过程中：前向传播使用被限制为 {−1, 0, +1} 的权重进行计算，而反向传播仍然携带全精度梯度。模型在训练中学习的是能够承受该约束的表示，而不是把约束强加给从未预料到它的表示。该算法被描述为专有知识产权，但任何读过 BitNet 系列工作的人都会对其形态感到熟悉。

在此基础上还有两项改进，二者都能从算术中看出来。第一项是选择性精度：2620 万个参数——约占模型的 0.098%，在 bf16 下大约 52 MB，主要是线性注意力层的循环状态路径以及归一化权重——保持全精度，而不是被三值化。第二项是分块旋转。在选择三值之前，每个权重矩阵都会以 1,024 的块大小经过沃尔什–哈达玛旋转，这会将离群值分散到各个坐标上，使三级近似破坏性更小。该旋转被折叠进存储的权重中，因此不额外占用字节；相应的变换则在运行时改为施加到激活值上。

最后这一个细节带来的后果，你在第一次尝试运行它时就会遇到，而这正是这种方法真正的代价。

你指的是哪个 IQ2_XXS，它实际得分是多少？

在比较质量之前，先纠正一个大多数报道都会忽略的问题：“IQ2_XXS”并不是某一个具体产物。它是 llama.cpp 的一种量化类型，而不同工具链将同一类型应用于同一个基础模型时，所生成的文件在大小上有明显差异，在质量上的差异则更为显著。

最清晰的公开证据，是 2026 年 8 月 15 日由一名用户发布的独立对比；该用户当时在考察构建一个低于 2 比特的 Qwen3.8-27B 到底是否值得。该测试是一项 wikitext-2 KL 散度测量，在 512 上下文下使用 100 个块，与本地构建的 Q8_0 参考模型进行对比，其困惑度为 6.7500；每个候选模型都在同一轮测试中使用相同的重要性矩阵、语料库、基线和 llama.cpp 构建。结果如下：

• unsloth UD-IQ2_XXS — 8.39 GiB，困惑度 7.6528，平均 KLD 0.146，KLD 中位数 0.076，top-1 一致率 82.98%

• bartowski IQ2_XXS — 8.75 GiB，困惑度 8.5352，平均 KLD 0.301，KLD 中位数 0.162，top-1 一致率 76.53%

动态变体以 0.36 GiB 的幅度更小，与静态变体相比，在平均 KLD 上约好 2.1 倍——其困惑度为基线的 1.13 倍。两个文件顶着同一个标签，却在衡量输出分布漂移程度的指标上相差两倍。同一项测试发现，所有低于 2 比特的候选都比两个已发布的 IQ2 选项更差，因此这个基础模型的实际下限落在 IQ2，而不是低于它。

这对比较很重要，因为它改变了“7.3 GB 的 IQ2_XXS 构建”所指的内容。Prism ML 的数字来自其对基础模型进行的自身量化，每个权重 2.2 比特。同一系列的 unsloth 动态构建测得 8.39 GiB。bartowski 构建测得 8.75 GiB。因此，Bonsai 与“IQ2_XXS”之间的体积差距，取决于你指的是哪个构建，在 1.4 倍到 1.5 倍之间——比标题所暗示的 1.23 倍更大，而且这一切都发生在质量比较开始之前。

训练后构建在哪里出现故障，以及为什么它容易被忽视

8.7 分的总体差距是说明这一差异时信息量最少的方式，因为 IQ2_XXS 构建中的退化并不均匀。它是有选择性的，而且其模式与大多数人会预测的正好相反。

• MMLU-Redux——训练后构建版本表现相当不错，处于80多分的中高水平

• GPQA Diamond — 约 65.5，相比之下三元构建为 85.76

• AIME26 —— 根据构建版本不同，介于 57.5 到 78.6 之间，而三值构建为 95.83

• LiveCodeBench — 处于 56.4 到 70.05 的范围内，而三元构建为 90.07

IQ2 的确切数值在 Prism ML 的测试套件与社区测量之间有所浮动，上述范围涵盖了两者，但在每一个来源中，其形态都是一致的：表层知识得以保留，而任何需要持续推理链的东西都会急剧退化。这正是随意的测试发现不了的失效模式。让一个 2-bit 构建去总结一份文档或回答一个事实性问题，它的表现会像一个远大于它的模型。让它维持多步推导或生成非平凡的代码，崩溃就是突然发生的，而非渐进式的。这就是为什么“我试的时候感觉没问题”不能作为关于量化模型的证据——它只能作为关于你恰好试过的那几个提示词的证据。

三值量化版本在同一批基准测试上并未出现那种崩塌。Prism ML 报告称，其 AIME26 成绩为 95.83，而全精度基座模型为 94.58；LiveCodeBench 则为 90.07 对 90.05——基本持平。这也是该发布中最有价值的一项说法，因为它表明：训练阶段的约束换来的，恰恰是训练后阶段所丢失的东西。

这个反论是真实存在的，而质量表并未捕捉到它

以上所有内容都表明，在每字节质量方面，三值构建更胜一筹。有一个维度，传统 GGUF 彻底胜出，而且这并非小事：它能在你已有的软件上运行。

Qwen3.8-27B 的 IQ2_XXS 构建版本是标准的 llama.cpp 工件。它可以在 llama.cpp、Ollama、LM Studio、Jan 以及任何链接了 ggml 的软件中加载，覆盖 ggml 支持的所有平台，无需分支版本，也无需特殊内核。其重要性矩阵可以重建或替换。它的行为与你磁盘上的其他任何量化模型别无二致。

Ternary Bonsai 2 27B 则不然。这一架构混合注意力所用的三值内核，位于 Prism ML 自己的 llama.cpp 分支中。原版 llama.cpp 会把 PTQ1_0 和 PQ2_0 视为无法识别的类型而拒绝——也完全不知道该如何处理这些量化包所假定的旋转基。面向 Apple Silicon 的 MLX 构建带有 Metal 和 CPU 内核，但没有 CUDA 路径，因此在 NVIDIA 机器上会回退到 CPU 前向传播，耗时可能长达数分钟。Prism ML 确实列出了与若干运行时的集成，但根本问题依然成立：这个模型是否可用，取决于你所选用的运行时是否已被教会关于它的知识。

这就是诚实的取舍。你要在两者之间做选择：一个是体积大 1.4 倍、在你最可能想要 27B 模型的那些任务上表现明显更差、但到处都能跑的版本；另一个是更小、更好，却建立在一个目前无非是某家实验室的分支加上若干已采用它的运行时之上的生态。

运行其中任何一个需要什么

内存计算比文件大小所显示的更接近，因为 VRAM 里不只有这些文件。

• IQ2_XXS 构建 — 权重为 8.39 至 8.75 GiB，在 16 GB 显卡上留下约 7.5 GB 空闲空间，用于上下文和草稿模型。上述独立测试特别指出，一个 8.39 GiB 的构建已经能够同时容纳一个 2.1 GB 的草稿模型。

• Ternary Bonsai 2 27B — PTQ1_0 语言模型为 5.93 GB，如果你要使用图像，还要加上 0.63 GB 的视觉塔，再加上上下文。Prism ML 的 PQ2_0 打包占用 7.25 GB，并且在受指令吞吐量而非带宽限制的硬件上是更快的选择。

就速度而言，所报告的三值数据为：在 RTX 5090 上解码速度为 142.5 tok/s，在 Apple M5 Max 上为 46.8 tok/s；第三方关于 IQ2 构建的报告则较少，其中在双 Radeon 显卡上的 Vulkan 测量结果约为 3.8 tok/s 生成速度，不过这个数字更多反映的是那个特定后端，而不是量化本身。双方的吞吐量数据都应视为与硬件高度相关。

OrcaRouter 适合用在何处，又不适合用在何处

这两个文件都不是路由器会提供的东西。它们是本地产物，而诚实的说法是，OrcaRouter 并不托管其中任何一个——这是一个关于在你自己的硬件上运行什么的比较。真正在我们这边的是它们二者所源自的模型。Qwen3.8-27B 全精度版本 可通过 OrcaRouter 自有基础设施获取，价格为每百万输入 token 0.33 美元、每百万输出 token 2.40 美元，并完好保留该模型原生的 262K 上下文及其低/中/高推理强度控制。

这就构成了一个混合部署方案，值得具体说明。对于压缩构建擅长的任务，就在本地运行它；偶尔需要完整精度的请求，则通过同一个密钥路由到托管的基础模型——无需第二份供应商合同，也无需改动代码，因为双方使用相同的 API。如果本地构建对某个工作负载来说并不合适，那么失败的请求可以 自动故障转移，而不是作为错误返回，这比在生产环境中才发现某个量化方案不合适要更便宜。

简短版本

• 就公开的每字节质量而言，三值构建明显胜出，而且这一优势集中在推理与代码这两类任务上——而这正是训练后构建退化最严重的类别。

• 在可移植性方面，IQ2_XXS 构建同样明显胜出。到处都能使用原版运行时，无需分叉，无需特殊内核，也没有静默生成垃圾结果的故障模式。

• 这一对比并不是"1.76 比特对 2.2 比特"，而是"训练过程中选定的表示 对 事后拟合出来的表示"——与后者相比，0.44 比特的差距不过是个舍入误差。

• 本文中三元构建的每一项质量数据，都是 Prism ML 在其自行选择的测试套件上进行的自家测量。IQ2 构建的 KLD 结果是独立的、单次运行的，并且只针对一个基础模型和一个测试集；它们是本次比较中最有力的第三方证据，但它们完全说明不了 Bonsai 的情况。

这个差距也会从另一个方向缩小，而且很可能很快就会。如果三值内核进入 llama.cpp 上游，那么对 Bonsai 的那个严肃反对意见就会消失，选择也会变得简单明了。在那之前，IQ2_XXS 构建版本仍保有一个真正的优势，而这与它本身有多好毫无关系。

如果你这周就要做决定，那么能一锤定音的测试只需花一个下午：从你自己工作负载中挑出二十个需要不止一步推理的提示词，把两个构建版本都跑一遍，然后盲评答案。已发布的表格会告诉你该往哪里看，却无法告诉你你的工作是否就在那里。