Meta 的 Linux 新方案压缩内存 452 倍？ Meta 的工程师在 Linux Plumbers Conference 2026 上抛出一个新方案，名字叫 CRAM，全称 Compressed RAM。官方摘要里的说法很克制：在 TAOBench 和 FIO 基准测试下，它做到了接近原生

💡 你将学到

Meta 的 Linux 新方案压缩内存 452 倍？ Meta 的工程师在 Linux Plumbers Conference 2026 上抛出一个新方案，名字叫 CRAM，全称 Compressed RAM。官方摘要里的说法很克制：在 TAOBench 和 FIO 基准测试下，它做到了接近原生

📜 目录

• 452 倍省掉的是什么
• 写入一碰就崩
• 瓶颈从来不在压缩
• 三个理由让你现在用不上

Meta 的 Linux 新方案压缩内存 452 倍？

Meta 的工程师在 Linux Plumbers Conference 2026 上抛出一个新方案，名字叫 CRAM，全称 Compressed RAM。官方摘要里的说法很克制：在 TAOBench 和 FIO 基准测试下，它做到了接近原生 DRAM 的性能。

但真正刷屏的是另一个数字：读取吞吐 4.89 亿次每秒，ZRAM 只有 110 万次每秒，差 452 倍。

这数字是真的。问题在于，它不能代表你打开一个程序时的体感。

452 倍省掉的是什么

CRAM 的核心，是不再把压缩内存伪装成块设备。Linux 内核有个长期假设：只要能给出一个 struct page，背后就有对应的真实物理内存。但压缩内存设备做不到，它对内核谎报了自己的真实容量，因为一块空间压完能装下多少逻辑内存，取决于数据本身有多好压。

Gregory Price 的解法是绕开这个矛盾：给压缩内存建一个私有的 NUMA 节点，看起来像一颗"影子CPU"上挂着的内存。这样内核可以直接用自己那套内存管理机制来管它，读取时硬件顺手解压，全程不缺页。而 ZRAM 和 zswap 建在 swap 层，程序要读一块压缩数据，得先触发一次缺页中断，从虚拟块设备里取出来、解压，再交给程序。

所以 452 倍省掉的是软件层开销，不是压缩本身的算力。

写入一碰就崩

那篇文章的作者在那张性能图上标注了一个容易被忽略的细节：那张图是对数刻度。也就是说 452 这个数量级，在图上其实已经"几乎不可比"。

真正扎眼的是另一组数字。低写入率下，CRAM 大约是 ZRAM 的 37 倍；一旦写入比例升到 20%，优势塌缩到 5.4 倍。从 452 到 5.4，中间隔了八十多倍。这不是性能衰减，是换了个赛道。

原因很直白：压缩后的数据不能原地改。要改一个字节，得改整块已经被压过的页，所以每次写入都要触发缺页，把这一页迁回原生 DRAM，改完再重新走一遍压缩流程。

这意味着 452 倍只在读多写少的场景里成立：大规模数据扫描、模型推理读权重、只读的配置加载。数据库、编译器、浏览器标签页这类频繁改内存的负载，一分钱红利都吃不到。而且 20% 写入那组测试里包含了内存打满导致的停顿时段，5.4 倍这个数字已经算偏乐观了。

瓶颈从来不在压缩

Gregory Price 在演讲里给了一组更硬的证据。他让人实测了读一页压缩数据到底要花多少时间，结果拆开是这样的：

最理想的情况下，解压的开销不到一次 swap 缺页成本的 10%。也就是说，压缩从来不是瓶颈，缺页才是。

我们默认"内存压缩慢 = 压缩算法费 CPU"，但真正让系统卡住的是中断、上下文切换和内存搬运。也正因为如此，一个完全不动压缩算法、只改内存管理模型的方案，才能拿到几百倍的提升。

Price 的实现比想象中简单。他没有新造一套内存子系统，而是给压缩内存建一个私有的 NUMA 节点，看起来像一颗"影子CPU"上挂着的内存，然后直接复用内核已有的页面迁移、内存气球、内存分层这些机制。他还加了一个叫"Chicken Bit"的开关：一旦 CRAM 忙不过来，就让内核先别往里塞新的分配，避免写入速度跟不上引发的级联崩溃。

三个理由让你现在用不上

一是没有硬件。CRAM 依赖带硬件压缩的内存设备，现实中最可能落地的平台是带内联压缩的 CXL 内存扩展器，你的笔记本和台式机上没有这种东西。

二是没进内核。mm/cram.c 目前只是等待上游审查的提案，没有时间表。

三是容量算不清。压缩比随负载剧烈波动，设备报出来的容量和实际能装下的逻辑内存对不上。演讲里有人当场问，如果按 4:1 压缩比去分配、实际只读，结果会不会变差；还有人指出全局目标压缩比其实更接近 2.5 倍而不是 4 倍。这些问题到演讲结束都没有确定答案，Price 自己也说了目前还没在真实设备上跑过。

这三条加起来足以让大部分人划走。但服务器内存太贵是个真问题，给机器加 DRAM 是笔实在的硬件开支，这也是这套方案从 Meta 出发的原因。

对个人用户来说，CRAM 不是今天的选项。如果你正被内存不足折磨，研究系统自带的压缩内存策略更实际。

Meta 那个工程师做的事，是把一个大家都以为解对了的问题重新问了遍：慢的到底是压缩，还是压缩外面的那一圈？