在記憶體供應緊張、DRAM 成本居高不下的背景下，Meta 工程師正為 Linux 開發一套名為 CRAM（Compressed RAM）的壓縮記憶體方案，目標是在不犧牲資料存取效率的前提下，讓壓縮後的記憶體仍可被系統視為可用資源。這套方案瞄準的，是既有壓縮機制在存取粒度上的根本限制，不過需注意的是，相關成果目前仍屬提案與技術探索階段，尚未進入 Linux 核心主線。
成本壓力下的現實考量
對 DevOps 與基礎設施團隊而言，記憶體向來是最難以彈性調配的資源之一。伺服器採購中，DRAM 往往佔去相當比重的硬體預算，而工作負載的記憶體需求卻持續上升。當容量不足時，傳統解法無非兩種：直接加購記憶體，或依賴核心層級的壓縮與換頁機制。
Meta 團隊在既有研究中指出，DRAM 是昂貴的，而新方案的出發點正來自這項成本現實——如果能在記憶體層級以軟體加硬體的方式壓縮資料，就有機會以更低的單位成本換取更大的有效容量。這對需要在有限硬體上撐起大規模服務的機構來說，是有意義的方向；對一般伺服器與雲端環境的管理者而言，這也代表記憶體成本的壓力確實可能催生新的技術選擇。
CRAM 的關鍵差異：存取粒度
CRAM 與既有方案最大的不同，在於壓縮後資料的存取粒度。傳統 ZRAM 或 zswap 在壓縮資料後，往往必須以較大單位（如頁級）進行交換或解壓，這意味著一旦需要存取其中一小段資料，就得拉動整個頁的處理流程。
CRAM 則嘗試讓壓縮後的記憶體仍保持快取線（cacheline）或位元組級別的可尋址性，並透過硬體加速負責壓縮與解壓運算。換句話說，系統不必「先解壓再使用」，而是直接對壓縮後的資料結構進行定位與存取，將壓縮從一項換頁層級的權宜措施，轉變成記憶體本身可用的一種表示方式。這項存取粒度的差異，才是 CRAM 與 ZRAM、zswap 最值得追蹤的地方，而非單純的性能數字。
性能宣稱仍待驗證
根據 Phoronix 於 2025 年 11 月的報導，Meta 團隊表示 CRAM 在性能上可接近原生 DRAM 的速度。但這項數字目前僅來自 Meta 自行提供的測試結果，尚無獨立第三方基準測試可供交叉驗證。
在核心合併狀態方面，CRAM 目前仍屬提案階段，相關程式碼與討論尚未進入 Linux 主線。對系統管理員而言，這意味著現階段不宜將 CRAM 納入任何容量規劃或效能預期中。若後續進入合併審查流程，或有獨立測試出現，勢必值得追蹤。
實務側欄：今天就該調校的 ZRAM / zswap
在 CRAM 進入核心之前，ZRAM 與 zswap 仍是 Linux 環境下最直接可用的記憶體壓縮工具。
- ZRAM 建立一個以記憶體模擬的區塊裝置，可直接取代磁碟式 swap 分區。適合無持久性交換區需求的伺服器。
- zswap 則是 swap 遷移前的壓縮快取層，位於記憶體與磁碟 swap 之間，能延長較快存取路徑的命中時間。
- 壓縮演算法選擇（如 zstd vs. lz4）會直接影響 CPU 與記憶體取捨：zstd 壓縮率較高，適合 CPU 相對充裕的主機；lz4 處理速度快，適合延遲敏感的場景。
- 壓縮比上限（
zswap.max_pool_percent）需依實際記憶體壓力調整，避免壓縮層本身佔用過多記憶體。 - 建議定期監控
zswap_stored_pages與 swap 使用率，以判斷壓縮機制是否真正發揮作用，而不是靜默失效。
相關程式碼與技術提案目前仍可在上游討論串追蹤，本則報導引述 Phoronix 的整理內容；正式合併前，任何性能宣稱都應視為初步結果，而非可依賴的基準。
在記憶體供應緊張、DRAM 成本居高不下的背景下，Meta 工程師正為 Linux 開發一套名為 CRAM（Compressed RAM）的壓縮記憶體方案，目標是在不犧牲資料存取效率的前提下，讓壓縮後的記憶體仍可被系統視為可用資源。這套方案瞄準的，是既有壓縮機制在存取粒度上的根本限制，不過需注意的是，相關成果目前仍屬提案與技術探索階段，尚未進入 Linux 核心主線。
成本壓力下的現實考量
對 DevOps 與基礎設施團隊而言，記憶體向來是最難以彈性調配的資源之一。伺服器採購中，DRAM 往往佔去相當比重的硬體預算，而工作負載的記憶體需求卻持續上升。當容量不足時，傳統解法無非兩種：直接加購記憶體，或依賴核心層級的壓縮與換頁機制。
Meta 團隊在既有研究中指出，DRAM 是昂貴的，而新方案的出發點正來自這項成本現實——如果能在記憶體層級以軟件加硬件的方式壓縮資料，就有機會以更低的單位成本換取更大的有效容量。這對需要在有限硬件上撐起大規模服務的機構來說，是有意義的方向；對一般伺服器與雲端環境的管理者而言，這也代表記憶體成本的壓力確實可能催生新的技術選擇。
CRAM 的關鍵差異：存取粒度
CRAM 與既有方案最大的不同，在於壓縮後資料的存取粒度。傳統 ZRAM 或 zswap 在壓縮資料後，往往必須以較大單位（如頁級）進行交換或解壓，這意味著一旦需要存取其中一小段資料，就得拉動整個頁的處理流程。
CRAM 則嘗試讓壓縮後的記憶體仍保持快取線（cacheline）或位元組級別的可尋址性，並透過硬體加速負責壓縮與解壓運算。換句話說，系統不必「先解壓再使用」，而是直接對壓縮後的資料結構進行定位與存取，將壓縮從一項換頁層級的權宜措施，轉變成記憶體本身可用的一種表示方式。這項存取粒度的差異，才是 CRAM 與 ZRAM、zswap 最值得追蹤的地方，而非單純的性能數字。
性能宣稱仍待驗證
根據 Phoronix 於 2025 年 11 月的報導，Meta 團隊表示 CRAM 在性能上可接近原生 DRAM 的速度。但這項數字目前僅來自 Meta 自行提供的測試結果，尚無獨立第三方基準測試可供交叉驗證。
在核心合併狀態方面，CRAM 目前仍屬提案階段，相關代碼與討論尚未進入 Linux 主線。對系統管理員而言，這意味著現階段不宜將 CRAM 納入任何容量規劃或效能預期中。若後續進入合併審查流程，或有獨立測試出現，勢必值得追蹤。
實務側欄：今天就該調校的 ZRAM / zswap
在 CRAM 進入核心之前，ZRAM 與 zswap 仍是 Linux 環境下最直接可用的記憶體壓縮工具。
- ZRAM 建立一個以記憶體模擬的區塊裝置，可直接取代磁碟式 swap 分區。適合無持久性交換區需求的伺服器。
- zswap 則是 swap 遷移前的壓縮快取層，位於記憶體與磁碟 swap 之間，能延長較快存取路徑的命中時間。
- 壓縮算法選擇（如 zstd vs. lz4）會直接影響 CPU 與記憶體取捨：zstd 壓縮率較高，適合 CPU 相對充裕的主機；lz4 處理速度快，適合延遲敏感的場景。
- 壓縮比上限（
zswap.max_pool_percent）需依實際記憶體壓力調整，避免壓縮層本身佔用過多記憶體。 - 建議定期監控
zswap_stored_pages與 swap 使用率，以判斷壓縮機制是否真正發揮作用，而不是靜默失效。
相關代碼與技術提案目前仍可在上游討論串追蹤，本則報導引述 Phoronix 的整理內容；正式合併前，任何性能宣稱都應視為初步結果，而非可依賴的基準。