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 预热、编码器训练、持续预训练、再到监督微调——总计约 3500 亿 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 价码，都是这项能力建造成本的第一张可信报价单。