在大模型的长思维链Chain-of-ThoughtCoT推理场景中一个很实际的矛盾是推理过程越长回答质量和可解释性通常越好但 token 消耗、接口延迟和上下文占用也同步上涨。很多团队在接入大模型 API 后会立刻遇到这类问题同一道数学题直接回答可能只花几十个 token要求“一步一步思考”后可能花几百甚至上千个 token而如果只是简单截断推理文本准确率又会明显下降。为什么不能像删废话一样删掉 CoT 里某些句子答案在于我们并不清楚哪些 token 真正支撑了最终答案。标题为 “Every Token Leaves a Ripple in the Stream of Thought: Eliciting Model-Internal Token Saliency for Chain-of-Thought Compression” 的论文把这个问题向前推了一步不要把 CoT 当成普通文本去压缩而应该回到模型内部去观察每个 token 在层与层之间留下的“涟漪”。如果某个 token 在模型内部计算流中对后续表示和最终答案产生了显著影响那么它在推理中的价值就比表面看起来更大。这类工作的核心目标是用“模型自己知道哪个 token 重要”来指导 CoT 压缩而不是靠人工编写的文本规则。这篇文章适合几类读者正在做大模型推理优化、希望降低 token 成本和响应延迟的技术同学对模型可解释性、归因分析和思维链研究有兴趣的研究者以及需要在工程中复现“按 token 重要性做裁剪”这类思路的开发者。下面会把论文标题中的关键概念拆开再给出一套可以在小规模实验中落地的原形思路包括最小代码骨架、评测口径、参数取舍和常见坑。1. 为什么 CoT 需要压缩压缩为什么不能只看文本1.1 CoT 的“长”来自推理过程的大段中间表示CoT 的原始价值很好理解让模型把隐式的推理过程显式化。对于一个数学题或逻辑题模型如果只输出最终结果中间任何一步出错都难以定位而如果让模型先生成若干中间步骤再给出结论模型可以在每一步中维持一个更稳定的局部上下文减少因为跳跃式推理带来的误差。工程代价也随之而来。以一次多步问答为例问题小明有 3 个苹果给了小红 1 个又去商店买了 2 个请问现在有几个苹果 不使用 CoT 4 使用 CoT 小明原本有 3 个苹果。 给了小红 1 个后小明剩 3 - 1 2 个。 又买了 2 个后小明有 2 2 4 个。 所以答案是 4。同样一个问题CoT 输出长度可能是直接回答的 5 到 20 倍。如果面对的是代码生成、多跳检索、数学证明或者复杂规划任务推理链可能达到几千 token。对于 token 计量收费的大模型 API 来说这些多出来的 token 会直接换算成成本对于自部署模型来说则对应推理时延、显存占用和吞吐量下降。这里的本质问题是CoT 中很多文本属于“中间状态记录”它们是否都值得进入模型的输出上下文如果某些中间步骤对最终答案没有实质贡献只是把同一个约束换了种说法重复了一遍那么它们被压缩掉是合理且安全的。关键是我们如何判断一个 token 是否“值得保留”。1.2 文本层压不动的高价值 token 与高成本 token 混在一起常规的文本压缩思路是在输出文本上做文章常见手段包括按固定比例截断 CoT 尾部只保留最后一段推理。删除看起来像口头语的 token例如“那么”“接下来”“我们知道”。用正则表达式提取括号、等式、关键实体丢弃叙事性句子。这些方法的共同问题是只看到了文本表面没有看到 token 在模型内部的作用。举例来说“因为 3 - 1 2”里的数字“1”通常会被判定为重要但在某些更复杂的问题里一个看起来不起眼的限定词“只包含偶数”可能才是决定最终答案方向的关键 token。文本层的语法结构无法告诉我们模型内部在计算表示时究竟吸收了多少来自这个 token 的信息。更麻烦的是CoT 是逐 token 生成的。前置 token 会进入后面 token 的注意力上下文因此某些表面上冗余的短语可能已经在计算过程中起到了“记忆锚点”或“状态稳定”的作用。直接删掉它会让后面生成步骤失去一个上下文支点。这也是为什么很多粗暴压缩方案在短文本上效果还好一到长 CoT 就立刻失效。1.3 “思维流中的涟漪”到底指什么论文标题用了一个很形象的比喻每个 token 都在“思维流”中留下一个“涟漪”。这里“思维流”可以理解为模型在处理 CoT 时产生的隐藏状态序列更具体地说是残差流residual stream中不断叠加、修正的信息流动过程。在 Transformer 解码过程中每个 token 的表示会经过多层 block每层又包含 attention 和 feed-forward 计算。当某个 token 的表示被更新时它的影响会沿着注意力权重流向其他位置再通过后续层被放大或抑制。如果我们把整个过程看作一个流动的流场那么每个 token 就是投进水里的石子它不一定改变整体水流方向但会在特定位置产生可测量的一圈圈波纹。“涟漪”不是一个营销比喻它在技术上对应可计算的影响量例如删除某个 token 后后续 token 表示的变化幅度。某一层注意力头对该 token 的依赖强度。某个 token 的 hidden state 经过干预后对最终输出概率的影响大小。这些都可以被量化。论文想表达的核心是token 的真正重要性不应该由人类语法习惯决定而应该由“它在模型内部留下的涟漪大小”决定。把这种内部显著性作为压缩依据会比文本规则更贴近模型真实的计算路径。2. 从题目拆解论文的方法主张内部显著性如何服务 CoT 压缩2.1 Token 在模型内部确实会留下可观测痕迹要理解这类方法先接受一个前提模型的中间表示比最终文本包含更多关于 token 作用的信息。举一个很常见的现象连续两次生成同一道数学题的 CoT模型可能输出不同的措辞但中间隐藏层对关键数值的计算可能是高度一致的。也就是说即使文本层面变了内部计算流中“真正被活跃使用的 token”是相对稳定的。我们可以用“某个 token 被移除后隐藏状态的变化量”来近似它的内部显著性。数学化表达可以是Saliency(token_i) Distance(H_with_token_i, H_without_token_i)其中 H 是某一层或某几层的隐藏状态矩阵Distance 是向量间距离函数例如 L2 距离或 cosine 距离。如果一次性删除 token i模型需要重新前向计算一次得到一个新的隐藏状态它与完整序列的隐藏状态差异越大说明这个 token 对后续计算的影响越大。注意这里有一个重要区分去 token 并不等价于“这个 token 在最终答案里出现了多少次”。一个只在最后答案里出现、却没有参与中间计算的数字它的内部显著性可能很低而一个出现在限制条件里、只出现一次但被多层 attention 反复引用的 token它的内部显著性会很高。前者适合被压缩保留策略覆盖后者必须保留。2.2 CoT 压缩的目标从“缩短字数”变成“保留有效涟漪”一旦我们把压缩对象从“输出文本”变成“内部信息流”压缩策略的设计目标就变了。传统压缩关心的是压缩后文本长度 / 原始文本长度 目标比例而模型内部显著性驱动的压缩关心的是压缩后计算流中保留的有效信息比例足够高 有效信息比例 保留 token 的显著性之和 / 全部 token 的显著性之和也就是说即使保留的 token 数量很少只要这些 token 贡献了大部分“涟漪”模型仍然有机会给出接近原始 CoT 的答案。这种思路最直接的应用是先用完整的 CoT 让模型推理一遍得到结果再计算每个 token 的显著性然后按显著性从高到低保留一部分 token最后让同一个模型只看压缩后的推理过程来重新生成答案。这样得到的压缩 CoT 不是“删句子”而是“保留骨干”。论文题目里的 “Eliciting Model-Internal Token Saliency” 强调的是显著性信息是从模型内部抽取出来的而不是外部词典或规则提供的。2.3 这类方法的一般路线为了便于后续工程实现可以把这类方法拆成五个阶段生成原始 CoT让模型输出完整推理过程。选择目标层决定观察哪一层的 hidden state。计算显著性对每个 token 计算它对模型内部表示或最终输出的影响量。制定压缩策略根据阈值、比例、保序或聚类选出需要保留的 token 集合。重跑答案把压缩后的 CoT 作为新的上下文让模型再输出一次答案并做一致性评估。在真实实现中最贵的阶段是第三步。逐 token 前向计算的时间复杂度是序列长度的线性倍数Token 越多归因计算就越昂贵。因此工业级落地通常会引入近似方法比如只在部分层采样、用梯度估算影响、或者只对关键位置做干预而不是对每个 token 都完整前向。下表把三类快速可见的压缩路线做一个对比方便理解模型内部显著性方案的定位。压缩路线判断依据优点缺点适用场景文本规则压缩词法、句法、停用词速度快、无需模型辅助不理解语义和内部用途对质量不敏感的日志类文本输出概率扰动删除 token 后答案概率变化直接反映最终答案影响计算成本高忽略过程信息需要对最终答案做归因模型内部显著性隐藏状态、注意力、梯度能定位计算链中真正关键 token涉及层选择实现复杂CoT 压缩、思维链摘要、可解释性3. 落地一个 token 显著性驱动的 CoT 压缩原型3.1 实验输入与评测口径在没有获得论文作者开源代码的情况下先不要追求复刻论文级别的完整实验。更合适的路径是先构造一个小规模评测集把核心假设验证清楚内部显著性分数能否用来预测“哪个 token 删除后模型更可能答错”。一个最小评测集可以由三种问题构成数学多步运算数字和运算顺序高度可控。条件约束题题目里有几个条件但只有一个条件真正影响答案。逻辑推理题推理链路较长且中间步骤不能随意删除。每条样本至少记录四个字段question: 原始问题 full_cot: 模型生成的完整思维链 answer: 模型基于完整思维链给出的答案 ground_truth: 标准答案评测口径建议同时看两个指标压缩率 1 - 压缩后 CoT token 数 / 原始 CoT token 数 准确率保持率 压缩后答案正确率 / 完整 CoT 答案正确率在学术论文中还会加入“删除后答案与原答案语义一致性”“关键步骤召回率”等指标。工程落地阶段先把准确率保持率作为主指标即可。3.2 用隐藏状态差分估计 token 显著性下面给出一个实验骨架用来估计某个 CoT 序列中每个 token 的“内部影响力”。这个代码不是论文的官方实现而是为了解释方法思路写的最小示例落地时要根据实际模型结构、显存限制和包版本调整。import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-1.5B-Instruct model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16) tokenizer AutoTokenizer.from_pretrained(model_name) model.eval() def get_hidden_norm(input_ids, target_layer-1): with torch.no_grad(): outputs model( input_idsinput_ids, output_hidden_statesTrue, return_dictTrue ) hidden outputs.hidden_states[target_layer] # 取所有位置的表示向量 return hidden[0] # [seq_len, hidden_dim] def l2_distance(vec_a, vec_b): return torch.norm(vec_a - vec_b, dim-1) def estimate_saliency_by_deletion(question_ids, cot_ids, target_layer-1): full_ids torch.cat([question_ids, cot_ids], dim-1) full_hidden get_hidden_norm(full_ids, target_layer) question_len question_ids.shape[-1] saliency_scores [] # 为减少计算量只遍历 CoT 部分 for rel_pos in range(cot_ids.shape[-1]): abs_pos question_len rel_pos deleted_ids torch.cat( [full_ids[:, :abs_pos], full_ids[:, abs_pos 1:]], dim-1 ) deleted_hidden get_hidden_norm(deleted_ids, target_layer) # 对齐到完整序列长度后求差异这里简化为比较同位置向量 # 更严谨的做法是先做位置对齐或取整体表示差异 diff l2_distance(full_hidden[abs_pos], deleted_hidden[min(abs_pos, deleted_hidden.shape[0] - 1)]) saliency_scores.append(diff.item()) return saliency_scores这个示例的核心思想是逐 token 做“删掉后重新前向”的扰动实验。目标层默认取最后一层 hidden state因为最后一层与输出概率最接近但最后一层未必是最能反映推理结构的位置所以在正式实验里目标层应当成为一个需要比较的变量。需要说明的是逐 token 前向计算非常昂贵。如果原始 CoT 有 500 个 token这个原型要额外执行约 500 次前向计算。它适合小规模分析不适合线上实时调用。工程化时通常会改用更廉价的近似方式例如用梯度乘以嵌入向量来估计敏感性或者使用激活 patching只在少量位置做干预。代码里也可以加一个采样间隔参数只估计每 2 个或每 4 个 token 的显著性以降低计算量。3.3 把显著性分数转成压缩策略拿到每个 token 的显著性分数后可以设计压缩策略。最简单的是 Top-K 保留def compress_cot_by_saliency(cot_tokens, saliency_scores, keep_ratio0.5): sorted_idx sorted( range(len(saliency_scores)), keylambda i: saliency_scores[i], reverseTrue ) keep_count max(1, int(len(cot_tokens) * keep_ratio)) keep_positions set(sorted_idx[:keep_count]) compressed [ token for idx, token in enumerate(cot_tokens) if idx in keep_positions ] return compressed但这个策略有一个明显问题只按分数全局选 token可能会把句子切成碎片导致上下文语义断裂。实际使用中建议在 Top-K 基础上加位置连续性约束也就是当一个位置被保留后相邻几个位置有更高的保留概率。这样压缩结果仍然是一段人类和模型都能理解的连续文本。另一种策略是块级压缩先把 CoT 按句子或语义片段切块计算块内所有 token 显著性之和再对块做保留或删除。块级压缩生成的文本更连贯但控制粒度相对粗token 级压缩更精细却需要处理语义断裂。3.4 最小评测脚本与结果记录表压缩策略准备好后需要做一次统一评测。评测脚本要保证唯一变量是“CoT 内容”模型参数、温度、解码方式都不能变化。def evaluate_compressed(question, compressed_cot, full_cot): prompts { full: build_prompt(question, full_cot), compressed: build_prompt(question, compressed_cot), } results {} for name, prompt in prompts.items(): answer model_generate(prompt) results[name] answer return results记录结果时建议按样本维度保存而不是只保存平均值因为子类别差异非常关键。下表是一个适合填写的记录格式样本 ID问题类型原始 CoT 长度压缩后长度压缩率完整 CoT 答案压缩后答案是否正确备注math_001多步算术41220650%44是关键步骤被保留logic_007约束推理3889775%BA否删除条件 token 导致答案偏移当样本量足够后还可以按问题类型分别统计。最理想的结果不是“所有题都能压 80%”而是“哪些类型的题适合 token 级压缩哪些必须保留完整链路”。这个子类差异才是工程落地时真正需要知道的结论。4. 关键设计点在哪一层、用什么归因、如何定义“保留”4.1 显著性信号来源对比除了逐 token 删除扰动还有很多信号可以表达 token 的内部重要性。选择哪一种取决于你能接受的算力和你能拿到什么样粒度的模型状态。信号来源计算方式优点缺点典型用途输出 logits 一阶梯度对目标 token 概率求输入嵌入梯度实现简单、速度快只反映最终 token 的局部敏感性快速过滤低相关 token隐藏状态差分删除 token 后重算 hidden state能捕捉长程影响多次前向成本高离线归因分析注意力权重汇总统计各层 attention 对 token 的依赖无需额外前向attention 高不等于因果影响大辅助排序激活 patching用干预表示替换某位置表示并观察输出变化能定位因果路径干预方式选择复杂研究推理机制、关键 token 定位层间残差增量计算 token 表示从某一层到下一层的变化幅值无需重跑前向指标较早层语义化程度弱快速筛选候选 token在一个正式实验里建议至少同时记录两层信号一层是中间层或注意力头层面的“结构重要性”一层是最后输出附近的“结果重要性”。两者互证可以降低单点信号带来的噪声。4.2 压缩粒度和保留机制压缩粒度需要和任务目标匹配。token 级精度高可以精确删除不显著 token但可能破坏可读性。短语级以连续短语为最小单元语义保留更好。语句级删除整个中间推理句代价最小但容易误删。事件级把多个 token 聚类为一个“推理事件”再判断事件重要性。保留机制也需要考虑三种情况位置保留token 仍留在原处删除位置留空或用占位符。 重排序保留把高显著性 token 单独拼成一段摘要。 改写保留基于高显著性 token 重新生成更短的推理句。第三种写法其实已经接近“把长 CoT 压缩成更短 CoT”它比 token 删除更自然但需要多一次生成调用成本并不一定低于原始推理。因此论文场景里的压缩通常更关注前两种尤其是位置保留和重排序保留。4.3 影响成本的关键因子对同一套显著性压缩流程来说运行成本和效果主要受以下因子影响因子调大后的影响调小后的影响推荐做法目标层数量信息更全面计算更贵容易漏掉关键路径先固定最后一层再补中间层采样 token 间隔更快可能漏掉重要位置更慢结果更稳定初筛时每 4 个 token 采样一次归因信号粒度更细噪声更高更粗稳定性更好用平滑窗口处理噪声保留比例准确率更稳压缩收益低成本越低风险越高从 70% 开始逐档下降评测任务数量结论更可靠时间成本高过拟合风险高至少覆盖数学、逻辑、规划三类在生产环境里“显著性计算”本身也消耗 token 或算力。如果归因的额外成本大于压缩节省的成本那整个方案就失去了工程意义。所以要在上线前对“单次压缩成本”和“单次推理节省成本”做一次量化对比。5. 从论文原型到工程应用要考虑的问题5.1 计算开销逐 token 扰动不是免费的模型内部显著性方案最容易被人忽视的成本来自归因阶段。最精确的逐 token 扰动需要多次前向计算对于一条 2000 token 的长思维链这个方法可能比原始推理还要慢好几倍。它更适合作为“离线分析工具”或“样本级策略学习器”而不是每次请求都实时执行的线上组件。一个可选的折中流程是用完整 CoT 跑出一批离线样本。在离线环境计算 token 显著性找出每个任务类型的高显著性 token 模式。把显著性结果归纳成可复用的启发式规则或轻量分类器。线上只执行轻量规则不再逐 token 做模型前向。这样做虽然损失了“完全自适应”的能力但把成本控制在大模型 API 能接受的范围内。5.2 压缩比与准确率不是单调关系很多第一次接触该方案的同学默认认为压缩比例越低准确率一定越高。实际上不一定。当压缩比例过高时CoT 被切得太碎模型拿到的上下文可能不足以支撑一个连贯的推理链准确率会出现悬崖式下降。当压缩比例很低时虽然接近原始 CoT但少量被误删的重要 token 仍然可能造成偶发错误。实验时不要只报告一个最优压缩率建议画出一条“压缩率-准确率保持率”曲线并标出下降拐点。举例压缩率 20%准确率 98% 压缩率 40%准确率 96% 压缩率 60%准确率 91% 压缩率 80%准确率 70%对于生产系统最安全的选择是取准确率下降不超过 3 到 5 个百分点的最大压缩率。不要追求极端压缩除非你能接受明显的质量回退。5.3 不同任务、不同模型下的迁移性内部显著性是在特定模型和特定任务上计算出来的它会随着模型系列、模型规模和提示模板变化。在一个 7B 模型上发现的高显著性 token 模式很可能在另一个 70B 模型上不成立在数学题上的模式也很难直接迁移到代码生成任务上。这意味着工程判断很重要模型版本升级后应该重新在离线集上验证压缩策略。任务类别变化后不要沿用旧压缩阈值。如果用 A 模型生成 CoT 做归因但实际生产用的是 B 模型压缩结果未必安全。如果条件允许优先做“相同模型、相同任务模板”下的归因分析把跨模型迁移作为第二步实验。5.4 与 token 用量计费和上下文限制的关系在调用 API 的实际场景里CoT 压缩带来两个直接收益一是减少了提示词和输出的 token 计费量二是降低了对上下文窗口的占用。对于长文本任务如果模型的输出达到上限并出现“输出被截断”“超过输出 token 上限”这类报错压缩 CoT 往往比简单增大 max_tokens 更有效因为后者只是放宽了上限并没有解决上下文稀释和成本膨胀的问题。同时要注意计费口径许多 API 平台的输入 token 和输出 token 单价不同。CoT 通常产生在输出阶段但如果把压缩后的中间结果作为下一轮上下文传入压缩也会影响输入 token 费用。记账时要分别统计输入侧和输出侧的差异不要只看总 token 数的减少比例。6. 常见坑和排查路径6.1 现象显著性分数平淡分不清哪个 token 重要可能原因包括观察层选择不当最后一层可能已经将绝大多数信息编码到少数位置信号计算方式没有对齐位置模型本身对该问题的输出概率非常稳定导致所有 token 的影响都被稀释。检查顺序先检查显著性分数的分布是否存在长尾。比较不同层的分数分布找到区分度最大的一层。改用“删除该 token 后输出正确性是否变化”这个更粗的指标来校验。对分数做平滑窗口避免单 token 噪声。处理建议不要只看绝对值建议使用相对排序而不是原始分数必要时把多个层的归一化分数相加。6.2 现象删除不显著 token 后答案明显崩坏这通常说明“不显著 token”的判断只考虑了局部表示没有考虑组合效应。单个 token 的影响可能很小但它和相邻 token 组合后可能承担了一个完整信息的编码功能。处理建议将压缩单元从 token 提升到短语或短句。在删除前增加组合测试同时删除整组 token观察答案变化。给删除操作加随机噪声判断模型是否本身就处于不稳定状态。保留比例回退 10 到 20 个百分点看崩坏现象是否消失。很多时候答案崩坏不是删除策略的问题而是因为压缩后的 CoT 在语义上出现了断点。连续保留比单纯 Top-K 保留稳定得多。6.3 现象开发环境效果好线上新 prompt 效果差这是典型的任务分布和 prompt 模板漂移问题。离线集里的问题类型可能比较单一线上问题分布广、表述更口语化内部显著性模式不再适用。排查路径对比线上失败样本和离线样本在 CoT 长度、句型结构上的分布。检查模板差异同一问题使用不同的 CoT 引导语显著性分布可能不同。检查模型版本是否一致一个很小的模型版本差异也会改变 token 显著性。在线上增加兜底逻辑当压缩 CoT 生成的答案和完整 CoT 生成的答案不一致时自动回退到完整 CoT。下面把高频问题汇总为一张表便于开发时直接查阅。现象常见原因检查方式处理建议显著性分数噪声大目标层单一或归因方式简单比较多个层和多种归因多信号取交集或加权平均删除后答案崩坏只删 token破坏语义连续性查看压缩后 CoT 的可读性改为短语级或块级压缩高比例压缩反而更好样本太少或评测集偏差检查子类准确率使用分层评测并关注拐点线上效果回退任务分布变化或模型版本变化按周采样线上日志做回归建立小规模回归集定期重算压缩成本高于收益频繁逐 token 扰动统计前向次数和耗时采用离线归因和线上轻量规则7. 复现与实验前可复用清单7.1 开始实验前确认的 10 项做 token 显著性驱动的 CoT 压缩实验之前建议先用下面的清单做一轮准备避免在数据集、模型和评测口径上返工。选定的模型名称和版本已经固定评测全程不改动。解码参数固定为同一个温度、top_p、max_tokens关闭随机性干扰。评测集至少包含 100 条样本并按任务类型分组。每条样本都有独立于 CoT 的标准答案。定义了“答案正确”的判定标准是字符串匹配、数值相等还是语义等价。写出完整 CoT 生成的固定 prompt 模板。确定目标层候选范围至少包含最后一层和一个中间层。确定显著性计算方式明确是删除扰动、梯度还是注意力汇总。确定了压缩粒度和保留策略不能只写 top_p。预计算了逐 token 扰动的最低成本确认运行时间可接受。7.2 实验记录模板完整记录每次实验的配置和结果比多做十组不确定的尝试更有用。每次实验至少记录模型Qwen/Qwen2.5-7B-Instruct 目标层-1 归因方式隐藏状态 L2 差分 压缩粒度token 级 保留比例0.6 保留策略Top-K 相邻 1 token 补全 评测集math_100 / logic_100 / plan_50 压缩率58% 准确率保持率96.7% 失败样本logic_007, plan_023 备注删除条件 token 会产生错误记录模板最好直接存成 CSV 或 JSON Lines方便后续绘制曲线和做回归对比。7.3 下一步可以扩展的方向如果已经从零跑通了内部显著性驱动压缩的流程下一步可以往四个方向扩展将显著性分数与注意力头机制结合分析是哪一个注意力头在传播“关键涟漪”。把压缩后的 CoT 作为训练数据微调一个小模型让模型学会不经过长推理也能解析关键约束。将压缩结果与“如果压缩后答案和完整答案不一致就回退”的兜底策略组合形成稳定的生产链路。在更长的多跳任务上测试例如带工具调用的 Agent 轨迹压缩这比纯 CoT 更接近真实业务。如果想要深入研究可以从激活 patching 和因果追踪方法开始阅读这两类方法解释的是同一件事在模型的庞杂参数里哪些内部状态真正导致了外部行为。理解它们之后再看 “Every Token Leaves a Ripple in the Stream of Thought” 这类工作读到的就不会只是“压缩 token 的又一个技巧”而是模型内部结构如何参与推理链构建的完整图景。如果手上刚好有带长思维链的推理数据建议先做一个小实验取 50 道正确答案稳定的题目计算每个 token 的隐藏层扰动或梯度显著性再把高显著 token 按原顺序输出成一条“骨干思维链”。观察这个骨干链是否仍然能让模型得出正确答案。这个观察本身比对着一堆参数调压缩比例更能帮助你理解模型的真实推理方式。