技术深度解析
Sqz的核心是在标准的Transformer推理流程中实施干预。在典型的LLM API调用中，用户提示和对话历史（即上下文）被拼接成一个Token序列。整个序列由模型的自注意力层处理，其计算成本在标准注意力机制中随序列长度呈平方级增长，在FlashAttention等优化变体中呈线性增长。Sqz在序列输入模型之前，插入了一个预处理压缩层，专门对上下文部分进行操作。
该项目的GitHub仓库（`sqz-ai/context-compressor`）概述了一个多阶段、有损压缩算法。首先，它使用一个轻量级嵌入模型将上下文分割成语义连贯的块。随后，聚类算法将具有高语义相似性的块分组。对于每个聚类，算法会选取或合成一个具有代表性的“范例”块，同时将聚类内的方差和位置关系信息编码成紧凑的元数据标签。最终压缩后的上下文由这些范例及其元数据组成，从而形成一个显著缩短的Token序列。在生成过程中，模型关注的是这个压缩后的表示。一个后处理步骤可选择性地利用元数据来“解压缩”或细化对原始、被省略上下文中具体细节的引用。
关键的技术挑战在于最小化压缩上下文中的*灾难性遗忘*——确保在追求效率的同时，不会丢失关键且独特的细节。据报道，Sqz采用了强化学习反馈循环，压缩算法根据下游模型在使用压缩上下文与完整上下文进行验证任务（例如问答）时的表现来获得奖励。
开发团队分享的初步性能数据说明了其中的权衡：
| 上下文长度 (Token) | 压缩比 | MMLU分数变化 | 预估成本降低 |
|---|---|---|---|
| 4,096 | 1.0x (基线) | 0.0% | 0% |
| 4,096 | 1.5x | -0.8% | ~33% |
| 4,096 | 2.0x | -2.1% | ~50% |
| 32,768 | 1.0x (基线) | 0.0% | 0% |
| 32,768 | 2.0x | -1.5% | ~50% |
| 32,768 | 3.0x | -4.7% | ~66% |
*数据解读：* 表格揭示了一个引人注目的效率边界。在中等压缩比（1.5x-2x）下，在MMLU等广泛知识基准测试上的准确性损失极小（<2%），而成本节约却非常可观。这表明，对于那些整体理解比完美回忆每个细节更关键的应用场景，该技术极具可行性。在超长上下文（32k Token）场景下，收益更为显著，而这正是成本负担最重的领域。
关键参与者与案例研究
Sqz项目诞生于一个日益关注推理效率的生态系统，对OpenAI、Anthropic和Google等模型提供商主导的叙事构成了挑战。这些巨头一直在上下文长度上竞争（Claude 3的200K，GPT-4 Turbo的128K），但将成本视为原始Token数量的函数。Sqz及类似方法，如`Mem0`记忆管理系统或针对上下文专家混合模型（MoE）的研究（例如受`JEPA`启发的架构），代表了对这种定价模式的自下而上、软件驱动的攻击。
Anthropic的总裁Daniela Amodei经常强调让AI变得“有益、诚实、无害”的重要性，同时也强调可扩展且负担得起。尽管Anthropic也在投资模型效率，但Sqz的外部压缩层提供了一条与供应商无关的路径，可应用于Claude的API流。同样，像Perplexity AI这样严重依赖长上下文检索与合成的初创公司，自然是采用或开发类似压缩技术以改善其单位经济性的天然候选者。
以GitHub Copilot Enterprise为例。其价值主张依赖于理解整个代码仓库。以当前费率，为每个查询处理一个10万Token的代码库在财务上是不可持续的。像Sqz这样的工具，作为中间件集成后，可以通过识别重复模式、标准库调用和相似函数结构来压缩相关代码上下文，可能在不损害代码建议质量的情况下，将有效上下文减少一半。
| 解决方案 | 方法 | 目标 | 关键优势 | 关键局限 |
|---|---|---|---|---|
| Sqz | 有损语义压缩 | 上下文窗口 | 供应商无关，直接节省成本 | 信息丢失风险，增加延迟 |
| OpenAI o1 | 搜索增强推理 | 模型架构 | 推理准确性高 | 专有技术，无直接上下文压缩 |
| Anthropic Claude 3 | 大原生窗口 (200K) | 基础模型 | 简单，保真度高 | 充分利用成本高昂 |
| vLLM + PagedAttention | 优化的KV缓存管理 | 推理服务器 | 内存使用高效 | 不减少计费Token数量 |
| Mem0 | 外部记忆系统 | 长期记忆/上下文 | 可扩展记忆管理 | 非直接压缩，系统复杂性 |