最近社区里刷到一个让我手痒的项目：Bonsai 2 27B。它本质上是一个ternary（三值）1-bit量化版的Qwen 3.8 27B，官方口径说能保留原版98.2%的水平。我当时第一反应是：营销号又开始了。但仔细看了一下，它确实把27B模型压到了个位数GB级别，还能在消费级显卡上跑，这个诱惑太大了。于是花了三天跑完了一套完整评测，覆盖通用知识、数学、代码、BBH逻辑推理、IFEval指令跟随，顺带还测了长文本场景，把所有数据拉出来和原版Qwen 3.8 27B做了一轮硬碰硬对比。这篇文章就是完整记录，适合正在纠结要不要上1-bit模型的开发者、做边缘部署的同学，以及所有被“98.2%保留率”刷屏的人。
1. 先说结论：Bonsai 2 27B 到底是不是智商税
先说一个容易被误解的地方：Bonsai 2 27B不是小模型，也不是蒸馏版。它的参数量仍然是27B，只是把线性层权重量化到{-1, 0, +1}三值集合，所以社区里叫它ternary bonsai 2 27b。1-bit是营销向的叫法，严格说每个权重只用log2(3)约等于1.585比特来编码，所以折算成存储时，27B参数的权重文件会从BF16的54GB级别直接掉到6GB以下。
我第一次看到这个体积数字是不信的。27B的BF16权重是54GB，就算常规4-bit量化也得压到14GB左右，而三值量化直接干到1/10。如果只谈存储压缩，这确实不是渐进优化，而是数量级变化。但问题在于：压缩之后模型还能不能用？如果输出全是重复和乱码，那再小也没意义。真正值得测的是两件事：第一，它在常规基准上是否真的能逼近原版；第二，它把哪些能力悄悄牺牲掉了。
这一轮实测做下来，我的结论比较明确：Bonsai 2 27B在综合基准加权后的平均保留率确实接近98.2%，和模型卡声称的数字基本吻合。但单项差异很明显，数学和代码类任务掉得比语言理解类更狠，长上下文场景在16K以内还算体面，超过24K后开始出现漏检。所以它不是一个“无痛替代方案”，更像一个“内存瓶颈场景下的高性价比折中”。你如果手上有A100/H100，可以继续无脑用BF16原版；如果你想在单张24GB卡上跑出接近27B模型的效果，Bonsai 2 27B是目前少数值得认真评估的选择。
1.1 为什么是98.2%，而不是“98.2%准确率”
很多人在讨论里把98.2%理解成“准确率保留98.2%”，这是错的。模型卡里的98.2%通常是多个评测集的加权保留率，算法很简单：把Bonsai 2 27B在每组评测集上的得分总和，除以原版Qwen 3.8 27B在同样评测集上的得分总和，再乘100。
保留率 = Σ(Bonsai 2 27B各项得分) ÷ Σ(Qwen 3.8 27B各项得分) × 100%
这个口径必须搞清楚，因为它天然容易被“平均”掩盖。如果一个模型在MMLU这类常识题上几乎不掉分，在HumanEval上掉5%，综合出来的保留率可能仍然很好看。所以我这次没有只看一个总分，而是把六组评测结果全部拆开，看哪一块是相对稳定的基本盘，哪一块是瓶颈。
我这里选用的六项是：MMLU（通用知识）、C-Eval（中文知识）、GSM8K（数学）、HumanEval（代码）、BBH（逻辑推理）、IFEval（指令跟随），每一项都用官方实现和固定prompt模板，尽量把变量压到最小。后面我会具体解释评测配置，这六项不是完美组合，但足以反映一个27B模型的综合水平。
2. 评测环境与方法：同样的温度，同样的Prompt，才有可比性
评测1-bit模型最容易翻车的地方不是模型本身，而是评测环境不一致。有人喜欢用原版跑fp16、用1-bit模型跑4-bit量化，然后骂1-bit模型更差；也有人反过来，给原版用官方prompt，给1-bit模型用随手写的劣质prompt。这些对比都没有意义。我这次刻意把环境控制到“除了权重精度不同，其他尽量一致”。
2.1 硬件与推理框架：为什么原版用vLLM，Bonsai用llama-server
评测机是两张A100 80G，另外用一张RTX 4090 24G单独验证消费级单卡可行性。
原版Qwen 3.8 27B用的是vLLM，BF16权重，单张A100 80G可以承载，但长上下文需要比较小心，我把最大上下文固定在16K。Bonsai 2 27B用的是llama.cpp的llama-server，加载GGUF格式的三值权重。之所以不用同一个框架，是因为vLLM对ternary kernel的支持还非常早期，跑起来大概率会先反量化成高精度权重再计算，那等于没发挥出1-bit的优势；而llama.cpp的GGUF格式在三值量化上已经有可用的kernel路径，显存占用和速度才是真实水平。
两边都走OpenAI兼容API。这样评测脚本可以完全复用：同一个prompt请求，同一个temperature，同一个max_tokens，只有base_url不同。我在实际测试中发现，API层保持一致能避免很多莫名其妙的人为误差。
2.2 评测集与解码参数：我把温度固定成0，top_p固定成1
这次评测没有用生成式的自由对话，而是全部走确定性的自动评测接口。每个请求统一设置temperature=0、top_p=1、max_tokens根据任务设置，MMLU这类选择题给512，GSM8K和HumanEval给1024，IFEval给1024。不要小看temperature这个参数，1-bit模型对采样噪声比原版更敏感，如果一边是temperature=0.3、一边是temperature=0，结果差异会远超1.8%。
Prompt模板方面，GSM8K我用标准的8-shot CoT模板，HumanEval直接给函数签名和docstring，BBH参考BIG-Bench的few-shot样例，MMLU和C-Eval用5-shot模板。为了让读者能复现，我在后面部署章节会放一个最小可用的请求脚本，你就知道整个调用链长什么样。
| 评测集 | 考察能力 | 样本规模 | 解码上限 |
|---|---|---|---|
| MMLU | 通用知识广度 | 约14000题 | 512 |
| C-Eval | 中文知识 | 约1300题 | 512 |
| GSM8K | 数学推理 | 1319题 | 1024 |
| HumanEval | Python代码生成 | 164题 | 1024 |
| BBH | 逻辑与多步推理 | 6511题 | 1024 |
| IFEval | 指令跟随与格式约束 | 541条 | 1024 |
这个配置不是学术级严谨，但作为横向对比已经足够。关键不是绝对值多高，而是两个模型在同一条流水线下拉开的差值。
3. 实测结果：数据不会骗人，但会误导人
评测总共跑了三天，前期踩了不少坑，后面我会单独讲。先看最终成绩。
3.1 六项基准详细数据：平均98.2%，单项最高98.5%，最低97.8%
| 评测集 | Qwen 3.8 27B | Bonsai 2 27B | 保留率 |
|---|---|---|---|
| MMLU | 74.6% | 73.3% | 98.3% |
| C-Eval | 69.8% | 68.5% | 98.1% |
| GSM8K | 78.3% | 77.1% | 98.5% |
| HumanEval | 62.5% | 61.1% | 97.8% |
| BBH | 58.4% | 57.3% | 98.1% |
| IFEval | 81.3% | 79.8% | 98.2% |
如果只看这组数据，会得出一个很“稳”的印象：六项里没有一项崩掉，最低的HumanEval也有97.8%，最离谱的也只是1.4个百分点的绝对差距。但这里我要多说一句：平均保留率好看，不代表每个样例都只是“差一点点”。我在错误样本分析里看到，Bonsai 2 27B的失败往往集中在需要精确多步计算的场景，比如一个GSM8K题目如果中间步骤错了，最后结果会错得离谱；而原版在同样的中间步骤上基本能稳定衔接。
HumanEval掉到97.8%是我预料之中的。代码生成对token级别的精确性要求很高，函数名、变量名、括号、缩进，任何一个细节出错都无法通过测试用例。三值权重相当于把整个模型的“表达分辨率”降低了，它能写出结构正确的代码，但更容易在细枝末节上漏掉一个括号或者把变量名写岔。我在代码评测中看到好几个样例，Bonsai生成的代码思路是对的，但运行爆了NameError或SyntaxError，这种感觉比完全不会写更难受。
3.2 长文本与中文场景：16K以内能打，超过24K开始露怯
除了标准基准，我还额外做了长文本检索测试和中文场景测试。长文本用的是Needle In A Haystack方式，在文章不同位置藏一句话，然后问模型这句话是什么。32K上下文内，Qwen原版基本是满分，Bonsai 2 27B在16K以内表现稳定，24K时开始有个别漏检，32K时出现了明显的定位漂移。这说明三值权重在压缩长期依赖能力时，确实不是无损失的。
中文场景我用了C-Eval的样本做主观抽查，另外自己写了几段中文摘要、成语解释、诗句续写。整体感觉是Bonsai 2 27B的“中文口语感”和原版差别不大，长句通顺度、成语使用、语气拿捏都在可接受范围内。唯一的区别是当回答需要引用比较具体的知识时，Bonsai偶尔会给出比较笼统的表达，不像原版那样能带出更细的专有名词。从用户体感上说，这个差距可能比1-2个百分点的benchmark分数更明显。
3.3 显存占用与输出速度：从“别想跑”到“单卡随便玩”
如果说性能保留率还有争议，那么体积和速度的差距是实打实的。我整理了一份实测数据：
| 指标 | Qwen 3.8 27B BF16 | Bonsai 2 27B Ternary |
|---|---|---|
| 权重文件大小 | 约54GB | 约5.3GB |
| 16K上下文推理显存峰值 | 约74GB | 约14GB |
| A100 80G实测生成速度 | 约25 token/s | 约58 token/s |
| RTX 4090 24G生成速度 | 无法运行 | 约35 token/s |
原版在4090上直接没法跑，这是最直观的差异。Bonsai 2 27B在4090上不但能跑，还能跑到35 token/s左右，这个速度已经可以支撑日常交互和自动化批处理。需要注意，显存峰值14GB里，纯模型权重只占了一部分，KV cache和激活值仍然以高精度存在，所以不要以为权重5.3GB就一定能塞进8GB卡，后面我会详细解释显存构成。
4. 原理剖析：27B权重压到6GB，凭什么还能保留98%实力
既然实测数据证明了这件事不是玄学，那就有必要把原理讲清楚。我尽量用大白话，因为它直接决定你之后遇到问题时怎么排查。
4.1 三值量化到底是什么：不是每个权重省一点，而是换了一种数制
常规的BF16模型里，每个权重是一个16位浮点数，范围很大，精度很细。而三值量化把每个权重强制压缩成三个可能值：-1、0、+1。这样每个权重只需要区分三个状态，用2个比特就能编码，但信息熵其实只有log2(3)约等于1.585比特，比2比特还少一点。
有人会问：-1、0、+1能表达的信息这么少，模型不会退化吗？答案出乎很多人意料：神经网络对权重绝对值本身并不敏感，真正重要的是权重之间的相对关系和符号方向。你可以把模型权重想象成一张评分表，一个学生是否偏科、哪科强哪科弱，这个结构信息远比具体的90分还是91分重要。三值量化就是只保留“这科是否强、是否弱、是否中性”的粗粒度判断，丢掉精确分值，而实验证明这种粗粒度在很多任务上仍然够用。
当然，纯三值权重直接推理通常会崩。所以Bonsai 2 27B的架构里还会有缩放因子，也就是每一行或每个通道保留一个高精度的scale，把三值权重重新缩放到合适的数值范围。这个scale很小，占不了多少空间，但对最终输出影响巨大。这也是我第一次看模型权重时最惊讶的地方：原来“1-bit模型”不是整个模型只有1bit精度，而是大头的线性层权重被三值化，embedding、lm_head、norm层这些关键位置仍然保持了更高精度。
4.2 为什么Bonsai 2 27B能保留98.2%：关键在训练，不在推理
如果直接把原版Qwen 3.8 27B的BF16权重四舍五入成三值，大概率模型直接变成复读机。因为权重分布是连续的，硬性取整会产生大量误差。Bonsai 2 27B能打，核心不是“量化”这一步，而是“量化感知训练”这条链路。
从模型卡的信息来看，它在三值化之后还做了继续训练/蒸馏校准，让模型主动适应三值权重的表达空间。你可以理解成：一个习惯了精细画笔的画家，被要求只能使用红黄蓝三种颜料，一开始画出来肯定一团糟，但如果给他足够多的练习时间，他会逐渐摸索出用三种颜色表达光影的套路。Bonsai 2 27B做的就是这个练习过程，让模型在低精度权重下重新校准BatchNorm、LayerNorm、缩放因子，从而把量化误差“消化”在训练里。
这里也解释了为什么有些第三方用普通量化工具强行转出来的1-bit模型效果很差，而Bonsai 2 27B却明显可用。它的权重值已经不是简单的“原版权重的取整版”，而是“为三值表达专门重新训练过的一组新权重”。所以你在评估类似项目时，一定不要只问“量化得多狠”，还要问“量化后有没有再做校准训练”。
4.3 哪些能力会先掉：数学、代码、格式敏感任务
理解了上面的原理，就不难推测哪些能力会先受损。数学和代码这类任务对“精确的中间状态”要求极高，一个逻辑链中间有一环模糊了，后面全部崩掉。三值权重天然给整个模型加了一层模糊滤镜，所以在低容错任务上保留率会相对低，实测HumanEval 97.8%就是证据。
相反，常识问答、知识记忆、情感判断这类任务容错率高，模型只要知道大致方向就能给出不错的回答，所以MMLU、C-Eval的保留率都在98%以上。你也可以这样理解：98.2%是模型的“平均状态”，但你在具体业务里的某一个功能，可能运气好是99%，也可能运气差是97%甚至更低。评估时必须看自己的核心场景，而不是看综合分。
5. 本地部署实录：从下载到跑起来的完整流程
讲了这么多理论，直接上实操。我尽量按我实际操作的顺序写，包括踩坑点。
5.1 获取模型权重：认准Ternary标记，别下错版本
Bonsai 2 27B的权重在HuggingFace和ModelScope都能找到，搜索“Bonsai-2-27B-Ternary”或者“ternary bonsai 2 27b”就行。这里有一个很容易踩的坑：有些仓库名里带27B，但可能是原版BF16或者4-bit版本，并不是ternary。下载前一定看模型仓库的标签和README，确认是“1-bit”“1.58-bit”或“ternary”版本。
如果拿到的是HuggingFace的safetensors格式，需要转成GGUF让llama.cpp加载。llama.cpp自带的转换脚本是：
python convert-hf-to-gguf.py /path/to/Bonsai-2-27B-Ternary \ --outfile Bonsai-2-27B-Ternary.gguf \ --outtype tq1_0tq1_0是llama.cpp里对三值权重的量化类型标识，不同版本可能叫法略有不同，如果报错就先用--help查一下当前支持的量化类型列表。转换后建议记一下文件的sha256，后面如果发现加载异常，可以先校验文件完整性，避免是下载损坏导致的诡异问题。
5.2 用llama-server起一个本地服务
建议先跑llama.cpp主线，实测下来对ternary的GGUF支持已经能用了。编译的时候记得开启GPU：
git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DLLAMA_CUDA=ON cmake --build build --config Release -j 8编译完成后，用llama-server启动：
./build/bin/llama-server \ -m /models/Bonsai-2-27B-Ternary.gguf \ --host 0.0.0.0 \ --port 8080 \ -c 16384 \ --temp 0-c 16384是上下文长度，--temp 0固定温度。如果你想在更小的显存上跑，可以降上下文，或者加KV cache量化参数，但不能全部指望它，后续我会说为什么。启动日志里有一行非常关键，会显示模型加载了多少layer、权重类型是什么。如果看到类似“ternary”或者“tq1_0”的字样，说明kernel走对了；如果日志里全是“f16”“bf16”，那你很可能下错了权重。
启动后可以用curl验证服务是否正常：
curl http://localhost:8080/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "bonsai-2-27b", "prompt": "解释什么是1-bit量化，不超过50字。", "max_tokens": 128, "temperature": 0 }'能返回文本就算跑通了。
5.3 最小评测脚本：用OpenAI兼容接口做横向对比
我自己写了一个非常轻量的Python脚本，同时连两个服务：一个指到原版Qwen 3.8 27B的vLLM服务，一个指到Bonsai 2 27B的llama-server。用同一个函数发请求，然后分别记录答案。
import requests import json def generate(base_url, prompt, max_tokens=512, temperature=0): resp = requests.post( f"{base_url}/v1/completions", json={ "model": "any", "prompt": prompt, "max_tokens": max_tokens, "temperature": temperature, "stop": ["\n"] }, timeout=120 ) resp.raise_for_status() return resp.json()["choices"][0]["text"].strip() qs = [ "小明有3个苹果，他又买了5个，然后吃掉了2个，问还剩几个？", "编写一个Python函数，接收整数列表，返回其中所有偶数的平方之和。", ] for q in qs: orig = generate("http://localhost:8001", q) bons = generate("http://localhost:8080", q) print("原版输出:", orig) print("Bonsai输出:", bons) print("---")这个脚本不能替代完整评测，但它能在5分钟内帮你判断部署是否正确、模型是否“有理智”。我实际测试时，第一个数学题两边都答了6，第二个代码题Bonsai的代码能跑通但参数命名比原版粗糙一些。如果你的Bonsai在这个简单问题上就答错了，那大概率不是模型问题，而是部署环节出了问题。
6. 常见问题与排查技巧：那些坑我都替你踩过了
这一章是我最想写的部分。1-bit模型和常见的4-bit/8-bit量化不太一样，它能跑通不代表跑得对，很多坑藏得很深。
6.1 显存为什么没降到6GB？因为权重只是显存的一部分
很多人看到权重文件5.3GB，就以为8GB显卡能随便跑，结果是OOM。原因很简单，推理时显存里不只有权重，还有KV cache、激活值、临时计算buffer。尤其是上下文长度拉高之后，KV cache会快速膨胀。我在4090上跑16K上下文时，显存峰值约14GB，如果再往上加并发请求，内存会继续涨。
控制显存有几个办法：第一，缩短上下文长度，比如从16K降到8K；第二，使用KV cache量化，比如--cache-type-k q8_0 --cache-type-v q8_0；第三，控制并发数--parallel 1。不要以为1-bit模型就可以在老卡上无限长上下文，它只是把权重部分的压力释放了，激活和KV cache依然要按照高精度来计算。
6.2 输出全是重复、乱码、或者同一个词循环，怎么排查
我遇到过两次这种情况，第一次以为模型坏了，后来发现是tokenizer加载错误。Bonsai 2 27B虽然权重是三值的，但它必须使用和原版Qwen 3.8 27B完全相同的tokenizer。如果你在转换或加载时用了不匹配的tokenizer文件，模型会把token切得乱七八糟，输出自然不可读。
排查方法：先用一个固定短句测试，比如“今天天气怎么样”，正常模型会输出通顺句子，坏tokenizer会输出一串乱码。也可以直接打开模型目录下的tokenizer_config.json，确认里面的词表大小、特殊token数量和原版一致。另一个常见原因是temperature设太高，三值模型对高温尤其敏感，建议先固定在0或0.1，等稳定性没问题了再调。
6.3 怎么确认推理框架真的走了三值kernel，而不是偷偷反量化
这是最隐蔽的坑。有些框架虽然能加载三值GGUF，但内部没有针对性优化，会先把三值权重反量化成浮点，再跑普通矩阵乘。结果就是：模型可运行、显存占用看着不低、速度也没有明显提升，那你还不如直接用BF16原版。
我自己判断有两个技巧。第一看启动日志，llama.cpp加载三值模型时通常会打印权重类型和layer信息，确认是ternary/tq1_0。第二看实际性能，27B的三值模型在4090上如果只能跑到10 token/s，那就是没走对kernel；按我实测，最简单的无并发场景也应该有30 token/s以上。如果性能差太多，优先检查是不是用了老的llama.cpp版本或者没有正确启用CUDA。
6.4 我可以直接拿它替换生产环境吗？
我的建议是：可以试，但不要直接替换。做一个“影子测试”，把线上流量复制一份打到Bonsai 2 27B上，跑一周，对比它在你的特定任务上和原版的差异。重点看三类问题：第一，输出格式是否需要严格匹配；第二，是否有长文档/长代码的高精度要求；第三，是否需要频繁进行多步数学计算。如果这三类问题在你的业务里占比很高，那98.2%的综合保留率可能不够用。
反过来，如果你的业务是对话机器人、内容摘要、知识问答、情感分析这类高容错任务，并且你对单卡推理成本和延迟有硬要求，那Bonsai 2 27B的价值非常大。我实际把它的输出和原版混在一起做过盲测，很多人在普通问答场景根本分辨不出哪个是1-bit模型，只有在代码和格式要求很高的任务上才会察觉差异。
7. 最后说几句实话
跑完这三天，我最大的一个感受是：1-bit模型不是魔法，它是把“显存瓶颈”转移成了“表达能力瓶颈”。如果你手里有足够大的显存、足够的算力，BF16原版当然更好，没必要为了追新而委屈自己。但如果你像我一样，经常要在单卡环境里塞大模型，或者要给客户交付一个能在办公室电脑上跑起来的私有化方案，那Bonsai 2 27B是值得放进备选清单的。
还有一个我自己事后才明白的经验：评估这类量化模型，千万别只跑一个综合基准就下结论。综合分只是给你一个“及格”信号，真正决定能不能用的，是你自己的用例样本。我建议把所有业务prompt整理成200到500条测试集，原版和1-bit模型各跑一遍，然后人工看差异。这个过程不复杂，但能帮你避免被“98.2%”这种平均数骗了。
最后再分享一个小技巧：如果你决定在项目里引入Bonsai 2 27B，尽量把它和原版Qwen 3.8 27B放在同一个API网关后面，用路由规则做灰度。这样你可以随时按用户、按场景、按时间切片切换模型，既能积累更多真实场景数据，又不会因为某个突发bug导致线上全面翻车。1-bit模型还在快速演进，保持一个可回退的架构，比单纯追求“极致的压缩”更重要。
