三值模型压到 1.485 比特，没有打破信息论
据 arXiv 上的 BITCOS 预印本，英特尔研究人员尝试用另一种布局存储三值大模型权重，最低做到每个权重符号 1.485 比特。论文标题里的“打破 1.58 比特屏障”容易引起误解：变化来自权重分布和编码方式，不是信息论失效。
作者：林岚｜OC 开发者生态编辑
据 arXiv 上的 BITCOS 预印本，英特尔研究人员尝试用另一种布局存储三值大模型权重，最低做到每个权重符号 1.485 比特。论文标题里的“打破 1.58 比特屏障”容易引起误解：变化来自权重分布和编码方式，不是信息论失效。
一句话结论：零权重足够多时，省下重复表示零的空间，可以让三值模型更紧凑；省空间能否转化为推理提速，还要看解包成本与硬件。
先区分三个值和三个等概率的值
三值权重只能取负一、零、正一。若三个符号等概率出现，常见的信息量参照是 log₂3，约为 1.585 比特。但“只能取三个值”并不意味着这三个值出现得一样多。零特别常见时，编码完全可以利用这种不均匀。
BITCOS 的做法可以直观地拆成两份记录：先用位图标出每个位置是否为零，再只给非零位置存正负号。假设零的比例是 z，符号部分的平均空间就是 1＋(1－z)，即 2－z。零越多，需要额外保存的符号越少。这是改变表示法，没有把原来的非零值偷偷丢掉。
这里的 1.485 也不是整个模型文件、运行内存乃至显存占用统一除以参数量后的结果。缩放因子等附加信息、运行时缓冲区和注意力缓存，需要另算。把权重符号压得更紧凑，与让一台机器能运行多大的完整模型，是相连但不同的两个问题。
小文件不能自动兑换快推理
压缩格式最大的工程难点，往往不是写入，而是读取。推理内核需要及时取出当前计算所需的值；如果为节省几个比特增加了复杂分支、索引查找或不规则访问，节省的带宽可能被解包开销吃掉。
因此，一个新布局真正有价值，需要同时回答两个问题：模型中是否有足够多的零，以及目标处理器能否便宜地把布局还原成计算所需的形态。只有第一项好看，得到的可能只是更小的下载包；第二项配合，才有机会改善运行吞吐。
作者在 29 个模型中观察到，26 个采用新布局后的符号存储更紧凑，并为若干 CPU 指令集和英特尔 Xe2 GPU 设计了解包实现。其端到端解码实验报告 CPU 最高约 1.18 倍、GPU 最高约 1.27 倍吞吐。这些都是指定平台、模型和基线下的作者结果，不是所有设备的共同涨幅。
部署时还要看瓶颈在哪里
对本来受权重读取带宽限制的任务，减少搬运量可能很有效；如果主要时间消耗在其他计算、通信或请求调度上，同样的压缩比例就未必显眼。并发数、上下文长度和批处理方式改变后，瓶颈也会移动。
模型服务团队因此不能只比较两个文件的大小。还应在自己的请求分布下记录首个输出等待时间、持续生成速度、内存峰值和兼容性，并把权重格式转换、加载以及维护多套内核的成本算进去。平均吞吐提升但小请求延迟恶化，也可能是不合适的部署选择。
这项工作的价值，是把一个看似固定的“每权重多少比特”重新放回数据分布与机器实现中讨论。它没有发明一种普遍超越下界的魔法压缩，也没有证明更低比特必然带来更聪明的模型。
关键事实
- 来源：2026 年 9 月 14 日提交的 BITCOS 预印本。
- 技术对象：既有三值权重的存储布局与解包实现。
- 数字边界：1.485 比特指最稀疏样本的权重符号部分；不是整机推理内存。
- 验证范围：论文所测 CPU 与 Xe2 GPU，不代表全部硬件。
OC 判断
低比特模型的下一步竞争，不只在训练时把数值压小，也在运行时如何少搬数据、少做解包。BITCOS 提供了一个可检验的工程方向，实际收益仍应由目标设备上的完整工作负载决定。
为什么重要
- 对开发者：选择权重格式时，应同时检查稀疏分布与运行内核支持。
- 对模型服务商：把压缩率和端到端延迟放在同一张测试表里。
- 对用户：更小的模型包值得期待，但不能据此推断回答质量或续航提升比例。
评论
围绕这篇文章补充信息、提出问题或分享观察。