Free()：在只读写推理模型中学习遗忘 Free(): Learning to Forget in Malloc-Only Reasoning Models
通过可插拔LoRA模块让推理模型主动清理冗余上下文，实现可持续长链推理
前置知识
推理模型（Reasoning Models）
推理模型是一类通过在推理阶段生成大量'思考token'（thinking tokens）来增强问题解决能力的大语言模型，典型代表包括 Qwen3 系列、DeepSeek V3 等。与传统模型直接输出答案不同，推理模型会在回答前进行详细的逐步推理过程，类似于人类的思考过程。这种通过扩展测试时计算（test-time compute scaling）来提升性能的范式，已经被证明在数学推理、代码生成等复杂任务上非常有效。
本文研究的核心问题——推理token过多反而导致性能退化——正是推理模型面临的关键瓶颈，理解推理模型的工作机制是理解本文动机的前提。
KV Cache（键值缓存）
KV Cache 是 Transformer 模型在自回归生成过程中存储历史 token 的 Key 和 Value 矩阵的缓存机制。每生成一个新 token，模型需要计算其与所有历史 token 的注意力分数，KV Cache 避免了重复计算，是 LLM 推理加速的核心技术。但随着生成长度增加，KV Cache 线性增长，占用大量 GPU 显存，成为长序列推理的主要瓶颈。
论文提出的 Free()LM 方法通过清理冗余上下文，可以将 KV Cache 使用量降低 45.6%，理解 KV Cache 机制有助于理解这一效率提升的意义。
LoRA（Low-Rank Adaptation）
LoRA 是一种高效的模型微调技术，通过在预训练模型的权重矩阵旁添加低秩分解矩阵 $\Delta W = BA$ 来实现参数高效微调，其中 $B \in \mathbb{R}^{d \times r}$，$A \in \mathbb{R}^{r \times k}$，$r \ll \min(d, k)$。LoRA 的优势在于：（1）只训练极少量参数（通常不到原模型的 1%）；（2）可以通过 merge/unmerge 操作在推理时动态切换能力；（3）多个 LoRA 模块可以独立训练后组合使用。
Free()LM 的核心组件 Free-Module 就是一个 LoRA 适配器，通过动态 merge/unmerge 来切换推理模式和清理模式，理解 LoRA 的 merge/unmerge 机制是理解本文方法的关键。
Chain-of-Thought (CoT) 过度思考
CoT 过度思考是指推理模型在解决问题时生成了大量冗余、重复或无效的推理步骤，这些步骤不仅浪费计算资源，还会污染上下文，最终导致模型陷入重复循环或产生错误答案。研究表明，当思考 token 占上下文窗口的 70-90% 时，进一步推理通常不会带来性能提升，反而可能导致性能退化。这种现象在 o1 风格的长链推理模型中尤为严重，单个问题可能消耗 10k-100k+ token。
过度思考是本文要解决的核心问题，Free()LM 的目标就是在推理过程中动态识别并清理这些冗余的思考步骤。
内存管理中的 malloc/free 类比
在 C/C++ 等编程语言中，malloc() 用于动态分配内存，free() 用于释放不再使用的内存。如果只 malloc 不 free，就会导致内存泄漏，最终耗尽系统资源。论文将这个类比引入 LLM 推理：标准 LLM 只会不断'分配'新的思考 token（malloc-only），但没有机制来'释放'过时的信息，导致上下文窗口被冗余信息填满，最终'崩溃'。
这个类比是论文的核心隐喻，理解它有助于把握论文的创新思路——为 LLM 推理补齐缺失的 free() 操作。
研究动机
推理模型通过生成更多思考 token 来增强问题解决能力，但研究发现了一个严重的性能退化问题：当思考 token 数量过多时，模型性能不升反降。作者使用 Qwen3-8B（32k 上下文窗口）在 AIME 24&25 的 480 条推理轨迹上验证了这一现象：当思考 token 超过 16k 时，退化率急剧上升；在到达上下文限制的 31 个实例中，26 个（84%）已经陷入重复循环；到 48k token 时退化率达到 100%，推理完全崩溃。更严重的是，对于需要超长推理的任务（如 HLE 中需要 80k+ token 的案例），标准的 Qwen3-235B-A22B 模型准确率直接降至 0%。这种现象的根本原因是标准 LLM 的'malloc-only'架构缺陷：它们只能被动积累所有推理步骤，没有机制来清理过时信息，导致上下文被冗余 token 污染。
本文的目标是本文的具体目标是为推理模型引入一个内在的'自我遗忘'能力，使其能够在推理过程中动态识别并清理冗余的上下文片段，从而维持一个紧凑、无噪声的推理状态。具体而言，作者希望：（1）打破'malloc-only'的架构限制，补齐内存管理中的 free() 操作；（2）在不损害模型通用能力的前提下提升长链推理性能；（3）实现跨模型架构的泛化能力，使训练好的清理模块可以即插即用地应用于不同模型。
与已有工作不同的是，现有的解决方案存在明显不足：（1）启发式压缩方法如 H2O 和 ThinkCleary 基于注意力分数的 token 剪枝，会破坏推理链的连贯性，导致模型陷入退化循环——在 Qwen3-8B 上，H2O 使平均 pass@1 从 44.24% 降至 42.05%，ThinkCleary 更降至 37.66%，且两者都未能减少响应长度；（2）上下文学习（ICL）方法，即通过提示让模型自我纠正或使用 Gemini-2.5-Pro 作为外部清理器，效果同样有限——在 Qwen3-8B 上仅获得约 1% 的提升；（3）KV Cache 压缩方法如 StreamingLLM、H2O 等主要面向吞吐量优化，其有损压缩可能导致'注意力分散'，在精确推理任务上反而降低性能。本文的独特切入角度是：将上下文清理视为一个需要显式训练的能力，通过设计专门的训练流程（数据合成 + 奖励机制）来训练一个精准的清理模块，而非依赖启发式规则或提示工程。
核心方法
Free()LM 的整体思路可以这样理解：想象一个学生在做数学题时，草稿纸上写满了计算过程。随着时间推移，草稿纸上会积累很多已经用过的中间步骤和走错的路径。普通推理模型就像一个只能往草稿纸上写字但永远不会擦除的学生，最终草稿纸会写满，甚至覆盖之前写的内容。Free()LM 则是一个聪明的学生，他有一个'橡皮擦'（Free-Module），能够定期停下来，识别哪些内容已经不需要了，把它们擦掉，保持草稿纸整洁。技术上，Free()LM 通过在标准 LLM 骨干模型上插入一个轻量级的 LoRA 适配器（Free-Module），通过动态 merge/unmerge 这个模块，在'推理模式'和'清理模式'之间切换。推理模式下模型等价于原始骨干模型，专注于生成推理 token；清理模式下模块被激活，扫描上下文并输出结构化的剪枝命令来删除冗余片段。
Free()LM 的核心创新在于两个层面：第一，概念层面——首次将'主动遗忘'作为推理模型的核心能力进行系统性研究，而非将其视为缺陷或副作用；第二，技术层面——设计了一个基于锚点的高效剪枝机制。与现有方法的本质区别在于：（1）与 KV Cache 压缩方法（如 H2O、SnapKV）不同，Free()LM 进行的是语义级剪枝而非 token 级剪枝，能够识别整个冗余推理段落并一次性删除；（2）与 ICL 方法不同，Free()LM 通过显式训练获得清理能力，而非依赖提示工程；（3）与控制输出长度的方法（如 O1-Pruner）不同，Free()LM 在推理过程中动态清理上下文，而非在输出端控制长度。具体而言，清理模块输出 JSON 格式的剪枝命令，其中 prefix 和 suffix 是定义待删除区间的字符串锚点。这种锚点设计使得模块只需生成少量命令 token 就能删除很长的冗余片段，极大提高了效率。
方法步骤详情
Free()LM 的方法分为推理流程和训练流程两部分。推理流程如下：（1）推理阶段：模型正常生成推理 token，Free-Module 处于未 merge 状态，与原始骨干模型等价；（2）触发清理：每生成 $L_{clean}$ 个推理 token（超参数，主实验设为 5000），自动触发一次清理循环；（3）清理阶段：将 Free-Module merge 到骨干模型，模型停止推理，扫描上下文识别冗余片段，输出 JSON 格式的剪枝命令；（4）执行剪枝：外部 Python 执行器解析 JSON，通过正则表达式删除目标区间；（5）恢复推理：unmerge Free-Module，恢复推理模式。恢复推理时采用'重预填充'策略：复用未改变前缀的 KV Cache，仅对改变的后缀进行严格重预填充。训练流程如下：（1）数据合成：从 DeepMath-103k 随机选取 1000 条轨迹，使用 Gemini-2.5-Pro 作为 oracle 生成候选剪枝操作。采用顺序剪枝策略——将轨迹切分为 1k token 的片段，每个片段的清理基于已清理的历史前缀而非原始上下文，模拟实际推理中的碎片化记忆状态；（2）奖励机制：对每个候选操作，在原始上下文和清理后上下文上分别执行 K=8 次独立推理 rollout，仅当剪枝后上下文准确率不低于原始准确率时才保留该高质量实例；（3）最终从约 8000 个候选实例中筛选出 6648 个高质量训练实例用于训练 Free-Module。
技术新颖性
Free()LM 的技术新颖性体现在多个方面：首先，'学习遗忘'这一概念本身就具有颠覆性——传统观点认为更多信息总是更好，但本文证明了在长链推理场景下，学会丢弃信息比积累信息更重要。其次，训练数据的构建方式极具创新性：采用顺序剪枝策略模拟实际推理中的记忆状态，使得训练数据反映了模型在实际推理中会遇到的碎片化上下文，而非简单地在完整上下文上训练。第三，奖励机制的设计非常精巧——通过 8 次并行 rollout 来评估剪枝质量，只有当剪枝后上下文不降低准确率时才保留该训练实例，这种'不伤害就是好的'的奖励标准避免了过度剪枝。第四，锚点式剪枝命令的设计（prefix + suffix 定义删除区间）使得模型可以用极少的命令 token 删除大量冗余内容，这是'深度剪枝'现象的技术基础——Free()LM 比 Gemini 生成更短的响应但准确率更高，正是因为其剪枝更精准，不需要重新生成被错误删除的内容。最后，Free-Module 的即插即用特性——8B 模型训练的模块可以直接用于 235B 甚至 DeepSeek-V3.2-Speciale 等异构架构——表明该模块学到了通用的上下文清理能力，这为'通用上下文剪枝服务'的部署策略提供了可能。
实验结果
Free()LM 在多个维度上展示了令人信服的实验结果。首先，在准确率提升方面：在 Qwen3-8B 上，Free()LM 平均 pass@1 达到 48.14%，相比 vanilla 的 44.24% 提升了 +3.90%，相比 Gemini ICL 基线的 45.55% 也提升了 +2.59%。在 Qwen3-30B-A3B 上，平均 pass@1 从 57.47% 提升至 62.30%（+4.83%）。在最大的 Qwen3-235B-A22B 上，平均 pass@1 从 69.18% 提升至 70.47%（+1.29%）。其次，在'深度剪枝'现象方面：Free()LM 在 Qwen3-8B 上的平均响应长度仅为 13.8k token，比 Gemini 基线的 15.8k 还短 12.7%，但准确率却更高——这表明 Free()LM 的剪枝更精准，能够精确识别真正的冗余而不会误删有用信息。第三，在解决长链推理崩溃方面：在 HLE 任务中，标准 Qwen3-235B-A22B 在超过 80k token 的超长推理轨迹上准确率降至 0%，而 Free()LM 将其恢复到约 50%，同时将上下文压缩了约 45%，成功将 100k+ 的轨迹压缩到模型最舒适的 40k-70k 区间。第四，在跨模型泛化方面：使用 Qwen3-8B 训练的 Free-Module 应用于 DeepSeek-V3.2-Speciale 时，在 IMOAnswerBench 上实现了 +2.3% 的 pass@1 提升和 45.99% 的 token 压缩率，证明了通用上下文清理能力的可迁移性。第五，在系统效率方面：在 Qwen3-235B-A22B 的 HLE 测试中，Free()LM 实现了 45.6% 的 KV Cache 内存节省（从 6.14GB 降至 3.34GB），但代价是 56.4% 的延迟增加。最后，启发式压缩方法的失败也值得关注：H2O 和 ThinkCleary 在 Qwen3-8B 上不仅未能提升准确率，反而导致性能下降（分别 -2.19% 和 -6.58%），且未能减少响应长度，原因是启发式剪枝破坏了推理链，导致模型陷入退化循环。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| AIME 24&25（数学竞赛推理） | pass@1 | 75.00% (Qwen3-8B), 87.92% (Qwen3-30B), 93.13% (Qwen3-235B) | 71.67% (Qwen3-8B), 83.33% (Qwen3-30B), 92.29% (Qwen3-235B) | +3.33% (8B), +4.59% (30B), +0.84% (235B) |
| BrUMO25（数学竞赛推理） | pass@1 | 72.50% (Qwen3-8B), 85.42% (Qwen3-30B), 94.58% (Qwen3-235B) | 69.58% (Qwen3-8B), 82.92% (Qwen3-30B), 91.67% (Qwen3-235B) | +2.92% (8B), +2.50% (30B), +2.91% (235B) |
| HMMT（数学竞赛推理） | pass@1 | 49.58% (Qwen3-8B), 70.42% (Qwen3-30B), 84.58% (Qwen3-235B) | 38.75% (Qwen3-8B), 60.83% (Qwen3-30B), 85.00% (Qwen3-235B) | +10.83% (8B), +9.59% (30B), -0.42% (235B) |
| BeyondAIME（数学竞赛推理） | pass@1 | 45.88% (Qwen3-8B), 62.25% (Qwen3-30B), 69.75% (Qwen3-235B) | 42.38% (Qwen3-8B), 56.50% (Qwen3-30B), 69.00% (Qwen3-235B) | +3.50% (8B), +5.75% (30B), +0.75% (235B) |
| HLE（人类最后考试，文本子集） | pass@1 | 5.38% (Qwen3-8B), 9.82% (Qwen3-30B), 18.03% (Qwen3-235B) | 4.59% (Qwen3-8B), 8.99% (Qwen3-30B), 16.13% (Qwen3-235B) | +0.79% (8B), +0.83% (30B), +1.90% (235B) |
| IMOAnswerBench（国际数学奥林匹克） | pass@1 | 40.50% (Qwen3-8B), 58.00% (Qwen3-30B), 62.75% (Qwen3-235B), 85.87% (DeepSeek-V3.2) | 38.50% (Qwen3-8B), 52.25% (Qwen3-30B), 61.00% (Qwen3-235B), 83.54% (DeepSeek-V3.2) | +2.00% (8B), +5.75% (30B), +1.75% (235B), +2.33% (DeepSeek) |
| BBH/MMLU-Pro/MMLU-STEM/GPQA-Diamond（通用推理） | 准确率 | 82.89%/75.58%/92.55%/61.36% | 82.86%/75.57%/92.29%/59.41% | 持平，无显著退化，GPQA 略有提升 |
局限与改进
尽管 Free()LM 取得了显著成果，但仍存在若干局限性：首先，延迟开销较大——Free()LM 在 Qwen3-235B-A22B 上引入了 56.4% 的延迟增加（从 353.2s 到 552.3s），主要来自三个方面：解码 free() 命令的时间、删除后重预填充的延迟、以及偶尔过度剪枝后重新生成信息的时间。虽然作者提出通过 KV Cache 直接剪枝策略（Strategy 2）可将开销降至约 20%，但该策略尚未在 vLLM 中实现。其次，剪枝间隔 $L_{clean}=5000$ 和最大迭代次数 50 是固定的超参数，缺乏自适应机制——不同任务和不同模型可能需要不同的清理频率，过频的清理可能损害推理连贯性，过少则无法有效控制上下文膨胀。第三，训练数据的 oracle 是 Gemini-2.5-Pro，其清理能力本身就有局限（ICL 方法仅提升约 1%），这意味着训练数据的质量上限受限于 Gemini 的能力。第四，论文在 HLE 超长轨迹上的结果虽然令人印象深刻（从 0% 恢复到约 50%），但作者自己也承认样本量有限，不能断言这是'智能提升'，只能说是'维持推理能力'。第五，Free()LM 目前只在数学推理任务上进行了全面评估，在代码生成、多轮对话、长文档理解等其他长链推理场景中的效果尚不明确。最后，模型需要额外的训练成本来训练 Free-Module，虽然参数量不大（LoRA），但仍需要设计和执行专门的数据合成和奖励评估流程。
独立分析的弱点
从独立分析的角度，Free()LM 存在以下可改进的弱点：（1）清理模式的触发机制过于简单——当前采用固定间隔 $L_{clean}=5000$ 触发清理，没有考虑推理内容的实际复杂度和冗余程度。改进方向可以是设计自适应触发机制，例如监控推理轨迹的重复度或困惑度，仅在检测到冗余信号时才触发清理。（2）剪枝命令的表达能力有限——当前的 prefix+suffix 锚点设计虽然高效，但只能删除连续区间，无法处理分散在不同位置的多个小片段冗余。改进方向可以是支持更复杂的剪枝模式，如多区间删除或条件删除。（3）清理模块的训练依赖外部 oracle（Gemini-2.5-Pro），而这个 oracle 本身的表现就有限（ICL 方法仅提升约 1%），这可能成为 Free-Module 能力的天花板。改进方向可以是采用更强的 oracle 或多 oracle 集成，或者探索自我改进的训练循环。（4）缺乏对清理质量的在线监控——模型无法判断某次清理是否成功，也无法在清理失败时回滚。改进方向可以是引入清理质量评估模块，在清理后快速验证上下文质量。（5）重预填充策略在每次清理后需要重新计算被修改部分的 KV Cache，增加了不必要的计算开销。如果 KV Cache 直接剪枝策略（Strategy 2）能够实现，延迟开销可以大幅降低。
未来方向
基于 Free()LM 的研究成果，可以延伸出多个有价值的未来研究方向：（1）通用上下文剪枝服务——作者提出的将 Free-Module 作为'通用上下文剪枝服务'的部署策略非常有前景，未来可以探索如何将 Free-Module 与多种推理框架（如 vLLM、TensorRT-LLM）深度集成，实现即插即用的上下文管理。（2）自适应清理策略——研究如何根据任务复杂度、模型状态和上下文质量动态调整清理频率和清理强度，而非使用固定的 $L_{clean}$ 参数。（3）跨模态扩展——当前工作仅关注文本推理，未来可以探索将 free() 机制扩展到多模态推理场景，如视觉推理、代码生成等。（4）与长上下文技术的结合——Free()LM 与上下文窗口扩展技术（如 YaRN、Ring Attention）是正交的，两者结合可能产生更大的收益。（5）清理模块的持续学习——研究如何让 Free-Module 在部署后根据实际使用反馈持续改进，形成在线学习的闭环。（6）理论分析——深入分析为什么'深度剪枝'（更短但更准确）能够成立，建立关于信息冗余和推理质量之间关系的理论框架。（7）将 free() 机制内化到模型架构中——而非作为外部 LoRA 模块，探索如何在 Transformer 架构层面原生支持选择性遗忘。
复现评估
从复现角度来看，Free()LM 的复现条件相对明确但有一定门槛。代码和模型方面：论文已在 GitHub 开源代码（论文中标注了 Code 链接），并在 Hugging Face 发布了训练好的模型（Models 链接），这大大降低了复现难度。数据方面：训练数据基于 DeepMath-103k 数据集，这是一个公开可用的数据集；数据合成过程使用 Gemini-2.5-Pro 作为 oracle，需要 API 调用成本；最终筛选出 6648 个高质量训练实例。算力方面：论文在两个 8xH20 节点上进行推理（Tensor Parallelism TP=16），使用 vLLM v0.8.5 作为推理后端，这对于复现完整实验需要相当大的计算资源，但 Free-Module 本身的训练（LoRA 微调）算力需求相对较小。难度方面：数据合成流程（顺序剪枝 + 奖励机制）描述清晰，但实现细节（如 Gemini prompt 设计、正则表达式匹配的边界情况处理）可能需要一定调试。评估方面：使用的数学推理基准测试（AIME、BrUMO、HMMT 等）均为公开数据集，评估流程（从 boxed 提取答案）也已标准化。总体而言，复现 Free()LM 的核心结果是可行的，但完整的跨模型泛化实验（特别是 DeepSeek-V3.2-Speciale 的实验）可能需要更多计算资源。
论文图表
左图展示了标准 LLM 被动积累 token 导致推理过程最终崩溃（退化）的现象——当思考 token 超过 16k 时退化率急剧上升，到 48k 时达到 100%。右图展示了 Free()LM 通过周期性识别和剪枝冗余推理步骤，主动维护紧凑、无噪声的状态，实现可持续的长链推理。
这张图是论文的核心动机图，直观展示了'malloc-only'架构的根本缺陷以及 Free()LM 的解决思路，是理解全文的关键起点。