原创 让你更懂AI的 2025-09-26 17:35 北京
2×压缩→TTFT最高4×，KV ½，长文更准
在大模型的发展历史上，「上下文长度」一直是横亘在研究和应用之间的最大鸿沟之一。
无论是百万行代码的全局理解，还是上百页文档的精确问答，当输入序列超过数万 token，现有 LLM 都会遭遇同样的困境：
计算复杂度随长度平方级上升，推理延迟严重；
KV 缓存膨胀，显存消耗成倍增加；
注意力稀释，模型在长上下文中容易「迷失中间」。
这几乎成了 LLM 的「死穴」——即使 GPT-4o、Claude 3 这样的顶级闭源模型，也要付出极高的工程代价才能支撑 128k 甚至更长的上下文。
Amazon 最新提出的 CompLLM，用一种极为简洁却有效的「段内软压缩」思路，正面击穿了这一瓶颈。在 2× 压缩率下，它让 Time To First Token 提速最高 4×，KV cache 占用减半，而且在超长上下文中反而更准。
这不仅是一篇研究论文，更可能是长上下文处理范式的一次拐点。
论文题目：
CompLLM: Compression for Long Context Q&A
论文链接：
https://arxiv.org/pdf/2509.19228
为什么传统「整块压缩」走不通？
在长上下文研究的语境里，「压缩」几乎是所有人第一时间想到的解法。方法大致分为两类：
硬压缩：通过摘要、删句子、改写提示，来缩短输入。优点是简单直观、可解释，但往往压不狠，一旦删错，就直接丢掉关键信息。
软压缩：通过学习一个映射，把原始 token 嵌入压缩成更短的 latent 向量，再交给 LLM 继续处理。这类方法更灵活，理论上也能压得更狠。
问题在于，绝大多数软压缩方法选择了「整块压缩」：把整篇上下文一次性打包进压缩器。听起来很合理，但实际落地却带来三个致命问题：
1. 复杂度没降下来：虽然输出序列变短了，但压缩器本身仍需全局处理上下文，复杂度依然为 。这就好比：你花了巨大的代价把一本 500 页的书压缩成 50 页，但过程本身就已经把时间耗尽。
2. 压缩结果无法复用：想象你有文档 A 和 B，如果第一次问「比较 A 与 B」，压缩器会生成一个 A+B 的整体表示。但当你下一次想问「比较 A 与 C」时，A 必须重新压缩，无法直接复用。这对真实场景中的 RAG 或代码助手简直是灾难。
3. 信息「越救越稀释」：整块压缩把所有 token 搅在一起，压缩器在有限的 latent 空间里往往难以突出重点。结果是：不是把答案相关信息埋没，就是把注意力分散到无关内容上。上下文越长，这种「注意力稀释」现象越严重。
因此，虽然「整块压缩」在论文里看似可行，但在真实的长上下文应用场景里，它更像是一个「治标不治本」的临时方案。
Amazon 的 CompLLM 正是针对这些痛点提出的：既要真正把复杂度从平方拉直成线性，又要让压缩结果能被缓存和复用，还要避免注意力稀释。这就是它能被称为「击穿死穴」的关键所在。
CompLLM的段内软压缩
复杂度如何从平方降到线性？
在标准 Transformer 中，注意力的复杂度为：
其中 是上下文长度。这让长上下文处理成本高得难以承受。
CompLLM 的突破点在于：将输入划分为长度为 的小段，每段独立压缩为 个概念嵌入（Concept Embeddings, CEs）。于是，整体复杂度变为：
由于 是固定常数（例如 20），复杂度随 呈线性增长，而不是平方增长。
▲ 图1. 段内压缩示意图
注：长文本被切分为多个小段，每段独立压缩后再拼接，从根本上避免全局 的开销。
CEs：把语义打包进更少的向量
在标准输入中，每个 token 对应一个 Token Embedding (TE)。
CompLLM 提出 Concept Embedding (CE)，即将一段 token 的信息「压缩打包」成更少的向量。
映射函数形式化为：
其中：
= 段长（例如 20）
= 向量维度
= 压缩率
例如，当 时，一段 20 个 token 压缩为 10 个 CEs，序列长度减半。
▲ 图2. TE → CE映射
注：多个 token 被映射为更少的概念嵌入，充当语义浓缩包。
训练目标：只对齐答案相关token
压缩器的训练关键在于：只对齐 答案相关 token 的隐状态，而不是强行复现所有 token。
论文的训练损失分三部分公式给出：
(1) 每层的蒸馏损失
其中 是答案 token 的索引集合， 是教师隐状态， 是学生隐状态。
(2) Smooth L1 损失定义
其中 。这确保了小误差时更平滑，大误差时不至于梯度爆炸。
(3) 总体训练目标
这个目标确保压缩后的上下文 与原始上下文 在 答案相关 token 的表征上一致，从而保留了回答所需的关键信息。
▲ 图3. CompLLM训练流程
注：上下文被切段并压缩成 CEs，与问题拼接后输入 LLM，仅在答案相关 token 上计算蒸馏损失。
压缩≠掉点，CompLLM越压越准
2×压缩，4×提速
在推理速度与显存占用方面，CompLLM 展现了巨大优势。在 2× 压缩率下，首 token 的生成速度（TTFT）最高可加速 4 倍，同时 KV cache 的占用减少一半，整体生成速度也接近翻倍。这意味着用户在处理长上下文任务时几乎可以“秒回”，而部署成本也大幅下降。
▲ 图4. CompLLM在2×压缩下实现TTFT提速4×，KV cache减半，生成速度翻倍。
总结：压 2×，首 token 提速 4×，显存压力直接腰斩！
四大数据集：上下文越长，反超越大
在 NarrativeQA、SQuAD、RACE 和 QuAIL 四个数据集上，CompLLM 的表现呈现出鲜明趋势：短上下文时与基线持平，但一旦超过 50k token，模型准确率显著反超，普遍提升 2–3 个百分点。
这说明压缩后的表示实际上减轻了注意力稀释，使模型在超长上下文中更专注于关键信息。
▲ 图5. CompLLM 在四个数据集上，长上下文下准确率显著超过基线。
总结：上下文越长，CompLLM 越能“反杀”基线！
LOFT 128k：小模型也能闯地狱模式
在极具挑战性的 LOFT 128k 基准上，小模型通常表现极差。但 CompLLM 显著提升了小模型的表现，不仅超过无压缩基线，还在部分任务上逼近闭源大模型。
▲ 表1. 在 128k 超长上下文下，CompLLM 让小模型依然保持稳定优势。
总结：CompLLM = 小模型的“长上下文外挂”。
与LLMLingua-2的正面对比
作者还将 CompLLM 与另一种分段压缩方法 LLMLingua-2 进行了对比。在 50k 以下的主流场景，CompLLM 明显更优；在 100k+ 超长上下文下，两者表现接近。这说明 CompLLM 在企业级 RAG 等应用中更具实用性。
▲ 图6. CompLLM 在常见上下文区间稳定优于 LLMLingua-2。
总结：主流场景下，CompLLM 比竞品更稳、更强。
模块化设计，可快速适配
很多方法在论文里看起来很亮眼，但落地时往往要改造模型结构，甚至重新训练整个模型。CompLLM 的不同之处在于：它把压缩器设计成一个独立模块，主模型权重保持冻结，因此在工程上具备较强的灵活性。
需要明确的是，压缩器本身仍需训练或微调，才能与目标模型匹配，并不是零成本开箱即用。但一旦完成适配，就能：
缓存可复用：在 RAG、代码助手等场景里，压缩结果可以重复调用，省算力、省显存；
线性扩展：复杂度 O(N)，只需重压修改部分，不必全量重跑；
正交优化：能与 FlashAttention、PagedAttention 等现有优化手段叠加；
长序列更稳：在超长上下文下，压缩不仅不掉点，还能缓解注意力稀释。
总结：CompLLM 的优势在于模块化 + 高复用，它降低了长上下文的工程门槛，但仍然需要训练压缩器来适配具体模型。
死穴被彻底击穿
长上下文一直被认为是 LLM 最难攻克的“死穴”：平方级的计算复杂度带来算力瓶颈，KV 缓存的爆炸增长拖垮部署成本，而注意力的稀释更让模型在长序列中“迷失中间”。无论是 GPT-4o 还是 Claude 3，哪怕撑起了 128k 上下文，也都付出了极高的代价。
CompLLM 的出现，意味着这道坎第一次被真正“击穿”。它没有依赖新的架构，也没有堆算力，而是用一种极简却有效的方式，把长上下文问题转化为可线性扩展的工程任务：切段、压缩、再拼接。结果是——推理更快、显存更省，而且在超长上下文下答案更准。
更重要的是，这不仅仅是一种加速技巧，而是一种范式转变：未来的长上下文处理，不再依赖“算力豪赌”，而是依靠更聪明的输入处理和信息压缩；长上下文能力，也不再是闭源巨模的专利，而会成为开源社区和小模型都能负担的标配。
CompLLM 让长上下文从“昂贵奢侈品”变成“人人可享的基础能力”。
更多阅读
#投 稿 通 道#
让你的文字被更多人看到
如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。
总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。
PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个，让知识真正流动起来。
📝 稿件基本要求：
• 文章确系个人原创作品，未曾在公开渠道发表，如为其他平台已发表或待发表的文章，请明确标注
• 稿件建议以 markdown 格式撰写，文中配图以附件形式发送，要求图片清晰，无版权问题
• PaperWeekly 尊重原作者署名权，并将为每篇被采纳的原创首发稿件，提供业内具有竞争力稿酬，具体依据文章阅读量和文章质量阶梯制结算
📬 投稿通道：
• 投稿邮箱：hr@paperweekly.site
• 来稿请备注即时联系方式（微信），以便我们在稿件选用的第一时间联系作者
• 您也可以直接添加小编微信（pwbot02）快速投稿，备注：姓名-投稿
△长按添加PaperWeekly小编
🔍
现在，在「知乎」也能找到我们了
进入知乎首页搜索「PaperWeekly」
点击「关注」订阅我们的专栏吧
·