原文链接： Compression is prediction — Annie Sexton, ngrok
本文是对原文的中文解读，不是逐句翻译。原文包含一组很直观的交互演示，建议在读完本文后打开原站体验。
这篇文章最重要的一句话，就是标题本身：压缩就是预测。
这听起来有些反直觉。压缩通常让人想到 ZIP、gzip 或 Brotli，LLM 则让人想到聊天、写作和编程。两者看似毫不相关，但它们在底层都面对同一个问题：
根据已经看到的上下文，下一个符号最可能是什么？
如果预测得准，真正出现的符号就可以用更少的比特表示；如果预测得差，就必须付出更多比特。压缩器想让文件更小，语言模型想让下一个 token 的预测更准，最终优化的其实是同一类量。
压缩的关键不是删除，而是发现冗余
文章先区分了“精简”和真正的压缩。代码压缩工具会删除空格、注释，缩短变量名；这能让文件变小，却主要是在丢弃机器不需要的信息。
无损压缩更关心的是冗余。例如，一串连续重复的字符可以从：
AAAAAAAAABBBBCCDAAADDDDDDDDD写成：
A9B4C2D1A3D9按 8 位 ASCII 计算，原始字符串需要 224 bits，游程编码后只需要 96 bits，缩小了约 57%。它之所以有效，不是因为随意删掉了内容，而是因为“连续重复”这条规律让原始信息可以被更短地描述。
这也揭示了压缩的本质：找出数据中的结构，用一套更短的描述替代原始数据，同时确保能够无损还原。
一个现代压缩器的三个部分
原文把现代压缩工具粗略拆成三个“器官”：
- 变换（transform）：重新排列或预处理数据，让冗余更容易被发现。变换本身不一定让数据变小，有时甚至会暂时变大。
- 模型（model）：估计每个符号出现的概率。这里的符号可以是字符、数字、token，也可以是二进制片段。
- 熵编码器（entropy coder）：接收模型给出的概率，把数据编码成最终的比特流。
真正决定压缩上限的，往往不是最后那个编码器，而是中间的模型。熵编码器负责把概率尽可能高效地兑换成比特，但如果概率估计本身很差，它也无能为力。
可以把两者的关系简单理解为：
上下文 → 概率模型 → 每个符号的概率 → 熵编码器 → 压缩比特流模型负责“猜”，编码器负责“按猜得有多准来收费”。
算术编码：一段数据为什么能变成一个数字
为了说明概率怎样变成更短的编码，文章使用了算术编码。
假设要编码字符串 ABABAAC。其中 A 出现 4 次，B 出现 2 次，C 出现 1 次，因此可以把 [0, 1) 这个区间按概率切成三段：
- A：4/7，约占 57.1%
- B：2/7，约占 28.6%
- C：1/7，约占 14.3%
编码第一个 A 时，把范围缩到 A 对应的区间；编码下一个 B 时，再在这个新区间里按相同比例找到 B 的子区间；如此反复，直到整串字符都被处理完。
最终会得到一个非常窄的区间。只要选择其中任意一个数，并让解码器拥有同一套概率分布，就能一步步反推出原始字符串。原文示例选择了 0.3876953125：原字符串按 ASCII 需要 56 bits，而这个数字只需 10 bits。
这里最值得理解的不是这个具体数字，而是区间缩小的方式：
- 高概率符号占据更宽的区间，编码它所需的精度较低，因此需要的比特更少。
- 低概率符号只占很窄的区间，必须用更高精度才能定位，因此需要的比特更多。
一个事件的理想编码成本可以写成：
bits = -log₂(p)概率越高，成本越低。概率为 1 时，成本趋近于 0；一个极不可能发生的事件，则会非常昂贵。
信息熵不是固定天花板，它取决于你的模型
信息熵描述的是：在某个概率分布下，平均每个符号至少需要多少比特。对于无损压缩，这是一条理论下限。算术编码早已能非常接近这个边界，所以今天的熵编码器更多是在比速度和内存，而不是谁还能凭空提高很多压缩率。
但这里有一个关键细节：熵取决于你使用的概率分布。
如果模型只统计全局字符频率，它知道英文中字母 U 的概率大约是 2.8%。按 -log₂(p) 计算，编码一次 U 大约需要 5.158 bits。
如果模型知道前一个字母是 Q，情况就完全不同了。在这个上下文中，U 的概率接近 99.9%，编码成本也随之降到约 0.001 bits。
这就是上下文模型的价值。order-1 模型看前一个符号，order-2 看前两个，依此类推。原文用 TO BE OR NOT TO BE 演示：加入一个符号的上下文后，压缩结果就减少了一半以上。
换句话说，更长、更有效的上下文让概率分布更有把握，也让数据更容易被压缩。
LLM 与压缩器真正相遇的地方
LLM 每生成一个 token，都会根据已有上下文给出下一批候选 token 的概率分布。聊天时，系统会从这个分布中选择一个 token，追加到上下文，然后继续预测。
用 LLM 做无损压缩时，流程稍有不同：我们不需要让模型“选择”下一个 token，因为真实的下一个 token 已经存在于待压缩数据中。模型只需要给出概率，编码器再根据它分配给真实 token 的概率计算比特成本。
- 如果模型认为真实 token 很可能出现，压缩成本很低。
- 如果模型自信地猜错，把概率给了别的 token，真实 token 的编码成本就会迅速增加。
这与训练 LLM 时最常见的交叉熵损失是同一件事的两种表述。训练想降低真实 token 的负对数概率；压缩则把这个负对数概率直接解释为需要支付的比特数。
原文引用了 Google DeepMind 2023 年的论文 Language Modeling Is Compression，其核心观点正是：语言建模与压缩可以被看成同一过程的两种视角。
文章还给出了一个直观对比。在压缩狄更斯的一段名句时：
| 概率模型 | 压缩后大小 | 占原文比例 |
|---|---|---|
| order-1 模型 | 434 bits | 24% |
| GPT-2 | 176 bits | 10% |
即使是今天看来已经很老的 GPT-2，仅靠更强的上下文预测，也能显著超过简单的字符模型。
为什么我们没有用 LLM 替代 gzip
数学上相通，不代表工程上应该直接替换。
现实中的压缩目标并不是“不惜代价把文件做到最小”，而是在计算、内存、延迟和兼容性约束下尽可能缩小数据。
浏览器解压 gzip 或 Brotli 的成本很低。若改用一个数 GB 的 LLM，服务端和客户端都必须拥有同样的模型，还要为每个 HTML、CSS、JavaScript 或 JSON 响应执行昂贵推理。为了省几 KB 而传输并运行数 GB 的模型，显然得不偿失。
因此，LLM 作为压缩器更像一个思想实验和评测工具，而不是 HTTP 压缩的现实替代品。它告诉我们“预测能力有多强”，却没有自动解决模型体积、计算成本和解码速度的问题。
我的解读：这篇文章真正值得带走的三点
第一，预测能力可以用压缩来检验。 如果一个模型真的理解某类数据的结构，它就应该能给真实的后续内容分配更高概率，从而用更少比特编码。压缩率提供了一种不依赖主观评分的模型能力视角。
第二，上下文的价值可以被量化。 “给模型更多上下文”并不天然有益；只有当上下文让真实后续变得更可预测时，它才降低了信息成本。无关或误导性的上下文反而可能让模型更自信地猜错。
第三，模型能力与系统价值不是一回事。 一个更强的模型可能产生更小的理论编码，但如果模型本身巨大、推理缓慢、难以在两端同步，它就不是更好的压缩系统。这与许多 AI 产品的现实相同：离线指标更好，不等于总成本、延迟和可维护性也更好。
所以，“LLM 是压缩器”不是说模型只会背诵训练数据，也不是说应该拿 ChatGPT 替代 ZIP。它更准确的含义是：一个模型对世界规律掌握得越好，就越能用上下文缩小未来的可能性空间；而缩小可能性空间，正是预测与压缩共同在做的事。
继续阅读原文及交互演示：Compression is prediction