Kotonia
ログイン今すぐ始める

Kotonia Articles

1.58bit 的 27B 忘记了什么——用日语实测「FP16 的 95%」这句话的盲区

PrismML 发布 Bonsai 27B(Qwen3.6-27B 的三值 1.71bit 压缩版)后第二天,我们就在本地做了实测。速度和体积的宣称是真的(121.6 tok/s、权重仅 6.66GiB),但日语场景下 52% 的回复混入了英文单词。我们定位了根因,并总结了一份多语言 LLM 产品的排查清单。

作者 6分钟阅读
#llm#quantization#ternary#localllm#gpu
其他语言日语英语

TL;DR

  • PrismML 于 2026-07-14 发布了 Bonsai 27B——将 Qwen3.6-27B 整体转换为三值(ternary,1.71bit)和二值(binary,1-bit)的版本,Apache 2.0 协议。我们在发布次日就做了本地实测。体积和速度的宣称是真的:在 RTX PRO 6000 Blackwell 上跑出了 121.6 tok/s(权重仅 6.66 GiB),超过官方公布的 H100 数值。英语对话、代码生成、tool calling 都保持了可用于生产的质量
  • 但日语坏掉了。用 50 条模拟语音聊天场景的日语提示测试,52% 的回复混入了英文单词(拉丁字母混入率 7.3%)。比如把「三日坊主」(日语里"三分钟热度"的说法)直译成 "three-day monk",然后整句话都变成英文;简体字「开」也会混进本该是日语的句子里
  • 用同样的 50 条提示测试未量化的 Qwen3.6-27B(Q4_K_XL),混入率只有 0.27%,受污染回复占 6%。基座模型的日语完全正常,劣化是在三值转换过程中产生的,而不是继承自基座
  • 有意思的一点是:三值(1.71bit)和二值(1.125bit)两个版本的劣化程度几乎一样(52% vs 56%)。如果这是容量不够导致的问题,继续削减比特数应该会让情况明显恶化,但并没有。转换过程中训练数据的分布,决定了模型最终保留下什么能力,而不是比特预算决定的。这和官方 15 个 benchmark 全部是英语这一事实完全吻合
  • 结论:「FP16 的 94.6%」这句话没有说谎,但那 94.6% 只是英语 benchmark 能测到的范围内的 94.6%。如果不加验证就把这类模型搬进多语言产品,它可能会以任何静态 benchmark 都测不出来的方式崩坏。采用前,先跑一个 5 分钟就能写出来的机械式金丝雀指标(见正文)

Bonsai 27B 是什么,为什么这么震撼

PrismML 的官宣概括起来就是:把 Qwen3.6-27B 整体转换成了 三值({-1, 0, +1},实际 1.71 bits/weight)和 二值({-1, +1},1.125 bits/weight)。权重从 FP16 的 54GB 分别压到三值 5.9GB / 二值 3.9GB。官方给出的数字是:iPhone 17 Pro Max 上 11 tok/s,M5 Max 上 44 tok/s。

sub-2bit 的 LLM 本身不是新鲜事,BitNet 系列早就有先例。真正震撼的是下面这两点:

  1. 对已经训练好的模型做后期转换,而不是从零开始。BitNet 系列必须从一开始就在低比特约束下做全量预训练,这意味着放弃已有的模型资产(所以规模最大也就停留在 2B 级别)。Bonsai 走的是「先训练出一个聪明的模型,再压缩」的路线,并因此做到了 27B
  2. 没有"逃生舱"。传统的"2bit 量化"通常会把 embeddings 和 attention 部分保留在 4~8bit,标签和实际情况经常对不上(官方 whitepaper 自己测出来,所谓"2-bit"的 IQ2_XXS 实际平均是 2.8 bits/weight)。Bonsai 从 embeddings 到 LM head 全部统一采用三值/二值,标签上写的比特数就是实际的比特数

whitepaper 的核心结论是:在 15 个 benchmark(全部在 thinking mode 下测试)的平均分上,FP16 是 85.07,三值是 80.49(94.6%),二值是 76.11(89.5%)。同样是 Qwen3.6-27B,IQ2_XXS(9.4GB)会崩溃到 72.73,而 Bonsai 用 60% 的体积(5.9GB)反而高出近 8 分。在 AIME26 上,IQ2_XXS 崩到 57.5,三值版本还能保持在 87.5。所用方法是基于加州理工 Hassibi 教授一系的理论做 QAT(从训练早期就引入三值约束进行转换训练),细节属于未公开的专利技术。

我一个人在运营一个日语语音角色扮演平台(kotonia.ai),生产环境用的 LLM 正好是同一个 Qwen3.6-27B 系的微调版本(ThinkingCap-27B NVFP4,约 20GB),常驻在 RTX PRO 6000 Blackwell 上。如果同一个基座的 27B 能压到 7GB,GPU 资源分配方式就要从根本上重新考虑。这个动机,足够支撑我在发布次日就动手验证。

测试环境

  • GPU: RTX PRO 6000 Blackwell Max-Q(96GB)。语音相关服务隔离在另一块 GPU 上,测试期间生产环境全程不受影响
  • 运行时: PrismML 的 llama.cpp fork(自定义量化类型 GGML_TYPE_Q2_0,加上用于 hybrid-attention 的 CUDA kernel,mainline 版本跑不了),针对 sm_120 从源码构建
  • 在同一台机器、同样的 prompt 下对比 4 个模型:
    • 三值 Bonsai 27B(Q2_0,7.2GB)
    • 二值 Bonsai 27B(Q1_0,3.8GB)
    • 未量化的 Qwen3.6-27B(unsloth UD-Q4_K_XL,17.6GB)—— whitepaper 自己拿来当 FP16 对照组的同一个文件
    • ThinkingCap-27B NVFP4(vLLM,生产环境实际运行的版本)—— 作为参考

首先,是真材实料的部分

一开始是带着怀疑去测的,结果基础设施层面的每一项宣称都被实测印证了,甚至还超出预期。

项目官方宣称实测(RTX PRO 6000 BW)
权重体积(三值)~5.9GB(原生目标)/ 7.2GB(当前 GGUF)6.66 GiB
推理显存占用4K 上下文下 8.4GB16K 上下文下 8.9GB
生成速度 tg12898 tok/s(H100)121.6 tok/s
提示处理速度 pp5122,596 tok/s(H100)3,210 tok/s

解码本身是带宽瓶颈型任务,所以在带宽性价比更高的工作站 GPU 上跑出超过 H100 的成绩,理论上说得通。但亲眼看到「27B 模型只占不到 9GB 显存,还能跑出 121 tok/s」,冲击力还是超出了数字本身。作为对比,同一环境下跑未量化的 Qwen3.6-27B Q4_K_XL 只有 65.7 tok/s。权重缩小 2.46 倍,速度提升 1.85 倍——带宽的数学关系直接转化成了体感速度。

只要停留在英语场景,质量看起来也是真的。

  • 英语闲聊和共情类回复很自然,没有找到明显崩坏
  • 代码生成用实际跑单元测试来机器判定,区间合并和游程编码两道题都 PASS
  • OpenAI 兼容的 tool calling 返回了结构正确的 tool_calls
  • 数学题:同一道题连续问 10 次,10/10 正确(不过下文会提到方差问题)

唯一和宣称不符的是自带的投机解码(DSpark,一种 EAGLE 系的 block-diffusion drafter)。官方宣称在 H100 上有 1.34 倍加速,但在我们的环境里只从 121.6 提升到了 125.3 tok/s,仅 +3%。看 draft 的接受率,英语 essay 场景是 73%,说明 drafter 本身是有效的,只是基座模型生成速度已经足够快,drafter 自身的 forward 开销把收益基本吃掉了。而在日语场景下,接受率直接掉到 10%。drafter 显然也是针对英语训练的。到这一步,已经有不祥的预感了。

"Kotone" 开始讲英语了

用和我们产品语音角色一样的条件(口语化、2-3 句、关闭 thinking)投喂日语闲聊,情况开始不对劲。

User: 資格の勉強始めたけど三日坊主になりそう。(刚开始准备考证,感觉又要三分钟热度了) Ternary Bonsai: Qualification study began but three-day monk?

「三日坊主」被直译成了 three-day monk,整句回复都变成了英文。还有其他例子:

User: 朝起きられないんだけど、何かいい方法ない?(早上起不来,有什么好办法吗?) Ternary Bonsai: 朝起きられないのは、身体が休んで欲しいから maybe? 夜前にPhoneを遠くに置き、 morning light を受けられるようにカーテンを开けると、目覚め方が良いよ。

除了混入英文单词(maybe、morning light)之外,「開ける」(打开,日语汉字写法)变成了简体字的「开ける」——不只是英语污染,连中文的字形系统都渗进来了。二值版本更加明显:面对日语的吐槽,直接整句用英文回复("Yeah, totally get that. Sometimes boss behavior can be really frustrating."),在被问到卡拉OK选曲建议时,还推荐了两首根本不存在的歌:《Hello Sunshine》和《Sugoi Nana》。

为了不止停留在印象层面,我们把这个现象量化了。

量化指标:拉丁字母混入率

用 LLM 做判定会引入可复现性方面的争议,所以我们选了一个更原始的指标。

  • 投喂 50 条日语闲聊 prompt(工作、恋爱、饮食、健康、兴趣爱好等),附带语音角色的 system prompt
  • 去掉回复中的空格,统计 拉丁字母([A-Za-z])占字符总数的比例,以及 包含 2 个及以上连续拉丁字母的回复所占比例

自然的日语口语中,外来语通常会用片假名表示,所以这个数字理论上应该接近零。对照组的实测结果也确实如此。

模型bits/weight日语混入率含英文单词的回复占比
未量化 Qwen3.6-27B(Q4_K_XL)5.20.27%6%
ThinkingCap-27B(NVFP4,生产环境)~40.56%2%
三值 Bonsai 27B1.717.29%52%
二值 Bonsai 27B1.1257.83%56%

超过一半的回复混入英文单词,对一个对话类产品来说基本等同于报废。中文场景下也是同样的趋势(用 10 条 prompt 做简易测试,基座模型和生产模型混入率都是 0%,三值版本是 4.1%,二值版本是 5.3%)。英语以外的语言被大范围削掉了,英语反而被浓缩、强化了。

平心而论,whitepaper 并没有隐瞒 15 个 benchmark 全部是英语这件事,也如实披露了 instruction following 和 agentic 能力的下降(比如 IFBench 从 68.0 降到 58.5)。既然官方从没对多语言能力做过任何宣称,那也谈不上被欺骗。**没有测量过的东西,自然也就看不见。**事情就是这么简单。

排除因果:元凶是转换工序

一个很自然的反驳是:「会不会本来 Qwen3.6-27B 的日语就弱?」所以我们特意把对照组设为 whitepaper 自己用作 FP16 参照的那个 GGUF 文件(unsloth UD-Q4_K_XL)。结果如上表所示:混入率 0.27%,受污染回复 6%。未量化基座模型的日语完全健康,这就确定了 劣化是在 Bonsai 的 QAT 转换过程中被引入的,而非继承自基座。

第二个发现是,三值(1.71bit)和二值(1.125bit)的劣化程度几乎已经饱和。比特容量相差 1.5 倍,但日语崩坏的程度几乎一样。如果这纯粹是"信息容量不够"导致的问题,二值版本理应明显更差,但事实并非如此。

也就是说,这不是容量问题,而是转换过程中训练了什么内容的问题。QAT 本质上是"在三值空间里重新学习最优表示"的过程,这个过程里流过的数据分布,直接决定了模型最终保留下来的能力分布。喂英语和代码,英语和代码就会留下;不喂日语闲聊,日语闲聊自然就留不下。官方宣传里"保留 27B 级别的 thinking、reasoning 和 agentic 能力"这句话是对的,但这个能力的定义域,被转换数据和 benchmark 所覆盖的范围严格框定住了。

与其说这是一种批评,不如说这是理解这项技术本质的关键。sub-2bit 转换与其说是"压缩",不如说更接近"向英语这个子空间做蒸馏"。而这个视角也蕴含着相反方向的希望:如果有人在转换数据里充分加入日语,烧出一版 Bonsai,日语很可能也能保留下来——因为崩坏的方式本来就不是容量决定的。

一个附带发现:thinking 长度的方差

whitepaper 的 benchmark 全部是在 thinking mode 下测的。而实际生产中真正起作用的不是均值,是方差。用同一道数学题连续问 10 次,虽然全部答对,但 thinking 的长度在 2,339 到 7,934 token 之间波动(相差 3.4 倍)。另外在一次单独的会话中,同一道题用掉 12,000+ token 的 thinking 也没能得出答案,属于一次失控观测。目前还没验证这是否是 sub-2bit 模型的特有现象(未量化模型本身也有一定的 thinking 长度方差),但如果要把 thinking mode 接入有延迟 SLA 的产品,token budget 和超时机制是必需品,不是可选项。

写给多语言产品运营者的检查清单

给和我处于同样处境的人(在非英语市场运营面向用户的 LLM 产品)的一些实务建议。

  1. **英语 benchmark 的平均分,对你的用户所使用的语言没有任何保证。**这不是 Bonsai 特有的问题,任何经过蒸馏、量化、剪枝等"转换"工序的模型都存在这个风险。转换过程中使用的数据分布通常不会被公开
  2. **金丝雀指标 5 分钟就能写出来。**自己产品的角色 prompt + 50 条测试 prompt + 拉丁字母混入率(或者针对目标语言、衡量"偏离该语言书写体系程度"的等价指标)。不需要判定用的 LLM,完全可复现,每次模型更新都可以直接接入 CI 跑一遍
  3. **投机解码的接受率同样和语言相关。**drafter 比主模型更小,训练数据的偏差在它身上会体现得更极端。不要把用英语测出来的加速比,直接外推到多语言流量上
  4. 如果要采用 thinking mode,用 p99 而不是 p50 的 thinking 长度来设计容量和超时

即便如此,这依然是一场革命的开端

虽然通篇都在讲日语被搞坏了,听起来有点矛盾,但测完之后的真实感受是:这个方向是真的。

  • 三值 27B(80.49)超过了 FP16 8B(79.3)。与其持有一个 16.4GB 的 8B 模型,不如持有一个 5.9GB 的三值 27B 更划算——这个逆转已经切实发生了
  • 因为是基于转换而非从零训练,它能跟上前沿模型的迭代节奏。BitNet 路线要求"为低比特专门从头训练",而这条路线只需要"每次有更强的模型出来,就转换一遍"
  • 既然崩坏方式不是容量决定的,做出多语言版本在理论上是可行的。如果有人在转换数据里加入充分的日语,那么在我现有的这块 GPU 上,跑一个顶级本地模型的未来完全可以想象

我的产品是日语 × 语音 × 实时性的综合考验,所以生产环境暂时还是会继续用 ThinkingCap-27B。不过这次测试得到的金丝雀指标,会被固定加入到今后的模型选型流程里。在 benchmark 照不到的质量死角里搏斗,本来就是做多语言产品的日常。

复现步骤

以下所有内容都可以用公开资源复现。

# 1. 编译 PrismML 的 llama.cpp fork(CUDA,Blackwell 用 arch 120)
git clone https://github.com/PrismML-Eng/llama.cpp llama.cpp-bonsai
cd llama.cpp-bonsai
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120 -DCMAKE_BUILD_TYPE=Release
cmake --build build -j --target llama-server llama-bench

# 2. 获取模型 (HF: prism-ml/Ternary-Bonsai-27B-gguf 等)
#    Ternary-Bonsai-27B-Q2_0.gguf (7.2GB) / Bonsai-27B-Q1_0.gguf (3.8GB)
#    对照组: unsloth/Qwen3.6-27B-GGUF 的 UD-Q4_K_XL (17.6GB)

# 3. 启动(官方推荐采样参数)
./build/bin/llama-server -m Ternary-Bonsai-27B-Q2_0.gguf \
  -ngl 999 -fa on -c 16384 --jinja \
  --temp 0.7 --top-p 0.95 --top-k 20 --min-p 0
# 如需关闭 thinking,在请求里传 chat_template_kwargs {"enable_thinking": false}

# 4. 测速
./build/bin/llama-bench -m Ternary-Bonsai-27B-Q2_0.gguf -ngl 999 -fa 1

混入率的测量脚本(50 条 prompt 加汇总统计,不到 100 行 Python)写得比较朴素,建议根据文章里的定义,针对自己的目标语言重新写一份,而不是直接照搬。prompt 集合越贴近你产品实际的角色设定,作为金丝雀指标的灵敏度就越高。

kotonia.ai 是一个基于多语言 TTS 和唇形同步虚拟形象的日语语音角色扮演平台。由于 LLM、TTS、虚拟形象生成全部跑在同一块本地 GPU 上,这类实测工作对我们来说既是兴趣,也是刚需。

Kotonia 将语音 AI、AI 聊天、图像生成和团队协作整合到一个 AI 工作区中。

试用 Kotonia