用900KB的Transformer把100MB压缩到7MB：HN社区吵翻了

📌 训练一个900KB的Transformer花20分钟死记硬背你的文件，然后呢？它能比gzip多压出3倍的剩余空间。代价是解压要45分钟。

六月中旬，HN用户 spidy__ 发了一个 Show HN 帖子，标题一如既往地嚣张：“Overfitted a 900KB Transformer to Compress a 100MB CSV into 7MB”。112 points，71条评论，评论区从 Fabrice Bellard 七年前就做过了吵到「随机数据到底能不能被压缩」的哲学命题。

这个项目叫 pym-particles，本质上是个实验：让一个微型 Transformer 死记硬背单个文件的内容，然后用算术编码器把预测结果转成压缩输出。不做泛化，只做过的拟合。

它的核心结论就一句话：对结构化数据，神经网络压缩可以碾压传统算法；对文本，勉强打平但慢得离谱。 这不是实用的压缩工具，但它用硬数据证明了一个直觉——算力确实可以换压缩率，只是性价比目前还不太行。

一、这是个什么实验？

先别被"Transformer"吓到。这个实验的思路其实异常朴素：

你有一个文件，比如 100MB 的纽约出租车 CSV 数据。传统压缩算法（gzip、zstd、LZMA2）会扫一遍文件，找出重复模式和统计规律，然后编码。

而 pym-particles 的做法是：训练一个神经网络去"背诵"这个文件。每看到一个字节，模型就猜下一个字节是什么。猜得越准，压缩率就越高。

关键区别在于：一般训练神经网络是为了「泛化」——从训练集学规律，然后用到没见过的新数据上。但这次过拟合不是 bug，是 feature。Dropout、weight decay、正则化？统统不要。任何帮助模型泛化的技巧都在跟目标对着干。

作者自己在 ARCHITECTURE.md 里写得很直白：

Unlike most ML systems, overfitting is not a failure mode here, it’s the entire goal.

二、技术原理：一个神经网络的「背诵大赛」

整个流程可以拆成三步：

Step 1：训练（过拟合）

把文件切成 256 字节为一个窗口的切片。前128字节做「上下文」，后128字节做预测目标。模型是一个只有 2层、隐藏维度128、4个注意力头 的小型 Transformer，参数量不到 900KB。

然后用 Adam 优化器（初始学习率 5e-4，500步 warmup + cosine 衰减），FP16 精度，纯过拟合训练 7-10 个 epoch。训练指标就是 bits/byte——这个值越低，最终压缩率越好。

Step 2：预测（不是压缩！）

模型本身不产生压缩输出。它的唯一工作是：「给定前面所有的字节，下一个字节是 0x00-0xFF 每个值的概率分别是多少？」 比如看到 The cat ，模型输出：

如果模型很自信（概率 0.98），那这个字节只需要 -log₂(0.98) ≈ 0.03 bits 就能表示；如果模型很犹豫（概率 0.1），就需要 -log₂(0.1) ≈ 3.3 bits。所以模型越准 = 比特烧得越少 = 文件越小。

Step 3：算术编码（真正干活的人）

算术编码器拿到模型给出的概率分布 + 正确答案，不断缩小区间，最后产出一个压缩比特流。解压时反过来：从比特流 + 模型的概率分布恢复出原始字节，精确到 bit 级别，无损。

速度为什么这么慢？

纯自回归跑完 100MB 要 ~28 小时，作者用了两个技巧把时间压到可接受的量级：

1. KV Cache — 生成新字节时只需要计算那一个 token 的 key/value 并追加，不用每次重算注意力
2. Seed 文件 + 并行流 — 把文件切成 100 个独立块，100 个压缩/解压流同时跑，在模型里 batch 执行

这样训练 ~20-30 分钟，压缩 ~45 分钟，解压 ~45 分钟（AMD 7800XT 单卡）。

模型架构速览：

三、实测结果：看完你就知道为什么 HN 吵翻了

100MB NYC 出租车 CSV 数据

我替作者补上他没做的传统算法对比（基于常见基准，CSV 场景）：

对于 CSV 这种高度结构化的数据（字段分隔、数值范围固定、时间戳重复），Transformer 捕捉模式的能力碾压了基于滑动窗口的传统算法。14.2 倍的压缩比，传统算法基本做不到。

100MB enwik9 文本切片

对文本数据，Transformer ≈ ZPAQ 的水平，但 ZPAQ 几秒就压完了，Transformer 要 45 分钟。而人类最强的通用文本压缩器 CMIX v19 在完整 enwik9 上能压到 0.89 bpb，还遥遥领先。

核心洞察：

• 🟢 CSV/结构化数据：Transformer 碾压传统算法，压缩率是 zip 的近 4 倍
• 🟡 文本数据：打平 ZPAQ，但慢了 100 倍不止
• 🔴 速度：是现阶段最大的硬伤，45 分钟解压 100MB 完全不具备实用价值

四、HN 评论区炸了锅：五个核心争论

争论一：「Fabrice Bellard 七年前就做过了」

最高赞评论来自 userbinator，一句话暴击：

Fabrice Bellard may have been the first to do this, 7 years ago.

他说的是 NNCP（Neural Network Compression），Fabrice Bellard（就是写 FFmpeg、QEMU 那个神人）在 2019 年就用 Transformer+LSTM 做无损压缩。NNCP v3.3 在完整 enwik9 上压到了 0.853 bpb，距离 CMIX（0.892 bpb）已经无限接近。而且 NNCP 是用纯 C 写的，不需要 PyTorch，效率完全不在一个量级。

NNCP 的 enwik8 成绩：

作者 spidy__ 的回应倒也坦诚：“Yeah yeah, I just found the idea kinda interesting so wanted to implement it”。有 HN 用户帮他说话：「Keep exploring and writing (please?)! Love seeing people explore… even after Fabrice Bellard had a go at it.」

不过也有人不买账，pentaphobe 怼道：

Hope this isn’t too spicy a take, but I find it a bit disingenuous to use language that implies invention (and with no mention or citation of previous work), only to switch to dismissive language when someone notes a predecessor who you’ve apparently already heard of.

这种"致敬 vs 原创"的张力在 HN 上很常见。不过说实话，如果你只看 NNCP 的 Python v2 版本（2021 年），那确实只是 RNN/LSTM 路线，而 pym-particles 用的是纯 Transformer + 并行流，工程思路还是有区别的。

争论二：「能不能用集成学习（bagging）提压缩率？」

SubiculumCode 提了个机器学习从业者都会想到的问题：

I’m sure someone’s tried to overfit a bunch of transformers for compression like this, then bag them to see how well it does?

gwern 的回答直接判了死刑：

Ensembling is not compute or parameter-efficient, so compression per se is a terrible application. This is related to why people train ever larger LLMs like 1 10t-parameter LLM, rather than 100 GPT-3-scale LLMs.

换句话说：堆模型能压得更小？当然能。但你训练 10 个 Transformer 的算力已经够你训练一个更大的模型了，压缩效率（bits / 算力成本）反而下降。在压缩这个场景下，参数效率是最重要的指标，集成学习的边际收益极低。

争论三：「随机数据到底能不能压缩？」

这是本线程最热闹的副讨论，几位用户你来我往争了好几层。

起因是有人提出"用圆周率的前 100MB 数字做基准文件"，然后话题就跑偏了：

• branc116（讽刺）：“Compressor: Output an empty file. Decompressor: find first 100M digits of pi, print them. Compression ratio of 0!”

• saulpw：“random digits aren’t compressible though?”

• SV_BubbleTime（争议极大）：“Random digits are compressible though. Random data does not mean it does not match a pattern in your dictionary.”

• gnabgib（纠正）：“No… they’re not. Do you understand random or compression?”

• IncreasePosts（关键辨析）：“Over infinite runs, you can’t compress random data, but that doesn’t mean any finite string of random digits is incompressible”

• saulpw（终结论断）：“That’s like a teenage ‘I am very smart’ thinking. If it’s encrypted it’ll also appear random and therefore not be compressible, but you have to encode every byte exactly.”

这个讨论其实触及到了一个深刻的问题：信息论里的 Kolmogorov 复杂度。理论上，一段「真正随机」的数据不可压缩——它的 Kolmogorov 复杂度等于自身长度。但一段「看起来随机」的数据（比如加密后的内容），有可能只是你还没找到描述它的更短程序。

这段争吵其实也解释了为什么 pym-particles 在 CSV 上效果这么好：CSV 根本不随机，全是结构。

争论四：「Stable Diffusion 能不能把图片压到 50 字节？」

whacked_new 搬出了 HN 经典段子。2022 年 stavros 写过一篇著名的讽刺文章：用 Stable Diffusion 的 img2prompt 把图片转成文字提示词，然后收端再用这个提示词生成图片。他把这个「压缩算法」命名为 STAV（Stable Transcription and Artistic Validation）。

效果？500KB 的 JPEG 可以被"压缩"成 50 字节的文本提示词。唯一的小问题是——它不是无损的。原文嘲讽道：“There are some minor kinks that need to be worked out, such as the fact that each image takes around a day to generate on mobile, but this is more than acceptable in certain domains.”

这就像：看一部电影 → 写一本小说 → 再根据小说拍一部新电影。压缩比完美，复现度随缘。

userbinator 给了灵魂点评：

While clearly satirical, it’s definitely quite thought-provoking from various angles including the basis of information, representation of data, and even copyright.

whacked_new 把这事和 Kolmogorov 复杂度联系起来——“It’s like calling gzip but instead of compression level you choose kolmogorov complexity level”。这句话其实点透了神经压缩的本质：你不是在压缩数据，你是在用神经网络逼近这个数据的最短描述。

争论五：「Google 能不能把神经压缩塞进 Chrome？」

Could Google use LLMzip to compress HTML massively and ship it alongside Chrome?

这个想法乍一看挺诱人：把一个大模型的压缩权重随浏览器分发，所有网页传输都用神经压缩，大幅提升压缩比，省流量。

作者 spidy__ 给出了冷静的回答：不现实。 100MB 解压要 45 分钟，网页加载要等这么久，用户早跑光了。而且神经压缩的模型是文件专属的——你为某个 HTML 文件训练的 900KB Transformer，对其他 HTML 文件完全没用。你不可能为互联网上每个网页都训练一个专属模型。

但换个角度看，如果有足够快的推理硬件（专用 NPU？），且模型能在文件间共享权重（类似 NNCP 的做法），那"浏览器内置神经压缩解压器"并非完全不可能——只是需要推理速度快 1000 倍才行。

五、一件关联工具：LMCache

本次讨论中关联出现的一个项目是 LMCache。虽然它本身跟文件压缩没关系，但它是 HN 社区同期关注的热门工具。

LMCache 是一个开源 KV Cache 管理层，无缝集成 vLLM / SGLang / TensorRT-LLM 三大主流推理引擎，让 LLM 推理时的 KV Cache 命中率大幅提升。

它的核心逻辑很简单：

1. 你向模型发送请求，LMCache 把生成的 KV Cache 存下来
2. 下次有相似的请求（比如同一个长 System Prompt），直接复用缓存，跳过重复计算
3. 支持跨请求、跨会话的缓存共享

从「用算力换空间/速度」的角度，LMCache 和神经压缩有共通之处：都是在用存储/缓存来减少重复计算，核心矛盾都是「存储成本 vs 计算成本」的权衡。

GitHub Stars 8,200+，PyPI 月下载 115K+，社区 900+ 人。对于做 LLM 推理部署的同学值得关注。

六、所以这到底有什么用？

诚实地说，短期没有任何实用价值。 45 分钟解压 100MB 在任何实际场景下都不成立。

但它的价值在于另一件事：用硬数据证明了「神经网络压缩 = 用算力 × 模型容量换压缩率」这条等式在结构化数据上确实成立。

几个值得关注的方向：

1. CSV / 日志 / 时序数据归档：如果你有海量结构化数据需要长期冷存储，且不介意花 45 分钟解压一次，那 14 倍的压缩比的确诱人。每 TB 数据可以省出 ~90% 的存储成本。

2. 硬件加速后的可能性：作者的 7800XT 推理 45 分钟，如果用 H100 + Flash Attention + 算子融合，10 分钟以内不是梦。再过两代 GPU，也许就降到 2-3 分钟了。

3. 专用神经压缩芯片：这跟视频编解码的路径很像——H.264 刚出来的时候软解都卡，后来有了硬件解码器就普及了。神经压缩会不会也走这条路？

4. 从单文件过拟合到领域模型：pym-particles 目前是每文件训练一个专属模型。NNCP 的做法更聪明——在大语料上预训练一个通用预测模型，然后微调到具体文件。这样压缩/解压就不需要从零训练了，速度会快得多。

5. 跟扩散模型的结合：HN 讨论里有人提到用 diffusion model 做压缩（字节级别的扩散生成），作者也表示感兴趣想尝试。这是一个几乎没被探索过的方向。

总结

神经压缩这件事，本质上是用 GPU 算力置换存储成本。这个置换等式现在还不划算——但历史上几乎所有的"不划算"都会随着硬件进步慢慢变成"划算"。视频编解码如此，字体渲染如此，文件压缩或许也不例外。

参考来源

1. pym-particles GitHub 仓库（一手）— https://github.com/samyak112/pym-particles — 项目源码、架构文档（ARCHITECTURE.md）、基准测试结果、实验记录
2. Fabrice Bellard NNCP 官网（一手）— https://bellard.org/nncp/ — NNCP v3.3 压缩基准成绩、论文 PDF、C 实现与 CUDA 版本
3. Hacker News 讨论帖（一手）— https://news.ycombinator.com/item?id=48644463 — 71 条社区讨论，涵盖先驱工作、集成学习、随机数据可压缩性、浏览器部署等
4. Matt Mahoney 大型文本压缩基准（一手）— http://www.mattmahoney.net/dc/text.html — 所有压缩算法在 enwik8/enwik9 上的权威排名
5. Stavros「用 Stable Diffusion 压缩图片」讽刺文章（一手）— https://www.stavros.io/posts/compressing-images-with-stable-diffusion/ — HN 讨论中引用的经典段子，Kolmogorov 复杂度视角
6. LMCache 官网 & GitHub（一手）— https://lmcache.ai/ , https://github.com/LMCache/LMCache — KV Cache 基础设施，8,200+ Stars
7. Hutter Prize — http://prize.hutter1.net/ — 人类知识压缩奖，enwik8 终极基准

延伸阅读

• 🧠 NNCP v2.1 论文 (bellard.org) — Fabrice Bellard 的神经网络压缩技术论文，了解神经压缩的 SOTA 思路
• 📊 Matt Mahoney’s Text Compression Benchmark — 全球文本压缩算法的奥运会排行榜，看 CMIX 如何以 0.89 bpb 霸榜
• 🎮 The Hutter Prize — €500,000 悬赏：把 1GB 的 enwik9 压缩到比目前最好成绩还小 1%。神经压缩是唯一的希望吗？