Long Context on JJ's Blog

📝 LongCodeZip: Compress Long Context for Code Language Models - ASE'25

Thu, 06 Aug 2026 00:00:00 +0000

LongCodeZip: Compress Long Context for Code Language Models

Conference: ASE 2025

Paper: https://arxiv.org/abs/2510.00446

Github: https://github.com/YerbaPage/LongCodeZip

Authors: Yuling Shi, Yichun Qian, Hongyu Zhang, Beijun Shen, Xiaodong Gu

Abstract

代码大模型在仓库级补全、模块总结和跨文件问答中，通常需要读取远超单个函数的上下文。直接把整个仓库送入模型不仅带来更高的推理延迟、显存和 API 费用，还可能因为 lost-in-the-middle 现象让真正有用的信息淹没在长上下文中。最直接的检索增强生成（RAG）虽然能够选取与问题相似的代码，却容易漏掉变量名和表面语义都不相似、但在执行逻辑上不可缺少的依赖。

LongCodeZip 是一个 training-free、model-agnostic、plug-and-play 的长代码上下文压缩框架。它把压缩拆成两个层次：

Coarse-grained compression：以函数或类为单位，使用指令条件下的近似互信息 AMI 排序，优先保留能帮助模型理解当前任务的代码实体；
Fine-grained compression：在保留下来的长函数内部，根据逐行困惑度变化切分语义块，再通过自适应预算和 0/1 背包选择最有价值的代码块。

这种设计同时利用了代码的层次结构和任务相关性。论文在 Long Code Completion、Long Module Summarization 与 RepoQA 三类任务上评估 LongCodeZip，在最高 5.6× 有效压缩率下仍能维持甚至提高任务性能，并显著降低生成阶段的时间与额外显存开销。

1. Motivation

1.1 Long Code Context 的实际代价

仓库级任务所需要的信息往往分散在不同文件、类和函数中。随着上下文长度增加，会同时出现四类问题：

计算代价增加：标准全注意力的计算量随序列长度近似二次增长；
部署成本增加：更长的 KV Cache 占用更多显存，闭源 API 也按输入 token 计费；
有效性下降：无关代码会稀释模型注意力，长上下文并不必然优于经过筛选的上下文；
窗口截断：当仓库代码超过上下文窗口时，简单截断可能恰好删除关键依赖。

因此，长代码压缩的目标不是机械地减少 token，而是回答两个问题：哪些函数与当前指令真正相关？一个相关函数内部又应该保留哪些连续代码块？

📝 SWE-Pruner Pro: The Coder LLM Already Knows What to Prune

Thu, 06 Aug 2026 00:00:00 +0000

SWE-Pruner Pro: The Coder LLM Already Knows What to Prune

Status: arXiv v1, 2026-07-20

Paper: https://arxiv.org/abs/2607.18213

Github: https://github.com/Ayanami1314/swe-pruner-pro

Authors: Yuhang Wang, Yuling Shi, Shaoqiu Zhang, Jialiang Liang, Shilin He, Siyu Ye, Yuting Chen, Kai Cai, Xiaodong Gu

Abstract

Coding Agent 在真实仓库中解决问题时，会不断调用 cat、grep、ls、python 等工具。工具输出不仅可能一次包含数百行内容，还会作为历史消息在后续轮次中被重复送入模型。真正决定修复方案的通常只是其中一小部分代码、错误信息或文件路径，其余内容却持续占用输入 token、显存和推理时间。

以往的上下文剪枝大致有两条路线：通用压缩方法根据困惑度、语法结构或检索相似度选择内容；SWE-Pruner 一类任务感知方法则额外部署一个评分模型，并要求 Agent 每轮写出描述当前信息需求的 Goal Hint。它们有一个共同点：都在 Agent 外部重新构造“哪些内容重要”这一信号。

SWE-Pruner Pro 的核心观察是：Agent 在阅读工具输出并准备下一步行动时，其最后一层隐藏状态已经编码了每行内容与当前任务的相关性。 因此，系统无需再调用独立模型，只需在冻结的 Agent backbone 上挂接一个小型分类头，将已有隐藏状态转换为逐 token 的保留概率，再通过行内多数投票得到 keep/prune 决策。一个由工具输出行数索引的长度感知嵌入，使短输出更保守、长输出更积极地压缩。

论文在 Qwen3-Coder-Next 与 MiMo-V2-Flash 两个开放权重 backbone、四个多轮 benchmark 上进行评测。SWE-Pruner Pro 在所有六个只读任务设置中都降低了总 token，最高节省 39.4%；在 MiMo-V2-Flash 的 SWE-Bench Verified 上，Resolve Rate 提高 3.8 个百分点。部署方面，把约 18M 参数的 head 放入 SGLang 推理引擎后，16 条轨迹回放中的聚合剪枝开销约为生成时间的 15.0%。

📝 Long-Context Modeling with Dynamic Hierarchical Sparse Attention for Memory-Constrained LLM Inference - ICML'26 Spotlight

Fri, 10 Jul 2026 00:00:00 +0000

Long-Context Modeling with Dynamic Hierarchical Sparse Attention for Memory-Constrained LLM Inference

Conference: ICML'26 Spotlight

Paper: https://arxiv.org/abs/2510.24606

Github: https://github.com/xiongsiheng/DHSA

Abstract

Transformer Attention 的时间和显存开销随上下文长度平方增长，限制了长上下文 LLM 在有限显存设备上的部署。虽然长上下文 Attention 通常具有明显稀疏性，但显著 token 的位置会随任务和输入变化。Sliding Window、A-shape 和固定 Block-Sparse 等静态模式无法充分适应这种输入相关的稀疏分布；部分动态方法又依赖预定义模板或启发式规则。

论文提出 Dynamic Hierarchical Sparse Attention（DHSA）。DHSA 保持 LLM backbone 冻结，根据每层的 query/key 表征在线预测稀疏模式。方法首先使用轻量级边界预测器将序列划分为可变长 chunk，然后计算 chunk-level similarity，并将高分 chunk 展开为 token-level key index。稀疏注意力后端只对被选中的 token 执行精确 causal attention。

在 Needle-in-a-Haystack、LongBench 和 RULER 上，DHSA 在低 token density 下保持接近 Dense Attention 的准确率。在效率方面：

相同 prefill 成本下，相比 Block-Sparse 获得约 12%–20% relative accuracy gain；
128K context、6.25% token density 下，attention kernel 相对 FlashAttention-2 加速约 10.66×；
LLaMA-3.1-8B 4-bit 在单张 RTX 3090 24GB 上可以处理 100K context，而 Dense Attention 无法在该显存限制下运行；
LongBench 上平均 TTFT 从 Dense FA2 的 3.28 秒降低到 1.88 秒。

1. Introduction

长上下文能力使 LLM 能够处理长文档问答、代码仓库分析、历史记录总结和长时间 Agent 交互。然而，标准 Attention 需要计算所有 query-key pair：