文章介绍了Amazon提出的CompLLM技术，一种创新的“段内软压缩”方法，旨在解决大模型在处理长上下文时面临的计算复杂度平方级上升、KV缓存膨胀和注意力稀释等核心难题。CompLLM通过将长文本划分为小段并独立压缩成概念嵌入（CEs），将复杂度从O(N²)降至O(N·S)，显著提升了推理速度（TTFT最高4×）并减少了显存占用（KV cache减半）。实验表明，CompLLM不仅在主流场景下表现优异，在超长上下文中准确率反而超越基线，并能显著提升小型模型的长上下文处理能力，有望成为长上下文处理的新范式。

💡 CompLLM提出“段内软压缩”新范式：该技术将长上下文输入切分成固定长度的短段，并对每个短段独立进行压缩，生成概念嵌入（CEs）。这种方法避免了传统“整块压缩”的全局处理开销，将注意力计算复杂度从与上下文长度N的平方关系（O(N²)）降低到与N的线性关系（O(N·S)），其中S为固定常数。这从根本上解决了长上下文带来的计算瓶颈，使得模型能够更高效地处理超长文本。

🚀 推理速度与显存占用大幅优化：在2×压缩率下，CompLLM实现了首个Token生成时间（TTFT）最高4倍的提升，同时KV Cache占用减少一半，整体生成速度也接近翻倍。这种性能的显著提升对于需要快速响应的长文本应用（如代码助手、RAG系统）至关重要，能够大幅降低部署成本并提升用户体验，使长上下文处理能力不再是大型闭源模型的专属。

📈 超长上下文下准确率反而提升：与传统方法在长上下文中容易出现信息丢失和注意力稀释不同，CompLLM在NarrativeQA、SQuAD、RACE和QuAIL等数据集上的实验显示，当上下文长度超过5万token时，模型的准确率反而显著提升2-3个百分点，普遍优于基线模型。这表明压缩后的表示能够减轻注意力稀释效应，使模型在处理海量信息时更聚焦于关键内容，提升了问答和理解的精度。

🔧 模块化设计与工程灵活性：CompLLM将压缩器设计为一个独立模块，允许在不改变主模型权重的情况下进行适配和训练。这种模块化设计大大增强了工程上的灵活性，使得压缩结果可以被缓存复用，支持线性扩展，并能与FlashAttention、PagedAttention等现有优化技术叠加使用。这降低了长上下文处理的工程门槛，使更多研究者和开发者能够负担和应用长上下文能力。

原创 让你更懂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的段内软压缩

压缩≠掉点，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 个百分点。

这说明压缩后的表示实际上减轻了注意力稀释，使模型在超长上下文中更专注于关键信息。

总结：上下文越长，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」

点击「关注」订阅我们的专栏吧

·

阅读原文

跳转微信打开