三元大模型默认每个权重占 1.625 位，Intel 团队改按真实权重分布编码后压到 1.485 位

原文来源：arXiv — 三元大模型的权重存储格式里藏着一个被忽略的假设，把它改掉就能省下最多 8.6% 的存储，并让解码更快。

三元大模型（Ternary LLM）把每个权重只存成三个符号之一：-1、0、+1。如果三个符号等概率出现，一个权重最少要 log₂3 ≈ 1.585 位。但真正落地时，行业通用的是「五个一组打包」——把 5 个三元权重塞进 1 个字节。由于分组大小要取 2 的幂，这个方案实际落到 1.625 位/权重。

1.585 到 1.625 之间的这点差距，源头是一个默认假设：三个符号出现的概率一样高。Intel 的 Evangelos Georganas、Alexander Heinecke 和 Pradeep Dubey 三位研究员决定去实测这个假设成不成立。

先说一句背景：三元模型（BitNet 那一系「1.58 位」思路）之所以受关注，是因为它把权重压到极端低精度之后，矩阵乘可以退化成加减法，端侧和 CPU 推理的能耗、内存占用都能大幅下降。而权重存储本身在推理时是内存带宽瓶颈——模型多大，就要按多大的量从内存搬到计算单元。所以每省下 0.1 位/权重，对受限设备来说都是实打实的。

先把假设测掉

他们测了 29 个三元大模型的真实符号分布，结果很直接：0 在权重里最多占到 51.5%。也就是说，三元模型远没有想象的那么「均匀」，它是偏稀疏的。

既然 0 明显偏多，把三个符号当成等概率就已经浪费了空间。他们的做法是换一种布局，把「是不是 0」和「正还是负」这两件事拆开存：

• 一张稠密的存在位图（presence bitmap），标记每个位置是不是非零；
• 一个紧凑化的符号向量（sign vector），只存非零位置的 +1 / -1。

这个布局叫 BITCOS。给定模型权重的零密度 z，它的存储开销是 2 − z 位/权重。z 越大，省得越多。

拆开存的好处在于：位图是稠密的、可以用位运算一次性处理，而符号向量只在非零位置上占空间，两者都不需要「每个权重固定占 1.625 位」这种一刀切。代价是解包逻辑比定长打包复杂——所以论文专门为几套主流指令集写了优化过的解包序列，而不是指望编译器自己搞定。

值得注意的是，这套思路和「乘法」是解耦的：BITCOS 只改权重怎么存，不改三元矩阵乘怎么算。也就是说，它可以和现有的三元 kernel 配合使用，不需要重写整个推理栈。

数字：1.485 位/权重

在 29 个被测模型里，BITCOS 有 26 个比五个一组打包更省。在零最多（最稀疏）的那个模型上，它压到了 1.485 位/权重。这个数字低于 log₂3，因为真实分布本来就不是均匀的，1.585 只是均匀分布下的下界。

省多少存储是一回事，能不能在硬件上跑得快是另一回事。BITCOS 的解包逻辑对现代 CPU 和 GPU 都友好，团队为 AVX-512、AVX2 以及 Intel Xe2 GPU 分别写了优化过的解包序列。

对照生产环境里最先进的三元矩阵-向量乘 kernel，在真实模型展现出的零密度下，BITCOS 带来的实测加速最高达到 1.28 倍。

端到端的效果也测了，跑在 5 类平台上（客户端 CPU、服务器 CPU、集成 Xe2 GPU、独立 Xe2 GPU）：

• CPU 上解码吞吐最高提升 1.18 倍；
• GPU 上最高提升 1.27 倍。

这件事为什么值得关注

过去几年，量化从 16 位一路压到 8 位、4 位、2 位，再到现在主推的 1.58 位三元，每一档都在往前挤那几个百分点。到了三元这一步，留给存储的空间按理说不多了。

这篇论文的启发在于：当存储格式逼近信息论下界时，剩下的优化空间不在「每个符号占几位」，而在「符号的分布是不是被浪费了」。五个一组打包之所以吃亏，是因为它按均匀分布来设计，而真实权重并不均匀。把「稀疏性」当成一等公民单独编码，就能白捡一截。

对做端侧推理、自己训练小模型的人，这个思路可以直接抄：先测你的模型里零到底占多少，再决定用什么打包格式。作者已经把 29 个模型的测量结果和三种硬件的解包序列都放进了论文里，复现门槛不高。

顺带说一句「零很多」这件事本身意味着什么。三元模型里出现超过一半的零，通常被解读为模型在极端低精度下的一种「自适应」——不重要的连接直接归零，剩下的非零权重承担全部表达。从这个角度看，五个一组打包的问题不只是「没利用统计规律」，而是它把一个结构性稀疏的模型，硬当成稠密均匀的模型来存，等于主动放弃了模型自己透露出来的信息。

这也是这篇论文值得非量化研究者的地方：它提醒我们，当压缩逼近理论上限时，红利的来源往往不是新算法，而是「别再假设数据是均匀的」。

值得注意的是，BITCOS 目前还是论文阶段的方法，作者没有说明是否已经合并进主流推理框架（如 llama.cpp、vLLM）。想用得自己实现解包 kernel——好消息是，零密度这个信息本来就是现成的，扫一遍权重就能算出来。