98.2% 分数背后是“缩水“还是“进化“？量化守恒定律：端侧 27B 能打不等于能扛

98.2% 分数背后是缩水还是进化量化守恒定律端侧 27B 能打不等于能扛【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit2026 年 9 月中旬PrismML 发布 Bonsai 2 27B基于 Qwen3.8 27B 三值量化ternary权重仅取 −1/0/1的端侧模型宣称以不足 1/9 的内存占用拿到基础模型 98.2% 的基准分数。消息瞬间点燃社区——上一代 Bonsai 27B 刚被 AnythingLLM 创始人称为AI 的 DeepSeek 时刻这一代又把这个口号往前推了一步。但与此同时另一拨声音同样响亮有博主把模型扒下来实测后结果有点懵声称小任务封神大任务翻车。98.2% 到底是真的还是又一个被基准游戏包装出来的营销数字本文不站队只拆两件事这个分数是怎么测出来的、它掩盖了什么以及为什么同一个模型官方分数与民间实测会出现如此大的观感撕裂。答案藏在一个朴素的事实里——量化是守恒的你可以把 27B 塞进手机但代价不会凭空消失只会从一类能力转移到另一类能力。能打是基准成绩能扛是设备与负载条件下的真实表现二者从来不是一回事。一、98.2% 的测量口径真实数字但有三个前提先看官方口径本身。仓库 README.md 给出了完整的测量协议14 个 benchmark、六个能力类别全部在 NVIDIA H100 上用 EvalScope vLLM 跑同一套基础设施、同一解码与评分流程且全部开启thinking mode思考模式——因为子 4-bit 区间内常规方法的崩溃在完整推理链路被激活时才最明显。变体真实每权重比特占用思考模式均分相对 FP16Qwen3.8-27B FP1616.0~54 GB86.32100%Qwen3.8-27B UD-Q4_K_XL4-bit5.217.6 GB85.1898.7%Qwen3.8-27B IQ2_XXS2-bit2.89.4 GB72.5984.1%Bonsai 2 27B1.725.9 GB84.7898.2%84.78 ÷ 86.32 ≈ 0.982数字本身经得起验算。真正值得玩味的是三个前提前提一98.2% 是选科后的总分。按类别拆开看README.md 的 By Skill Category 表分数损失并非均匀分布数学97.06 → 96.57−0.49编程89.07 → 89.420.35持平指令遵循81.25 → 82.661.41反超智能体/工具调用BFCL v376.74 → 74.92−1.82知识推理85.55 → 79.86−5.69视觉71.36 → 66.19−5.17也就是说Bonsai 2 把预算几乎全部花在了保推理主干上数学、代码、指令遵循纹丝不动甚至小胜而知识类与视觉类任务吸收了绝大部分损失。总分 98.2% 这个数字本身没有说谎但它是一个加权平均后的幸存者偏差——如果读者关心的是视觉问答或多跳知识推理真实折扣是 93% 乃至更低。前提二98.2% 是在数据中心 GPU 上测的不在手机上。官方基准跑在 H100 vLLMbatch 1、thinking mode、逐 benchmark 独立评分。这与端侧用户的真实运行环境Apple Silicon 笔记本、旗舰手机、单张消费级显卡之间隔着整个部署工程。前提三1.72 bits/weight才是这个模型的真实身份证。README 特意点出行业里一个心照不宣的套路一个广泛使用的 Qwen3.8-27B 2-bit 构建真实是 2.8 bits/weight、占 9.4 GB。标签是2-bit实际货不对板。Bonsai 2 的三值表示承载 log₂3 ≈ 1.585 bits 信息加上每 128 个权重共享一个 FP16 缩放因子全模型真实 1.72 bits/weight——这个模型的名字配得上它的位宽。这也是它敢与 IQ2_XXS 正面 PK 的底气在比后者小 1/3 的体积上总分高出 12 分以上。而 MLX 容器版本因为每 128 权重要同时存 scale 和 bias 两个 FP16实际存储成本是 2.25 bits/weight语言模型部分 7.67 GB加上 0.92 GB 未量化的视觉塔共 8.60 GB。注意runtime/codec.py中transcode()的实现MLX 的 2-bit 码 {0,1,2} 通过scales, bias-s精确还原三值水平 {−s, 0, s}bias 不携带任何新信息只是容器格式的开销。换句话说8.60 GB 里有一部分是格式税不是模型本身变重了。官方在 runtime/codec.py 里用与 GGUF 版本逐位比对 group scale 的方式验证了这种无损转码。二、博主实测结果有点懵懵在哪社区情报里有两条非常典型的一手体验《手机能跑 27B 大模型我把 PrismML 的 Bonsai 27B 扒下来测了一遍结果有点懵》以及续篇《再聊 Bonsai 26GB 本地免费 AI 实测小任务封神大任务翻车》。标题本身已经给出了结论闲聊、翻译、摘要这类小任务体验极好一旦上长文档、多轮工具调用、大段代码等大任务就露怯。这不是博主测量能力的问题也不是官方造假而是三个被忽略的工程事实在叠加事实一采样参数不对分数直接失真。官方基准使用的采样参数是temperature1.0, top_p0.95, top_k20thinking mode。这些参数写在 generation_config.json 里但 mlx-lm / mlx-vlm 并不读取该文件——quickstart.py的 docstring 明确警告不显式传采样器生成就是贪婪解码。仓库的 quickstart.py 因此专门把 sampler 参数从配置文件里提出来显式传给推理接口。端侧用户如果图省事用默认贪婪解码或者随手调低 temperature拿到的根本不是 benchmark 里的那个模型行为。同一个权重两种采样配置体验差一个世代。事实二吞吐量是内存带宽墙不是算力墙。README 的吞吐表说得非常直白tg128生成阶段是内存带宽受限的交互式阶段pp512提示处理才是计算受限阶段。Bonsai 2 在 M5 Pro 笔记本上生成速度 28.1 tok/sM5 Max 上约 47 tok/sM4 Pro 上仅 18 tok/s、prefill 约 125 tok/s——大任务翻车很大一部分原因在这里长上下文提示的 prefill 时间肉眼可见多轮 agent 循环一次调用几秒到十几秒体感上就是卡住/变笨。媒体与官方口径的数字差异IT 之家报道 RTX 5090 上 143 TPS官方表格给出 PQ2_0 打包 129.9 TG128同样源于测量协议不同——同一模型测法不同数字就不同。事实三智能体/工具调用是明确的软肋。官方数据 BFCL v3 从 76.74 掉到 74.92社区测试同样报告Tool Calling 存在数个百分点下降影响 Agentic 场景可靠性。对大任务的定义恰恰是长程 agentic 工作流——这是 Bonsai 2 官方主打的卖点README 的 Use Cases 第一条就是Laptop-local 27B agents却也是它相对最弱的环节。能打benchmark 高分与能扛真实 agent 循环不掉链子在这里第一次出现了肉眼可见的分离。三、量化守恒定律信息不灭只是搬家把两个版本的体验差异放回同一张表结论其实是确定的Bonsai 2 的损失是结构性的而不是随机劣化。对照常规量化的表现更能说明问题——README 的逐 benchmark 表里IQ2_XXS 在 AIME26 上跌到 57.5、LiveCodeBench 上 56.4却在 MMLU-Redux 上仍保持 88.93。常规低比特量化崩的是需要长链推理的任务而这类任务在随手测试里根本测不出来——这就是休闲测试发现不了崩溃的原因。Bonsai 2 在这两项上分别拿到 95.83 与 90.07恰恰是它宣称thinking 保留最硬的证据。上一代 Bonsai 27B 在 Gemma-4-31B 家族上也复现了同样的模式说明这是方法属性不是单模型运气。PrismML 为此引入了一个非常值得借鉴的度量——智能密度Intelligence DensityD -log2(1 - score/100) / size_GB变体体积 (GB)基准均分智能密度 (1/GB)Bonsai 2 27B5.8084.780.469Ternary Bonsai 27B上一代5.7580.980.416Qwen3.8-27B IQ2_XXS9.472.590.199Qwen3.8-27B UD-Q4_K_XL17.685.180.157Qwen3.8-27B FP165486.320.053Bonsai 2 的密度是最密的常规构建IQ2_XXS的 2.3 倍、FP16 的近 9 倍。这里藏着真正的量化守恒定律能力score与体积size之间不存在免费的午餐但存在可交易的汇率——同一个模型可以决定把 1GB 的预算兑换成推理链完整性还是知识覆盖面。Bonsai 2 的选择非常明确保推理主干让知识与视觉去扛。而 config.json 里还有一个被多数报道忽略的细节视觉塔以未量化的 FP16 原样打包0.92 GB。也就是说官方在最容易坍缩的多模态路径上悄悄留了一扇高精度逃生门——这是对 98.2% 里那部分视觉损失最诚实的注解他们知道视觉扛不动 1.72-bit所以干脆不量化它。四、消费者该信分数还是信体验两者都要但各信各的结论不是分数骗人或体验翻车而是这两个问题问的是不同的东西。该信分数当你在比较量化方法论时。如果问题是你该选 Bonsai 2 的三值方案还是某个常规 IQ2_XXS/Q4 构建那么基准分数是唯一客观的裁判——它能把长链推理坍缩这种休闲测试永远测不出来的系统性缺陷用 AIME26 的 57.5 vs 95.83 一次性摊开。这一层分数比体验可靠得多。该信体验当你在决定这台设备能不能扛我的负载时。官方在 README.md 的 Limitations 里主动承认了质量-体积的权衡也承认 PTQ1_0 密集打包在 Ampere/Hopper/Blackwell 上因解包算术反而更慢——没有一种打包在所有硬件上通吃PQ2_0 在指令吞吐受限的高端卡上更快PTQ1_0 在 Ada 级与低功耗 L4 上更优。选购时必须先回答你的瓶颈是内存带宽、显存容量还是指令吞吐给端侧用户的可执行建议直接照仓库的工程事实来Apple Silicon 上跑 MLX 包必须用仓库自带的 runtime 加载器。config.json声明model_type: prism_hadamard_qwen35普通 MLX 加载器会跳过激活侧的 Hadamard 变换与逆嵌入查找返回错误结果而不是报错。runtime/artifact.py中的Packed模块、runtime/runtime.py 里的fwht()归一化 Sylvester-Walsh-Hadamard 变换与 hadamard.json 中 1024 块的符号向量构成完整的配套契约reload-validation.json 记录了 402 个打包模块重载后 logits 逐位一致。换加载器 换模型。显式传采样参数默认贪婪解码会显著低估这个模型。对号入座选打包CUDA 上按显卡代数选 PQ2_0/PTQ1_0别盲从单一速度数字。管理预期多模态与长程 agent 是它相对最弱的场景视觉塔没量化本身就是信号单次补全、长文总结、本地编程辅助才是它封神的区间。回到标题的问题98.2% 是缩水还是进化它两者都是取决于你拿它跟谁比、在哪测、测什么。与真实的 1.72-bit 身份相比它证明了端到端训练 Hadamard 旋转 无高精度逃生通道这条路线可以把手持设备的智能密度推上一个数量级——这是进化与全能力无损的隐含期待相比知识与视觉类任务 93% 级的保留率、agentic 场景数个百分点的下滑、以及 28 tok/s 级别的交互手感——这是缩水。量化守恒定律没有例外没有任何压缩能同时保体积、保速度、保全科能力。Bonsai 2 只是把天平明确地压在了推理主干这一侧。对于把 27B 塞进口袋这一目标而言这或许正是它应该压的那一侧。【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考