arXiv 2606.09659·2026-06-09 👁️ — 次瀏覽

Latent Context Language Models：以 350B token 訓練的 encoder-decoder 壓縮擊敗 KV-cache 剪枝——16 倍壓縮下 GSM8K 仍有 81%，基線方法掉到 0%

Ang Li, Sean McLeish, Haozhe Chen, Nimit Kalra, Zaiqian Chen, Artem Gazizov, Venkata Anoop Suhas Kumar Morisetty, Bhavya Kailkhura, Harshitha Menon, Zhuang Liu, Brian R. Bartoldson, Tom Goldstein, Sanae Lotfi, Micah Goldblum, Pavel Izmailov

一支橫跨 Goldstein、Goldblum 與 Izmailov 團隊的 15 人作者群，把 encoder-decoder 上下文壓縮重新做到規模化：0.6B 編碼器加 4B 解碼器，以約 350B token 訓練，刷出速度／記憶體／準確率的新帕雷托前沿，模型與程式碼全數開源。

arxiv.org/abs/2606.09659 ↗

發表了什麼

一篇題為 「End-to-End Context Compression at Scale」（arXiv:2606.09659，cs.CL，2026 年 6 月 8 日提交）的論文，把一個多數研究者早已歸檔為「試過了、太失真」的想法——encoder-decoder 上下文壓縮——重新拿出來，並追問：如果不再把它當成外掛小技巧，而是用預訓練等級的規模認真訓練，會發生什麼事？這支 15 人作者群橫跨 Tom Goldstein、Micah Goldblum 與 Pavel Izmailov 的研究圈，共同作者還包括 Zhuang Liu、Sanae Lotfi、Brian Bartoldson、Bhavya Kailkhura 與 Sean McLeish。

動機是每個長上下文部署都會撞上的問題：KV cache 隨上下文長度線性成長，到了數十萬 token 的量級，瓶頸不再是權重而是 cache 本身。現有的 KV-cache 壓縮方法不是大幅犧牲品質，就是光壓縮一條長提示就要耗費可觀的時間與算力。作者的答案是 Latent Context Language Models（LCLMs）：用一個小型編碼器把長 token 序列映射成短得多的潛在嵌入序列，解碼器讀的是潛在向量而非原始 token。

運作方式

架構刻意保持簡單。一個 0.6B 參數的編碼器（由 Qwen3-Embedding 初始化）以固定 1024-token 視窗讀取上下文，將每 N 個 token 平均池化成單一潛在向量；一個 MLP adapter 把這些潛在向量投影到 4B 參數解碼器（由 Qwen3-4B-Instruct 初始化）的嵌入空間。團隊訓練了 1:4、1:8 與 1:16 三種壓縮比的變體。

真正承重的部分是訓練預算。每個模型都走過四階段流程——adapter 暖機、編碼器訓練、持續預訓練、再到監督式微調——總計約 3,500 億 token，訓練資料交錯壓縮與未壓縮區塊，並加上輔助重建目標。過去的壓縮器論文頂多用幾十億 token 微調；這是這套配方第一次被推到真正的持續預訓練規模，也正是作者把貢獻定位為「at scale」而非新機制的原因。

數據

面對一排強勁的 KV-cache 壓縮基線——SnapKV、KVzip、FastKVzip、Expected Attention 與 Attention Matching——論文在通用任務表現、壓縮速度與峰值記憶體三個維度上報告了新的帕雷托前沿：

• 首 token 延遲（TTFT）： LCLMs 避開了 cache 剪枝方法仍須支付的完整 prefill 成本，在 RULER 類設定的高壓縮比下，TTFT 加速最高達 8.8 倍。
• 資訊密集任務： 在 16 倍壓縮（94% 的 token 被移除）下的 GSM8K，LCLMs 仍保有 81% 準確率，而競爭方法崩跌到 0%。cache 剪枝丟掉它判定不重要的條目；訓練出來的壓縮器則學會把算術留下來。
• 記憶體： 在 H200 上，16 倍壓縮下從 128K 到 512K token 的峰值記憶體幾乎持平，且該方法可擴展到 100 萬 token 的上下文，而基線方法直接記憶體耗盡。

論文還有一個前瞻性的代理實驗：解碼器先略讀壓縮上下文，再呼叫 EXPAND 工具取回任何需要逐字內容的原始文字區塊，在大海撈針任務上大幅提升精確字串比對的準確率。所有東西都已釋出——模型在 Hugging Face（latent-context），程式碼在 GitHub（LeonLixyz/LCLM）。

為什麼建造者該在意

這篇論文的實務主張是：上下文壓縮要成為一種訓練出來的能力，而不是事後的 cache 手術，才會真正有效。這個區別對三類人都重要。如果你經營長上下文服務，TTFT 與記憶體數字同時打擊你最痛的兩條成本曲線，因為編碼器很小、批次處理便宜。如果你在做代理，「略讀後 EXPAND」的模式是一個貨真價實的新記憶層級：比重讀原始歷史便宜，比文字摘要忠實，且能按需無損還原。如果你在訓練模型，這個結果可以解讀為：投入 350B token 能買到剪枝方法花再多錢也買不到的 16 倍上下文折扣——而你的平均上下文長度每翻一倍，這筆交易就更划算一次。

誠實的保留意見：釋出的解碼器只有 4B 參數，還沒有人證明這套配方在前沿規模模型上成立；訓練成本是真實的，且由製作壓縮器的一方承擔；GSM8K 在 16 倍壓縮下的數字雖然驚人，但只是一個任務族。0% 基線的比較也對這個設定有利，因為 cache 剪枝方法從來就不是為 94% 的逐出率設計的。

實務者筆記

如果我今天經營一套長上下文服務堆疊，在相信這些結果能遷移之前，我會先用自己的真實流量，把釋出的 1:4 模型跟現有的 SnapKV 式管線對打——但這個實驗很便宜，因為權重與程式碼都是公開的，解碼器也只有 4B。我會盯的指標不是平均準確率，而是失敗模式：剪枝的失敗方式是無聲地丟掉事實，訓練出來的壓縮器的失敗方式是把事實弄糊，而 EXPAND 工具模式給了第二種失敗一條復原路徑，第一種失敗則沒有。對代理建造者，我會現在就原型化壓縮記憶，即使原始日誌仍留作真值來源：把舊回合存成潛在向量、按需展開，並量測代理實際需要展開的頻率。那個比率會告訴你真正的壓縮預算是多少。

被低估的角度

這篇論文安靜的含義是經濟層面的，不是架構層面的。KV-cache 剪枝把壓縮留在服務層，每個供應商在每次請求都要付一次成本，永遠如此。LCLMs 把成本移到訓練端，付一次，然後攤提到所有未來的請求——這正是當年讓指令微調擊敗提示工程的同一種轉移。如果這套配方能隨解碼器規模放大，「上下文壓縮」就不再是一項推論優化，而會變成一種可以出貨、版本化、微調的模型能力。值得追蹤的開放問題是：前沿實驗室會採用 encoder-decoder 的拆分，還是把壓縮器折進模型本體；無論哪條路，這篇論文公布的 350B token 價碼，都是這項能力建造成本的第一張可信報價單。