📝

BREVIS 提出程序合成式无损压缩：给每个权重张量搜出一段可逆算子程序，执行即可逐位重建。2.13TB 权重压到 1.41TB，比 zstd 平均再小 12.94%，论文见 arXiv 2608.02162。

把模型权重用代码跑出来：BREVIS 无损压缩省 3 成体积

原文来源：小红书笔记「把模型权重用代码跑出来，无损节省3成体积」（作者：马铃薯炖土豆）
论文：arXiv 2608.02162

背景：权重存储正在指数膨胀

Hugging Face 上的模型仓库，从 2020 年的 425 个涨到今天的 295 万个，存着 15 PB 以上的数据。zstd、gzip 这类通用压缩器把权重当普通字节流，但在模型权重这种特殊结构上表现并不好——因为它们忽略了浮点数的内在结构。

核心洞察：IEEE 754 的分段规律

计算机存小数用的是 IEEE 754 标准。它不把一个数当成一整块，而是像科学计数法那样拆成三段：

符号位（正还是负）
指数位（数量级有多大）
尾数位（精度）

一个 FP32 就是 1 位符号 + 8 位指数 + 23 位尾数。

举例：FP32 存的 (+1.0, −1.0, +1.0, −1.0, +1.0, −1.0)，按三段拆开看：

符号位是 (0,1) 重复三次
指数位是六个 127
尾数位是六个 0

三个字段各有各的规律，而且规律种类完全不同。混在一起看就是一堆没头没尾的字节，单一的固定算法只能抓住其中一种规律——这就是通用压缩器在权重上表现差的根本原因。

BREVIS：压缩文件 = 一段程序

作者换了个思路：给每个张量写一段程序，跑起来能把原来的比特一位不差地生成出来。那么压缩后的文件就是这段程序，解压就是执行它。

为此设计了一套只有七个可逆算子的小语言：重复、常量、相邻差分、按位宽合并浮点字段等。上面那六个数可以被写成一行：

1	merge(repeat₃(0,1), const(127), const(0))

难点：怎么搜出这段程序？

如果枚举所有程序再逐个执行验证，绝大多数都是错的，纯浪费。BREVIS 的做法是反向搜索：

不从算子出发去凑结果，而是从结果出发去拆
每个待解决的子问题都带着它必须生成的那段目标比特，算子会把目标原地拆成子目标，像递归一样往下推进
只要子节点各自生成了自己的目标，父节点就必然生成它的目标；一路推到最上层，整个张量必然一位不差

关键收益：正确性在构造过程中就被保证，不需要反复执行验证。

实测结果

在 10 个公开 checkpoint 上做了实验，总共 2.13 TB 数据：

指标	数值
压缩前	2.13 TB
压缩后	1.41 TB
节省	33.9%
vs zstd	平均再小 12.94%
vs ZipNN（专门模型压缩器）	更小；压缩快 7.2%、解压快 8.9%

一点延伸思考

BREVIS 属于「程序合成（program synthesis）」路线在系统层面的落地：把「数据压缩」重新定义成「找到能生成这段数据的程序」，而反向搜索让正确性免于验证成本。这与传统熵编码（Huffman/算术编码）是完全不同的范式——它利用的不是统计冗余，而是结构冗余（IEEE 754 位段之间的规律）。

对做模型分发、推理引擎、模型存储优化的团队来说，这是值得关注的增量：不动权重精度（无损）、不需要特殊硬件（解压就是执行小程序）、直接兼容现有 safetensors 生态。

数据备注：以上全部数字（425→295 万仓库、15PB、33.9%、12.94%、7.2%/8.9%）均来自原文笔记，原文已标注 arXiv 2608.02162。