Ternary Bonsai 2 27B：5.9 GB 里能装下什么，以及 98.2% 没有告诉你的事

Ternary Bonsai 2 27B 是 Prism ML 于 2026 年 9 月 17 日发布的一个拥有 273.6 亿参数的多模态语言模型，而关于它需要理解的一点是：它的语言权重只会取恰好三个值中的一个。它的基础模型是 Qwen3.8 27B——一个 27B 的混合注意力模型——Bonsai 保留了该架构、该训练方式和该形态，并将语言模型的矩阵权重替换为三值表示。交付的文件为 5.93 GB。全精度参考版本为 53.81 GB。厂商的主要宣称是，它保留了原模型基准平均成绩的 98.2%。

先从大多数报道会一带而过的部分说起：那个 98.2% 是 Prism ML 自己的数字，测于 Prism ML 自己的 20 项基准测试套件，用的是 Prism ML 自己的测试框架，公司之外没有任何人复现过。这不是指控——发布后仅一天，这本就是常态，也正是你该赋予它的定位。今天你能独立验证的是文件：Hugging Face API 列出 Ternary-Bonsai-2-27B-PTQ1_0.gguf为 5.947 GB，而 FP16 参考版本为 53.808 GB，即缩小了 9.05 倍，与厂商所称的“约 9 倍”相符，且无需信任任何人。体积是事实。质量保留率是厂商的测量结果。有意思的内容在两者之间——分类明细，它精确地显示出压缩在何处是免费的，在何处不是。

本次发布还有另一面。9月18日，也就是公告发布后的第二天，OrcaRouter 发布了同一模型的一个运行时消融变体——OrcaRouter Ternary Bonsai 2 27B Uncensored——它在推理时移除一个学习到的拒绝方向，同时让权重保持逐位完全相同。下文将用独立章节介绍它，因为这项技术才是有趣之处，也因为它自身的限制与其结果一样具有启发性。

它是一个压缩的 Qwen3.8 27B，而不是新训练的模型

这一区别，正是解释这次发布与复述一份新闻稿之间的差别。Prism ML 并没有从零训练一个 27B 模型，也没有采用新的预训练方案。它所做的是拿过 Qwen3.8 27B，改变其权重存储与计算所采用的数值表示方式。

架构保持不变，仍是基座模型的那一套：一种混合注意力设计，大约 75% 是线性注意力、25% 是完整注意力，并配有 SwiGLU MLP 模块、RoPE 和 RMSNorm。这一混合主干也正是 262K token 上下文被称为“具备完整上下文能力”而非仅仅“支持”的原因——以线性注意力为主，才能让长上下文在设备上仍可负担。该模型是一个视觉语言模型：它既能接受文本，也能接受图像，而视觉塔是原版、未量化的 Qwen 塔，独立打包。

Prism ML 贡献的有两点。第一是三值表示本身，加上使其得以存活的量化感知训练。第二是内核——针对 Apple Silicon 和 CUDA 上那个混合注意力栈的自定义低位宽内核，它们直接对打包权重进行操作，而不是将其解包为 FP16 再相乘。没有第二项贡献，第一项就只是一种无法高速使用的存储格式。

Prism ML 自己的白皮书给出的参数分布为：语言主干部分为 24.35B，分布在 64 个块中；嵌入与 LM head 部分为 2.54B；27 块的视觉塔部分为 0.47B，总计 27.36B。视觉塔是唯一真正独立的构件：GGUF 发行版将其打包为一个约 0.63 GB 的 4 位 mmproj 文件，仅在图像实际到来时才会加载，因此纯文本服务永远不会携带它。

这是来自同一实验室的第二代 Bonsai；第一代 Bonsai 27B 于 2026 年 7 月问世，大约早了两个月，两代之间的对比是一个合理的问题——我们会在与 Bonsai 27B 的正面对比中讨论，而不是在这里重复。

“ternary g128”具体是什么意思？

如果你以前没有接触过三值权重，那么这一段会让其余所有内容变得清晰可读，因此这里不采用简写。

神经网络中的普通权重是一个 16 位浮点数——在可用范围内约有 65,536 个可区分值，每个值存储起来都要占用 16 位。三值权重并不是一个小浮点数。它是在三种符号中做出的选择：−1、0 或 +1。这就是它的全部词汇表。如果朴素地存储一个这样的符号，每个权重就要占用两位，因为两位能表示四种状态，而你只需要三种。

仅凭其自身，那会造成表达能力的灾难性损失，这也是为什么该格式从来不只是这个符号。每 128 个连续权重为一组，共享一个 FP16 缩放因子，而实际的权重值就是该三值符号乘以这个缩放因子：

• w = ssub>g/sub> · t，其中 t ∈ {−1, 0, +1}，且 ssub>g/sub> 是这 128 个元素组成的组共用的一个 FP16 缩放因子

所以，模型仍然能表示很大范围的量级——只不过它是以粗粒度的、按组划分的步长来表示，而不是逐个权重的步长。这个 0 并不是舍入产生的假象；它是一个真实的第三状态，正是有了它，一组 128 个权重才能在需要时大部分保持静默。

旋转基正是让人意外的那部分。在三元赋值发生之前，每个权重矩阵都会按块经过一次正交旋转的变换——即一个 Walsh–Hadamard 矩阵与一条固定的 ±1 符号对角向量相结合，块大小为 1024——而三元值正是在这个旋转后的空间中选取的。旋转会在准备阶段被折叠进所存储的权重中，因此既不占用额外的比特，也不产生额外的权重流量。在推理时，运行时则改为对激活值应用相应的变换，而打包后的模型会在其元数据中声明自身的旋转，因此运行时要么应用相应的变换，要么拒绝加载该文件。

何必费这个劲？因为 Hadamard 旋转会把权重矩阵的能量更均匀地分散到各个坐标上，这使得随后的三级量化对模型造成的损害远小于直接作用于原始、尖峰状分布时的情况。这种旋转不是装饰；它正是三值模型还能保留接近父模型质量的原因。代价是，在批大小为 1 时，该变换位于每次投影的关键路径上，这是一个实实在在的工程问题——Prism ML 在 Metal 上把符号翻转融合进变换的加载路径，并在 CUDA 上将其跨整个线程块并行化，以免它主导解码过程。

这些数字，请仔细看：1.585、1.71、1.72、1.76

围绕这次发布流传着四个位宽数字，它们都是正确的，而且衡量的是四件不同的事。把它们混为一谈，是这件事上最容易犯的错误。下面逐一说明每个数字以及它实际涵盖的内容。

• 每个权重 1.585 比特——一个三进制符号的信息量，即 log₂3。这是格式本身的属性，而非任何文件的属性。实际发布的任何内容都不是以 1.585 比特/权重运行的。

• 每个权重 1.71 比特 ——仅三值张量。再加上按 128 个权重摊销的 16 位 FP16 组缩放，就得到 log₂3 + 16/128 ≈ 1.71。这仍不是实际发布的数字；它只是孤立来看的三值张量。

• 每个权重 1.72 比特 —— 语言模型中的每一个参数，包括少量以高于低位表示形式保存的参数。Prism ML 将 26,238,464 个参数——占语言模型的 0.0976%，在 bf16 下约 52 MB——保持在更高精度下，主要是线性注意力层的循环状态路径以及归一化权重。这些张量既不旋转也不量化，正是它们将这一数字从 1.71 提升到 1.72。在 1.72 下，理想化的占用空间为 5.80 GB，减少约 9.3 倍。这是 Prism ML 的“True Ternary”行，它是一个目标，而不是你可以下载的文件。

• 每权重 1.76 比特——实际发布的 GGUF。高效内核需要一种打包格式，而 Prism ML 的 PTQ1_0 将三进制位密集打包，最终达到每权重 1.76 比特、5.93 GB，约 9.1 倍。这个文件正是公告所引用的“5.9 GB”和“小 9 倍”背后的那一个，也是上述测量所证实的那一个。

第二种打包方式是PQ2_0，它将每个三进制位存储在 2 位槽中，而不是密集存储。它以更多空间为代价换取更便宜的解包：2.16 位/权重，占用 7.25 GB，约为 7.4 倍。没有哪种打包方式能在所有情况下都更快——PTQ1_0 每步移动的权重数据大约少 18%，但需要付出算术代价来解包密集的三进制位，因此它在内存是关键瓶颈的 Ada 代显卡和 L4 上胜出，而在批大小为 1 的解码反而受指令吞吐量限制的 Hopper、Blackwell 和 Apple silicon 上落败。提示词处理在所有情况下都更有利于 PQ2_0，因为它是计算受限的。

给任何拿这些数据与来源核对的人两条事务性说明。首先，Prism ML 自己的文档在舍入上略有不同——白皮书的存储表给出 PTQ1_0 为 1.76 比特/权重，对应 5.93 GB，而 Hugging Face 上的 GGUF 模型卡给出的是 1.75 和 5.95 GB，实际测得的文件为 5.947 GB。这些是同一文件以不同精度进行的描述，并非实质内容上的分歧。其次，所公布的“超过 9 倍”的缩减幅度是厂商自己给出的；按实际文件衡量，它是 53.808 / 5.947 = 9.05 倍，二者相符。

基准测试图景：不是平均值，而是分布形态

最显眼的数字是平均 83.9，而 Qwen3.8 27B FP16 基线为 85.4，相当于 98.2%。平均值是其中最无趣的部分。底下那层形态才是真正信息所在，而它并不均匀。

• 指令遵循 — 82.66 对 81.25。这是压缩模型唯一胜过其全精度父模型的类别。这不是随便就能解释掉的噪声；这是在厂商自家测试套件上取得的一个类别胜利。

• 数学 —— 96.57 对 97.06，编程 —— 81.58 对 82.17。两者基本持平：在类别平均分上分别只差半分和零点六分。对于一个占用规模仅为其九分之一的模型而言，整套技术能否成立，正是要靠这些结果来论证。

• 知识与推理 —— 83.95 对 86.66。下降了 2.7 个百分点，而总分平均值中所缺的 1.8 个百分点里，有相当一部分正源于此。

• 视觉 — 78.59 对 81.64。下降了 3.05 分，是单一类别中最大的跌幅。值得注意的是，视觉塔本身并不是被压缩的部分；读取其输出结果的语言模型才是。

• 智能体与工具调用 — 77.57 对 79.74。该类别平均值涵盖 τ 2-Bench 的 80.22 与 BFCL v3 的 74.92。

一些单独的结果值得了解，因为它们并非都指向同一方向。在 Terminal-Bench 2.1 上，该模型得分为 52.8，而全精度为 69.7——约为四分之三——在 SWE-bench Verified 上，其得分为 60.8，而全精度为 80.6，同样是大约四分之三。这是该模型系列首次在 Terminal-Bench 上接受评估，并且 Prism ML 明确表示，它在首个 Bonsai 版本中承诺的长周期软件工程能力提升只是部分实现，而非完全实现。与此相对：τ 2-Bench 从上一版本的 73.6 升至 80.2，BFCL v3 保持在 74.9，AA-LCR 则为 77.0，与全精度相差不到 1 分。AIME26 达到 95.83，LiveCodeBench 达到 90.07。

哪些地方可信，哪些地方不可信。在数学、编程和指令遵循方面，可以相信其整体格局——在这些类别中，该技术确实做到了它所声称的事，而且它们是在与基线相同的一套测试框架上测得的。但对于长周期的智能体任务要谨慎：真正考验持续、工具驱动的工程能力的两项基准测试——Terminal-Bench 2.1 和 SWE-bench Verified——所显示的差距明显大于总体数字所暗示的程度，而且厂商自己也如实说明了这一点，并未加以隐瞒。此外，在其他人复现之前，请把整张表视为某一个实验室在某一个测试框架上得出的测量结果。这一警示在这里并非走过场——它正是“该模型保持了 98.2%”与“该模型的厂商在厂商自己选定的测试套件上测得 98.2%”之间的区别。两者都是真的；但只有一个是关于该模型本身的事实。

为什么这优于同一基础模型的 IQ2_XXS 构建

这值得单独设一节，而不是只用一行带过，因为它是证明量化感知三值训练优于训练后量化的全部论据。

让 Qwen3.8 27B 变小的常规做法是在训练后对其进行量化。白皮书的对比对象是同一基础模型的 IQ2_XXS GGUF 构建版本：

• Ternary Bonsai 2 27B — 1.76 比特/权重，5.93 GB，20 项基准测试平均分 83.9

• Qwen3.8 27B IQ2_XXS — 2.2 比特/权重，7.3 GB，20 项基准平均 75.2

经训练压缩的模型既更小，又更好。它比传统低位构建小 1.23 倍，得分却高出 8.7 分。这种组合并非舍入误差造成的偶然；它所要说明的是：在训练期间选定的表示方式，其价值远超事后施加同等名义比特预算所能达到的效果。

更有启发性的部分是如何常规构建会失败，因为这种失效是有选择性的，而且很容易被忽略。IQ2_XXS 的退化并不均匀。它在表层知识上依然撑得住——MMLU-Redux 上为 85.79——但在需要持续推理链的任务上却会崩塌：AIME26 上为 78.6，LiveCodeBench 上为 70.05，GPQA Diamond 上为 65.45。Bonsai 2 在同样这三项上的得分分别为 95.83、90.07 和 85.76。随便聊几句的测试会觉得 IQ2_XXS 构建完全够用，永远不会暴露出这种崩塌；而损伤恰恰存在于长链推理和代码生成发生的地方。正是这种不对称性说明，“我试的时候感觉挺好的”并不能作为关于量化模型的证据。

Prism ML 把同一论证浓缩为一个它称之为"智能密度"的单一衍生数字——大致就是每吉字节的基准测试能力。在包含 20 项基准测试的套件上，它报告 Bonsai 2 为每 GB 0.444，IQ2_XXS 构建为 0.276，FP16 为 0.051。该指标是厂商自行构造的，其权重设定是一种设计选择，而非定律；但它所产生的排序与原始表格给出的排序相同，因此它增添的是解释，而非证据。

关于这项对比，再坦诚地补充一点。Prism ML 的 GGUF 模型卡还报告了第二项范围更窄的评估——一个包含 14 项基准的思考模式套件——其中相同的保持率数字再次出现，为 84.78 对 86.32，而 IQ2_XXS 为 72.59。两个不同的套件都得到相同的 98.2%，这在一定程度上佐证了总体结论并非某一基准选择造成的假象。但两项测试仍由同一实验室在同一测试框架上运行。我们对这场对比更完整的拆解，包括打包格式问题，见与 Qwen3.8 27B GGUF 构建版本的对比。

运营它实际需要什么

吞吐量数据来自白皮书中标准化的 tg128 测量，批次大小为 1，且不包含视觉塔：

• Apple M5 Max — 解码 46.8 tok/s，提示处理 765 tok/s

• Apple M5 Pro — 解码 27.7 tok/s；PQ2_0 包的另一次更长窗口运行测得持续 27.0 tok/s，GPU 供电轨功耗为 27.0 W，CPU 和 GPU 合计为 32.8 W

• Apple M4 Pro — 解码速度为 18.0 tok/s，而提示处理速度约为 125 tok/s，在处理超长上下文时正成为约束瓶颈

• NVIDIA RTX 5090 — 在 PQ2_0 包上解码速度为 142.5 tok/s，每 token 能耗为 0.582 mWh

Prism ML 提出的实际主张并非加速比，而是某种缺失：53.8 GB 的 FP16 基线根本无法装入 16 GB 笔记本电脑，因此有意义的说法是，一个 27B 级别的模型如今能在日常硬件上交互式运行。在 M5 Pro 上，实测解码以约 201 GB/s 的速度流式读取权重，证实了低比特表示旨在利用的内存带宽主导型特征。

然后是边缘情况，它们比峰值数字更重要。

你不能使用原版 llama.cpp。三元混合注意力内核位于 Prism ML 自己的 llama.cpp 分支中。原版 llama.cpp 会将 PTQ1_0 和 PQ2_0 类型视为未知类型而拒绝，而且——更危险的是——它会毫无警告地加载较旧的 Q2_0 三元格式并产生垃圾输出，因为它没有 Hadamard 激活运行时。如果你在不应用匹配旋转的二进制文件上运行此模型，你不会遇到报错；你得到的将是看似流畅的胡言乱语。这是在这个版本上白白浪费一下午时间的最可能方式。

MLX 包没有 CUDA 路径。MLX 版本（prism-ml/Ternary-Bonsai-2-27B-mlx-2bit）面向 Apple Silicon，在该平台上，它为 Python 和 Swift 两种运行时中的混合栈提供了自定义内核。其量化矩阵乘法有 Metal 和 CPU 内核，但没有 CUDA 实现，因此在 NVIDIA 机器上，这个特定包完全无法获得 GPU 加速。CPU 推理可以运行，但在 CPU 上执行一次 27B 前向传播可能耗时数分钟——这使得 Linux CPU 路径对于实现测试和可复现性有用，而对于提供服务则毫无用处。

这两个包是真正的取舍，而非排名优劣。 如果你使用的是 Ada 架构显卡或 L4，又或者显存是硬性瓶颈，那么 PTQ1_0 是首选，占用 5.93 GB。如果你使用的是 Hopper、Blackwell 或 5090，PQ2_0 能以多出 1.3 GB 的代价换来解码速度。如果你使用的是 Apple 芯片，请注意上文中的 M5 Pro 数据是在 PQ2_0 上测得的，而演示环境默认下载的也正是这个包。

关于 MLX 打包格式自身占用计算的一点说明，因为这是一个常见的困惑来源。MLX 容器是一种仿射 2 位格式，其每个块都会为每 128 个权重存储一个 FP16 scale 和一个 FP16 bias。Bonsai 的三元权重只需要 scale —— 量化级别完全由 scale 得出 —— 因此 bias 纯属无用负担，于是每个块为 128 个权重付出的是 36 字节，而非 34 字节。这使 MLX 打包格式的打包速率升至 2.250 比特/权重，既不是 1.72，也不是 1.76。它是承载相同三元值的另一种容器，其在 Hugging Face 上实测的文件大小为 8.005 GiB。

运行时消融变体

9月18日，OrcaRouter 发布了 OrcaRouter Ternary Bonsai 2 27B Uncensored，该模型完全在运行时对其实施拒绝方向消融。其工程思路比产品本身更值得关注，因此先讲思路。

传统的 abliteration 会修改权重。它在激活空间中找到一个对应拒绝行为的方向，然后将写入残差流的权重矩阵对该方向做正交化：W ← W − r(rᵀW)。在普通的 FP16 模型上这没问题——被编辑后的矩阵仍是稠密的浮点矩阵，所以存下来继续用就行。但在三值打包上，这条路走不通，而且它之所以走不通，恰恰是因为这个模型存在的那个理由。正交化一个三值矩阵会得到一个稠密的全精度矩阵。要把它存回三值打包，就必须重新量化——而对编辑后的权重重新量化，并不能复现出生成原始权重的量化感知训练。你丢掉的正是当初花代价换来的东西。

所以，投影改为在推理时进行。与其改变 W，不如改变其输出：

• y ← y − α · dot(y, r) · r，以 float32 计算，其中 y 是残差贡献，r 是归一化拒绝方向

当 α = 1 时，每个残差写入中与拒绝方向平行的分量会被移除。当 α = 0 时，模型保持原样。α 大于 1 时会过度投影，并可能降低质量。由于 α 是运行时参数而非检查点属性，同一个包可以在同一进程中对自身进行 A/B 测试——这正是 OrcaRouter 的评估所做的。原始 Bonsai 包保持比特级完全相同：未修改任何权重、无重新量化、无额外权重量化误差。

有两个实现细节，是这种做法的朴素版本会失败的地方。

129 个干预站点，而不是 16 个。每个能够写入残差流的模块都必须被包装，而在这个混合架构中，这包括 64 个 mlp.down_proj 块、48 个 linear_attn.out_proj 层、16 个 self_attn.o_proj 层以及 model.embed_tokens——总共有 129 个。只包装 self_attn.o_proj 是显而易见的错误，它只能捕获其中 16 个，使其余 113 次写入未被投影。一个自检脚本会测量沿拒绝方向的剩余分量是否被压低到残差范数的大约 1e-6，并在未检测到全部 129 个站点时发出警告。

不要重新旋转该方向。三值包将其投影以旋转基的形式保留在其输入维度上，并在激活侧进行补偿。拒绝投影作用于这些投影的输出，这些输出已经回到正常的隐藏基——因此，拒绝方向是一个普通的 5120 维向量，对其施加额外的 Hadamard 旋转将完全针对错误的基进行投影。

OrcaRouter 测量了什么——我们自己的数据，而非独立数据

这些是 OrcaRouter 自己的基于规则的测量结果，并且应当如此解读：一个基于规则的开头短语分类器，而不是 LLM 评判器，思考模式关闭，贪婪解码，64-token 预算，其中 base 和 ablated 是同一进程中的相同权重，以 α = 0 对比 α = 1。它们只是指示性的，未达到可发表水平，也并非对 Prism ML 所声称的任何内容的验证。

关于拒绝，以收到拒绝的提示词占比来衡量：

• AdvBench（n=100）——99.0% 基线，6.0% 消融，其中 56.0% 已作答，但裹在免责声明中

• JailbreakBench（n=100）——基础版 96.0%，消融版 4.0%，附条件版 52.0%

• StrongREJECT（n=150）——99.3% 基础，3.3% 消融，45.3% 附加说明

• HarmBench（n=150）—— 基准 98.7%，消融 7.3%，带限定说明 48.0%

• MaliciousInstruct（n=100）— 97.0% 基础，0.0% 消融，52.0% 附带说明

• ForbiddenQuestions（n=150）——基线 75.3%，消融 5.3%，带限定说明 42.7%

• SimpleSafetyTests（n=50）——基础 96.0%，消融 18.0%，带附加说明 60.0%——而且这个数字还被低估了。该集合主要是自残类提示词，而模型会用危机转介来回答，开头是“听到这些我深感抱歉……”，分类器的精确短语列表没有命中它，于是将其评为合规。该集合上真实的残余拒绝率高于 18.0%。分类器被有意保持原样，以便这些数字与 OrcaRouter 的其他模型卡保持可比。

任何集合中的回复都没有用完其token预算，因此这些比率均未因截断而虚高。在良性提示上，同样的投影也消除了过度拒绝：XSTest-safe的拒绝率从5.2%降至0.4%，JailbreakBench的良性子集则从25.0%降至0.0%。已发布的包会拒绝该基准测试中四分之一的良性提示；而经消融后，它一个也不拒绝。

在能力方面，权重比特完全一致意味着无需付出重新量化的代价，而测量结果也与此相符：

• MMLU（n=300）— 76.7% 基线，77.7% 消融，+1.0

• GSM8K（n=150）— 87.3% 基线，86.0% 消融，−1.3

• CMMLU（n=500）—— 基线 76.2%，消融 75.6%，−0.6

在这些样本量下，任何变动都在噪声范围内；一道 GSM8K 题就值 0.7 分。MMLU-Pro 被排除而非报告：它的提示要求在给出答案前先进行推理，而双方有 63–64% 的回复在 token 预算内尚未得出答案，因此任何准确率数字都只是由预算设定的下限，而不是一项测量结果。

最重要的注意事项

拒绝方向是从 Bonsai pack 训练所依据的 BF16 基础模型估计得到的。架构和隐藏基完全相同，因此几何关系吻合。但该方向在量化感知训练中能保留到什么程度，尚未得到充分测量。

运行时可以从数学上并以约 1e-6 的精度证明，它从每一次残差写入中移除了所提供的方向。仅凭这一点，它无法证明该方向在量化模型中仍能捕获它在稠密模型中所捕获的同一行为特征。这些是不同的论断，而只有第一个已经确定。任何阅读上文安全表的人都应明白：该干预的有效性完全取决于方向迁移假设，而这个假设正是悬而未决的问题。

此外，OrcaRouter 对这次发布本身还给出了一种务实的定位，这一点值得复述，而不应通过转述被淡化掉：移除一个习得的拒绝方向，可能会让模型对原本会拒绝的请求作出回应。这是一种研究与推理控制机制，并不证明任何由此产生的输出是安全、正确或恰当的；使用它的部署方应实施自己的访问控制和策略执行。移除拒绝并非无代价的改进，而本文也不是以仿佛它是无代价改进的口吻写成的。

给任何想要复现它的人的另外三条实用说明。该 pack 必须用它自己捆绑的运行时来加载——普通的 MLX 加载器可能看起来加载成功，却在暗中计算错误的东西，所以如果在消融甚至还未启用之前输出就已经不对，请先检查加载路径。支持按层选择性消融，因此这种干预不必是全有或全无。而消融评估是在该 pack 展开后的 FP16 扩展版上运行的，而不是由 pack 驱动其自身的内核，因为打包后的量化 matmul 没有 CUDA 实现，而 CPU 后端每次前向传播需要数分钟；该扩展版精确承载了 pack 的三元值，并在抽查中能把 pack 自身的下一 token 分布复现到小数点后三位，但这是一次容器层面的改动，值得知晓。代码和完整表格都在 OrcaRouter Ternary Bonsai 2 27B Uncensored 仓库中。另一份单独的比较将消融后的 MLX 构建与未修改的 Qwen3.8 27B MLX 路径进行对比，更深入地探讨了运行时的具体细节。

这会走向何方，以及还有哪些尚未得到证实

一个近乎无损的 27B 模型被压缩到约 6 GB 后，对本地智能体带来的改变主要在于什么能够常驻。一个能在 16 GB 笔记本上与真实上下文窗口并存的语言模型，可以在智能体做其他工作时保持加载——读取文件、调用工具、跨轮次保持计划——而不是按请求换入或被推送到服务器。这就是“你试一下的本地模型”和“你让它一直运行的本地模型”之间的区别，也正是 τ 2-Bench 80.2 和 BFCL v3 74.9 这些智能体指标所要支撑的具体特性。

未经证实的事项比公告所暗示的要多。

• 无独立复现。本文中的每一个质量数值——83.9、98.2%、各类别平均值——都是 Prism ML 在自家测试套件上自行测得的结果。这不是该发布版本的缺陷，而只是刚满一天该有的样子。它也会是最先发生变化的一点。

• 长周期智能体工作是厂商自家表格中最弱的一环，而非最强的一环。Terminal-Bench 2.1 上 52.8 对 69.7 是实打实的差距，而且厂商自己也说这项能力只算部分具备。

• 你尚未尝试过的提示词。低比特模型的失败特征是有选择性的，而 IQ2_XXS 在 AIME26 和 LiveCodeBench 上崩溃、却在 MMLU-Redux 上保持 85.79，这是现有最清晰的证据，说明基准平均分并不能告诉你，在你的工作负载上会发生什么。Bonsai 2 在这两个基准上没有表现出那种崩溃，这令人鼓舞，但并不等同于保证。

• 上文所述的消融变体中的方向迁移问题，该问题从构造上就无法解决。

• 随着运行时不断演进，这些内核能否经受住考验。目前，这个模型需要一个分支；原版 llama.cpp 会拒绝三种格式中的两种，并悄悄弄乱第三种。在这些内核合并到上游之前，“llama.cpp 能运行的地方它就能运行”对本模型来说尚不成立。

这次发布本身并无争议。一个 27B 级别的多模态模型，体积仅 5.93 GB，只有其所压缩自的模型占用空间的九分之一，数学与编码能力与母模型持平、指令跟随还略胜一筹——这对本地推理而言是一个真正不同的运行点。在 2026 年 9 月 18 日，合理的姿态是：把文件大小当作事实，把那个保留率数字当作厂商一天前在其自行选择的测试套件上做出的谨慎声明，而在你自己把你的工作负载跑上去之前，先对自己的工作负载保留判断。

运行时消融代码、拒绝方向以及完整的评估表格均由OrcaRouter发布，与团队构建的路由平台一同公开。