「9 倍更小、98.2% 保留」：厂商话术技术管理者怎么读

开场：一句话，两个数字

9 月 17 日，PrismML 官方博客发布 Ternary Bonsai 2 27B，官方口径一句话：比全精度版本小 9 倍以上，同时保留 98.2% 的聚合基准性能。这话错了吗？未必。但这话该怎么读，是另一门手艺。同一天，这句话在 Hacker News 拿到 563 个赞。而把时间往前拨两个月，这家公司在首发第一代 Bonsai 27B 时，官方话术已经从「把模型做小」悄悄换成了「压缩成为部署解锁（deployment unlock）」。

营销词不是谎言的同义词，但它有自己的造词逻辑，也有自己的受益人。技术管理者的工作不是骂它，也不是信它，而是把它拆回能验证的零件。

拾闻：一句话两个数字，为什么值得单开一期？

永亮：因为我十七年乙方汇报和方案评审做下来，一半以上的分歧不在技术，在话术。厂商报一个数，甲方听一个数，两边以为说的是同一件事，签约之后才发现完全不是。这期就拆这个事：数字怎么读、词怎么造、星怎么涨，最后给你三个能在采购会上直接问出口的问题。

Q1：先拆「9 倍更小、98.2%」这两个数字本身

永亮：先声明口径：以下全部是 PrismML 官方博客的自报数字，我引用时都带「官方称」。在这个前提下，这两个数字恰恰是最值得拆的样本。

按官方博客，Ternary Bonsai 2 27B 基于 Qwen3.8 27B，权重做三值化——{-1, 0, +1} 三个值，再加 FP16 分组缩放，官方称每权重 1.76 有效比特，模型总占用 5.9GB，支持 262K 上下文，多模态图文输入，Apache 2.0 协议。单看这些，工程上是扎实的活儿，这一点要承认。

值得慢下来读的是后半句。官方称「比全精度版本小 9 倍以上，同时保留 98.2% 的聚合基准性能」。拆开看，有三个口径问题。第一，「9 倍」的分母是谁？全精度版本是 FP16 还是 FP32？分母不同，倍数完全不同。第二，「98.2%」聚合了哪些基准、按什么权重聚合？官方博客里没有给出完整基准清单，也没给聚合方式——这不是指控，是披露程度的问题。第三，也是最容易被忽略的：基准分数不等于真实任务体验。聚合基准是几十个任务的平均分，平均保留 98.2%，意味着有些单项任务掉得多、有些掉得少，而被平均拉平的那部分，可能恰好掉在你的业务关键任务上。

再说一遍我的身份：乙方汇报做了十七年，这套数字打包的手法，我既见过别人用，也自己用过。保留一位小数的百分比，是为了显得精确；用「聚合」而不列清单，是为了让掉分的地方不出现在台面上。我没有任何说官方造假的意思——没给清单，可能是篇幅所限，也可能是选择性呈现，两种都有可能。但管理者的读法只有一种：凡是「X 倍」「Y%」这种打包数字，先问分母和清单，再谈信不信。

Q2：「near-lossless」「deployment unlock」这种词是怎么造出来的

永亮：词不是随手造的，每个营销词背后都有一个具体的受益人。

两个月前，PrismML 首发第一代 Bonsai 27B 时，官方话术是「压缩成为部署解锁」（deployment unlock）。这次的 Bonsai 2，社区讨论里出现了 near-lossless（近无损）这类说法。把两个词摆在一起看，造词的路数很清楚。

「无损」在工程上有明确定义：信息可以完整还原。但量化模型做不到——三值化之后，原始权重是找不回来的。所以没人敢说无损，于是造出「near-lossless」：加一个字，既借到「无损」的分量，又不用承担「无损」的证明责任。谁受益？短期是传播者，一个听起来专业的词能让帖子多转几轮；长期是厂商，词传开之后，默认印象就种下了。

「deployment unlock」是另一条路：不给数字，给叙事。「压缩」是工程词，讲出来只有工程师在乎；「解锁部署」是商业词，讲给老板和投资人听。把 5.9GB 说成「解锁部署」，听的人脑子里的问题就从「这个模型多大」换成「这能帮我省多少卡」。技术参数没变，叙事对象换了，这是两个月前那次首发就完成的转向。

受益人排一排：第一是厂商的市场和融资叙事；第二是内容传播者，有新词可写；间接受益的甚至是甲方里想推动立项的人，因为顺耳的词能降低立项阻力。唯一不受益的是掏钱验收的那位——如果他在签约前没把词拆回数字的话。

Q3：三天、五个仓库、几千颗星——Jev 这波同名项目潮怎么读

拾闻：聊完厂商造词，看社区这边。TypeSafe 的 Jev 模型，三天内 GitHub 上冒出五个同方向项目，星数加起来上万。这是技术火爆的证据吗？

永亮：先把可核的事实摆清楚，再谈怎么读。

Jev 是 TypeSafe 公司的商业模型。按 TypeSafe 官方博客的说法，它自称 system one 模型：不逐字生成回答，而是对给定选项直接输出每个选项的概率，用在 agent 的快速分支决策上。TypeSafe 没有公开模型设计。

同名项目的 wave 是 9 月 16 日起来的，到今天三天。按 GitHub 公开数据：browser-use 的 jev-ultrafast 5487 星，README 主打一个「7.1 秒订完苏黎世到伦敦机票」的演示，README 顶部就是 Browser Use Cloud 的 waitlist 候名单入口；tamaratran 的 fast-jev-compaction 3206 星；TheoLeeCJ 的 SemIf 1585 星，原名 OpenJev，首页声明与 TypeSafe 无关联；vinnylarouge 的 jevlike 885 星，自述「Jev 是 TypeSafe 商业模型、设计未公开，本仓库是同输入输出形状的独立入门模型」；jarrodwatts 的 jev-trader 866 星，一个每 300 毫秒做一次买卖决策的链上交易机器人。Hacker News 上「OpenJev」的帖子拿到 534 个赞。

这组数字里有两种东西，必须分开读。第一种是营销动作：跑得最快的仓库把演示和 waitlist 漏斗放在同一屏，星数增长本身就是漏斗入口——这不是技术证据，是获客工程，做得挺漂亮，但它回答不了「这个模型行不行」。跟风挂名的部分也一样：名字蹭上热点，星数涨得快，可星数从来不等于可用性。我作为老乙方说一句：评审会上拿 GitHub 星数当技术证据，和拿饭店排队长度当口味评分，是同一种方法论错误。

第二种东西恰恰是健康信号。SemIf 改名并声明与 TypeSafe 无关联，jevlike 明说自己是「同输入输出形状的独立入门模型」——这两份免责声明，是社区在补厂商没做的披露。热点出来之后，有人愿意花功夫做形状兼容的独立实现，并且把「我不是官方、设计我不知道」写在首页，说明社区里有人在乎可复现。营销动作会退潮，免责声明会留下。读这波 wave，看后者就够了。

Q4：采购和立项的时候，怎么用三个问题拆话术

永亮：这是这期我最想给的东西。三个问题，评审会上可以直接用。

第一个问题：请给一个可复现的口径。「9 倍更小」的分母是什么模型、什么精度？「98.2%」的基准清单和聚合权重能不能列出来？这个问题的关键不在答案，在对方怎么接。能给清单的，数字大概率经得起查；开始讲「行业惯例」「不方便公开」的，你就明白了——他要保护的不是机密，是数字。第二个问题：有没有第三方复测？不是找一篇转引官方数字的报道，而是找一个和厂商没有利益关系的团队，在相近条件下跑出可对比的结果。上周我们刚拆过一个官方自报口径的基础设施案例，技术栈和难点全是一家之言——自报口径不是不能信，是不能只信。第三个问题最狠：把宣传词写进验收条款。「你们说 near-lossless，那验收标准就按误差界写；你们说 98.2%，那验收就按你们给的基准清单逐项测。」话术一旦变成合同语言，要么对方开始认真定义每个词，要么这个词从方案里消失——两种结果，对甲方都是赢。

这三个问题我用了十几年，原理一句话：营销词的特点是只能向上汇报、不能向下验收。凡是没法写进验收条款的词，在采购决策里的权重就应该是零。

Q5：收个尾——什么话术值得警惕，什么夸张可以接受

拾闻：最后给观众一个分辨的标尺？

永亮：我的标尺按「夸张的方向」分，不按行业分。

速度类的夸张，我容忍度高。「7.1 秒订完机票」这种演示，哪怕是挑了最好的条件录的，它的声称方向是「快」，而快的验证成本极低——你自己跑一遍就知道真假。能力类的声称，我零容忍。「98.2% 性能保留」「near-lossless」这种，声称方向是「相当于」，而「相当于」的验证成本极高，等你验完，约已经签完、钱已经付出去了。还有一类比能力声称更值得警惕：定义类话术。「deployment unlock」这个词本身没有任何可验证内容，它干的是重新定义问题——把「模型被压缩了」重新说成「部署被解锁了」。定义类话术的特征是：它说得越顺耳，你越要回头找一找，原来那个问题去哪了。

所以我的排序是：速度夸张，笑笑就行，自己复现一次算数；能力声称，先问口径和第三方，验收条款见真章；定义话术，直接追问原始问题。十七年审过的方案，最后闹出纠纷的，几乎都不是数字报错了，而是词从头到尾没定义清。

尾声

拾闻：最后，用一句话总结这期？

永亮：营销词不是谎话，是压缩包。技术管理者的工作不是骂它也不是信它，是在签约前把它解压——分母、清单、验收条款，解压完再看，它往往没那么可怕，也没那么便宜。

拾闻：这句话，送给大家。下期见。

---

【技术纵深】三值量化到底做了什么，为什么 5.9GB 反而是整篇博客里最能验算的数字

这期主线是读话术，有的读者可能想多知道一层：三值量化是什么，为什么「1.76 有效比特」这个古怪的数字，反而是官方博客里最诚实的部分。

三值权重：{-1, 0, +1}。 常规量化是把每个权重从 16 位或 32 位浮点压成更少的比特，比如 4 比特整数。三值化走得更远：每个权重只允许取负一、零、正一三个值，再配一组 FP16 分组缩放系数。官方称这套组合摊下来每权重 1.76 有效比特。

1.76 为什么诚实。 三个值本身用不到 2 比特就能编码，加上分组缩放和编码开销，摊到每个权重是 1.76 比特。这个数字带小数、不整，恰恰说明它是算出来的平均值，不是挑出来的整数。27B 参数乘 1.76 比特，除出来就是 5.9GB 上下——这个乘法谁都能算。数字能验算，是它可信的原因；可信的数字被拿去包装不可验算的「98.2%」，这正是话术的全部所在。

丢掉的那 1.8% 不是均匀分布的。 三值化对不同任务的伤害不一样：对权重分布平滑、容错高的任务，损失接近零；对依赖精细数值差异的任务，掉分明显。聚合平均分掩盖的正是这个不均匀。这就是 Q1 那句话的根据：先问清单，再谈信不信。

回到本期主线。能验算的数字从来不吓人，吓人的数字往往验算不了。这是读所有厂商话术的第一原理。

---

本期信息来源

• PrismML 官方博客 2026-09-17：Ternary Bonsai 2 27B 发布（基于 Qwen3.8 27B；三值权重 + FP16 分组缩放；每权重 1.76 有效比特；5.9GB；262K 上下文；Apache 2.0；「小 9 倍以上、保留 98.2% 聚合基准性能」均为官方自报口径，完整基准清单与聚合方式未披露）
• PrismML 官方博客（两个月前）：第一代 Bonsai 27B 发布，官方话术「压缩成为部署解锁」（deployment unlock）
• Hacker News 2026-09-17：Ternary Bonsai 2 讨论帖，563 ▲
• TypeSafe 官方博客：Introducing System One Models and Jev（Jev 为商业模型、模型设计未公开，均为官方口径）
• GitHub 公开数据（截至 2026-09-19 上午）：browser-use/jev-ultrafast 5487★、tamaratran/fast-jev-compaction 3206★、TheoLeeCJ/SemIf 1585★（首页声明与 TypeSafe 无关联）、vinnylarouge/jevlike 885★（自述为同输入输出形状的独立入门模型）、jarrodwatts/jev-trader 866★（五个仓库均创建于 2026-09-16）
• Hacker News：「OpenJev」讨论帖，534 ▲