[{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/categories/%E8%AE%BA%E6%96%87/","section":"Categories","summary":"","title":"论文","type":"categories"},{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/tags/%E8%AE%BA%E6%96%87/","section":"Tags","summary":"","title":"论文","type":"tags"},{"content":" 面向大语言模型的门控注意力机制：非线性、稀疏性和 Attention-Sink-Free # 摘要 # 门控机制已被广泛应用于从早期模型如 LSTM 和 Highway Networks，到近期的状态空间模型、线性注意力，以及 softmax 注意力。然而，现有文献很少深入探讨门控的具体作用。在本研究中，我们通过全面实验系统性地探究了引入门控的 softmax 注意力变体。具体而言，我们在一个包含 3.5 万亿 token 的数据集上训练了 30 种 15B 规模的 Mixture-of-Experts（MoE）模型和 1.7B 规模的密集模型，并进行了详尽比较。我们的核心发现是：一种简单的修改——在 SDPA 之后应用每个注意力头独立的 sigmoid 门控——能够持续提升模型性能。该修改还增强了训练稳定性，允许使用更大的学习率，并改善了模型的扩展特性。通过对多种门控位置和计算变体的比较，我们将此效果归因于两个关键因素：（1）在 softmax 注意力中的低秩映射上引入非线性；（2）使用依赖于查询的稀疏门控分数来调节 SDPA 的输出。值得注意的是，我们发现这种稀疏门控机制能够缓解“attention sink”现象，并提升长上下文外推能力。我们同时公开了相关代码和模型，以促进后续研究。\nMotivation # 尽管门控机制已被广泛采用并取得经验上的成功，但其功能与影响仍超出初始直觉之外，尚未得到充分探索。而这种理解不足，影响了对其利用 理解不足阻碍了对门控机制真实贡献的评估，尤其是在其与其他架构因素混杂的情况下。例如，尽管 Switch Heads（Csordas 等，2024a;b）引入了 sigmoid 门控以选择前 K 个注意力头专家，但我们的实验揭示了一个有趣的发现（附录 A.1）：即使缩减为单个专家，其中门控仅简单地调节 value 输出，仍然存在显著的性能提升。这强烈表明门控机制本身具有重要的内在价值，独立于路由机制之外。类似地，在 Native Sparse Attention（NSA）（Yuan 等，2025）中，尽管展示了整体性能的提升，但并未将门控机制的贡献与稀疏注意力设计本身的效果区分开来。这些考量突显了严格分离门控效应与其他架构组件影响的必要性。\n前置知识 # 注意力 # 注意力是基于 QKV 三个矩阵计算出来的，可以理解为最终结果是对于 V 乘上了一个权重（相当于对于出 V 矩阵中重要的值乘以更高的权重，不那么重要的则乘以较低的权重）\n$$ Attn(Q,K,V)=softmax(\\frac{QK^T}{\\sqrt{d_k}})V $$其中 d_k 注意力头的维度，除以这个是为了对于注意力进行缩放，用于稳定方差和梯度\n自注意力 # 自注意力顾名思义，就是自己对于自己的注意力。具体而言，就是 Q、K、V 都来自同一个输入 X\n$$ Q=W_QX,K=W_KX,V=W_VX $$然后带入上面计算 Attn 的式子中计算自注意力\n$$ SelfAttn(X)=softmax(\\frac{W_QX(W_KX)^T}{\\sqrt{d_k}})W_vX $$ 多头自注意力 和 最终输出 # 指在一个层中，使用不同的 W_Q/W_K/W_V 计算出不同的 SelfAttn 的结果，用于提取/处理不同的信息。其中每一组 W_Q/W_K/W_V 构成一个头。将一层内多个头的计算结果拼接起来之后，一起乘上一个 W_O，就差不多可以作为这一层的输出了。\n实际还有残差连接、FFN 和 Norm 等操作\n例如 Qwen3-8B，共 36 层、每层有 32 个头，伪代码表示如下\n下面的伪代码仅用于大概展示 Transformer 的工作原理，实际不同模型的 Norm、FFN、残差连接等操作的顺序和次数可能不太一致，例如 Qwen 的架构就采用的前置 Norm，而非下面伪代码展示的后置 Norm ## 输入 X: 形状通常为 [Batch_Size, Seq_Length, Hidden_Dimension] for each_layer in layers: # Qwen3-8B 共 36 层 # 多头自注意力机制 head_outputs = [] # 实际代码实现中，每个头的计算是并行的，也不需要下一步的拼接 for each_head in each_layer.heads: attn_of_this_head = each_head(X) head_outputs.append(attn_of_this_head) concat_output = concatenate(head_outputs) attention_output = each_layer.W_O_linear(concat_output) # 文字中省略的其他部分 # 残差连接 X_after_attn = LayerNorm(X + attention_output) # 前馈神经网络 (FFN） ffn_output = each_layer.ffn(X_after_attn) # 再次残差连接 + 归一化 X = LayerNorm(X_after_attn + ffn_output) return X 使用门控机制增强的 Attn # 设计一个门函数\n$$ Y'=Y \\boxed{?} Activate(XW_\\theta) $$其中 X 不同于用户输入的 X，这里的 X 指用于调整门控指的输入（在实验中，作者使用 Norm 之后的隐藏状态作为 X），\\(W_\\theta \\) 是一个 linear 层\n作者 huggingface 上说采用的是 Qwen3 架构，Qwen3 是前置 Norm，所以可以将 Norm 之后的东西作为 X 输入门 其中 \\(\\boxed{?}\\)指一种运算方式，因为作者实验中设计了不同的计算方式，这里将其模糊处理\n其中\\(Activate\\)是一种激活函数，同样因为作者实验中采用了不同的激活函数，这里模糊处理\n实验 # Settings # 作者进行了以下几组实验：\n不同位置施加门（G1~G5) 施加门的粒度：\\(XW_\\theta \\) 是标量 or 和 Y 同尺寸的矩阵 每个头共享一个\\(W_\\theta \\) or 每个头有自己的\\(W_\\theta \\) 乘法（\\(Y'=Y \\odot Activate(XW_\\theta)\\)） or 加法（\\(Y'=Y + Activate(XW_\\theta)\\)）门控 激活函数：\\(Activate=SiLU\\) or \\(Activate=Sigmod\\) 由于 SiLU 无上界，所以在实验中 SiLU 仅用在了加法门控中\n代码里能看到，是对于每一层都应用了各自的 Gate 模型、设备、超参、数据等 # 模型：15A2.54B（128 个总专家、top-8 softmax 门控机制、细粒度专家、全局批处理 LBL、z-loss）、1.7B 两个模型\n细粒度专家：专家参数量较少，比如这个模型，总共 15B 的参数拆出了 128 个专家 全局批处理：在计算 Loss 时，不再局限于单卡，而是统计全局一个 Batch 中的 Token 分布。可以让全局大 batch 中同时均衡覆盖各种不同任务，能提高 MoE 训练的效果 z-loss：在 MoE 训练的时候，router 参数的改变会导致 loss 飙升，于是谷歌设计了 z-loss 来解决这个问题 数据集：\n训练：应该是一个内部数据集（我们在一个包含 3.5T 高质量 token 的子集上训练模型，涵盖多语言、数学和通用知识内容） 测试（few-shots）：Hellaswag（英语）、MMLU（通用知识）、GSM8k（数学）、HumanEval（代码）、C-eval 和 CMMLU（中文），以及多种内部数据集 超参：Context Length=4096\n模型学习率Batch sizestep MoE-15A2.54B1k步内预热到2e-3余弦退火到3e-51024100k 1.7B（400B Token）最大学习率 4e-3 1024 1.7B（3.5T Token）最大学习率 4.5e-32048 算法备注：Attention 部分采用组查询注意力\n组查询注意力指多个 Query 头共享一组 KV 头，和 baseline 性能接近，但是降低显存和提高速度 比如在 n 个注意力计算的公式中，n 个 W_K 是固定的一个 linear、n 个 W_V 固定一个 linear，但是 n 个 W_Q 是 n 个 linear 结果 # MoE-15A2.54B # 在 G1 和 G2 处添加门控是最有效的 不同粒度差别不大、分头还是 Head Shared 差别不大 乘法比较好 Sigmod 比 SiLU 好 1.7B # 作者另外发现使用门控机制可以大大提高训练的稳定性，减少 Loss 峰值的出现，于是可以继续使用更大的模型参数、大学习率、大 Batch Size 获得性能又好、训起来又快的模型\n分析 # 作者将门控机制提升性能，归结为两个主要原因：\n门控的非线性运算提升了模型性能 门控引入了强输入依赖的稀疏性，降低了 Attention Sink 问题 非线性运算提升模型性能 # 在多头注意力中，第 i 个 token 和第 k 个头的对应关系如下：\n可以看到，W_V 和 W_O 是直接相乘的，缺乏非线性变换，而 G1 和 G2 相当于在 WV 和 WO 之间应用了非线性变换，所以性能提升了，而其他门控变化不大\n同时作者进行了消融实验，发现仅在 SDPA 输出后加 RMSNorm（无额外参数）也能显著降低 PPL\n强输入依赖的稀疏性 # 作者分析了门控分数的分布，发现 SDPA 输出门控分数大多分布集中在 0 附近、少数 long tail 到 1，是稀疏的 G1 门控分数取决于当前的 Query，模型可以根据 Query 再进一步过滤信息，而 G2 这种直接对 Value 做 Gate 的效果并不好 我个人觉得这个解释比较牵强，G1 的 Input 是 X 的隐藏状态和 MultiHead 的结果，为什么说它和 Query 是强关联的？ 我觉得可以解释成，G1 相当于基于 X 又进行了一次 Query 作者做了消融实验，将 Sigmod 函数换成一个非稀疏版本的 Sigmod，发现相比直接用 Sigmod 性能下降 $$ NSSigmod(x)=0.5+0.5Sigmod(x) $$ 门控缓解了 Attention Sink 现象 # 什么是 Attention Sink 现象 # 有研究者发现，LLM 深层的时候，倾向于给第一个 Token 分配更高的注意力（如下图）\n有一个解释如下：\nLLM 在浅层时已经完成了信息的处理，所以后续如果再融合输入的 token 的信息反而会降低输出的质量，于是模型就需要获取尽可能少的信息。而由于传统模型是因果的，后面的 Token 能够看到前面的 Token，因此后面的 Token 中是包含前面的 Token 的信息的。因此，在深层，LLM 倾向于将 Attention 放到信息最少的 Token 上面，也就是第一个 Token/最开始的几个 token\n作者发现，使用稀疏的门控 G1 可以大大降低 Attention Sink 现象，而不那么稀疏的 G2 或者使用了 NS-Sigmod 激活函数的 Gate 的 Attention Sink 的现象会很明显\n使用门控有利于模型 Context 扩展 # 作者分析 Baseline 依靠 Attention Sink 来消耗多余的注意力，但是当应用 YaRN 时，这种方式就被破坏了，导致 Baseline 性能大幅下降，而使用 G1 可以在模型的 Attention 输出中挑拣出需要的信息，模型就不需要依赖 Attention Sink 了，因此性能下降小于 Baseline\nYaRN 的做法是什么 # 随着序列长度增加，QK^T 会大大增加\n长度增加则让 Q 和 K 的整体方向更接近，导致 QK^T 结果更大，因此需要对于 Attention 进行缩放 YaRN 是修改 Attention 计算方式为：\\(Attn=Softmax(\\frac{QK^T}{t\\sqrt{d}})V\\)，其中 t 被称为温度系数，YaRN 作者提出了一个经验值\\(t=\\frac{ln(s)}{10}+1\\)，S 指缩放因子，比如 32K 上下文缩放到 128K，S=128/32=4\n所以 YaRN 和 Attention Sink 就具有天生的冲突，Attention Sink 将大量 Attention 消耗到 First a few token 上，但是 YaRN 又将这个尖锐的 Attention 拉回来了\n","date":"2025 Dec 6","externalUrl":null,"permalink":"/posts/%E9%9D%A2%E5%90%91%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E7%9A%84%E9%97%A8%E6%8E%A7%E6%B3%A8%E6%84%8F%E5%8A%9B%E6%9C%BA%E5%88%B6%E9%9D%9E%E7%BA%BF%E6%80%A7%E7%A8%80%E7%96%8F%E6%80%A7%E5%92%8Cattention-sink-free/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e面向大语言模型的门控注意力机制：非线性、稀疏性和 Attention-Sink-Free\n    \u003cdiv id=\"面向大语言模型的门控注意力机制非线性稀疏性和-attention-sink-free\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#%e9%9d%a2%e5%90%91%e5%a4%a7%e8%af%ad%e8%a8%80%e6%a8%a1%e5%9e%8b%e7%9a%84%e9%97%a8%e6%8e%a7%e6%b3%a8%e6%84%8f%e5%8a%9b%e6%9c%ba%e5%88%b6%e9%9d%9e%e7%ba%bf%e6%80%a7%e7%a8%80%e7%96%8f%e6%80%a7%e5%92%8c-attention-sink-free\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003e\u003cfigure\u003e\u003cimg\n    class=\"my-0 rounded-md\"\n    loading=\"lazy\"\n    decoding=\"async\"\n    fetchpriority=\"low\"\n    alt=\"\"\n    src=\"/post_imgs/%E9%9D%A2%E5%90%91%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E7%9A%84%E9%97%A8%E6%8E%A7%E6%B3%A8%E6%84%8F%E5%8A%9B%E6%9C%BA%E5%88%B6%EF%BC%9A%E9%9D%9E%E7%BA%BF%E6%80%A7%E3%80%81%E7%A8%80%E7%96%8F%E6%80%A7%E5%92%8CAttention-Sink-Free/VeBEbQu4tokbLoxifqrc69bJnjh.png\"\n    \u003e\u003c/figure\u003e\n\u003c/p\u003e","title":"面向大语言模型的门控注意力机制：非线性、稀疏性和Attention-Sink-Free","type":"posts"},{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/","section":"某位老王的小窝","summary":"","title":"某位老王的小窝","type":"page"},{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/categories/%E7%AE%97%E6%B3%95/","section":"Categories","summary":"","title":"算法","type":"categories"},{"content":"","date":"2025 Dec 6","externalUrl":null,"permalink":"/tags/%E7%AE%97%E6%B3%95/","section":"Tags","summary":"","title":"算法","type":"tags"},{"content":" Saber：一种针对扩散语言模型的自适应加速与回溯增强的高效采样方法 # Saber: An Efficient Sampling with Adaptive Acceleration and Backtracking Enhanced Remasking for Diffusion Language Model\n这篇文章设计了 DLM 的 remask 机制，是对于已经解码出来的 token 的 remask 摘要 # 扩散语言模型（DLMs）正作为一种强大且有前景的替代方案，逐渐取代主流的自回归范式，在并行生成和双向上下文建模方面具有固有优势。然而，在代码生成任务中，由于更强的结构约束，DLMs 的性能受到推理速度与输出质量之间关键权衡的显著阻碍。我们观察到，通过减少采样步骤来加速代码生成过程通常会导致性能的灾难性下降。在本文中，我们引入了一种新的无需训练的采样算法——自适应加速与回溯增强重掩码（即 Saber），用于 DLMs 以在代码生成中实现更好的推理速度和输出质量。具体而言，Saber 受到 DLM 生成过程中的两个关键洞察启发：1）随着更多代码上下文的建立，可以自适应地加速；2）需要一个回溯机制来逆转生成的标记。在多个主流代码生成基准上的广泛实验表明，Saber 在主流 DLM 采样方法上平均提升了 1.9% 的 Pass@1 准确率，同时实现了平均 251.4% 的推理加速。通过利用 DLMs 的固有优势，我们的工作显著缩小了代码生成中与自回归模型之间的性能差距。\n这篇工作局限在代码生成，可能是 Motivation 里观察到的现象在代码生成中更加直观 也可能是相关工作中提到 ReMDM 与该方法类似，但是代码生成任务上并不理想 Motivation # 根据图 a 大概整体 confidence 是随着降噪进行越来越大的 图 b 没说是具体是哪个 token 的置信度，但是看起来可能是红色的 sorted 图 a 表明，DLM 生成过程难度逐渐降低。\n在最开始时，由于大量 token 是[MASK]，DLM 的不确定性很高，但随着逐渐解码，DLM 的不确定性逐渐降低，可以在这里使用一个自适应的加速策略，在采样初期保持谨慎，在后面逐渐激进\n图 b 表明，DLM 生成具有动态上下文\nDLM 具有动态的上下文，随着越来越多的[MASK]被解码，DLM 对于已经生成的 token 的置信度会发生变化，DLM 可能会越来越觉得之前生成的某个 token 是错误，但是传统的 DLM 在采样中是不可逆的，无法将一个 unmask 出来的 token 重新 mask\n方法 # 动态 unmask 自适应加速 # 动态设置置信度阈值 tau_t，将其设置为之前步骤中 unmask 的 token 的平均置信度，c_max 是一个超参\n如果某些 token 的置信度超过 tau_t，就并行解码出来，作为 Draft，记作 D_t\nRemask # 先基于上一步 decode 的激进程度，判断这一步需要 remask 的 token 数量，mu 是一个超参\n然后计算先前已有的 token 的置信度变化（不包括刚刚 decode 出来的 token）：\n选出 top-mu_t 的 token，将其重新回退为[MASK]\n实验 # A6000（48G）、LLaDA-8B-Instruct，max_new_tokens 设置为 256、block_size 设置为 128\n在其他模型上面的效果（HumanEval）\n消融 # 一些其他想法 # 在另一篇文章中看到以下内容：\nDLM 相比同参数的 AR，可以说很慢了\n","date":"2025 Nov 7","externalUrl":null,"permalink":"/posts/saber%E4%B8%80%E7%A7%8D%E9%92%88%E5%AF%B9%E6%89%A9%E6%95%A3%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E7%9A%84%E8%87%AA%E9%80%82%E5%BA%94%E5%8A%A0%E9%80%9F%E4%B8%8E%E5%9B%9E%E6%BA%AF%E5%A2%9E%E5%BC%BA%E7%9A%84%E9%AB%98%E6%95%88%E9%87%87%E6%A0%B7%E6%96%B9%E6%B3%95/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eSaber：一种针对扩散语言模型的自适应加速与回溯增强的高效采样方法\n    \u003cdiv id=\"saber一种针对扩散语言模型的自适应加速与回溯增强的高效采样方法\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#saber%e4%b8%80%e7%a7%8d%e9%92%88%e5%af%b9%e6%89%a9%e6%95%a3%e8%af%ad%e8%a8%80%e6%a8%a1%e5%9e%8b%e7%9a%84%e8%87%aa%e9%80%82%e5%ba%94%e5%8a%a0%e9%80%9f%e4%b8%8e%e5%9b%9e%e6%ba%af%e5%a2%9e%e5%bc%ba%e7%9a%84%e9%ab%98%e6%95%88%e9%87%87%e6%a0%b7%e6%96%b9%e6%b3%95\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eSaber: An Efficient Sampling with Adaptive Acceleration and Backtracking Enhanced Remasking for Diffusion Language Model\u003c/p\u003e","title":"Saber：一种针对扩散语言模型的自适应加速与回溯增强的高效采样方法","type":"posts"},{"content":" R-STITCH：用于高效推理的动态轨迹拼接 # R-STITCH: DYNAMIC TRAJECTORY STITCHING FOR EFFICIENT REASONING\n摘要 # 思维链（Chain-of-thought, CoT）能够增强大语言模型（LLMs）的问题求解能力，但由于其较长的自回归推理轨迹，带来了显著的推理开销。现有的加速策略要么通过提前终止或压缩来缩短推理路径，要么采用较小模型进行投机解码（speculative decoding）。然而，当模型间一致性较低时，投机解码的增益有限，并且严格强制执行 token 级别的对齐，忽略了这样一个观察：某些小模型在正确时能够生成显著更简洁的推理轨迹，从而可能减少推理长度。我们提出了 R-Stitch，一种无需训练的混合解码框架，利用 token 级别的熵作为不确定性的代理，在小型语言模型（SLM）与大语言模型（LLM）之间动态分配计算任务。我们的分析表明，高熵 token 更容易引发错误，这启发了我们设计一种基于熵的路由策略：让 SLM 高效处理低熵 token，而将不确定性较高的 token 交由 LLM 处理，从而避免完全回滚并保持答案质量。我们进一步扩展该设计，提出 R-Stitch+，其学习一种自适应路由策略，能够超越固定阈值动态调整 token 预算。通过同时降低每个 token 的解码复杂度和生成 token 的总数，我们的方法实现了显著的加速，且准确率损失可忽略不计。具体而言，在 DeepSeek-R1-Distill-Qwen-7B 上达到 3.00 倍的峰值加速，在 14B 模型上达到 3.85 倍，在 QWQ-32B 上达到 4.10 倍，同时保持与完整 LLM 解码相当的准确性。此外，该方法自然支持可调节的效率–准确性权衡，可根据不同的计算预算进行定制，无需重新训练。项目地址为 https://caesarhhh.github.io/R-Stitch。\nMotivation # 第一张图，Wrong 的答案中，每个 token 的熵总体比较大\n第二张图，大多数 token 的熵很低，只有 10% 左右的 SLM 生成的 token 的熵大于 0.1\n第三张图，定义有害 token 为首个使得 SLM 由正确转向错误的 token，发现有害 token 的熵要高于局部平均熵\n所以可以基于熵，设计设计一个 router\n方法 # 基于阈值 # 设计一个超参数 \\(\\tau\\)\n先由 SLM 开始生成，如果发现某个 token 的熵大于\\(\\tau\\)，则切换到 LLM；相同的，如果 LLM 生成的某个 token 的熵小于\\(\\tau\\)，就切换到 SLM\nKV Cache 两个模型单独维护，每次切换就用已生成的问题去填充上新的 KV Cache\n基于 RL # 当 SLM 的熵超过阈值时，将当前模型的隐藏状态将被输入到一个轻量级的路由模块，该模块决定是继续使用 SLM 还是切换到 LLM。\n那么从 LLM 切换到 SLM 时，是输入 LLM 的隐藏状态吗？ 原文没讲，且代码没放出来，上面的 Github 仓库只有一个 README RL 的奖励包含两部分，acc 分数和效率分数\n效率分数包含 Prefill 部分和 Decode 部分，其中 Prefill 部分的函数如下（abcd 是常数）：\nN_inf 是输入的 token 数量，N_kv 是当前阶段 KV Cache 的长度\nDecode 部分的函数如下（cd 和上面的 cd 不一样，但是也是常数）：\n作者使用 SLM 和 LLM 在小批量数据集上测试了一波，用于拟合 T_prefill 和 T_decode 函数，后续直接基于这两个函数计算效率分数\n所以总体的奖励函数是：\n$$ R=r_{acc}+r_{eff}=r_{acc}-\\lambda r_{acc}\\hat{L}=r_{acc}-\\lambda r_{acc}T_{prefill}T{decode} $$但是要注意的是，当且仅当回答正确时，才对于 eff 进行惩罚，防止模型为了追求速度而放弃精度\n使用 DAPO 优化\n实验 # 数据集：OlympiadBench、AIME、Minerva、AMC、MATH\n模型：\nLLM：Deepseek-MATH-R1-Distilled-Qwen-7B、14B、QwQ-32B SLM：L1-1.5B-Short 超参数：lambda=5e-6，batchsize=32，rollout group size 8.\n","date":"2025 Nov 7","externalUrl":null,"permalink":"/posts/r-stitch%E7%94%A8%E4%BA%8E%E9%AB%98%E6%95%88%E6%8E%A8%E7%90%86%E7%9A%84%E5%8A%A8%E6%80%81%E8%BD%A8%E8%BF%B9%E6%8B%BC%E6%8E%A5/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eR-STITCH：用于高效推理的动态轨迹拼接\n    \u003cdiv id=\"r-stitch用于高效推理的动态轨迹拼接\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#r-stitch%e7%94%a8%e4%ba%8e%e9%ab%98%e6%95%88%e6%8e%a8%e7%90%86%e7%9a%84%e5%8a%a8%e6%80%81%e8%bd%a8%e8%bf%b9%e6%8b%bc%e6%8e%a5\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eR-STITCH: DYNAMIC TRAJECTORY STITCHING FOR  EFFICIENT REASONING\u003c/p\u003e","title":"R-STITCH：用于高效推理的动态轨迹拼接","type":"posts"},{"content":" 真-Self-Spec-DLM # SELF SPECULATIVE DECODING FOR DIFFUSION LARGE LANGUAGE MODELS\n摘要 # 基于扩散的大语言模型（dLLMs）已成为自回归模型的一种有力替代方案，凭借双向注意力和并行生成范式展现出独特优势。然而，当前并行解码方法的生成结果与逐步解码存在偏差，可能导致性能下降，限制了其实际部署。为解决此问题，我们提出自推测解码（Self Speculative Decoding, SSD），这是一种无损推理加速方法，利用 dLLM 自身同时作为推测解码的起草器与验证器，无需额外辅助模块。SSD 引入了一种自起草机制，使模型能够对多个位置生成预测，并通过分层验证树在单次前向传播中完成验证。与传统需要独立起草模型的推测解码不同，SSD 通过挖掘 dLLM 本身对多个位置的并行预测能力，消除了模型冗余和内存开销。这种自推测机制使得模型可在一次前向传播中逐步验证并接受多个 token。实验表明，SSD 在 LLaDA 和 Dream 等开源模型上实现了最高达 3.46 倍的加速，同时保持输出与逐步解码完全一致。代码将公开于 GitHub。\nMotivation # 扩散语言模型（dLLMs）在推理效率方面仍面临挑战。与具备原生键值（KV）缓存支持的自回归模型（ARMs）不同，dLLMs 的双向注意力机制以及在去噪步骤中动态的 token 更新，阻碍了传统 KV 缓存策略的直接应用。如图 1 所示，在启用 Fast-dLLM（Wu et al., 2025）中的缓存时，dLLM 生成在中等批量大小（≤ 8）下表现出明显的内存受限特征，吞吐量扩展接近线性扩展，这为投机式解码方法（speculative decoding approaches）（Leviathan et al., 2023; Chen et al., 2023）创造了机会，此类方法可通过增加计算来降低延迟。\n为什么说 dLLM 表现出内存受限特征、吞吐量接近线性扩展就可以做投机采样呢？ 意思是理论最好是线性，但是实际效果不如线性吗？ 方法 # 起草 # 设起草长度 draft_len = 3\n在 dlm 的一个 steps 中，并行 greedy decode 出 block 内置信度最高的 draft_len 个 token，如果 block 内的[MASK]数量小于 draft_len，则多出来的部分要从下一个 block 中 decode 出来\n例如输入的 Token 是 BLOCK1: X [MASK] [MASK] [MASK] BLOCK2: [MASK] [MASK] [MASK] [MASK]\n其中 BLOCK1 中红色[MASK]的置信度最高，按 step by step 的流程，红色[MASK]应当被 decode 出来，即：\nBLOCK1: X X [MASK] [MASK] BLOCK2: [MASK] [MASK] [MASK] [MASK]\n随着 X 被 decode 出来，所有[MASK]位置也获得了 logits，将按照 draft_len 进行起草\nBLOCK1 中只有 2 个[MASK]，则需要独立并行 Decode 出 Block1 中所有[MASK]，并在同一个 step 中 decode 出 BLOCK2 中置信度最高的[MASK]\n比如起草出来的 Token 是 BLOCK1: X X B A BLOCK2: [MASK] C [MASK] [MASK]\n其中 B 的置信度为 0.6， A 的置信度为 0.95，C 的置信度为 0.75\n验证 # 根据起草部分的输入和输出构造要验证的内容。假设每一步只 decode 一个 token，则 draft 输入到输出每一步中间产物应当为：\ndraft 输入：X X [MASK] [MASK] [MASK] [MASK] [MASK] [MASK]\n1：X X [MASK] A [MASK] [MASK] [MASK] [MASK] (因为 A 这个 token 在左侧 block 中，且置信度为 block 内最大)\n2: X X B A [MASK] [MASK] [MASK] [MASK] (因为 B 这个 token 在左侧 block 中，尽管 C 的置信度更高，但应当按照半自回归的顺序解码)\n3（draft 输出）：X X B A [MASK] C [MASK] [MASK]\n将上述的 0123 组合起来，构造一个 batch：\n[\n[X, X, [MASK], [MASK], [MASK], [MASK], [MASK], [MASK]],\n[X, X, [MASK], A, [MASK], [MASK], [MASK], [MASK]],\n[X, X, B, A, [MASK], [MASK], [MASK], [MASK]],\n[X, X, B, A, [MASK], C, [MASK], [MASK] ]\n]\n送回模型本身，获取每个红色位置的 logits，如果红色位置的 logits 刚好能 decode 出来起草的 token，则接受草稿，否则拒绝草稿，并从获得的 logits 位置重新采样出一个 token 放上去，并拒绝这一次后续的草稿\n比如接受了 A，拒绝了 B，且从拒绝 B 时的 logits 中可以采样出 D，则这次验证的输出为\nX X D A [MASK] [MASK] [MASK] [MASK]\n然后回到起草过程，继续生成新的 token\ntop-k 验证 # 如果 draft 的 token 在验证阶段 top-k 的 token 之中则采用，其他路径一致\n实验 # top-k 验证 # Upper bound 是所有 draft 都被 accpet 的理论极限 accepted_token / (draft_len) + 1\n","date":"2025 Nov 7","externalUrl":null,"permalink":"/posts/%E7%9C%9F-self-spec-dlm/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e真-Self-Spec-DLM\n    \u003cdiv id=\"真-self-spec-dlm\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#%e7%9c%9f-self-spec-dlm\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eSELF SPECULATIVE DECODING FOR DIFFUSION  LARGE LANGUAGE MODELS\u003c/p\u003e","title":"真-Self-Spec-DLM","type":"posts"},{"content":" SlowFast 采样加速 DLM # ACCELERATING DIFFUSION LARGE LANGUAGE MODELS WITH SLOWFAST SAMPLING: THE THREE GOLDEN PRINCIPLES\nCode: https://github.com/LiangrunFlora/Slow-Fast-Sampling\n摘要 # 基于扩散的语言模型（dLLMs）通过实现并行 token 生成，显著降低了推理延迟，已成为传统自回归 LLM 的一个有前景的替代方案。然而，现有的 dLLMs 采样策略，如基于置信度或半自回归解码方法，通常表现出静态行为，导致效率次优且灵活性受限。本文提出了 SlowFast Sampling，一种新颖的动态采样策略，能够自适应地在探索性解码与加速解码阶段之间切换。我们的方法由三个黄金原则指导：确定性原则、收敛性原则和位置性原则，这些原则决定了何时以及何处在可信赖且高效的前提下进行 token 解码。我们进一步将该策略与 dLLM-Cache 相结合，以减少冗余计算。在多个基准和模型上的大量实验表明，SlowFast Sampling 在 LLaDA 上实现了最高达 15.63 倍的加速，在结合缓存时最高可达 34.22 倍，且精度损失极小。值得注意的是，我们的方法在吞吐量方面优于 LLaMA3 8B 等强自回归基线，证明了精心设计的采样策略可以充分释放 dLLMs 在快速高质量生成方面的潜力。\nMotivation # 当前 DLM 要么基于置信度选择 token 并将其 decode 出来，要么采用半 AR 解码。然而这两者方法在并行解码大量 token 的时候效果并不理想，且在整个生成过程中表现出静态、恒定的采样速度。\n因此作者希望能提出一种动态的采样策略，一种能够决定每一步采样多少 token、哪些 token 的策略\n观察到的现象 # 图 a 展示了随着 decoding 进行，token 的置信度逐渐收敛，要么越来越高，要么越来越低\n图 b 展示了 LLaDA 在 GSM8K 上经过 256 步扩散过程中的置信度图谱变化，高置信度位置的 token 越来越多并被优先 decode、且这些 token 往往连续出现\n文中其实并没有解释为什么有的 token 的置信度会变低 于是作者提出 3 个 Gold Principle：\n原则含义意义 确定性表现出更高置信度的token本质上更具确定性。因此，它们更有可能在解码过程的早期被正确解码，并且在后续的扩散步骤中需要较少的调整。通过优先处理那些能够快速达到高置信度阈值的token，我们可以减少对序列中已确定部分的冗余计算。 收敛随着扩散过程的展开和token的逐步优化，许多token的语义含义趋于稳定，其对应的置信度分数收敛至一个稳定值。这种收敛表明这些token已基本定型，几乎不需要进一步优化。已表现出收敛性的token（即在最近若干步中具有稳定的标识和置信度）更不易发生变化。激进解码可避免不必要的重新评估，从而加快处理速度。 位置**即使没有显式的约束条件，模型的采样偏好通常也会倾向于出现在特定的、通常是相邻的位置上的token。这种固有的位置偏差可以被策略性地加以利用。例如，序列的部分内容可以有效地被缓存，从而带来显著的加速增益。**识别这些区域有助于实现有针对性的解码。无需均匀处理所有token，而是可以将计算资源集中在当前最易于解码的区域上。 方法 # 还是 block 内并行，但是 block 之间是 ar\nblock 内部分为两阶段 dlm 解码，探索阶段（slow）和加速 decoding（fast）阶段\n探索阶段 # 小心解码：每一个 step，只 decode 出置信度最大的一个 token，一共执行 k（超参数）个 step 终点预测：每个 step 中，取出 block 内距离该 token 最远的、置信度高于 t_{min_conf}（超参数）的 token，并认为 dlm 可以自信地 decode 到这个位置 这一段是应用了位置原则，高置信度的 token 往往是聚集的 稳定性检查：多个 step 之间维护一个历史记录（保留最近 K_hist 条，也是超参数），用于记录最远的 token 的位置，如果最近 K_hist 个记录的方差小于 σ^2_stable，则认为稳定了，取历史记录的平均值作为最终确定下来的位置，并将 block 中从开始到此为止的所有 token 进入 Fast decoding 阶段\n回退策略：如果最终没能达到稳定，则准备了两种回退策略来估计最终的终点：\n保守区间回退（默认）：还是取历史记录的平局值 全序列慢速解码（极端情况）：不进入 Fast Decoding 阶段 加速 Decoding 阶段 # 区域外缓存：对于上面计算出的终点外的 token，只计算他们一次，并将这些位置的计算结果 cache 下来 区域内并行解码：在区域内尝试激进的并行解码，同时解码所有置信度高于 t_{high_conf}（超参数）的 token 回退策略：如果没有 token 高于 t_{high_conf}，则解码 top-k_fast（超参）的 token 实验 # 模型：LLaDA 8B、Dream 7B\n硬件：4090\n超参数：\n参数值含义 t_{min_conf}0.1slow阶段终点预测时的置信度阈值 t_{high_conf}0.85fast阶段并行解码的token的置信度阈值 K8slow阶段探索步数 k_hist2slow阶段保留的最终历史记录数 σ^2_stable1.0slow阶段的历史记录方差阈值 K_fast未汇报Fast阶段回退的并行解码top-k的k 下图的 K_p 和 K_r 文章中没提到，应该是 Cache 的超参数\n","date":"2025 Nov 7","externalUrl":null,"permalink":"/posts/slowfast%E9%87%87%E6%A0%B7%E5%8A%A0%E9%80%9Fdlm/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eSlowFast 采样加速 DLM\n    \u003cdiv id=\"slowfast-采样加速-dlm\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#slowfast-%e9%87%87%e6%a0%b7%e5%8a%a0%e9%80%9f-dlm\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eACCELERATING DIFFUSION LARGE LANGUAGE MODELS WITH SLOWFAST SAMPLING: THE THREE GOLDEN  PRINCIPLES\u003c/p\u003e","title":"SlowFast采样加速DLM","type":"posts"},{"content":"","date":"2025 Oct 10","externalUrl":null,"permalink":"/tags/cot%E5%8E%8B%E7%BC%A9/","section":"Tags","summary":"","title":"CoT压缩","type":"tags"},{"content":" 简洁提示：通过生成过程中的连续简洁提示提升推理效率 # ConciseHint: Boosting Efficient Reasoning via Continuous Concise Hints during Generation\n摘要 # 近期，诸如 DeepSeek-R1 和 OpenAI o1 系列等大型推理模型（LRMs）通过思维链（Chain-of-Thought, CoT）扩展生成长度，在复杂推理任务上实现了显著的性能提升。然而，一个新兴的问题是这些模型倾向于生成过度冗长的推理过程，从而导致效率低下的问题。现有的关于提升效率的研究主要遵循“推理前”范式，例如提示（prompting）加推理或微调（fine-tuning）加推理，却忽视了一个颇具前景的方向——在推理生成过程中直接鼓励模型进行简洁表达。为填补这一空白，我们提出了一种名为 ConciseHint 的框架，该框架在推理过程的 token 生成阶段持续注入文本提示（可人工设计或基于简洁数据训练得到），从而持续鼓励推理模型进行简洁表达。此外，ConciseHint 能够根据查询的复杂度自适应地调整提示强度，确保该方法不会损害模型性能。在包括 DeepSeek-R1 和 Qwen-3 系列在内的最先进 LRMs 上的实验表明，我们的方法能够有效生成更简洁的推理过程，同时保持良好的模型性能。例如，在 GSM8K 基准测试中，使用 Qwen-3 4B 模型，我们的方法在几乎无准确率损失的情况下，将推理过程长度减少了 65%。\nMotivation # 过长 CoT 效率低 LRM 通常生成不必要的连贯性 token，或执行冗余的自我验证 作者想要在生成中间推理步骤的过程中通过干预来引导 LRM 更简洁地表达\n方法 # ConciseHint 在推理过程中（多次）注入类似 \u0026lt;|im_start|\u0026gt;make answer concise!\u0026lt;|im_end|\u0026gt; 的提示，例如原文是：\nOkay, let me try to figure out this problem. The problem says a robe takes 2 bolts of blue fiber and half that much white fiber\n则会被修改为\nOkay,-\u0026lt;|im_start|\u0026gt;make answer concise!\u0026lt;|im_end|\u0026gt;- let me try to figure out this problem. The problem says a robe takes 2 bolts of blue fiber and half that much white fiber\n注入强度 # 过高的注入会损害 Acc，但是过少的注入就会导致效果没那么好。\n所谓“注入强度”就是每次注入之间的 token 数量 \\(\\tau_k\\)\n定义如下：\n$$ \\tau_k = \\alpha + \\beta \\cdot l_k, \\alpha \\gt 0, \\beta \\gt 0 $$其中 alpha 和 beta 为超参数，alpha 为基本注入间隔，实验中设置为 128，beta 设置为 0.2，l_k 是目前推理的长度。也就是说推理越长，注入间隔越大\n为什么要这样设计呢？作者称基于“简单的问题可容忍的压缩率比复杂问题更大”这个假设，所以在 l_k 较小时，可以多多注入，但是当 l_k 长起来了，说明问题复杂了，需要减少注入频率\n注入位置 # 从实验中得出的规则：\n在早期推理过程中，注入的位置不应当过于接近 Think 结束的位置 否则后续生成会很快结束推理，或者只是懒惰地重复上一个提示之后生成的文本。这显著降低了准确率\n但是也不应该过于接近 Think 开始的位置 虽然将提示注入到开头能够解决准确率下降的问题，但它会引入额外的计算开销\n于是设计插入位置如下：\n$$ 插入位置=\\tau_k \\times min((\\tau_k-\\alpha)/1024, 0.8) $$ 修改提示词（AdaP） # 将一开始提示词换成“Please adaptively control the answer length based on the query’s complexity. The lower the complexity, the more concise your answer should be”\n但是如果将 AdaP 应用在注入的提示词上，可以获得更好的效果\n训练 Embedding # 类似可学习的 token 吧？ 先准备一个包含问题及其相应简洁推理回答的数据集，然后通过在原始回答中以固定间隔注入待训练的 hint embedding，构建修改好的推理回答。进行 SFT。E_{ori}是在 ConciseHint 中手动设计的 Hint Embedding，训练后得到优化后的提示嵌入 E_{optim}\n$$ E_{interp}=\\alpha \\times E_{optim}+(1-\\alpha) \\times E_{ori}, 0 \\le \\alpha \\le 1 $$这种方法记为 ConciseHint-T\n实验 # Training free # 数据集：GSM8K、AIME24、GPQA-Diamond\n模型：Qwen3-8B、Qwen3-4B、Qwen3-1.7B、DeepSeek-R1-14B\nOri 为原始模型\nBeConcise 是在一开始输入的提示词中添加“Be concise”\nAdaP 是在一开始输入的提示词中添加“Please adaptively control the answer length based on the query’s complexity. The lower the complexity, the more concise your answer should be”\nOri+Ours 是将**-\u0026lt;|im_start|\u0026gt;make answer concise!\u0026lt;|im_end|\u0026gt;-** 插入思考过程\nAdaP+Ours 是将**-\u0026lt;|im_start|\u0026gt;Please adaptively control the answer length based on the query’s complexity. The lower the complexity, the more concise your answer should be\u0026lt;|im_end|\u0026gt;-** 插入思考过程\nTraining # 其他 # 不同超参数：\n在不同地方插入提示\n","date":"2025 Oct 10","externalUrl":null,"permalink":"/posts/%E7%AE%80%E6%B4%81%E6%8F%90%E7%A4%BA%E9%80%9A%E8%BF%87%E7%94%9F%E6%88%90%E8%BF%87%E7%A8%8B%E4%B8%AD%E7%9A%84%E8%BF%9E%E7%BB%AD%E7%AE%80%E6%B4%81%E6%8F%90%E7%A4%BA%E6%8F%90%E5%8D%87%E6%8E%A8%E7%90%86%E6%95%88%E7%8E%87/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e简洁提示：通过生成过程中的连续简洁提示提升推理效率\n    \u003cdiv id=\"简洁提示通过生成过程中的连续简洁提示提升推理效率\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#%e7%ae%80%e6%b4%81%e6%8f%90%e7%a4%ba%e9%80%9a%e8%bf%87%e7%94%9f%e6%88%90%e8%bf%87%e7%a8%8b%e4%b8%ad%e7%9a%84%e8%bf%9e%e7%bb%ad%e7%ae%80%e6%b4%81%e6%8f%90%e7%a4%ba%e6%8f%90%e5%8d%87%e6%8e%a8%e7%90%86%e6%95%88%e7%8e%87\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eConciseHint: Boosting Efficient Reasoning via Continuous Concise Hints during Generation\u003c/p\u003e","title":"简洁提示：通过生成过程中的连续简洁提示提升推理效率","type":"posts"},{"content":"","date":"2025 Oct 10","externalUrl":null,"permalink":"/tags/diffusion/","section":"Tags","summary":"","title":"Diffusion","type":"tags"},{"content":"","date":"2025 Oct 10","externalUrl":null,"permalink":"/tags/dllm/","section":"Tags","summary":"","title":"DLLM","type":"tags"},{"content":" Prophet：Diffusion 模型基于置信度的 Decoding 早停 # Prophet: Fast Decoding for Diffusion Language Models\n20250827 提交到 arXiv 上的，感觉像是占坑的，实验部分有些不完善 摘要 # 扩散语言模型（DLMs）最近作为自回归方法的替代方案出现，提供了并行序列生成和灵活的标记顺序。然而，它们的推理速度仍比自回归模型慢，主要是由于双向注意力的成本以及生成高质量输出所需的大量精炼步骤。在本工作中，我们强调并利用了 DLMs 的一个被忽视的特性——早期答案收敛：在许多情况下，正确答案可以在最终解码步骤之前的一半步骤内被内部识别，无论是在半自回归还是随机重新遮蔽调度下。例如，在 GSM8K 和 MMLU 数据集上，分别有高达 97% 和 99% 的实例仅使用一半的精炼步骤即可正确解码。基于这一观察，我们引入了 Prophet，这是一种无需训练的快速解码范式，能够实现早期提交解码。具体而言，Prophet 使用前两名预测候选之间的置信度差距作为标准，动态决定是否继续精炼或“全部投入”（即一次解码所有剩余标记）。它可无缝集成到现有的 DLM 实现中，开销可以忽略不计，并且不需要额外的训练。在多个任务上对 LLaDA-8B 和 Dream-7B 的实证评估表明，Prophet 将解码步骤数减少了多达 3.4 倍，同时保持了高质量的生成效果。这些结果将 DLM 解码重新定义为一个何时停止采样的问题，并证明早期解码收敛为加速 DLM 推理提供了一个简单而强大的机制，与现有的加速技术相辅相成。我们的代码可在 https://github.com/pixeli99/Prophet 公开获取。\nMotivation # 实际应用中 DLM 仍然慢于 AR 模型，因为缺乏 KV Cache 以及出于性能考虑没法并行拉太大 在半 AR remask 和 random remask 的早期阶段，有相当高的比例的样本可以被正确解码。这一趋势在随机重掩码中更为显著。例如，在 GSM8K 和 MMLU 数据集上，分别有高达 97% 和 99% 的实例仅使用一半的精炼步骤即可被正确解码。 几个发现 # 在解码的早期阶段，可以正确解码的样本比例较高。对比图 1(a)和图 1-(c)表明，使用低置信度 remask 时，前一半的步骤中已经有 24.2% 的样本被正确 decoding 出来，前 25% 的步骤中已经有了 7.9% 的样本被正确 decoding 出来。但是如何换成随机 remask，前一半的步骤能正确 decoding 出 97.2%，前 25% 步骤能正确 decoding 出 88.5% 作者添加了后缀提示“Answer”，显著提高了早期 decoding 的效果，在在随机 remask 下，25% 的步骤已经可以正确 decoding 出 94.6% 的 token 了 图 2 表明，大部分非答案 token（绿框上下的 token）在最终确定前频繁波动，但是答案 token（绿框中的 token）倾向于较早期就趋于稳定（左图是到一半的步骤时，答案 token 就停止变化了，右图是不到一半时就停止变化了，所以有至少一半的步骤是不需要的） 方法 # Prophet，Trainingfree，在模型预测稳定后立即预测答案，并一次性 decoing 所有剩余 token\n每次 forward，diffusion 模型会生成一个 shape 为 \\(seq\\_len \\times vocab\\_size\\)的 logit 矩阵，对于每个位置，取出其中最高 logit 值 \\(L_{t,i}^{(1)}\\)和次高 logit 值\\(L_{t,i}^{(2)}\\)，并作差\n$$ g_{t,i}=L_{t,i}^{(1)}-L_{t,i}^{(2)} $$设计三个阈值超参 \\(\\tau_{hight}、\\tau_{mid}、\\tau_{low}\\) ，分别对应所有 decoding 步数的前 1/3、中 1/3 和后 1/3，如果 \\(g_{t,i}\u003e\\tau\\)则把这个 token 确定下来（greedy，选 logit 最大的）。随着解码步数的增大，即：\n$$ \\tau_{hight}\\gt\\tau_{mid}\\gt\\tau_{low} $$ 实验 # 模型： LLaDA-8B、Dream-7B\n比较 3 种 decoding 策略，Full 代表标准的 diffusion，完整的步数 budget 为 50，Half 是一个简单的 baseline，将 budget 设置为 25，Prophet 为作者的方法， \\(\\tau_{hight}=8.0， \\tau_{mid}=5.0， \\tau_{low}=3.0\\)\n数据集：MMLU、ARC-Challenge、HellaSwag、TruthfulQA、WinoGrande、PIQA、GSM8K、GPQA、Countdown、Sudoku\n采用贪婪解码\nAcc 基本持平甚至，速度 1.6x~3.4x\n未汇报 Half 的结果 ","date":"2025 Oct 10","externalUrl":null,"permalink":"/posts/prophetdiffusion%E6%A8%A1%E5%9E%8B%E5%9F%BA%E4%BA%8E%E7%BD%AE%E4%BF%A1%E5%BA%A6%E7%9A%84decoding%E6%97%A9%E5%81%9C/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eProphet：Diffusion 模型基于置信度的 Decoding 早停\n    \u003cdiv id=\"prophetdiffusion-模型基于置信度的-decoding-早停\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#prophetdiffusion-%e6%a8%a1%e5%9e%8b%e5%9f%ba%e4%ba%8e%e7%bd%ae%e4%bf%a1%e5%ba%a6%e7%9a%84-decoding-%e6%97%a9%e5%81%9c\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eProphet: Fast Decoding for Diffusion Language Models\u003c/p\u003e","title":"Prophet：Diffusion模型基于置信度的Decoding早停","type":"posts"},{"content":"","date":"2025 Oct 10","externalUrl":null,"permalink":"/tags/spec/","section":"Tags","summary":"","title":"Spec","type":"tags"},{"content":" SpecDiff：使用扩散模型作为 Draft 模型 # Speculative Diffusion Decoding: Accelerating Language Generation through Diffusion\n摘要 # 推测解码已成为一种广泛采用的方法，可在不牺牲模型输出质量的前提下加速大语言模型的推理过程。尽管该技术通过实现并行序列验证显著提高了生成速度，但其效率仍受限于现有 Draft 模型中对逐个 token 生成的依赖。为克服这一限制，本文提出了一种改进的推测解码方法，该方法使用离散 Diffusion 模型生成草稿序列。这使得 Draft 生成和验证两个步骤均可并行化，从而显著加快推理过程。我们提出的方法——推测扩散解码（Speculative Diffusion Decoding，SpecDiff），在标准语言生成基准任务上进行了验证，实验证明其相比标准生成方法可实现最高达 7.2 倍的加速，相比现有推测解码方法最高可达 1.75 倍的加速。\n动机 # 已有的加速投机采样的研究主要集中在引入额外的并行化技术，然而，生成效率的提升是以每次生成所需的操作数量和/或内存的显著增加为代价的。 作为 Draft 模型，Diffusion 模型在速度和质量上取得了一个平衡 且使用 Diffusion 模型作为 Draft 模型，可以实现 Draft 的并行化 先前的研究让大家先入为主认为 Target 和 Draft 模型应当是同系列模型，而本文提出质疑 投机采样需要精调超参（比如 Draft 生成的 token 数），但是如果使用扩散模型作为 Draft 就对于这个超参精度要求没那么高，因为其生成都是并行的，所以调大了损失不大 方法 # 方法比较常规\n下面算法中的“当 diffusion 模型降噪 T 步生成 draft”是作者强调的 SpecDiff 和 Speculative Decoding 方法不同的地方…… 因为可以降噪 T 步生成 gamma 个 token，而 gamma\u0026gt;T T 这个参数仅用于提高 Draft 模型输出的质量 当 diffusion 模型降噪 T 步生成 draft 用 Target 获得所有 token 概率 按照投机采样的方式接受 or 拒绝 token T 次去噪，生成 gamma 个 token 使用 Target 进行 Verify 进行标准的投机采样，找到第一个 reject 的位置 n 如果未全部 accept，则直接输出 否则，对于第 n+1 个位置从调整后的分布中采样一个 token，并回到第一步 调整分布的方法：\n设 Target 的分布为 P(x)={A:0.6, B:0.3, C:0.1}，Draft 的分布为 Q(x)={A:0.4, B:0.5, C:0.1}\nDraft 输出的 B 被 Target 拒绝，并从 max(0, P(x)-Q(x))={A:0.2, B:0, C:0}\n这样做的目的是防止 B 再一次从 P(x)里被取样出来，导致效果不佳\n但是可能会有一个问题\n由于 Diffusion 和 Autoregressive 模型大概率不是同一个系列的模型，他们的概率分布可能有较大差异，因此作者又引入了一个方法，即对最初的几个 Token 采用标准的投机采样，从而在一开始就优化了 SpecDiff 的性能\n没提到所谓的“标准的投机采样”是怎么做的 实验 # 数据集：CNN/DM（文本总结）、OpenWebText（文本生成）、MT Bench（文本生成）\n采样策略：Greedy，nums_of_tokens = 1024\n模型：\nTarget：GPT-2 XL（1.5B）、GPT-Neo（2.7B）、Vicuna（33B）\nDraft：\nOurs: Masked Diffusion Language Model（MDLM，110M） Baseline: GPT-2 (86M) 硬件：A100（80G，CUDA 12.2）\n应用了 FlashAttention\nDraft 一次生成 gamma 个 token 后再交给 Target 检查\n$$ \\alpha=\\frac{Draft被接受的token数}{Draft总token数} $$看上去相比较于标准的投机采样，只实现了 1.5x 左右的加速\n下图中的 Task Speedup 是模型在对应数据集上的加速效果，Overall Speedup 是在所有 Spec-Bench (Xia et al., 2024) tasks 上测量的平均成绩\n如果不在初始阶段先进行几个 token 的投机采样，速度会有些微的下降\nLimitation # Diffusion 经常过于自信，导致对选中的 token 的概率过高（尤其是 temp\u0026gt;0 的情况下），容易导致 reject。需要想办法对齐 Diffusion Draft 和 Target 的概率 在短序列生成任务中效果并不明显 ","date":"2025 Oct 10","externalUrl":null,"permalink":"/posts/specdiff%E4%BD%BF%E7%94%A8%E6%89%A9%E6%95%A3%E6%A8%A1%E5%9E%8B%E4%BD%9C%E4%B8%BAdraft%E6%A8%A1%E5%9E%8B/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eSpecDiff：使用扩散模型作为 Draft 模型\n    \u003cdiv id=\"specdiff使用扩散模型作为-draft-模型\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#specdiff%e4%bd%bf%e7%94%a8%e6%89%a9%e6%95%a3%e6%a8%a1%e5%9e%8b%e4%bd%9c%e4%b8%ba-draft-%e6%a8%a1%e5%9e%8b\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eSpeculative Diffusion Decoding: Accelerating Language Generation through Diffusion\u003c/p\u003e","title":"SpecDiff：使用扩散模型作为Draft模型","type":"posts"},{"content":" DiffuSpec：解锁 DLM 做投机采样 # DIFFUSPEC: UNLOCKING DIFFUSION LANGUAGE MODELS FOR SPECULATIVE DECODING\n摘要 # 随着大语言模型（LLMs）规模的扩大，准确性得到提升，但解码过程的自回归（AR）特性导致延迟增加，因为每个 token 都需要一次串行的前向传播。推测性解码通过引入一个快速的起草模型来提出多 token 草案，并由目标模型并行验证这些草案，从而缓解该问题。然而，许多部署仍依赖于自回归（AR）起草模型，其串行计算限制了实际时钟时间的加速效果。我们重新审视了起草阶段，提出了 DiffuSpec——一种无需训练、可直接集成的框架，利用预训练的扩散语言模型（DLM）在单次前向传播中生成多 token 草案，同时保持与标准自回归验证器的兼容性。由于 DLM 草案是在双向条件下生成的，各位置并行生成的候选 token 构成一个 token 格，其中每个位置局部概率最高的 token 并不一定形成符合因果顺序的从左到右路径。此外，DLM 起草需要预先指定草案长度，这引入了速度与质量之间的权衡。为应对这些挑战，我们引入两个实用组件：（i）在该格上进行的因果一致性路径搜索（CPS），用于提取一条与自回归验证对齐的从左到右路径；（ii）自适应草案长度（ADL）控制器，根据最近的接受反馈和实际生成长度动态调整下一次提案的大小。在多个基准测试中，DiffuSpec 实现了最高达 3 倍的时钟时间加速，确立了基于扩散模型的起草方法作为推测性解码中自回归起草器的一种稳健替代方案。\nMotivation # dlm 可以在一次 forward 中给出一整个 block 的 token 候选，并可选的对这些 token 进行迭代优化。这些能力刚好契合 draft 的核心需求——更高的吞吐量和更高质量的候选提议。然而 dlm 的 token 是在上下文同时作用下生成的，而非严格的从左到右的因果依赖。这导致形成一个扩散 token 格（diffusion token lattice），其节点为每个位置上的候选 token，其中局部最高概率的 token 未必构成一条符合因果性的从左到右路径。此外，DLM 生成需要预先设定草稿长度。这些特性共同引出了我们研究的两个实际问题：（i）因果对齐：如何从该格结构中选择一条与自回归（AR）验证相一致的从左到右路径以最大化接受率；以及（ii）草稿长度：**如何选择块大小以在生成成本和验证接受率之间取得平衡，因为更长的草稿会增加提议成本，却不能保证更高的接受率。**尽管已有并行工作开始探索基于扩散的 drafters（Christopher et al., 2024），但一种无需训练、即插即用且系统性处理因果一致性与草稿长度的框架仍缺乏充分研究。\n方法 # 因果一致的路径搜索（Causal-Consistency Path Search，CPS） # dlm 对于每个 token 会生成很多 logits，基于这些 logits 计算出该 token 不同选项的概率，找到累计概率大于等于 \\(\\tau\\)（超参数，0.8） 的地方，保留所有候选项\n如果候选项太多，则只保留 M_max 个（超参数，15）\n然后对于保留下来的所有路径使用 n-gram 或小的因果 LM 打分（论文中使用 3-gram KenLM）\n\\(\\pi\\)代表一条路径， \\(\\pi_i\\)代表路径中第 i 个 token，使用下面的函数对于推理路径进行综合打分，中括号内左侧代表 lambda 乘 dlm 自己对这个 token 的概率，右侧是（1-lambda）乘小因果 LM 对这个 token 的概率，lambda 是一个超参数（0.5）\n这样实现了 dlm 和因果的综合打分，选出得分最高的路径，传入后续步骤\n自适应草稿长度（ADAPTIVE DRAFT LENGTH，ADL） # DLM 中长度有那么重要吗？更重要的不应该是 steps 吗？ Motivation # 草案长度 kt 共同决定了起草成本、提案质量和验证器接受率。较短的草案往往产生简略的片段；适中的草案能够捕捉更完整的推理过程；而过长的草案则会使内容饱和并触发提前的 EOS，同时积累大量偏离路径的 token，这些 token 会被验证器拒绝。从经验上看，EOS 感知的生成长度 Lgen 随 kt 增加而后趋于饱和，且被接受的长度 Lacc 跟随其变化\n固定的 kt 要么在过长时浪费计算资源，要么在过短时限制进展，这促使我们引入一种自适应控制器。\n方法 # 在 CPS 之前，先计算 draft 在 EOS 前生成了多少 token，如果没有 EOS 就是生成的 draft length，获得 \\(L^{gen}_t\\);并设 CPS 后 Target 接受的长度为\\(L^{acc}_t\\)，其中 t 是投机采样中的解码轮次，target 做了几次 verify，t 就是几\n为了避免不同的 t 之间差异太大导致方差太大（图 5 的蓝色阴影部分），作者对于上面的两个 L 进行了平滑处理\n其中 \\(\\rho\\)也是超参数（0.5）\n于是更新下一次的 draft token 数如下：\ndelta（10），k_min=20, k_max=30\n合并 CPS 和 ADL # 实验 # 数据集：Multiturn Conversation（MT）、Machine Translation（Trans）、Summarization（Sum）、Open-domain QA（QA）、Mathematical Reasoning（Math）、Retrieval-Augmented Generation（RAG）\n指标：平均接受 Token 数（Mean Accepted Tokens, MAT）、比 AR 贪婪采样加速比（Speedup）\nBaseline：\nTraining Free\n经典的投机采样（SPS） 前瞻性解码 Lookahead（构造[I, love, [MASK], [MASK]]，使用 Target 并行预测多个 MASK，并将预测出来的内容拼起来当作草稿，再输入 Target 进行验证） PLD（适用于 few-shot 提示，拿 answer 的前缀去 prompt 做 n-gram，并将匹配到的内容作为 draft 送入 Target） Recycling（维护一个 token 图，将被接受的 token 序列放入图中，下次遇到相似的 token 直接在图里进行 BFS，将 BFS 的结果作为 draft 送入 Target） SAMD（维护一个大型 offline 的语料库，如果匹配到了类似的字符串前缀则直接取出相关语料作为 draft 送入 Target） Training Based\nMedusa（给模型增加多个预测 head，基于当前的 hidden state 估算未来几个 token，有点像 lookahead） Hydra（类似 Medusa，但是每个 head 使用的是上一个 head 给出的 hidden state，将 Medusa 的并行改为了串行，但是提高了草稿质量实现了加速） EAGLE（为模型增加 EAGLE predictor heads，在单次前向传播中预测未来多个 token，同时增加一个自回归验证信号 (accept/reject)，用以估计每个 token 是否能被 Target 接受） EAGLE2（改进 EAGLE，添加动态 draft length、模型内部学习“何时应该停”与“何时继续预测”，即自适应验证边界） 模型：Target Qwen2.5-32B、Draft Dream-7B\n由于 Training based 的方法没有兼容 Qwen2.5-32B 的 checkpoints 开源，所以作者选择汇报 Vicuna-33B 的结果\n其他细节：A100、bs=1、启用 KV cache、DiffuSpec 设置 step=1\n消融 # ","date":"2025 Oct 10","externalUrl":null,"permalink":"/posts/diffuspec%E8%A7%A3%E9%94%81dlm%E5%81%9A%E6%8A%95%E6%9C%BA%E9%87%87%E6%A0%B7/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eDiffuSpec：解锁 DLM 做投机采样\n    \u003cdiv id=\"diffuspec解锁-dlm-做投机采样\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#diffuspec%e8%a7%a3%e9%94%81-dlm-%e5%81%9a%e6%8a%95%e6%9c%ba%e9%87%87%e6%a0%b7\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eDIFFUSPEC: UNLOCKING DIFFUSION LANGUAGE  MODELS FOR SPECULATIVE DECODING\u003c/p\u003e","title":"DiffuSpec：解锁DLM做投机采样","type":"posts"},{"content":"","date":"2025 Sep 5","externalUrl":null,"permalink":"/tags/fastapi/","section":"Tags","summary":"","title":"FastAPI","type":"tags"},{"content":"","date":"2025 Sep 5","externalUrl":null,"permalink":"/tags/nginx/","section":"Tags","summary":"","title":"Nginx","type":"tags"},{"content":"","date":"2025 Sep 5","externalUrl":null,"permalink":"/tags/python%E5%90%8E%E7%AB%AF/","section":"Tags","summary":"","title":"Python后端","type":"tags"},{"content":"","date":"2025 Sep 5","externalUrl":null,"permalink":"/tags/web%E6%9C%8D%E5%8A%A1%E9%85%8D%E7%BD%AE/","section":"Tags","summary":"","title":"Web服务配置","type":"tags"},{"content":"","date":"2025 Sep 5","externalUrl":null,"permalink":"/tags/%E9%83%A8%E7%BD%B2/","section":"Tags","summary":"","title":"部署","type":"tags"},{"content":" 后端部署第二步：本地到公网——如何使用 Nginx 发布 FastAPI 服务 # 在当今的开发环境中，快速构建和部署后端服务变得至关重要。FastAPI 作为一个高性能、现代化的 Python 异步 Web 框架，广受开发者喜爱。而 Nginx 则是部署 Web 应用最常见也是最稳定的解决方案之一。\n本文将手把手带你完成如下目标：\n启动一个最小 FastAPI 应用； 使用 Nginx 把服务代理到 80 端口； 实现通过公网 IP 或域名访问服务。 不需要复杂的设置，只需几个步骤，就能让你的本地服务走向世界。\n前提条件 # 请确保你已经具备以下环境：\n一台可以访问公网的 Linux 服务器或云主机（如 AWS EC2、腾讯云、阿里云等）； 已安装 Python 3.7+； 已安装 Nginx； 有一些基本的 Linux 操作经验。 如果你准备好了，就让我们开始吧！\n第一步：创建并启动一个最小 FastAPI 后端服务 # 首先，我们搭建一个最小可运行的 FastAPI 应用。建议使用 Python 虚拟环境：\n# 安装依赖 sudo apt update sudo apt install python3-pip -y pip3 install fastapi uvicorn 接着，创建一个名为 main.py 的文件，内容如下：\n# main.py from fastapi import FastAPI app = FastAPI() @app.get(\u0026#34;/\u0026#34;) def read_root(): return {\u0026#34;message\u0026#34;: \u0026#34;Hello from FastAPI via Nginx!\u0026#34;} 使用 Uvicorn 启动服务：\nuvicorn main:app --host 0.0.0.0 --port 8000 此时你已经可以通过 http://\u0026lt;你的服务器IP\u0026gt;:8000 在浏览器中访问这个返回 JSON 的接口。\n第二步：安装并配置 Nginx # 如果还未安装 Nginx，请先执行以下命令安装：\nsudo apt install nginx -y 确保 Nginx 正常运行：\nsudo systemctl start nginx sudo systemctl enable nginx 第三步：配置 Nginx 作反向代理 # 我们需要编辑 Nginx 配置文件，将来自公网 80 端口的请求转发到本地的 8000 端口。\n新建一个配置文件（或编辑默认配置）：\nsudo nano /etc/nginx/sites-available/fastapi 请输入以下内容：\nserver { listen 80; server_name your_domain_or_ip; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } 替换 your_domain_or_ip 为你的实际公网 IP（如 123.456.78.9）或绑定的域名（如 api.example.com）。\n接下来，启用该配置：\nsudo ln -s /etc/nginx/sites-available/fastapi /etc/nginx/sites-enabled/ sudo nginx -t # 检查配置是否正确 sudo systemctl reload nginx 第四步：在防火墙中开放 80 端口（如有） # 如果你启用了防火墙（如 UFW），确保端口 80 是开放的：\nsudo ufw allow 80 第五步：测试访问 # 现在，一切已准备就绪：\n浏览器访问：http://your_domain_or_ip/ 示例：http://123.456.78.9/ 你应能看到如下 JSON 输出： {\u0026#34;message\u0026#34;: \u0026#34;Hello from FastAPI via Nginx!\u0026#34;} 恭喜你！你的 FastAPI 服务已经可以通过公网访问了！\n第六步：使用 systemd 管理 FastAPI 服务（推荐） # 虽然我们可以用 uvicorn 手动在终端启动 FastAPI 服务，但这种方式有两个明显的问题：\n当 SSH 会话断开时，uvicorn 会关闭； 服务无法随系统开机自动启动； 为了让 FastAPI 稳定运行在后台并具备开机自启功能，我们推荐使用 systemd 进行进程管理。\n接下来，我们将创建一个 systemd 单元文件来管理 FastAPI 服务。\n6.1 创建 FastAPI systemd 服务文件 # 假设你的主机上 FastAPI 项目的路径为 /home/ubuntu/fastapi-app，并在该目录下有一个 main.py 文件。\n以下步骤以 ubuntu 用户为例：\n编辑 systemd 服务文件： sudo nano /etc/systemd/system/fastapi.service 在文件中填写以下内容： [Unit] Description=FastAPI Application with Uvicorn After=network.target [Service] User=ubuntu WorkingDirectory=/home/ubuntu/fastapi-app ExecStart=/usr/bin/python3 -m uvicorn main:app --host 0.0.0.0 --port 8000 Restart=always RestartSec=3 Environment=PYTHONUNBUFFERED=1 [Install] WantedBy=multi-user.target 请根据你的实际路径和运行用户进行调整：\nWorkingDirectory 指向你的 FastAPI 应用目录； ExecStart 中使用的 python3 和运行参数视你的环境而定； 如果你使用虚拟环境，请指定对应虚拟环境下的 python 路径，比如： ExecStart=/home/ubuntu/fastapi-venv/bin/python -m uvicorn main:app --host 0.0.0.0 --port 8000 6.2 启用并启动服务 # 创建完文件后，执行以下命令：\nsudo systemctl daemon-reexec sudo systemctl daemon-reload sudo systemctl enable fastapi sudo systemctl start fastapi 现在你的服务已经注册为系统服务并自动启动了！\n6.3 查看服务状态 # 使用以下命令查看运行状态：\nsudo systemctl status fastapi 你应看到如下类似输出：\n● fastapi.service - FastAPI Application with Uvicorn Loaded: loaded (/etc/systemd/system/fastapi.service; enabled) Active: active (running) since ... ... 6.4 查看输出日志（可选） # 你可以使用 journalctl 查看程序输出日志：\nsudo journalctl -u fastapi -f 这将实时跟踪 FastAPI 服务的日志输出，方便调试请求和错误信息。\n6.5 重启与停止服务 # 重启服务：\nsudo systemctl restart fastapi 停止服务：\nsudo systemctl stop fastapi 为什么使用 systemd？ # 使用 systemd 管理服务的几大益处：\n稳定：系统守护进程会在服务崩溃时自动重启； 安全：服务以特定用户运行，避免 root 权限； 开机自启：确保服务器重启后服务仍能使用； 日志集中：方便使用 journalctl 跟踪日志和排错。 这是部署生产环境服务最推荐的方式之一。\n借助 systemd 配置，FastAPI 服务变成了一个真正的系统级网络服务。你无需手动启动，也不怕 SSH 会话断开。真正实现了后端“后台运行、永不掉线”的目标。\n常见问题排查 # 无法访问服务？ 检查是否正在运行 uvicorn； Nginx 是否启用正确配置并重新加载； 防火墙是否允许 80 端口； 是否将域名正确地解析到了服务器 IP。 ","date":"2025 Sep 5","externalUrl":null,"permalink":"/posts/%E5%90%8E%E7%AB%AF%E9%83%A8%E7%BD%B2%E7%AC%AC%E4%BA%8C%E6%AD%A5%E6%9C%AC%E5%9C%B0%E5%88%B0%E5%85%AC%E7%BD%91%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8-nginx-%E5%8F%91%E5%B8%83-fastapi-%E6%9C%8D%E5%8A%A1/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e后端部署第二步：本地到公网——如何使用 Nginx 发布 FastAPI 服务\n    \u003cdiv id=\"后端部署第二步本地到公网如何使用-nginx-发布-fastapi-服务\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#%e5%90%8e%e7%ab%af%e9%83%a8%e7%bd%b2%e7%ac%ac%e4%ba%8c%e6%ad%a5%e6%9c%ac%e5%9c%b0%e5%88%b0%e5%85%ac%e7%bd%91%e5%a6%82%e4%bd%95%e4%bd%bf%e7%94%a8-nginx-%e5%8f%91%e5%b8%83-fastapi-%e6%9c%8d%e5%8a%a1\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003e在当今的开发环境中，快速构建和部署后端服务变得至关重要。FastAPI 作为一个高性能、现代化的 Python 异步 Web 框架，广受开发者喜爱。而 Nginx 则是部署 Web 应用最常见也是最稳定的解决方案之一。\u003c/p\u003e","title":"后端部署第二步：本地到公网——如何使用 Nginx 发布 FastAPI 服务","type":"posts"},{"content":"","date":"2025 Sep 5","externalUrl":null,"permalink":"/categories/%E5%BC%80%E5%8F%91/","section":"Categories","summary":"","title":"开发","type":"categories"},{"content":"","date":"2025 Sep 5","externalUrl":null,"permalink":"/categories/%E8%BF%90%E7%BB%B4/","section":"Categories","summary":"","title":"运维","type":"categories"},{"content":" Fast-dLLM：通过 KV Cache 和并行 Decoding 加速 dLLM # Fast-dLLM: Training-free Acceleration of Diffusion LLM by Enabling KV Cache and Parallel Decoding\n摘要 # 基于扩散的大型语言模型（Diffusion LLMs）在非自回归文本生成方面表现出潜力。然而，由于缺乏 KV Cache 以及在同时解码多个 token 时的质量退化，开源 Diffusion LLMs 的实际推理速度通常落后于自回归模型。为了弥补这一差距，我们引入了 Fast-dLLM，这是一种针对双向扩散模型设计的新颖分块近似 KV 缓存机制，能够在性能下降可忽略的情况下实现缓存重用。此外，我们识别出并行解码中生成质量退化的主要原因是条件独立性假设下标记依赖关系的破坏。为了解决这个问题，Fast-dLLM 还提出了一种置信度感知的并行解码策略，仅对超过置信度阈值的标记进行解码，从而缓解依赖关系冲突并保持生成质量。在 LLaDA 和 Dream 模型上的实验结果表明，在准确率损失最小的情况下，吞吐量提升了最高 27.6 倍，缩小了与自回归模型的性能差距，并为 Diffusion LLMs 的实际部署铺平了道路。\nMotivation # dLLM 生成快，因为有并行 token 生成的潜力以及双向注意力机制 目前的 dLLM 没有 KV Cache，所以在实际应用中并不如 AR（autoregressive）模型，且 dLLM 同时生成多个 token 时，其质量会下降。 Masked Diffusion Model（MDM）生成过程 # 设在某时刻，整句话的噪声水平为 \\(t \\in (0,1]\\)，MDM 的功能就是让下一时刻，这句话的噪声水平为 \\(s \\in [0, t)\\)，也就是进行降噪。而整句话降噪完成的概率=每个 token 降噪完成的概率的乘积，即（设这句话有 n 个 token）：\n\\(q_{s|t}=\\prod_{i=0}^{n-1} q_{s|t}(x_s^i \\mid x_t)\\)\n其中如果 \\(x_t^i\\)已经生成（不为 MASK），则\\(q_{s|t}(x_s^i \\mid x_t)=1\\)（因为已经生成了，不需要修改了）\n如果\\(x_t^i\\)未生成（为 MASK），则有\\(\\frac st\\)的概率保持 MASK（例如从 t=1 降噪到 s=0.3，还剩余 30% 的 token 未生成），而有\\(1-\\frac st\\)的概率生成一个 token，且该 token 取自于\\(q_{0|t}(x_s^i \\mid x_t)\\)\n$$ q_{s|t}(x_s^i \\mid x_t) = \\begin{cases} 1, \u0026 x_t^i \\neq [MASK], \\; x_s^i = x_t^i \\\\[6pt] \\frac{s}{t}, \u0026 x_t^i = [MASK], \\; x_s^i = [MASK] \\\\[6pt] \\frac{t-s}{t} \\, q_{0|t}(x_s^i \\mid x_t), \u0026 x_t^i = [MASK], \\; x_s^i \\neq [MASK] \\end{cases} $$ 并行 Decoding 的问题 # 如果让 dLLM 补全下面这句话：\n两个字组成的扑克牌牌型是：[MASK][MASK]。\n可选答案有“同花”、“顺子”、“葫芦”、“高牌”等，如果是 AR 模型，当生成第一个字（比如“同”）之后下次 forward 会参考第一个字生成第二个字（“花”）。\n但是对于 dLLM，目前的采样方法是先为每个 token 生成一个概率分布，然后从这些分布中独立采样。这样就很可能导致不理想的组合，比如“同子”。\n所以并不能独立采样，而应当在联合概率中考虑依赖关系\n方法 # 块级 Decoding 的 KV Cache # 左侧图——前缀 KV Cache（Prefix KV Cache） # 先计算 Prompt 的 KV Cache，并在其相邻的下一个 Block（Block0）中使用，基于 Prompt Cache 生成 Block0 之后，基于 Prompt Cache 和 Block0 生成新的 Prompt+Block0 Cache（Block1 第一次去噪的时候顺便生成的，所以没有额外计算），用于生成 Block1\n在第一次去噪完成后，Block0 就生成了两个 token，按道理应当基于这两个 token 更新一下 Cache，可是并没有，作者解释如下：\n作者可视化出了不同推理步骤间 KV Cache 的相似性，作者发现相邻的推理步骤间的 KV Cache 十分接近，所以作者在 Block0 生成两个 token 后并没有立即更新 Cache，而是直接复用了 Cache 来更新剩余两个 token，待 Block0 都生成完成，才更新一次 Cache\n右侧图——双向 KV Cache（DualCache） # 不仅缓存前缀标记，还缓存后缀标记，在块解码方案下，这些后缀 token 完全由【MASK】组成。DualCache 进一步提高了加速效果。图 3b 中的红色框区域进一步表明，在块解码过程中后缀键和值的差异可以忽略不计。\n置信度感知的并行 Decoding # 在每次降噪过程中，并非激进地使用各自独立概率来生成所有被 mask 的 token，而是为每个 token 计算一个置信度分数（比如最大 softmax 概率）。\n如果有些 token 的置信度超过阈值，则在当前降噪步骤中被 decode 改 token，其他就仍然保持 mask 状态 如果没有 token 的置信度超过阈值，则只 decode 最高的 token 作者通过数学证明提出上述方法可以用于并行 Decoding 而尽可能避免产生刚刚提到的问题。得出只要满足置信度分数（softmax 概率） \\(\\gt \\frac{n}{n+1}\\)(n 为一共要生成的 token 个数，也就是一个 block 中的 token 数)就可以近似避免并行带来的问题，但是阈值越低，问题避免效果越差。\n于是引入一个超参数 f，只 decode \\(置信度 \\gt 1-\\frac{f}{n+1}\\)的 token\n实验 # 硬件：A100 80G\n超参：如未另外说明，则 block_size=32，使用了 Prefix Cache，f=0.9\n数据集：GSM8K、MATH、HumanEval、MBPP、MathVista（视觉数学）、MathVerse（视觉数学）\n模型：LLaDA、LLaDA-1.5、Dream、LLaDA-V（视觉）\n框架：lm-eval（原来还有一个专用于 lm 评估的框架）\n黑色为 Acc，蓝色是 token per second，红色是加速比\n主实验 # LLaDA： # Dream # LLaDA-V # 其他实验 # Block Size 的选择 # 阈值对于 Acc、Steps 的影响 # DualCache # 放在文章一开始结果 # ","date":"2025 Sep 5","externalUrl":null,"permalink":"/posts/fast-dllm%E9%80%9A%E8%BF%87kv-cache%E5%92%8C%E5%B9%B6%E8%A1%8Cdecoding%E5%8A%A0%E9%80%9Fdllm/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eFast-dLLM：通过 KV Cache 和并行 Decoding 加速 dLLM\n    \u003cdiv id=\"fast-dllm通过-kv-cache-和并行-decoding-加速-dllm\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#fast-dllm%e9%80%9a%e8%bf%87-kv-cache-%e5%92%8c%e5%b9%b6%e8%a1%8c-decoding-%e5%8a%a0%e9%80%9f-dllm\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eFast-dLLM: Training-free Acceleration of Diffusion LLM by Enabling KV Cache and Parallel Decoding\u003c/p\u003e","title":"Fast-dLLM：通过KV Cache和并行Decoding加速dLLM","type":"posts"},{"content":"","date":"2025 Sep 3","externalUrl":null,"permalink":"/tags/%E6%9C%8D%E5%8A%A1%E5%99%A8/","section":"Tags","summary":"","title":"服务器","type":"tags"},{"content":"","date":"2025 Sep 3","externalUrl":null,"permalink":"/tags/%E5%90%8E%E7%AB%AF/","section":"Tags","summary":"","title":"后端","type":"tags"},{"content":" 后端部署第一步：Nginx 发布服务前的准备工作 # 你是不是刚刚用 Java、Python 或 Go 写出了第一个后端程序？它在本地跑得飞快，通过 localhost:8080 就能访问，功能也都挺顺畅。接下来，自然而然会冒出一个念头：“我要怎样才能让别人也能访问到它？”\n把一个后端服务从本地搬到公网，其实没有想象中复杂。本文不涉及深奥的配置，而是带你先把部署前的关键步骤和必备知识捋清楚。等地基打牢，后续配置就水到渠成。\n为什么需要 Nginx？ # 想象一下，一家公司有很多部门：技术部、财务部、人事部。如果没有前台，客户走进公司就得自己乱逛，不仅效率低，还可能跑到不该去的地方。\n前台的作用就是先接待所有来访的人，再把他们送到正确的部门。\n在部署环境里：\n你的 后端服务 就是各个部门（可能分别跑在 8080、5000 端口）。 Nginx 就是前台。 用户的浏览器请求，就是来访的客户。 Nginx 接收来自公网的请求，再转发到对应的服务，这就是所谓的 反向代理。\ngraph TD A[用户浏览器访问你的网站] --\u003e|HTTP 请求| B[Nginx（公网 IP）] B --\u003e|转发到 8080端口| C[Java服务 #1] B --\u003e|转发到 5000端口| D[Python服务 #2] C --\u003e|响应数据| B D --\u003e|响应数据| B B --\u003e|响应返回给用户| A 为什么推荐用 Nginx？\n用户只会接触到 Nginx，不会直接触碰到后端服务，更安全。 所有流量统一从 Nginx 入口进入，方便管理。 支持负载均衡，能把请求分发到多个后端实例。 处理静态文件的效率极高，比大多数后端框架要快。 一句话：Nginx 是后端服务的门面，专业、高效、又可靠。\n内网和公网：两个不同的世界 # 在本地调试时，你访问的是 localhost 或 127.0.0.1，这个地址只在你自己电脑上有效，别人根本连不上。\n如果想让所有人都能访问，就必须把服务部署到一台有 公网 IP 的机器上。这就像房子的门牌号：只有在全球唯一的地址，别人才能找到你。\n所以我们的目标就是：用一台有公网 IP 的服务器跑 Nginx，把外部请求转发给只在内网可见的后端服务。\n部署前需要准备什么？ # 在正式上路之前，你得先备齐工具。简单梳理一下：\n1. 一台云服务器 # 去阿里云、腾讯云等平台买一台带公网 IP 的轻量服务器就行，新手入门用 1 核 CPU + 1~2G 内存的配置完全够用。\n2. Linux 系统（推荐 Ubuntu） # 服务器也需要操作系统。Linux 是绝对主流，其中 Ubuntu 对新手最友好，文档和教程都很多。买服务器时直接选 Ubuntu 20.04 或 22.04 就好。\n3. 域名和 DNS # 记住一长串 IP 地址不现实，域名就是更好记的“昵称”。当然，如果没有域名，其实用IP访问也是可以的。 如果你需要域名，那就去买个自己喜欢的域名（比如 my-app.com），然后在域名管理后台添加一条 A 记录，指向你服务器的公网 IP。这样别人输入域名就能找到你的服务。\nsequenceDiagram participant User as 用户浏览器 participant DNS as DNS服务器 participant Server as 你的云服务器 User-\u003e\u003eDNS: 访问 my-app.com DNS--\u003e\u003eUser: 返回 IP 地址（如 123.123.123.123） User-\u003e\u003eServer: 向 123.123.123.123 发送 HTTP 请求 Server--\u003e\u003eUser: 返回网页内容 4. 防火墙与安全组 # 服务器默认不可能对外敞开所有大门。 只需开放最必要的端口：\n22 用于远程登录（SSH） 80 用于 HTTP 443 用于 HTTPS 其他端口一律关掉，养成好习惯。\n当然如果你的服务并不出名且你认为足够安全，直接关闭防火墙、放行全部安全组也并非不可。但是不建议这样做\n在 Ubuntu 上安装 Nginx # 一切准备就绪后，登录到服务器，输入以下命令：\n# 1. 更新软件包列表，确保我们能安装到最新的软件 sudo apt update # 2. 安装 Nginx sudo apt install nginx -y # 3. 启动 Nginx 服务 (通常安装后会自动启动，这步是为确保) sudo systemctl start nginx # 4. 设置 Nginx 开机自启 sudo systemctl enable nginx 完成后，在浏览器里访问你服务器的公网 IP，如果看到 “Welcome to nginx!” 页面，就说明 Nginx 已经正常运行。\n小结 # 到这里，你已经完成了从“本地孤岛”到“具备公网门面”的第一步：\n了解了 Nginx 的角色和作用 理解了内网与公网的区别 知道了云服务器、域名、DNS、防火墙的基本用法 在服务器上亲手跑起来了 Nginx 下一篇文章，我们将动手配置 Nginx，把 localhost:8080 上的后端服务真正挂到你的域名上，正式对外开放。\n","date":"2025 Sep 3","externalUrl":null,"permalink":"/posts/%E5%90%8E%E7%AB%AF%E9%83%A8%E7%BD%B2%E7%AC%AC%E4%B8%80%E6%AD%A5nginx-%E5%8F%91%E5%B8%83%E6%9C%8D%E5%8A%A1%E5%89%8D%E7%9A%84%E4%B8%87%E5%85%A8%E5%87%86%E5%A4%87/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e后端部署第一步：Nginx 发布服务前的准备工作\n    \u003cdiv id=\"后端部署第一步nginx-发布服务前的准备工作\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#%e5%90%8e%e7%ab%af%e9%83%a8%e7%bd%b2%e7%ac%ac%e4%b8%80%e6%ad%a5nginx-%e5%8f%91%e5%b8%83%e6%9c%8d%e5%8a%a1%e5%89%8d%e7%9a%84%e5%87%86%e5%a4%87%e5%b7%a5%e4%bd%9c\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003e你是不是刚刚用 Java、Python 或 Go 写出了第一个后端程序？它在本地跑得飞快，通过\n\u003ccode\u003elocalhost:8080\u003c/code\u003e 就能访问，功能也都挺顺畅。接下来，自然而然会冒出一个念头：\u003cstrong\u003e“我要怎样才能让别人也能访问到它？”\u003c/strong\u003e\u003c/p\u003e","title":"后端部署第一步：Nginx 发布服务前的万全准备","type":"posts"},{"content":" 自信地深度思考 # DEEP THINK WITH CONFIDENCE\n摘要 # 大型语言模型（LLMs）通过测试时扩展方法（如基于多数投票的自洽性）在推理任务中展现了巨大的潜力。然而，这种方法通常会导致准确率提升逐渐减弱和计算开销过高。为了解决这些挑战，我们引入了“置信度深度思考”（DeepConf），这是一种简单而有效的方法，在测试时增强了推理效率和性能。DeepConf 利用模型内部的置信度信号，在生成过程中或生成后动态过滤掉低质量的推理路径。它不需要额外的模型训练或超参数调优，并可以无缝集成到现有的服务框架中。我们在多种推理任务和最新的开源模型（包括 Qwen 3 和 GPT-OSS 系列）上评估了 DeepConf。值得注意的是，在 AIME 2025 等具有挑战性的基准测试中，DeepConf@512 实现了高达 99.9% 的准确率，并相比完整的并行思考减少了最多 84.7% 的生成标记数。\n动机 # 先前的研究通过多个推理路径多数投票能提高 Acc，但是带来了大量的计算开销 多数投票平等对待每个推理路径，但是低质量的路径可能会导致次优的性能 也有方法在整条轨迹上计算全局置信度度量，以识别并过滤低质量轨迹，从而提高多数投票性能。但是全局置信度可能掩盖局部推理步骤中的置信度波动，而这些波动可以为估计追踪质量提供足够的信号。对整个追踪中的所有标记进行平均可能会掩盖在特定中间步骤中发生的关键推理故障。其次，全局置信度度量需要在计算之前生成完整的推理追踪，这会阻碍对低质量追踪的早期停止。 有研究表明，可以通过模型内部的 Token 分布得出的度量来有效评估推理轨迹的质量，于是定义 Token 置信度为位置 i 处前 k 个标记的负平均对数概率：\n定义整个推理轨迹中的 Token 置信度的平均值为模型对于整个轨迹的置信度\n作者认为平均轨迹置信度会掩盖中间推理的失败（少数高置信度 token 会掩盖低置信度片段。其次，这种方法需要完整的轨迹来进行质量评估，这阻止了低质量生成的早期终止，导致计算效率低下。）\n方法 # 新的置信度测量方式 # 组置信度 # 每个标记都与一个滑动窗口组 Gi 相关联，该组由 n 个先前的标记（例如，n = 1024 或 2048）组成，相邻窗口之间存在重叠。对于每个组 Gi，组置信度该组所有 token 置信度的平均值。\n我们观察到，轨迹中置信度极低的中间步骤会显著影响最终解决方案的正确性。例如，当在使用“wait”、“however”和“think again”等重复低置信度标记进行推理时，置信度急剧下降会破坏推理流程，并导致后续错误。\n底部 10% 组置信度 # 为了捕捉极低置信度组的影响，作者提出了底部 10% 组置信度，其中轨迹置信度由轨迹内组置信度底部 10% 组置信度的均值确定。\n其中 Gb 是置信度得分最低的 10% 的组的集合。实证研究表明，10% 能够有效捕捉不同模型和数据集中最有问题的推理片段。\n最低组置信度 # 作者还考虑最低组置信度，这表示在推理轨迹中置信度最低的组的置信度——即前 10% 最低置信度组的一个特例。该指标仅基于最低置信度组来估计轨迹质量：\n尾部置信度 # 通过关注推理轨迹的最后部分来评估推理轨迹的可靠性。该指标的提出是基于观察到推理质量通常会在长链思维的末尾下降，而最后步骤对于得出正确结论至关重要。在数学推理中，最终答案和结论步骤尤为重要：那些开始表现良好但结尾较弱的轨迹可能会产生错误的结果，尽管中间推理看起来很有希望。\n其中 T_tail 代表一组固定数量的 token，如 2048\n作者统计了在 HMMT25 的 30 个问题上，30*4096 个轨迹的推理结果\n离线带置信度的思考 # 采用多数投票的方法，但是使用置信度加权\n并应用置信度过滤器（只使用前 η% 的推理轨迹）\n在线带置信度思考 # 在在线思考过程中评估置信度，能够在生成过程中实时估计轨迹质量，并允许动态终止没有前景的轨迹。这种方法在资源受限的环境或需要快速响应的情况下尤其有价值。最低组置信度指标在此在线设置中可以有效应用。当标记组置信度低于临界阈值时，我们可以停止轨迹生成，确保这些轨迹在置信度过滤过程中很可能会被排除。\n作者提出一种办法（基于最低组置信度），可以在推理时提前停止希望不大的路径，具体包含两个部分：离线预热和自适应采样\n离线预热 # 离线预热是为了找到一个判断可以提前终止的阈值 s。对于每个新的 Prompt，生成 N 个推理轨迹，于是停止阈值定义为\n其中 T_{warmup}表示所有的预热轨迹，Ct 是轨迹 t 的置信度，η 是期望保留比例\n具体来说就是找了个分位点 s\n自适应采样 # 根据问题难度动态决定 N 为多少。难度通过生成轨迹之间的共识进行评估，其量化方式为多数投票权重与总投票权重的比值\n设置一个超参数 τ，如果 β\u0026lt;τ，则认为当前模型未达成共识，就继续推理，直到达到固定的推理预算 B。否则，追踪生成停止，使用现有的追踪确定最终答案。\n实验 # 模型：DeepSeek-r1-distill-qwen3-8b、Qwen3-8B、Qwen3-32B、GPT-OSS-20B、GPT-OSS-120B\n数据集：AIME24、AIME25、BRUMO25、HMMT25、GPQA\nBaseline：多数投票（每个大语言模型采样 T 个独立的推理路径，并通过无权重多数投票选择最终答案）\n实验设置：每个 Prompt 提前生成 4096 个完整推理轨迹来建立一个共同的采样框架，离线实验在每次运行时从该池中重新采样大小为 K（例如，K=512）的工作集，并应用指定的投票方法。在线实验同样重新采样一个工作集，以驱动即时生成并提前停止；该池确保了不同方法之间的采样一致性。对于滑动窗口计算置信度的的 window size 是 2048 个 token，N=16，τ=0.95\nPass@1 是一次推理，Cons@K 是无权重 K 次投票，Measure@K 是置信度权重的多数投票\n下图是 offline\n下图是 online\n这样比 token 数量吗\u0026hellip; Token 数量乘以 10^8 为 512 次推理 token 总量 ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/%E8%87%AA%E4%BF%A1%E5%9C%B0%E6%B7%B1%E5%BA%A6%E6%80%9D%E8%80%83/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e自信地深度思考\n    \u003cdiv id=\"自信地深度思考\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#%e8%87%aa%e4%bf%a1%e5%9c%b0%e6%b7%b1%e5%ba%a6%e6%80%9d%e8%80%83\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eDEEP THINK WITH CONFIDENCE\u003c/p\u003e","title":"自信地深度思考","type":"posts"},{"content":" TriangleMix：无损且高效的用于预填充阶段的注意力模式 # TriangleMix: A Lossless and Efficient Attention Pattern for Long Context Prefilling\n摘要 # LLM 依赖于注意力机制，其时间复杂度随着输入序列长度的增长而呈二次方增长，从而在 Prefilling 阶段产生显著的计算瓶颈。现有的静态稀疏注意力方法通常会降低准确率，而动态稀疏方法则由于在运行时需要估计稀疏索引而引入了额外的计算开销。为了解决这些局限性，我们提出 TriangleMix，一种无需训练的静态注意力模式。TriangleMix 在浅层中使用密集注意力，并在深层中切换为三角形形状的稀疏模式。大量实验表明，在深层中 TriangleMix 可将注意力开销减少 3.7 倍至 15.3 倍，并在不牺牲模型准确率的前提下，对于长度从 32K 到 128K 的序列，整体首次生成延迟（Time-to-First-Token, TTFT）减少了 12% 至 32%。此外，TriangleMix 可以与动态稀疏方法无缝结合，从而实现进一步加速，例如在 128K 序列长度下使 MInference 加速 19%，凸显了其提升 LLM 推理效率的潜力。\nMotivation # 先前研究揭示，Attention 计算是 LLM Prefilling 阶段的关键瓶颈（Jiang et al., 2024a; Lai et al., 2025）\n现有的静态和动态稀疏注意力方法存在不足\n静态稀疏注意力在长上下文中表现不佳（如 StreamingLLM（Xiao 等，2023））将计算复杂度从 O(N²) 降低至 O(N)，但在长上下文任务中会带来明显的性能下降（Li 等，2024a） 动态稀疏方法（如 MInference（Jiang 等，2024a）和 FlexPrefill（Lai 等，2025））旨在通过在推理过程中动态计算稀疏注意力索引。动态稀疏性方法在处理极长上下文（例如，超过 128K token）时是有效的。然而，由于在运行时需要估计稀疏块索引，它们会带来额外的开销。虽然这一开销在上下文非常长时可以忽略不计。但是如果上下文在 32K to 128K 时就有问题，这些开销无法忽略，如下表，MInference 在 32k 上下文是消耗时间比 Dense 更长，而 FlexPrefill 仅实现了 1.4x 的加速 所以作者希望开发一种静态注意力模式，以有效加速各种上下文长度下的预填充阶段。为实现该目标，我们提出了一种基于梯度的全新方法，用于识别注意力图中的关键部分。\n方法 # 稀疏注意力 # 原版的注意力：\nM 是一个因果 mask 矩阵，是一个 01 矩阵\nQKV 的 shape 为(N, d)，则 M 的 shape 为(N,N)，c 是一个巨大的正常数以确保前面计算的数据可以被 Mask 掉\n稀疏注意力则是通过找出一个稀疏 mask M‘来加速计算，M‘ mask 掉的数据比 M 多，所以计算少，所以快\n并确保 |A-A\u0026rsquo;| 不会太大，以保证性能\n现有的稀疏注意力方法分为两类：静态稀疏性和动态稀疏性。在静态稀疏性中，稀疏掩码 M ′ 是固定的，不依赖于输入。例如，StreamingLLM 表明，大多数注意力分数集中在前几个 sink token 以及滑动窗口中的邻近 token 上（Xiao 等，2023）。这导致了下图绿色的 mask（只计算绿色），但是长上下文中性能下降显著\n而动态稀疏注意力就是基于 QK 估算 M‘，往往有较高性能且长上下文中优势显著，但是对于中短上下文则不能提高较高的加速效果、甚至反而不如稠密注意力快\n对于注意力的分类 # 作者为了分析 Attention，将注意力分为下面三类：\n流式部分：包含注意力下沉的（attention sink）和滑动窗口（sliding window）； 其中 si 表示 sink token 的数量，sl 表示滑动窗口的大小。\n最后一个 Q-K 部分：涵盖 Q 的最后一部分与 K 之间的交互，不包括 Streaming 部分； 其中 last ≥ 1 指定了对应于最后一节的行数\n中间 Q-K 部分：由 Q 和 K 中间部分之间剩余的交互组成。 对注意力的分析 # 作者发现 M_middle 和 M_last 所保留的两个部分的注意力得分是相近的，尽管两者都明显低于在 M_streaming 中观察到的平均得分。为了更精确地衡量这些部分的相对重要性，作者引入了一种新的基于梯度的探测技术。\n作者设定了一个探测变量 \\(\\theta\\),形状为 层数 x 输入的 Token 数 x 输入的 Token 数，最开始所有元素都设置为 1，然后修改每层原有的注意力如下：\n然后取出 ground truth 对应的 token 的 logits（如果 ground truth 有多个 token，则计算 ground truth 的第一个 token），并计算\n以探测哪些层的哪些 Attention 对于 ground truth 的 token 的影响最大\n作者随机生成了 100 个样本，并设置 sink token 的数量（sink）为 64，滑动窗口大小（sl）为 128，并且最后注意力段的长度（last）也设置为 128。每个输入序列大约包含 2000 个 token。以计算每个区域的 attention 的重要性\n没说咋随机生成的 100 个样本诶 观察图像可知，尽管 Middle Q-K 在平均注意力分数上比 Last Q-K 更高，但是 ground truth 对于 Last Q-K 更敏感（因为平均梯度大），且 Middle 的梯度在早期层比较高，在中后期层就逐渐降低。\n因此作者提出假设，可以在后期层中跳过 Middle QK 的计算，仅计算一个直角三角形的 Attention 的就可以\n这种方法还可以同时在浅层中应用其他稀疏注意力算法进一步加速计算\n作者提到，三角注意力最早由（Li 等，2024a）提出，但是 Li 对于所有层都施加了三角注意力，最后性能显著下降\n实验 # 模型：Llama-3.1-8B-Instruct（128K 上下文）、Llama-3-8B-Instruct-262K、Qwen2.5-7B-Instruct（128K）\nbaseline：\n静态稀疏注意力：Streaming（一种 A 形的 Mask， 设置超参数 si = 8 and sl = 512）、Triangle 注意力（si = 8, sl = 512, and last = 128）、StremingMix，（对于层数 l ≤ Ltri_start 的层使用密集 Attention，而对于更深的层则使用流 Streaming）、DuoAttention（给每个 Head 设置一个 Mask 矩阵，但是在 Qwen 上训练不收敛，所以未汇报 DuoAttention+Qwen） 动态稀疏注意力：MInference 和 FlexPrefill（γ = 0.90 and γ = 0.95.） 超参数：为 Llama-3-18B-Instruct 和 Llama-3-8B-Instruct-262K 设置 Ltri_start = 16，而为 Qwen2.5-7B-Instruct 设置 Ltri_start = 20。作者的方法中的 Triangle 注意力的超参数与 baseline 中一致\nAcc：\n首 Token 时间：\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/trianglemix%E6%97%A0%E6%8D%9F%E4%B8%94%E9%AB%98%E6%95%88%E7%9A%84%E7%94%A8%E4%BA%8E%E9%A2%84%E5%A1%AB%E5%85%85%E9%98%B6%E6%AE%B5%E7%9A%84%E6%B3%A8%E6%84%8F%E5%8A%9B%E6%A8%A1%E5%BC%8F/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eTriangleMix：无损且高效的用于预填充阶段的注意力模式\n    \u003cdiv id=\"trianglemix无损且高效的用于预填充阶段的注意力模式\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#trianglemix%e6%97%a0%e6%8d%9f%e4%b8%94%e9%ab%98%e6%95%88%e7%9a%84%e7%94%a8%e4%ba%8e%e9%a2%84%e5%a1%ab%e5%85%85%e9%98%b6%e6%ae%b5%e7%9a%84%e6%b3%a8%e6%84%8f%e5%8a%9b%e6%a8%a1%e5%bc%8f\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eTriangleMix: A Lossless and Efficient Attention Pattern for Long Context Prefilling\u003c/p\u003e","title":"TriangleMix：无损且高效的用于预填充阶段的注意力模式","type":"posts"},{"content":" ASC：CoT 压缩的激活引导 Training free # Activation Steering for Chain-of-Thought Compression\n摘要 # 大语言模型（Large language models，LLMs）在包含中间推理步骤（称为思维链（chains of thought，CoTs））时擅长复杂推理。然而，这些推理过程对于简单问题也往往过于冗长，导致上下文浪费、延迟增加和能耗上升。我们观察到，在模型残差流（residual-stream）激活空间中，以英文为主的冗长 CoTs 与以数学为中心的简洁 CoTs 占据着不同的区域。通过提取并注入一个转向向量（steering vector）在这两种模式之间转换，我们可以可靠地促使生成更加简洁的推理内容，从而在不重新训练模型的前提下有效压缩 CoTs。我们将该方法形式化为激活引导压缩（Activation-Steered Compression，ASC），这是一种在推理阶段通过直接修改隐藏表示来缩短推理路径的技术。此外，我们还从理论上分析了 ASC 对输出分布的影响，并基于闭式 KL 散度约束（closed-form KL-divergence-bounded constraint）推导出用于调节转向强度的理论依据。仅使用 50 组成对的冗长与简洁示例，ASC 在 MATH500 和 GSM8K 数据集上实现了高达 67.43% 的 CoT 长度缩减，同时在 7B、8B 和 32B 参数规模的模型上保持了准确率。作为一种无需训练的方法，ASC 引入的运行时开销可以忽略不计，并且在 MATH500 上，8B 模型的端到端推理实际运行时间平均提升了 2.73 倍。这使得 ASC 成为在对延迟或成本敏感的应用场景中简化具备推理能力的 LLMs 部署的一种实用且高效的工具。\nhttps://github.com/ArminAzizi98/ASC\nMotivation # Overthinking 消耗资源 Overthinking 影响性能 使用激活引导具有可解释性 和现有方法（retrain、prompt-engineer、早停法）兼容 Long Response 和 Short Response 的 t-SNE # 从 MATH500 和 GSM8K 中采样问题，并使用 ds-distill-qwen7b 和 ds-distill-llama-8b 生成推理 CoT，并使用 gpt-4o 生成 short cot。\nWe feed each input independently into the model，并提取出第 21 层的 output\n看了下代码，这里的 input 指 Question+Answer 直接拼起来 问题和长短 CoT 示例如下：\nt-SNE 降维如下，特征明显\n方法 # 激活向量 # 记冗长 CoT 为 l_i，简短 CoT 为 s_i，定义 h^l 为第 l 层的输出，h^l(s)为将字符串 s 输入模型时第 l 层输出的隐藏状态\n引导向量计算如下：\n用自然语言表达就是，将问题和回复拼接成字符串，获取最后的隐藏状态，对于每个问题用短回复 ➖ 长回复，并最终求出平均值，获得一个向量\n在 decode 阶段应用这个向量，其中 gamma 为超参数：\n自适应 Gamma # 确保应用激活向量前后 KL 散度变化有限：\n其中 \\(\\varepsilon\\)是一个超参数\n数学推导（我得再啃啃） # 推导结论 # 如果定义：\n则有：\n其中 \\(\\gamma_{raw}=\\frac{ax}{L}\\)，并且 x 是 \\(x^3+x^2-\\frac{4\\varepsilon{L}^2}{a^4}=0\\)的解\n我们在小型校准集（50 个隐藏状态）上估计两个尺度参数 α 和 L。对于每个隐藏状态，我们使用选定的引导方向计算一个雅可比矩阵-向量积（Jacobian–vector product），并记录其欧几里得范数；这些范数的中位数即作为我们对 α 的估计值。为了获得 L，我们在每个校准点上沿相同方向计算一个海森矩阵-向量积（Hessian–vector product），收集得到的范数，并取其第 95 百分位数。\n如何应用方法 # 从数据集中 sample 50 个样本，分别用推理模型和非推理模型生成冗长 CoT 和简短 CoT，并提取出对于的隐藏状态，用隐藏状态获取向量并估算 gamma\n实验 # 数据集：MATH500、GSM8K\n模型：deepseek-r1-distill-llama-8b、deepseek-r1-distill-qwen-7b、qwq-32b\n超参数： \\(\\varepsilon = 10^{-3}\\)，在每个数据集中提取出 50 条数据用于预估 a 和 L 从而预估 \\(\\gamma\\) ，temperature=0.7，top_p=0.9, repetition_penalty=1.1\n硬件：A6000，torch2.5.1+cu124，transformers4.50.1\nBaseline：\nCoT CoD（Chain-of-Draft，大概方法还是类似 CoT，但是让模型先生成核心步骤，每个步骤不超过 5 个 token，纯 prompt 的内容） DEER（DEER：基于 Trial 置信度的推理早停，出现 Wait 时计算一下置信度，如果置信度够高了就 Early exit） TCC（http://arxiv.org/abs/2501.19393 大致方法是将 eos 替换成 Wait，直到达到 budget） SEAL（SEAL：大语言模型的可操控推理 Traning Free， 跟这篇 Paper 有点像，SEAL 的方法是使用引导向量引导 response 多多生成执行 Thought 而少生成反思和过渡 Thought，引入了新的超参数） 此外，作者还测试了跨数据集提取向量的压缩作用：\n以及如果不使用预估的 gamma 而是直接指定的话：\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/asccot%E5%8E%8B%E7%BC%A9%E7%9A%84%E6%BF%80%E6%B4%BB%E5%BC%95%E5%AF%BC-training-free/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eASC：CoT 压缩的激活引导 Training free\n    \u003cdiv id=\"asccot-压缩的激活引导-training-free\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#asccot-%e5%8e%8b%e7%bc%a9%e7%9a%84%e6%bf%80%e6%b4%bb%e5%bc%95%e5%af%bc-training-free\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eActivation Steering for Chain-of-Thought Compression\u003c/p\u003e","title":"ASC：CoT压缩的激活引导 Training free","type":"posts"},{"content":" SEAL：大语言模型的可操控推理 Traning Free # SEAL: Steerable Reasoning Calibration of Large Language Models for Free\n摘要 # 大语言模型（Large Language Models，LLMs），例如 OpenAI 的 o1 系列，已展现出通过扩展的思维链（chain-of-thought，CoT）推理机制处理复杂推理任务的出色能力。然而，最近的研究（Fu 等，2024；Wang 等，2025）揭示了 CoT 推理轨迹中存在显著冗余，这不仅增加了推理延迟，还因将注意力分散至不必要的推理路径而对模型性能产生负面影响。为了解决这个问题，我们研究了 LLMs 内部的推理结构，并将其归类为三种主要思维类型：执行（execution）、反思（reflection）和过渡（transition）思维。此外，我们的分析表明，过多的反思与过渡思维与失败案例高度相关，并且这些思维类别在潜在空间中表现出清晰的分离性。基于这些发现，我们提出了 SEAL（Steerable rEAsoning caLibration），一种无需训练的方法，可无缝校准 CoT 过程，在提高准确性的同时展现出显著的效率提升。SEAL 包括一个离线阶段，用于在潜在空间中提取推理引导向量；随后是在推理过程中通过表示干预利用该引导向量进行即时校准。值得注意的是，该引导向量在多种任务之间表现出强迁移能力。广泛的实验在多个模型（DeepSeekR1-Distill 和 QwQ-32B-Preview）以及多个基准（Math500、GSM8K、LiveCodeBench）上验证了 SEAL 的有效性，准确率最高提升了 11%，同时推理 token 减少了 11.8% 至 50.4%。\nhttps://github.com/VITA-Group/SEAL\nMotivation # CoT 推理轨迹中存在显著冗余，这不仅增加了推理延迟，还因将注意力分散至不必要的推理路径而对模型性能产生负面影响。 LLM 按照执行、反思和过渡思维进行 think，且这些 thought 在隐藏状态中是可以被分离出来的 LLMs 的推理模式 # 使用\u0026quot;\\n\\n\u0026quot;分割整个 think 过程，每一段作为一个 thought，将这些 thought 分成 3 类：\n执行思维：其中模型分析问题并逐步求解 反思思维：模型暂停推理过程以验证其步骤 过渡思维：模型转换推理流程，并从另一个角度 rethink 对于三种 thought 的 token 数量和最终答案正确与否分类统计了一下，得到以下结果：\n随着题目难度增加，Token 消耗越来越多 错误样本中的 Token 数量显著高于正确样本 且每种类型的思维在错误案例中均表现出更多的步骤。鉴于正确和错误样本的难度具有可比性，这些结果表明，此类过多的推理步骤在必要推理过程之外引入了显著冗余，并可能对性能产生负面影响。\n错误样本中思维数量的增加主要由反思和过渡思维的增加所驱动，因为每个反思或过渡步骤通常都伴随着多个执行步骤。\n不同 thought 的隐藏状态特征 # t-SNE 降维\n执行思维和其他思维在隐藏状态中可以区分开（例如第 20 层） 不同思维的可分离性在深层中表现得显著更好，而初始层则难以区分它们。 反思思维和过渡思维彼此之间的相似性要高于与执行思维的相似性。直观上，反思和过渡思维都涉及对先前推理步骤的重新考虑或修改，而执行思维则代表原始的逐步推理过程。 DeepSeek-R1-Distill-Qwen-1.5B 在 MATH500 上\n我没太理解为什么要汇报 t-SNE 结果 方法 # 推理引导向量提取 # 从数据集中抽取出一部分作为验证集，让 Reasoning 模型进行推理，并依据\\n\\n 切分成多个 thought，使用关键字将 thought 进行归类（‘Alternatively’就归类为过渡）\n其他 Thought 将被归类为执行 Thought\n对于每个 Thought j，从第 i 层 Transformer 中提取对应于第一个 token“\\n\\n”的输出表示，记为 Hj i。然后计算每个思维类别的平均表示：\n由于作者的主要目标是保留执行 Thought 而减少不必要的反思和过渡，因此构建引导向量：\n解码时隐藏状态干预 # 使用上述的 S 向量对于解码过程进行即时干预\n在解码过程中，在每一个思维步骤结束时，通过对某一层所有 \\n\\n token 的隐藏状态应用基于 S 得到的偏移量来进行干预，其形式化表示为：H_e = H + α · S，其中 α 是一个超参数。\n由于提取过程是离线进行的，因此不会在解码过程中引入任何额外的延迟\n实验 # 超参数： \\(\\alpha=1\\)\n模型：Deepseek-R1-Distill-Qwen-1.5B（干预第 20 层），Deepseek-R1-Distill-Qwen-7B（干预第 20 层），QwQ-32B-Preview（干预第 55 层）\n数据集：Math500、GSM8K、LiveCodeBench\n贪婪解码\n下表中的 Logits Penalty 是 baseline，指对于和对应 thought 相关的 token 施加 logits 惩罚的结果，比如对于 wait 和 alternatively token，惩罚值为-3\n下面两个表的引导向量 S 都是在 MATH500 的一个 subset 上提取出来的，但是都没有汇报是如何划分 subset 的，也没有汇报这个 subset 是否和测试用的数据集有重叠，所以第一个表参考价值不是很大，但是第二个表参考价值一些\n对于为什么施加 logits 惩罚反而可能提升了 token 数量，作者解释如下：\nLogit Penalty（即 token 空间调整）方法的一个局限性在于，它通常针对单个 token 进行操作，例如 alternatively 或 wait，而不是在概念层面进行调整。然而，反思和过渡性思考通常通过短语或更长的句子表达，例如 let me double-check 或 another approach is。这种情况仅通过 Logit Penalty 难以完全抑制。此外，我们观察到，即使降低了这些思考中代表性 token 的 logit 值，模型仍然表现出反思和过渡的倾向——只不过是以更隐晦的方式，例如通过改写表达。\n消融实验 # 使用引导向量弱化不同 thought 对不同层施加 不同系数 \\(\\alpha\\) ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/seal%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E7%9A%84%E5%8F%AF%E6%93%8D%E6%8E%A7%E6%8E%A8%E7%90%86-traning-free/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eSEAL：大语言模型的可操控推理 Traning Free\n    \u003cdiv id=\"seal大语言模型的可操控推理-traning-free\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#seal%e5%a4%a7%e8%af%ad%e8%a8%80%e6%a8%a1%e5%9e%8b%e7%9a%84%e5%8f%af%e6%93%8d%e6%8e%a7%e6%8e%a8%e7%90%86-traning-free\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eSEAL: Steerable Reasoning Calibration of Large Language Models for Free\u003c/p\u003e","title":"SEAL：大语言模型的可操控推理 Traning Free","type":"posts"},{"content":" Hmm 等 Token 影响模型推理能力 # Demystifying Reasoning Dynamics with Mutual Information: Thinking Tokens are Information Peaks in LLM Reasoning\n感觉 Motivation 阐述的不是很明确，但是想法的不错\n但是工程方面似乎有些问题，详情请看下面的高亮块\n摘要 # 大规模推理模型（LRMs）在复杂问题求解方面展现出了令人印象深刻的能力，但其内部的推理机制仍缺乏深入理解。本文从信息论的角度出发，研究了 LRMs 的推理轨迹。通过追踪中间表示与正确答案之间的互信息（MI）在 LRM 推理过程中如何演变，我们观察到一种有趣的 MI 峰值现象：在某些特定生成步骤中，MI 会在 LRM 的推理过程中突然且显著地增加。我们对该现象进行了理论分析，并证明随着 MI 的增加，模型预测错误的概率会下降。此外，这些 MI 峰值通常对应于表达思考或转折的词元（token），例如“Hmm”、“Wait”和“Therefore”，我们将这类词元称为思考词元（thinking tokens）。接着我们表明，这些思考词元对 LRM 的推理性能至关重要，而其他词元则影响甚微。基于这些分析，我们提出了两种简单但有效的改进方法，通过精心利用这些思考词元来提升 LRM 的推理表现。总体而言，本研究为理解 LRMs 的推理机制提供了新的视角，并为提升其推理能力提供了可行的实践路径。代码地址为 https://github.com/ChnQ/MI-Peaks。\nMotivation # 尽管最近的逻辑推理模型（LRMs）如 DeepSeek 的 R1 系列模型[18]和 Qwen 的 QwQ[42]展现出了令人印象深刻的推理能力，但驱动这些能力的基本机制仍缺乏清晰的理解。 一些发现 # 截止目前，LRM 内部的推理的动态仍然是不可知的。且一些研究表明 LRM 的某些关键 token 会严重影响模型生成内容的安全性，所以作者希望弄清楚：\n在 LRMs 的推理过程中，是否存在显著影响最终结果的关键推理步骤或中间状态？ 实验发现模型的中间步骤与 gold answer 之间的互信峰值的分布是稀疏且不均匀的\n这表明在某些关键的推理步骤中，LRMs 的表示变得对正确答案影响较大。于是又提出另一个问题：\n这些 MI（互信度）峰值是否可能与模型的推理性能相关？ 作者继续实验，发现当 LRM 的输出与 ground truth 之间的累积互信度增加时，LRM 的推理出错的概率会降低。但是 LRM 所对应的基座模型就没表现出这么明显的峰值现象。所以作者认为峰值现象的出现可能源于密集的推理训练，并且可能和 LRM 卓越的推理能力相关\n于是提出第三个问题：\n在推理过程中，MI 峰值处的表示承担了哪些语义角色？ 发现这些具有互信息（MI）峰值的表示主要对应于诸如“Wait”、“Hmm”、“Therefore”、“So”之类的词符（token），这些词通常表达沉思、自我纠正或转折过渡的含义。\n作者将上述具有 MI 峰值的 token 命名为 thinking token，并假设这些思考 token 可能在模型的推理能力中发挥了关键作用，为了验证以上猜想，作者在某次实验中抑制了 thinking token 的生成，并且发现这样做显著损害的模型性能。且如果抑制的是其他 token，则没有明显的区别\nContributions # 提出了两种 Training free 的提高 LRM ACC 的方法：\n表示循环（Representation Recycling, RR）方法。RR 鼓励模型更好地利用这些具有信息量的表示 基于思考 token 的测试时扩展方法（Thinking Token based Test-time Scaling, TTTS）。具体而言，当存在额外的 token 预算时，我们强制模型从思考 token 开始继续进行推理。 模型 MI 峰值现象 # 方法 # MI 峰值的出现 # 将一个数据集的 X 输入的 Model 中，获得 T 个输出 Token（Y\u0026rsquo;），并且收集每个 token 对应的 hidden state，设 A 为提取 hidden state 的函数，这个过程记为：\n各个 Token 和 gold answer 间的 MI # 在提取表示之后，我们随后度量每个生成 token 的隐藏状态 ht 与标准答案的隐藏状态 hy 之间的互信息（MI），从而获得一个 MI 序列：[(ht; hy), I(ht; hy), \u0026hellip;, I(ht; hy)]。\n是怎么获得到 hy 的呢？ 看代码得知，LRM 没使用任何 template（hy 和 ht 都没有），直接将 ground truth 输入到 LRM 中，并提取出对应的几个 token 的 hidden state hy 没使用任何 template 也可以理解，毕竟不希望 template 中的内容干扰 hy 但是为什么 ht 也不应用 template 呢？\n对于 ht 的问题我已经在 github 上提问了，尚未得到答复\n计算 MI # 采用希尔伯特-施密特独立性指标，用于衡量两个变量之间的独立性\n峰值定义 # 对于一个 MI 序列，定义 Q1 和 Q3 是其中两端的两个四分位点，定义 IQR(m)=Q3-Q1 为四分位距，定义峰值为：\n其中 τ 为超参数，实验中设置为 1.5\n实验 # 在 MATH 数据集上实验，MI 是稀疏的、不均匀的\nMI 峰值导致模型出错的概率边界越窄 # 作者想知道，MI 峰值和 Acc 的关系\n这一段我没看明白，不知道作者从哪里拿出两个定理，我推半天没推出来 定理 1.，设模型共生成 T 个 token，Pe 是模型出错的概率则有 其中 Hb 为二元熵：\n定理 2， 作者声称定理 1 建立了 LLM 预测误差 pe 的下界。直观上，它表明若要 LLM 实现较低的误差率，其在生成过程中的一系列内部表示应能够捕捉关于正确答案的更多信息。换句话说，在生成轨迹中保持较高的互信息（MI）可能有助于降低模型可达到的最小误差。定理 2 给出了预测误差 pe 的一个上界，这补充了定理 1 中的下界。它表明，表示序列与正确答案之间的累积互信息（MI）越高，大语言模型（LLM）误差概率的上界就越紧。\n非推理模型的 MI 峰值 Weaker 且 Less # MI 峰值所对应的 token 的语义特征 # 直接将上述推理的结果 decode 出来，发现在 MI 峰值处出现的 token 主要是表达自我反思或 LRM 推理过程中转折的连接词。作者定义这些 token 为 thinking token\nMI 峰值对于 LRM 的推理的重要性 # 抑制 thinking token 的出现会大大影响 Acc，而抑制普通 token 的出现不会\n抑制 thinking token 的方法是在生成过程中将其概率设置为 0，导致无法采样到想要抑制的 token\n抑制普通 token 的方法是随机采样一些 token，并将其概率设置为 0\n我觉得这抑制普通 token 的方法问题太大了 作者对于抑制 thinking token 的方法并非严格递减的解释如下，有时抑制 Wait，模型会生成 But wait 短语来规避这种抑制\n应用上述发现提升 LRM 推理能力 # 推理过程中高互信息表示的再利用(RR) # 方法 # 对于 Thinking Token，将其对应的 hidden state 在某一层处理两次再传递给下一层\n例如普通 Token 在第 l 层的处理为：\\(h_l=TF_l{h_{l-1}}\\)，但对于 Thinking Token 在第 l 层的处理就是 \\({h'}_l=TF_l{h_{l-1}},h_l=TF_l{{h'}_l}\\)，但是对于其他层都是常规处理\n实验 # 为了评估 RR 的有效性，我们在三个数学推理基准测试中使用 DeepSeek-R1-Distill-Llama-8B 和 DeepSeek-R1-Distill-Qwen7B 进行实验。由于在推理过程中无法获取真实答案，我们首先使用 MATH 数据集的训练集记录思维 token（如第 3.1 节所述），然后当模型生成这些思维 token 之一时触发 RR。基于以往研究建议，LLMs 的中间层或高层倾向于编码更具语义丰富的内容，因此我们经验性地将 l 设置为这些层次。\n没介绍实验中具体取的哪一层\n我不理解为什么 7B 和 8B 模型在 AIME24 上效果这么好，反而我们的 Qwen25-32B-Instruct 在 AIME24 上只有 10% 以下是另外一篇文章汇报的 Qwen25-32b-instruct 的结果，感觉可能和 sampling 策略有关，我采用的是 temperate，这些论文似乎更倾向于 greedy\nTest-Time Scaling with Thinking Tokens # 方法 # 基于上面识别出的思维 token 集合，我们过滤掉语义内容较少的 token（例如标点符号和单个字符），并保留诸如“So,”、“Hmm,”之类的 token，这些 token 通常表示思考、过渡或进一步推理的开始。然后在推理过程中，我们将其中一个思维 token 附加到模型初始输出的末尾，并允许其继续生成额外的推理步骤。\n实验 # ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/hmm%E7%AD%89token%E5%BD%B1%E5%93%8D%E6%A8%A1%E5%9E%8B%E6%8E%A8%E7%90%86%E8%83%BD%E5%8A%9B/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eHmm 等 Token 影响模型推理能力\n    \u003cdiv id=\"hmm-等-token-影响模型推理能力\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#hmm-%e7%ad%89-token-%e5%bd%b1%e5%93%8d%e6%a8%a1%e5%9e%8b%e6%8e%a8%e7%90%86%e8%83%bd%e5%8a%9b\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eDemystifying Reasoning Dynamics with Mutual Information: Thinking Tokens are Information Peaks in LLM Reasoning\u003c/p\u003e","title":"Hmm等Token影响模型推理能力","type":"posts"},{"content":" AdaCoT：通过强化学习实现的帕累托最优自适应链式思维触发器 # AdaCoT: Pareto-Optimal Adaptive Chain-of-Thought Triggering via Reinforcement Learning\n摘要 # LRM 在需要复杂推理的任务上常常面临挑战。尽管 CoT 显著提升了推理能力，但它会不分情况地为所有查询生成冗长的推理步骤，这导致了巨大的计算成本和低效，尤其是对于简单输入时更是如此。为了解决这一关键问题，我们提出了 AdaCoT，使 LLMs 能够自适应地决定何时调用 CoT。AdaCoT 将自适应推理建模为一个 Pareto Improvement 问题，旨在平衡模型性能与 CoT 调用相关的成本（包括频率和计算开销）。我们提出了一种基于强化学习（RL）的方法，具体使用近端策略优化（PPO），通过调整惩罚系数动态控制 CoT 触发决策边界，从而使模型能够根据隐式的查询复杂性判断是否需要 CoT。一项重要的技术贡献是选择性损失掩码（Selective Loss Masking, SLM），其设计目的是在多阶段 RL 训练过程中防止决策边界崩溃，确保稳健且稳定的自适应触发。实验结果表明，AdaCoT 成功地在帕累托前沿上导航，大幅减少了不需要复杂推理的查询中的 CoT 使用。例如，在我们的生产流量测试集上，AdaCoT 将 CoT 触发率降低至 3.18%，并减少了 69.06% 的平均响应 token 数量，同时在复杂任务上仍保持高性能。这种显著的 token 减少直接转化为推理计算负载的大幅降低。AdaCoT 开创了自适应 CoT 触发的先河，为开发更高效、更响应迅速且更具成本效益的 LLMs 提供了一个实用且原则性的解决方案，这对于交互式和资源敏感型应用尤为重要。\nMotivation # 即便是简单回答，CoT 也会大大消耗 Token 数量 现有的研究无法依据题目难度（查询复杂度）自适应 CoT 方法 # 目标描述 # 主要两个目标：最大化 acc + 最小化部署成本\n几个指标：\n\\(T(\\theta)=CoT 触发率 = \\frac{使用 CoT 回复数}{回复总数}\\)，如果有\u0026hellip;.算 CoT\n$$ P(\\theta)=模型性能=Acc $$ 其中两个 lambda 是两个超参数\n数据生成和 SFT # 使用一个辅助模型（实验中使用 15B 模型）对于一个用户和 AI 的对话打标签，标签共两种：是/否需要深度思考\n基于辅助模型标注结果，对于数据进行处理。如果辅助模型任务需要深度思考，则不做处理，否则就将推理部分替换为空()，然后对于模型进行 SFT，让模型能同时具备思考和不思考的能力\n强化学习 # 奖励函数如下：\n$$ R(x, r)=R_{base}(x, r) - \\alpha_1P_{miss}(x,r) - \\alpha_2P_{over}(x,r)-\\gamma P_{fmt}(r) $$其中 Rbase 为衡量响应质量的基础奖励，Pmiss 是对于推理省略的二元惩罚，Pover 是对于过度推理的二元惩罚，Pfmt 是对于格式化错误的二元惩罚，其他是非负超参数\n为了防止在强化学习过程中，模型落入其中一种 CoT 模式（要么只 CoT、要么全跳过），AdaCoT 引入了选择性损失掩码（Selective Loss Masking， SLM），具体实现为掩盖后的第一个 token（决策 token）的损失。\n实验 # 模型：豆包 15B 和 150B 模型\n训练过程：SFT+ 数学 RL+ 通用 RL\nBaseline: Full CoT SFT、Full CoT RL、No CoT SFT、No CoT RL、仅经过了 SFT 未 RL 的 AdaCoT\n数据集：LiveBench [45]、MMLU Pro [42]、SuperGPQA [7]、GPQA [32]、Chinese SimpleQA [12]、SimpleQA [44]、AIME24 \u0026amp; AIME25、MATH [13]、OlympiadBench [11]、SweBench Agentless [18]、LiveCodeBench [17]、KOR-Bench [25]、ProcBench [8] 和 SysBench [31]\n超参：强化学习共 4 个阶段，Exp1 (α1 = 0.1, α2 = 0.3), Exp2 (α1 = 0.2, α2 = 0.3), Exp3 (α1 = 0.3, α2 = 0.3), and Exp4 (α1 = 0.3, α2 = 0.1)，gamma 设置为 1.0\n此外，团队还实验了 SFT 的 Meta-Reasoning，具体来说就是\n在后填充一些内容，测试结果如 ⬇️\n但是这个测试也很怪，选择的是 1k 的 daily-use prompt 作为测试集 ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/adacot%E9%80%9A%E8%BF%87%E5%BC%BA%E5%8C%96%E5%AD%A6%E4%B9%A0%E5%AE%9E%E7%8E%B0%E7%9A%84%E5%B8%95%E7%B4%AF%E6%89%98%E6%9C%80%E4%BC%98%E8%87%AA%E9%80%82%E5%BA%94%E9%93%BE%E5%BC%8F%E6%80%9D%E7%BB%B4%E8%A7%A6%E5%8F%91%E5%99%A8/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eAdaCoT：通过强化学习实现的帕累托最优自适应链式思维触发器\n    \u003cdiv id=\"adacot通过强化学习实现的帕累托最优自适应链式思维触发器\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#adacot%e9%80%9a%e8%bf%87%e5%bc%ba%e5%8c%96%e5%ad%a6%e4%b9%a0%e5%ae%9e%e7%8e%b0%e7%9a%84%e5%b8%95%e7%b4%af%e6%89%98%e6%9c%80%e4%bc%98%e8%87%aa%e9%80%82%e5%ba%94%e9%93%be%e5%bc%8f%e6%80%9d%e7%bb%b4%e8%a7%a6%e5%8f%91%e5%99%a8\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eAdaCoT: Pareto-Optimal Adaptive Chain-of-Thought Triggering via Reinforcement\nLearning\u003c/p\u003e","title":"AdaCoT：通过强化学习实现的帕累托最优自适应链式思维触发器","type":"posts"},{"content":" AdaptThink: 让模型决定是否思考 # AdaptThink: Reasoning Models Can Learn When to Think\n摘要 # 最近，大型推理模型通过采用类似人类的深度思考，在各种任务上取得了令人印象深刻的表现。然而，冗长的思考过程显著增加了推理开销，使得效率成为关键瓶颈。在这项工作中，我们首先证明了对于相对简单的任务，NoThinking（即提示推理模型跳过思考并直接生成最终解决方案）在性能和效率方面都是更好的选择。受此启发，我们提出了 AdaptThink，一种新颖的强化学习算法，用于教导推理模型根据问题难度自适应地选择最优思考模式。具体而言，AdaptThink 包含两个核心组件：(1)** 一个约束优化目标，鼓励模型选择 NoThinking 同时保持整体性能**；(2) 一种重要性采样策略，在基于策略的训练过程中平衡 Thinking 和 NoThinking 样本，从而实现冷启动，并使模型在整个训练过程中探索和利用两种思考模式。我们的实验表明，AdaptThink 显著降低了推理成本，同时进一步提升了性能。特别地，在三个数学数据集上，AdaptThink 将 DeepSeek-R1-DistillQwen-1.5B 的平均响应长度减少了 53%，并将其准确性提高了 2.4%，这凸显了自适应思考模式选择在优化推理质量和效率平衡方面的潜力。我们的代码和模型可在 https://github.com/THU-KEG/AdaptThink 获取。\nMotivation # 在简单问题（最高高中竞赛水平）上不思考（填充来跳过思考过程）和思考相当甚至更好 方法 # 两种推理模式，think 和 nothink，think 即为正常推理，no-think 是使用空 think 段填充来跳过思考过程\n约束优化目标 # \\(\\pi_{\\theta_{ref}}\\)是一个 Reasoning 模型，保持不变； \\(\\pi_\\theta\\)是当前在训练的模型，在训练之前，两个模型是同一个\nR(x,y)是如果做对就返回 1，否则为 0\n在保证回复的 Acc 的基础上有限选择 nothink（y 的第一个 token 是的）\n为了实现上述有约束的优化目标，将约束作为惩罚项，乘以系数 \\(\\lambda\\) 融合进目标函数：\n两项同时除以 \\(\\lambda\\)，让 \\(\\delta = \\frac{1}{\\lambda}\\)\n但是由于\\(\\pi_{\\theta_{ref}}\\)保持不变，所以可以提前在数据集上跑一波来近似 \\(R(x,y')\\)，于是作者从数据集中随机抽取 K 个样本，并估算\\(R(x,y')\\)\n将上式带入优化目标得\n下式中， \\(A(x, y) = 1(y_1=\\text{}) · \\delta + R(x, y) - R_{ref}(x)\\)\n重要性采样策略 # 上面提到，从数据集中采样 K 个来近似\\(R(x,y')\\)，但是在训练之前模型只能天然生成 think 的回复而不会 Nothink，为了解决这个问题，作者修改了模型的推理过程。让第一个词为的概率为 0.5，为 wstart（如“嗯，”、“Alright”等发语词，实验中使用的是 Alright）\n然后用这个新的分布来近似\\(R(x,y')\\)\n实验 # 模型： # DeepSeek-R1-Distill-Qwen1.5B、DeepSeek-R1-Distill-Qwen-7B\n数据集： # 训练集： # DeepScaleR（AIME 1983-2023, AMC, Omni-Math and STILL 派生出来的包含 40k 问题的数据集）\n测试集： # GSM8K、MATH500、AIME2024（AIME 每个问题采样 16 次，取 16 次平均值）\n实现细节： # 使用 VeRL 作为训练框架，上下文 16K，batchsize 128，learning rate 2e-6\nK（上面从训练集中抽样来进行估计的超参数）=16，δ（惩罚系数的倒数）=0.05，ε（clip 中的超参）=0.2\n训练 1 个 epoch，314 个 step\n1.5B 模型 8H800，32 个小时，7B 8H800 28 个小时\n分别为 1.5B 和 7B 模型选择了 300 步和 150 步的 checkpoint\nDPO shortest 是在数据集中采样多个响应，并取出最短的那个来 DPO 训练\nOverThink 将每个训练问题的原始长思考响应作为负例，同时将思维过程中前两次得到正确答案的尝试作为正例来构建偏好数据，然后使用 SimPO 来缓解模型的过度思考行为。\nDAST 使用基于长度的奖励函数对预先采样的响应进行排名来构建偏好数据\nO1-Pruner 预采样估计参考模型的性能，然后使用离线策略 RL 风格的微调，在准确性约束下鼓励模型生成更短的推理过程\nTLMRE 引入了一个基于长度的惩罚项到策略型强化学习中，以激励模型生成更短的响应。\nModelMerging 通过将非推理模型（即，Qwen-2.5-Math-1.5B/7B）的权重与其进行加权平均，从而缩短推理模型的响应长度。\nRFTMixThinking 首先对每个训练问题 x 使用 Thinking 和 NoThinking 采样多个响应，然后选择 (1) 如果实例级通过率 R ̄nothink(x) ≥ R ̄think(x)，则选择正确的 NoThinking 响应，以及 (2) 如果 R ̄nothink(x) \u0026lt; R ̄think(x)，则选择正确的 Thinking 响应，并使用这些选定的响应来微调模型。\n不同惩罚系数的选择\n观察到 AdaptThink 的现象，题目越难越容易 Think：\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/adaptthink_-%E8%AE%A9%E6%A8%A1%E5%9E%8B%E5%86%B3%E5%AE%9A%E6%98%AF%E5%90%A6%E6%80%9D%E8%80%83/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eAdaptThink: 让模型决定是否思考\n    \u003cdiv id=\"adaptthink-让模型决定是否思考\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#adaptthink-%e8%ae%a9%e6%a8%a1%e5%9e%8b%e5%86%b3%e5%ae%9a%e6%98%af%e5%90%a6%e6%80%9d%e8%80%83\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eAdaptThink: Reasoning Models Can Learn When to Think\u003c/p\u003e","title":"AdaptThink: 让模型决定是否思考","type":"posts"},{"content":" SpecReason：使用推测性推理实现加速推理 # SpecReason: Fast and Accurate Inference-Time Compute via Speculative Reasoning\n摘要 # CoT 效果好但是带来巨大开销。我们解决这些开销的关键洞察是，LRM 推理及其嵌入的推理对近似的容忍度很高：复杂的任务通常被分解成更简单的步骤，每一步都基于它为下游步骤提供的语义见解带来效用，而不是它生成的确切 token。因此，我们引入了 SpecReason，这是一个利用轻量级模型自动加速 LRM 推理的系统，该轻量级模型（推测性地）执行更简单的中间推理步骤，并仅保留昂贵的基础模型来评估（并可能纠正）推测输出。重要的是，SpecReason 专注于利用思考 token 的语义灵活性以保持最终答案的准确性，这与先前的推测技术是互补的，特别是推测性解码，后者要求每个步骤的 token 级别等价。在各种推理基准测试中，SpecReason 比普通的 LRM 推理实现了 1.5-2.5 倍的速度提升，同时将准确性提高了 1.09% 至 9.9%。与没有使用 SpecReason 的推测性解码相比，它们的结合额外降低了 19.4%-44.2% 的延迟。我们在 https://github.com/ruipeterpan/specreason 开源了 SpecReason。\n动机 # 中间步骤实际用不了那么多计算（SLM 也能胜任） # 在长 CoT 中的许多推理步骤中，推理任务的难度并不是均匀分布的。虽然整体任务对于小型模型来说可能具有挑战性，但只有少数关键推理步骤（例如，分析问题，通过公式或案例分析将其分解，以及制定逐步推理问题的计划）对整体推理进展至关重要，而其他许多推理步骤则相对容易。\n推理的进展依赖于洞察力，而不是确切的 token（对于同一个思路表述不一也问题不大） # 推理步骤的作用不在于确切的 token，而更多在于它在语义上多能推动推理过程继续。传统 LLM 推理中的翻译等任务中忠实于确切的 token 组合更为重要，而在 LRM 的思考 token 中的推理 CoTs 更关心能够推进推理链的信息。对于给定的步骤存在一系列有效的表述：许多语义相同或语义相似的 token 序列可以起到相同的引导后续推理的功能。\n偶尔的错误可以通过自我反思来纠正（SLM 出错了 LRM 可以修改过来） # 此外，LRM 表现出强大的自我反思能力。即使早期步骤中包含事实性或逻辑性错误，LRM 也常常能在随后的推理步骤中自我纠正，通常以输出如“Wait”或“Hmm”这样的 token 为标志。而且，由于在 LRM 推理中，只有最终 response 的 token 才计入准确性，LRM 推理可以容忍偶尔的错误，因为模型通常能够识别这些错误，并在自我反思过程中将推理引导回正确的路径。这种容错特性进一步表明了近似的潜在好处。\n总之，LRM 推理本质上更能容忍 token 的近似，只要整体的推理轨迹得以保持即可。\n方法 # 推测性推理（Speculative Reasoning） # 让 SLM 进行推理，每一步（一个句子或一个自然段）都提示 LRM 生成一个 token 的 score 来评估步骤是否可以采纳，如果 score 比较低，就用 LRM 进行重新生成\n实验 # 模型：QwQ-32B（LRM）、R1-1.5B（SRM）\n数据集：AIME、MATH500、GPQA\n其他：pass@1，k=16， temperature=0.6 maxlen=8k\n软硬件：vllm A6000（48G）\nSpecDecode 是投机采样、SpecReason+Decode 是投机采样 + 本文方法，Fig3 中 score 阈值为 7\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/specreason%E4%BD%BF%E7%94%A8%E6%8E%A8%E6%B5%8B%E6%80%A7%E6%8E%A8%E7%90%86%E5%AE%9E%E7%8E%B0%E5%8A%A0%E9%80%9F%E6%8E%A8%E7%90%86/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eSpecReason：使用推测性推理实现加速推理\n    \u003cdiv id=\"specreason使用推测性推理实现加速推理\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#specreason%e4%bd%bf%e7%94%a8%e6%8e%a8%e6%b5%8b%e6%80%a7%e6%8e%a8%e7%90%86%e5%ae%9e%e7%8e%b0%e5%8a%a0%e9%80%9f%e6%8e%a8%e7%90%86\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eSpecReason: Fast and Accurate Inference-Time Compute via Speculative Reasoning\u003c/p\u003e","title":"SpecReason：使用推测性推理实现加速推理","type":"posts"},{"content":" ThinkLess：一种无需训练的推理高效方法，用于减少推理冗余 # ThinkLess: A Training-Free Inference-Efficient Method for Reducing Reasoning Redundancy\n摘要 # 虽然链式思维（CoT）提示提升了大型语言模型（LLMs）的推理能力，但过长的推理 token 序列会增加延迟和 KV 缓存内存使用量，甚至在上下文限制下截断最终答案。我们提出了 ThinkLess，一种推理高效的框架，能够在不修改模型的情况下提前终止推理生成并保持输出质量。注意力分析表明，答案 token 对早期推理步骤的关注最少，而主要集中在推理终止符 token 上，这是由于因果掩码下的信息迁移所致。基于这一发现，ThinkLess 在更早的位置插入终止符 token，以跳过冗余推理同时保留底层知识传递。为防止早期终止导致的格式破坏，ThinkLess 引入了一种轻量级的后调节机制，利用模型天然的指令跟随能力生成结构良好的答案。无需微调或辅助数据，ThinkLess 在大幅减少解码时间和内存消耗的同时，实现了与完整长度 CoT 解码相当的准确率。\nMotivation # 资源消耗 过长 CoT 效果可能反而不好 长 CoT 可能挤占最后生成答案的 token 数量 方法 # 观察到现象 # 注意力下沉，在早期层模型会关注整个推理过程，但是到了后面的层模型更多关注，因为包含整个推理的信息\n基于上述现象，提出假设，在推理过程中，之前，存在一个 token，已经具备了足够的信息，在此 token 以后添加能在有足够的信息后终止思考。\n验证假说 # 在 DeepSeek-R1-Distill-Qwen-7B 推理中每 16 个 token 的地方插入提前终止思考一次，并提取出的隐藏状态\n然后应该是移除让模型继续生成了，重复上述操作，每 16 个 token 提取一次 然后计算各个隐藏状态的余弦相似性\n发现这些相似性相似程度很高，可以认为后续就几乎没有新的有用信息加入了。\n尝试在不同位置截断并看最终 Acc，发现尽管早期 hidden state 已经具备很多信息了，但是 Acc 还是很低，但是到了越往后越高 ⬇️。\n为什么截断位置 0 和 10 的时候很比较高呢？ 作者分析提到，在早期截断时，模型其实答对了，但是模型最后没能格式化，比如在 GPQA 上选择题，直接输出了选项内容但是没输出选项 ABCD，导致自动评分错误，对于这个问题，作者选择在写一段简洁的 prompt 拼在题目之前以限制模型的输出\n实验 # 数据集：GSM8K、MMLU、GPQA、BBH\n模型：Qwen2.5-7B/14B、LLaMA3.1-8B\nBaseline：上述模型蒸馏 Deepseek-R1 的变体，例如 deepseek-r1-distill-qwen-7b\n效果真的挺好的，基本上都是 ThinkLess 胜\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/thinkless%E4%B8%80%E7%A7%8D%E6%97%A0%E9%9C%80%E8%AE%AD%E7%BB%83%E7%9A%84%E6%8E%A8%E7%90%86%E9%AB%98%E6%95%88%E6%96%B9%E6%B3%95%E7%94%A8%E4%BA%8E%E5%87%8F%E5%B0%91%E6%8E%A8%E7%90%86%E5%86%97%E4%BD%99/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eThinkLess：一种无需训练的推理高效方法，用于减少推理冗余\n    \u003cdiv id=\"thinkless一种无需训练的推理高效方法用于减少推理冗余\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#thinkless%e4%b8%80%e7%a7%8d%e6%97%a0%e9%9c%80%e8%ae%ad%e7%bb%83%e7%9a%84%e6%8e%a8%e7%90%86%e9%ab%98%e6%95%88%e6%96%b9%e6%b3%95%e7%94%a8%e4%ba%8e%e5%87%8f%e5%b0%91%e6%8e%a8%e7%90%86%e5%86%97%e4%bd%99\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eThinkLess: A Training-Free Inference-Efficient Method for Reducing Reasoning Redundancy\u003c/p\u003e","title":"ThinkLess：一种无需训练的推理高效方法，用于减少推理冗余","type":"posts"},{"content":" Thinkless: LLM Learns When to Think # Thinkless: LLM Learns When to Think\n摘要 # 推理语言模型（Reasoning Language Models），具备扩展的链式思维推理能力，在需要复杂逻辑推理的任务上展现了卓越的性能。然而，对所有查询应用详尽推理通常会导致显著的计算效率低下，尤其是在许多问题有简单解决方案的情况下。这引发了一个开放性问题：大型语言模型（LLMs）能否学会何时进行深度思考？为了解答这一问题，我们提出了 Thinkless，这是一种可学习的框架，能够使 LLM 根据任务复杂性和模型自身的能力，自适应地选择短形式或长形式的推理方式。Thinkless 在强化学习范式下进行训练，并使用两种控制 token： 用于简洁的回答， 用于详细的推理过程。我们方法的核心是一种解耦组相对策略优化（Decoupled Group Relative Policy Optimization, DeGRPO）算法，该算法将混合推理的学习目标分解为两个部分：(1) 控制 token 损失，用于指导推理模式的选择；(2) 回答损失，用于提高生成答案的准确性。这种解耦的公式化设计使得可以精细地控制每个目标的贡献，从而稳定训练过程，并有效避免了在标准 GRPO 中观察到的崩溃现象。实验结果表明，在 Minerva Algebra、MATH-500 和 GSM8K 等多个基准数据集上，Thinkless 能够将长链思维的使用减少 50% 至 90%，大幅提升了推理语言模型的效率。代码可在 https://github.com/VainF/Thinkless 获取。\nMotivation # Long cot 效率低 已有的研究的模型推理与否受制于人类的先验知识，可能陷入次优，让模型自己决定才是正解 方法 # 影响推理的因素 # 用户问题的难度：形如 1+1=？的问题不需要推理 模型的能力：即使有些问题较难，但是如果模型能力上去了也不用过多推理 用户对于效率和准确性的容忍度 具体方法： # 用于预热的蒸馏 # 目的：构建一个能生成 short 形式和 long 形式的模型\n步骤：取一个 reasoning 模型和一个 instruct 模型，分别对于同一个问题进行回复，并在其回复前加上或标签，构建以下数据集\n并使用该数据集 SFT，\n为什么不把两个回复拆开呢？ 或者是说训练的时候其实是分开训练的\n让模型遇到就开始 reasoning，遇到就开始简单回答\n通过解耦的 GRPO 学习何时思考 # 优化策略 # 其中 c 要么是要么是，代表进入推理模式或直接回答\n奖励设计 # 简言之，鼓励且 ✅，稍微鼓励且 ✅，❌ 了扣大分\n解耦策略优化 # 原 GRPO\n但是（1）模式-准确性不平衡 - 每条轨迹仅包含一个控制 token，而有 Ti 个响应 token，这不成比例地削弱了模式选择相对于响应准确性优化的影响。（2）长思-短思不平衡 - 更长的序列由于归一化因子 1/(Ti + 1)的存在进一步抑制了控制 token 的梯度贡献，导致 token 相比被优化得不足。\n所以设计了新的策略\n实验 # 模型：DeepSeek-R1-Distill-Qwen-1.5B\n数据集：AIME、Minerva Algebra、MATH-500 和 GSM-8K\n使用 DeepSeek-R1-671B 和 Qwen2.5-Math-1.5B-Instruct 在 DeepScaleR 上分别生成 think 和 short\n硬件：4 张 H100\n超参：\n生成数据集 max_len: 16k（长了截断），SFT 时调整到 24k\nSFT 训了一轮，RL 训 600 步\n在 AIME 上大胜！\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/thinkless_-llm-learns-when-to-think/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eThinkless: LLM Learns When to Think\n    \u003cdiv id=\"thinkless-llm-learns-when-to-think\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#thinkless-llm-learns-when-to-think\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eThinkless: LLM Learns When to Think\u003c/p\u003e","title":"Thinkless: LLM Learns When to Think","type":"posts"},{"content":" 🧠 思维操控：外部 CoT 辅助大模型推理 # Thought Manipulation: External Thought Can Be Efficient for Large Reasoning Models\nTraining Free\n摘要 # 近期在大型推理模型（LRMs）方面的进展证明了扩展测试时计算规模能够提升多个任务中的推理能力。然而，LRMs 通常会遭受“过度思考”问题，即模型生成大量冗余的推理步骤，而这些步骤仅带来有限的性能提升。现有的工作依赖微调来缓解过度思考的问题，但这需要额外的数据、非传统的训练设置、可能引发的安全性错位风险，以及较差的泛化能力。\n通过实证分析，我们揭示了 LRM 行为的一个重要特性：将由较小模型生成的外部 CoTs（链式思维）放置在思考标记（ 和 ）之间，可以有效地引导模型生成更少的推理步骤。基于这一洞察，我们提出了一种简单而高效的流程，称为 ThoughtMani，以使 LRMs 能够跳过不必要的中间步骤，并显著降低计算成本。我们进行了广泛的实验以验证 ThoughtMani 的实用性和效率。例如，在 LiveBench/Code 数据集上应用于 QwQ32B 时，ThoughtMani 在几乎不增加 CoT 生成器开销的情况下，保持了原始性能并减少了约 30% 的输出 token 数量。此外，我们发现 ThoughtMani 平均提升了 10% 的安全性对齐。由于模型供应商通常同时提供不同尺寸的模型，ThoughtMani 为构建更高效且易于使用的 LRM 提供了一种有效途径，从而适用于现实世界的应用场景。\nMotivation # 计算资源 基于微调的方法通常需要额外的数据收集，从而导致成本增加。此外，微调可能会引发安全性的对齐问题 实证 # 使用 LLM（ Qwen-Max、Qwen-Plus、Qwen2.5-7B-Instruct 和 Qwen-2.5-3B-Instruct）生成推理，然后使用和包裹其推理，并将用户的 Question+ 构造的 think 一同输入到 LRM（QwQ 和 Deepseek-Distillation-Qwen2.5-32b(14b)-instruct）中，用于生成最终答案。\n生成推理的 Prompt： “If you are a teacher, you are listing the important key points for solving the problem and no calculation details should be included. You are not allowed to produce any final answer. Add when the key points are finished. You may provide only very high-level ideas for solving the problem, no calculation details should be included.”\n**发现使用 RL 的 LRM 在很多情况下仍然会再生成自己的推理链，**但是如果外部 CoT 是质量较高的（比如 Qwen-Max）生成的，那么 LRM 再自己推理的概率会小很多。\n但是基于蒸馏的 LRM 很少会再生成自己的推理链，作者推测基于蒸馏的 LRMs 可能并未真正“理解”推理或思考的概念。相反，它们的行为主要由监督微调期间学到的模式跟随技能驱动。\n方法 # 使用 LLM 生成 high level 的 CoT “If you are a teacher, you are listing the important key points for solving the problem and no calculation details should be included. You are not allowed to produce any final answer. Add when the key points are finished. You may provide only very high-level ideas for solving the problem, no calculation details should be included. If you feel that you cannot solve it, output and return.”\n如果 LLM 生成的 CoT 为空（Prompt 中写了如果模型觉得自己无法解决，那就直接输出 STOP），就抛弃掉 LLM 的 CoT 转而让 LRM 自行推理 实验 # 数据集\n数学：AIME-2024、GSM-8k、MATH-500 编程：LiveBench 安全对齐：WildJailbreak 模型：\nCoT 模型：Qwen-Max, Qwen-Plus, Qwen-2.5-7B-Instruct, and Qwen-2.5-3B-Instruct. LRM：QwQ-32B（RL）、Deepseek-Distillation-Qwen-2.5-14B（32B）-Instruct（Distill） 模型均为 4-bit 量化版本 实验设置：\n框架：vLLM 超参：temperature 0.7, top-k 0.95, maxlen 30000（AIME）、 20000 （Others） Baselines：\nEmpty Thought，将推理模型的 think 部分替换为空 Truncation，在到达原 Reasoning 一半的长度时添加截断推理 Prompt Reduction，（Let’s quickly conclude the answer without showing step-by-step reasoning.） 其他 CoT 压缩：Tokenskip、CoT-Valve 感觉如果不做 Training free，填入 CoT 之后再基于填入的 CoT 进行 SFT 应该还蛮有潜力的 ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/%E6%80%9D%E7%BB%B4%E6%93%8D%E6%8E%A7%E5%A4%96%E9%83%A8cot%E8%BE%85%E5%8A%A9%E5%A4%A7%E6%A8%A1%E5%9E%8B%E6%8E%A8%E7%90%86/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e🧠 思维操控：外部 CoT 辅助大模型推理\n    \u003cdiv id=\"-思维操控外部-cot-辅助大模型推理\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#-%e6%80%9d%e7%bb%b4%e6%93%8d%e6%8e%a7%e5%a4%96%e9%83%a8-cot-%e8%be%85%e5%8a%a9%e5%a4%a7%e6%a8%a1%e5%9e%8b%e6%8e%a8%e7%90%86\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eThought Manipulation: External Thought Can Be Efficient for Large  Reasoning Models\u003c/p\u003e","title":"🧠思维操控：外部CoT辅助大模型推理","type":"posts"},{"content":" ⏰ 开始作答：弹性推理实现的可扩展的 CoT # Scalable Chain of Thoughts via Elastic Reasoning\n这篇文章给我的感觉就像让 LRM 参与面试 一般的 LRM 会尽可能长时间思考，确保答案正确，最后给出答案 但是这篇文章的 LRM 会思考一段时间，当面试官说“注意时间”的时候 LRM 就强行终止思考，基于已经思考的内容给出答案\n其实我更想看一下经过这样处理以后模型的 Reasoning 过程会变成什么样子，会不会更抽象更简洁概括，可惜的是作者并没有放出来\n摘要 # 大型推理模型（LRMs）通过生成扩展的思维链（CoT）在复杂任务上取得了显著进展。然而，其不受控的输出长度为实际部署带来了重大挑战，在实际应用中，对 tokens、延迟或计算资源的推理时间预算有着严格的限制。我们提出了弹性推理（Elastic Reasoning），这是一种可扩展的思维链框架，明确将推理过程分为两个阶段——思考和解决方案，并分别为这两个阶段分配独立的预算。在测试时，弹性推理优先保证解决方案部分的完整性，从而在资源受限的情况下显著提高了可靠性。我们引入了一种轻量级的预算约束 rollout 策略来训练出对截断思考过程具有鲁棒性的模型，并将其整合到 GRPO 中，该方法教导模型在思考过程被中断时进行自适应推理，并能够有效泛化到未见过的预算约束，而无需额外训练。在数学（AIME、MATH500）和编程（LiveCodeBench、Codeforces）基准测试中的实证结果表明，弹性推理在严格预算约束下表现出稳健性，同时相比基线方法大幅降低了训练成本。值得注意的是，即使在无约束条件下，我们的方法也能生成更简洁和高效的推理过程。\n代码尚未公开 动机 # 推理长度过长消耗资源 目前已有方法（Long2Short 和 Length Control）会显著降低模型性能 真的显著降低模型性能嘛…… 不过感觉这篇 paper 还在写，是 5 月 8 号放到 arxiv 上的 方法 # 提出“预算分配”，将总预算 c 分为 t 和 s（t 和 s 是两个超参）两个部分，t 代表思考，s 代表解决方案。并且当推理用光 t 的预算后，就添加一个来强行终止推理\n为了提升基于上述被截断的推理生成答案的性能，引入了一种新的训练策略，教导 model 在不完整的 CoT 基础上生成答案\n训练 # 首先基于 LRM 生成依次 think 和 solution，在生成 think 的过程中，如果 think 长度超出了 t，则强行添加转为生成解决方案。使用 GRPO 训练\n论文没提到如果 solution 超出了 s 怎么办 个人估计应该是直接截断吧？ 推理 # 同样采用上述方法控制 think 的长度\n实验 # 模型：DeepScaleR-1.5B-Preview、DeepCoder-14B-Preview\n数据集：\n训练\n数学：AIME（1984-2023）、AMC、Omni-Math、STILL 编程：TACO、SYNTHETIC-1、LiveCodeBench 评测\n数学：AIME2024、MATH500、AMC、Olympiad-Bench、Minerva Math 编程：LiveCodeBench、Codeforces、HumanEval+ 超参：训练时 t=s=1k；推理时 s=1k，t 测试了多组不同数据\nL1 是使用 RL 让模型根据提示中提供的约束条件动态分配推理计算资源。 S1 是强制预算，通过截断或使用特殊 token 填充来强制用满预算 E1 就是使用本文的方法 train 出的 model：带有 Budget Constraint 字样的是在推理时也设定了 token 预算的 在数学上，始终优于 L1-Exact 和 S1，接近 L1-MAX（但是 E1 训练步骤少）。且当推理不设置预算的时候，其效果是除了原始模型外最佳的\n在编程问题上和原始模型打得有来有回\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/%E5%BC%80%E5%A7%8B%E4%BD%9C%E7%AD%94%E5%BC%B9%E6%80%A7%E6%8E%A8%E7%90%86%E5%AE%9E%E7%8E%B0%E7%9A%84%E5%8F%AF%E6%89%A9%E5%B1%95%E7%9A%84cot/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e⏰ 开始作答：弹性推理实现的可扩展的 CoT\n    \u003cdiv id=\"-开始作答弹性推理实现的可扩展的-cot\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#-%e5%bc%80%e5%a7%8b%e4%bd%9c%e7%ad%94%e5%bc%b9%e6%80%a7%e6%8e%a8%e7%90%86%e5%ae%9e%e7%8e%b0%e7%9a%84%e5%8f%af%e6%89%a9%e5%b1%95%e7%9a%84-cot\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eScalable Chain of Thoughts via Elastic Reasoning\u003c/p\u003e","title":"⏰开始作答：弹性推理实现的可扩展的CoT","type":"posts"},{"content":" DEER：基于 Trial 置信度的推理早停 # DYNAMIC EARLY EXIT IN REASONING MODELS\n摘要 # 近期大型推理语言模型（LRLMs）的进展依赖于测试时扩展，这将长链条思维（CoT）生成延伸以解决复杂任务。然而，过长的 CoT 不仅会降低问题解决的效率，还可能因过于详细或冗余的推理步骤而导致准确性损失。我们提出了一种简单而有效的方法，允许大型语言模型（LLMs）在生成过程中通过早期退出机制自我截断 CoT 序列。与依赖固定启发式规则不同，所提出的方法在潜在的推理转换点（例如，“Wait” tokens）监测模型行为，并在模型对试探性答案表现出高置信度时动态终止下一推理链的生成。我们的方法无需额外训练，可无缝集成到现有的类似 o1 推理 LLMs 中。在多个推理基准测试 MATH-500、AMC 2023、GPQA Diamond 和 AIME 2024 上的实验表明，所提出的方法在 deepseek 系列推理 LLMs 上始终有效，平均将 CoT 序列长度减少 31% 至 43%，同时将准确性提高 1.7% 至 5.7%。\nMotivation # 过长 CoT 显著增加计算开销、推理延迟 过长 CoT 可能偏离正确道路导致 Acc 下降 推理信息中具有信息刚刚好足够的关键点（Pearl Reasoning） 验证 Motivation 3 # 文中似乎对于“Wait”等 token 有一个假设，就是当这个 token 出现时，代表着 llm 要换推理路径了 选择 AIME2024 数据集，让 DeepSeek-R1-Distill-Qwen-14B 进行完整推理和解答，然后从 think 过程中找出“Wait”这个 token，基于这个 token 将完整的推理划分为思考片段，然后仅保留 len(思考片段) \u0026gt; 5 的样本。对于这些样本保留了其不同比例（20%-90%）的思考片段，并在每个截断的推理序列末尾添加了一个结束思考的 token 分隔符，以强制终止慢思考过程。结果如下图\n结束思考的 token 分隔符应该是这种 LLM 对于大多数问题（75%）的推理具备这样一个 Pearl Reasoning，甚至部分（36.7%）问题的 pearl reasoning 还不到原问题的一半。\n值得注意的是，有一些 Question 在推理较短的时候正确，但是长了反而错了 此外，还验证了一下原始推理是正确/错误的但是使用早停机制后正确的数量（Threshold 为 1.0 代表原始推理）\nMethod # 识别出推理中信息刚刚好充足的关键点（Pearl Reasoning），并迫使模型在这一步停止思考转为开始回答，提出三步走方法来识别关键点：\n推理转换监控 像“Wait”这样的词识别为推理转换的关键点，并对其出现进行监测。出现以后进入下一步\n试验性答案诱导 将最后的“Wait”替换为“Final Answer”，来诱导 model 尝试给出答案\n替换为 final answer 后，模型在推理过程中尝试给出答案，并在最后加上 置信度评估 计算试答的置信度，如果试答的置信度够高，就让 LLM 基于已生成的想法直接给出结论；否则就撤回替换那一步，让 LLM 继续推理\n$$ A=LRLM(P,T,I) $$P 代表输入的 Prompt，T 是目前已经生成的 Thought，I 代表引导回答的 token，A 代表着 final answer token 后的东西，由很多 token 组成的 token 序列：\\(A=[a_1,a_2,a_3,……a_n]\\)\n通过下面的公式计算 A 的置信度，下图中 M 为 LM Head 及其前置组件，以 logits 作为输出。\n如果置信度 c 大于阈值 \\(\\lambda\\)（超参），则认为到了 Pearl Reasoning。\n小优化 # 当推理出现 Wait 的时候，不是停止继续推理，而是通过 Attention Mask 进行继续往下推理和试着回答的并行，并通过基于置信度的动态 KV 缓存管理进行剪枝。\n不知道这个“基于置信度的动态 KV 缓存管理进行剪枝”是指什么 是说试着回答之后将尝试回答的部分剪掉，然后重新开始推理？ 实验 # 数据集：\n数学：MATH-500、AMC 2023、AIME 2024、GPQA Diamond 编程：HumanEval、BigCodeBench 模型：DeepSeek-R1-Distill-Qwen 系列 1.5B、7B、14B、32B，额外测了 QwQ-32B\n超参：max_len=16384\n没提到 lambda 的设置，但是后面测试了一系列 lambda 关于 LEN，原文提到测量的是 the number of generated words，应该是包括了推理和最终答案的所有内容 其他现象 # DEER 纠正的错误比 DEER 造成的错误多（绿色部分多于红色部分） 如果 DEER 能在红色样本上避免过早退出，在在 AMC23 上 7B 模型能打败 14B 模型，因此可以研究如何修改早停策略 一系列 \\(\\lambda\\)和编程数据集 监控其他的推理分界线 DEER（W）是 Wait，DEER（A）是 Alternatively\n在 QwQ-32B 上的实验 ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/deer%E5%9F%BA%E4%BA%8Etrial%E7%BD%AE%E4%BF%A1%E5%BA%A6%E7%9A%84%E6%8E%A8%E7%90%86%E6%97%A9%E5%81%9C/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eDEER：基于 Trial 置信度的推理早停\n    \u003cdiv id=\"deer基于-trial-置信度的推理早停\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#deer%e5%9f%ba%e4%ba%8e-trial-%e7%bd%ae%e4%bf%a1%e5%ba%a6%e7%9a%84%e6%8e%a8%e7%90%86%e6%97%a9%e5%81%9c\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eDYNAMIC EARLY EXIT IN REASONING MODELS\u003c/p\u003e","title":"DEER：基于Trial置信度的推理早停","type":"posts"},{"content":" SoftCoT：Prompt➡️SLM➡️LLM # SoftCoT: Soft Chain-of-Thought for Efficient Reasoning with LLMs\n投机采样\n摘要 # 链式思维（CoT）推理使大型语言模型（LLMs）能够通过生成中间推理步骤来解决复杂的推理任务。然而，大多数现有的方法专注于硬 token 解码，这将推理限制在离散的词汇空间内，并且可能并非总是最优的。尽管最近的研究探索了连续空间中的推理，但这些方法通常需要对整个模型进行微调，并且容易遭受灾难性遗忘，从而限制了它们在零样本设置下已经表现良好的最先进的 LLM 中的适用性，尤其是在提供适当指令的情况下。为了解决这一挑战，我们提出了一种新的连续空间推理方法，该方法无需修改 LLM。具体来说，我们使用一个轻量级的固定辅助模型来投机性地生成实例特定的软思维 token 作为初始的思维链条，然后通过一个可训练的投影模块将这些 token 映射到 LLM 的表示空间中。在五个推理基准上的实验结果表明，我们的方法通过监督的、参数高效的微调提升了 LLM 的推理性能。\n动机 # 现有的 CoT 压缩或者连续 CoT 需要微调整个 model，一方面计算成本高，另一方面可能带来灾难性遗忘，并降低了模型通用性 CCoT 和 Coconut 性能下降，推测可能对于 GPT-2 比较合适但是对于新模型效果不佳（SoftCoT 作者归因为灾难性遗忘） 为了避免灾难性遗忘，需要冻结 LLM 的参数，使用一个小型助手 model（ALM，Assistant Language Model）来辅助 LLM\n方法 # 将 ALM 的 map 到词汇前的最后一层隐藏状态取出作为 SoftThought token，将 SoftThought Token 输入到投影模块，通过投影模块将其映射到 LLM 的 latent space（可以为不同任务训练不同的投影模块）\nALM 输入 X_assist 生成 Soft Thought Token，\n这三个分别是对于 ALM 的 Instruction、要推理的问题，以及 SoftThought Token 的占位符\nh_assist 表示辅助模型的最终层隐藏状态，而 t_assist 是 N 个占位符被填充后的的 h_assist 片段。t_assist 作为 Soft Thought\n将 t_assist 输入投影模块，得到 t\n基于此，构建 LLM 的 input\n分别是对于特定问题的固定的 instruction、要推理的问题、和投影出来的 t\n实验 # 数据集：GSM8K、ASDiv、AQuA、StrategyQA、Data Understanding\nBaseline：\nCoconut（Meta 的连续空间推理） 零样本 CoT 零样本 CoT + 占位符（Pause Token） 零样本 Assist-CoT（使用 ALM 生成提示词来驱动 LLM） 模型选择：\nALM 原文中并未提及具体选的哪个，但是在举例中选用 LLaMA-3.1-1B-Instruct LLM 分别选用 LLaMA-3.1-8B 和 Qwen2.5-7b 思考 # 这篇文章有些胜之不武，两个 model 加起来参数量也大，token 也多，计算时间也久，效果要是还差那就奇了怪了，但是对此我也有一些思考\n能否省去 LLM 的 Reasoiong Question，将投影模块的 output 作为初始 hidden state（属于对 input 进行压缩） 能否和 LightThinker 结合，输入 SoftToken 以后采用 LightThinker 的方式进行 CoT 压缩，能否提高 LightThinker 的 Acc？（待实验验证） 或者更进一步，就设计一个 LLM 在正常推理，但是不定期将其推理的隐藏状态取出放到 Input 并重新推理？不定期可以是设计一个二分类器或直接像 LightThinker 按照句子或段落？ ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/softcotprompt%EF%B8%8Fslm%EF%B8%8Fllm/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eSoftCoT：Prompt➡️SLM➡️LLM\n    \u003cdiv id=\"softcotpromptslmllm\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#softcotpromptslmllm\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eSoftCoT: Soft Chain-of-Thought for Efficient Reasoning with LLMs\u003c/p\u003e","title":"SoftCoT：Prompt➡️SLM➡️LLM","type":"posts"},{"content":" CODI: 通过自蒸馏将 CoT 压缩到连续空间中 # CODI: Compressing Chain-of-Thought into Continuous Space via Self-Distillation\n这篇侧重于隐藏状态推理，但是我觉得也可以算压缩吧\nAttention Sink：Q 和前面所有 K 计算的时候，关注大多在首尾，对于起始符关注较高\n再加上会有信息迁移的现象，所以靠后的 token 关注度会比较高\n摘要 # Chain-of-Thought (CoT) 通过使大型语言模型（LLMs）能够进行自然语言的逐步推理来增强其能力。然而，语言空间对于推理可能不是最优的。虽然隐式 CoT 方法试图在不使用显式的 CoT token 的情况下实现推理，但它们在任务性能上一直落后于显式 CoT 方法。我们提出 CODI（通过自蒸馏实现连续 Chain-of-Thought），这是一种新颖的框架，它将 CoT 蒸馏到一个连续空间中，在这个空间里，一个共享模型同时充当教师和学生角色，共同学习显式和隐式 CoT，同时在生成最终答案的 token 上对齐它们的隐藏激活。CODI 是第一个在 GSM8k 上与显式 CoT 性能相匹配的隐式 CoT 方法，同时还实现了 3.1 倍的压缩，准确率比之前最先进的方法高出 28.2%。此外，CODI 表现出在更复杂的 CoT 数据集上的可扩展性、鲁棒性和泛化能力。此外，CODI 通过解码其连续思维保持了解释性，使其推理过程透明。我们的发现确立了隐式 CoT 不仅是一种更高效而且是强大的替代方案，可以替代显式 CoT。\nMotivation # 人类数学推理中大脑的语言区域并未被激活，因此自然语言推理可能不是最优的 隐藏状态的推理是稠密的，而自然语言推理是稀疏的 方法 # 设计了一个自蒸馏框架，其中 Teacher 模型学习外显的 CoT，而 Student 学习隐式的 CoT\n学生的最终回答计算出 L_student，教师的回答计算出 L_teacher，将教师模型中的关键 token 的隐藏激活与学生模型的对应部分计算 L_KD\n看代码得知，所谓的“关键 Token 的隐藏激活”是指 CoT 后、正式回答前的最后一个 Token 所对应的隐藏状态，比如“The final Answer is：”的冒号 最终 Loss：（三个系数是三个超参，看代码均设置为 1，论文中未提及）\n在模型架构方面，仅对学生模型进行了修改，增加了两个特殊 Token，BoT 和 EoT、一个两层的 MLP+ 归一化将隐藏状态改成 Token\n学生的推理步骤如下：输入问题、手动插入 BoT、计算 n（超参数，看代码设置为 6，论文中提到 6 个步骤足够大多数 CoT 任务）个步骤、手动插入 EoT、自然语言给出答案\n实验 # 似乎未提到训练时的硬件资源，只提到了推理时使用一张 A100（应该是 80G）\n训练数据集：GSM8k-Aug 和 GSM8k-Aug-NL\n测试数据集：上述数据集、SVAMP、GSM-HARD、MultiArith、MAWPS\nbaseline：\nCoT-SFT（temperature 设置 0.1，取 10 次的平均值） No-CoT-SFT（不生成中间步骤） iCoT（另一种隐藏状态推理的模型） Coconut（截止发文时的隐藏状态推理的 SOTA） ACC 与 CoT-SFT 相差无大、优于其他隐藏状态推理\nToken 数量也赢！\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/codi_-%E9%80%9A%E8%BF%87%E8%87%AA%E8%92%B8%E9%A6%8F%E5%B0%86cot%E5%8E%8B%E7%BC%A9%E5%88%B0%E8%BF%9E%E7%BB%AD%E7%A9%BA%E9%97%B4%E4%B8%AD/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eCODI: 通过自蒸馏将 CoT 压缩到连续空间中\n    \u003cdiv id=\"codi-通过自蒸馏将-cot-压缩到连续空间中\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#codi-%e9%80%9a%e8%bf%87%e8%87%aa%e8%92%b8%e9%a6%8f%e5%b0%86-cot-%e5%8e%8b%e7%bc%a9%e5%88%b0%e8%bf%9e%e7%bb%ad%e7%a9%ba%e9%97%b4%e4%b8%ad\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eCODI: Compressing Chain-of-Thought into Continuous Space via Self-Distillation\u003c/p\u003e","title":"CODI: 通过自蒸馏将CoT压缩到连续空间中","type":"posts"},{"content":" HAWKEYE：大小模型协作实现精简 CoT # Hawkeye:Efficient Reasoning with Model Collaboration\n摘要 # 链式思维（CoT）推理在增强大型语言模型（LLMs）的推理能力方面展现了显著的有效性。然而，其效率仍面临挑战，因为会生成过多的中间推理 tokens，这引入了语义冗余和过于详细的推理步骤。此外，计算成本和延迟是重要的问题，因为成本随着输出 tokens 的数量（包括中间步骤）增加而上升。在这项工作中，我们观察到大多数 CoT tokens 并非必要，仅保留其中一小部分便足以生成高质量的响应。受此启发，我们提出了 HAWKEYE，这是一种新颖的后训练和推理框架，在该框架中，一个大模型生成简洁的 CoT 指令，以指导一个小模型生成响应。HAWKEYE 通过强化学习量化 CoT 推理中的冗余并提取高密度信息。借助这些简洁的 CoTs，HAWKEYE 能够在显著减少 token 使用和计算成本的同时扩展响应。我们的评估表明，HAWKEYE 仅使用完整 CoTs 的 35% 即可达到相似的响应质量，同时将清晰度、连贯性和简洁性提高了约 10%。此外，HAWKEYE 在复杂数学任务上可加速端到端推理高达 3.4 倍，同时将推理成本降低多达 60%。HAWKEYE 将开源，并且相关模型不久后将可供使用。\n动机 # Token 太多了成本太高 ➕ 大多数推理过程的 Token 是冗余的不必要的\n关于大多数推理 Token 的不必要性，作者简单举例：对于同一个问题，o1 使用了 40k token 但是 4o 只用了 4k\n观察发现 # CoT 包含大量冗余信息 # 重复的提示（hints）、填充短语（Well、嗯……，等）、过于细致的步骤\n实验设计 # 让大模型（GPT-4o、Claude 3.5 Sonnet、Grok 3）生成 CoT，并把答案去除仅保留推理步骤 提示词： 你是一位耐心且思维缜密的数学辅导老师。请仔细按照以下问题逐步进行推理，并使用清晰的逻辑和中间计算过程。彻底解释你的思考方式，但不要给出最终答案。 问题：¡在此插入问题¿ 让我们一步步思考。\n让 LLM 移除上述推理步骤中的冗余信息，实现 CoT 的“压缩” $$ 压缩率=\\frac{被减去的token数}{原始的token数} $$ 提示词： 你得到了一个用于解决问题的详细逐步推理（Chain-of-Thought）。你的任务是在保持大约 (compression ratio)% 的原始 tokens 不变的情况下修订该解释。如果需要，可以进行轻微的编辑以澄清或改善风格，但要保留整体结构、意义以及大多数措辞。不要简化或省略步骤。 关键要求是保留原始推理中最重要信息，确保核心逻辑和步骤得到保存。 原始 CoT： \u0026lt; 在此插入原始 Chain-of-Thought\u0026gt; 修订后 CoT：\n压缩前后对比及不同压缩率对比\n将压缩的 CoT 交给小模型（LLaMA3.1-1B, Qwen2.5-0.5B），让小模型基于 CoT 给出最终答案 似乎没给出小模型的 Prompt？\n发现压缩率在 70%（仅保留 30% 推理步骤）的情况下仍能保持优异性能\n方法 # HAWKEYE：后训练 # 基于上述观察到的现象，使用 GRPO 训练，长度惩罚初始设置为 0.3，并对超过该阈值的 token 数量施加一个与其成比例的二次方惩罚。\n上图中的 s 是一个固定的 instruction prompt\n更新的是 Model A（生成 CoT 的大模型）的参数，基于 CoT 得出最终答案的 Model B（小模型）的参数不动。依据小模型给出的最终答案评分\n如此设计的优势： # 让 Model A 生成更少的 CoT 防止 Model A 绕过推理过程直接给出答案来“作弊” 对于 2，如果没有小模型（Model B），大模型会直接给出答案（答案正确 + 输出短）来获取最高的分数\nHAWKEYE：推理 # 实验 # 硬件：\nbaseline：Deepseek-R1-Distilled-Qwen-7B、Qwen2.5-0.5B\n模型：Deepseek-R1-Distilled-Qwen-7B-Hawkeye + Qwen2.5-0.5B\n数据集：MATH, MATH500, GSM8K, AIME\nHawkeye 稍稍下降，但是相差不大\n优秀闭源大模型对于 DeepSeek 和 Hawkeye 的评分：\n相差不大甚至略胜一筹，且发现将 SLM 从 0.5B 调整到 7B 提升不明显\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/hawkeye%E5%A4%A7%E5%B0%8F%E6%A8%A1%E5%9E%8B%E5%8D%8F%E4%BD%9C%E5%AE%9E%E7%8E%B0%E7%B2%BE%E7%AE%80cot/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eHAWKEYE：大小模型协作实现精简 CoT\n    \u003cdiv id=\"hawkeye大小模型协作实现精简-cot\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#hawkeye%e5%a4%a7%e5%b0%8f%e6%a8%a1%e5%9e%8b%e5%8d%8f%e4%bd%9c%e5%ae%9e%e7%8e%b0%e7%b2%be%e7%ae%80-cot\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eHawkeye:Efficient Reasoning with Model Collaboration\u003c/p\u003e","title":"HAWKEYE：大小模型协作实现精简CoT","type":"posts"},{"content":" LCIRC: 长文档循环压缩方法 （LLM Training Free） # LCIRC: A Recurrent Compression Approach for Efficient Long-form Context and Query Dependent Modeling in LLMs\nAccepted to NAACL 2025 Main\nCheck h 的 size\n摘要 # 虽然大型语言模型（LLMs）在生成连贯且上下文丰富的输出方面表现出色，但其高效处理长篇上下文的能力受限于固定长度的位置嵌入。此外，处理长序列的计算成本呈二次增长，这使得扩展上下文长度变得困难。为了解决这些挑战，我们提出了带有循环压缩的长篇上下文注入（LCIRC），这是一种通过循环压缩实现对超过模型长度限制的长篇序列高效处理的方法，而无需重新训练整个模型。我们进一步引入了查询依赖的上下文建模，该方法有选择性地压缩与查询相关的信息，确保模型保留最相关的上下文内容。我们的实证结果表明，查询依赖的 LCIRC（QD-LCIRC）显著提升了 LLM 处理扩展上下文的能力，使其非常适合需要全面上下文理解和查询相关性的任务。\n动机 # 当上下文超出模型最大长上下文会导致遗忘先前信息\n二次方计算复杂度高，所以单纯增加上下文是不可取的\n方法 # 下图中带 🔥 的部分为训练的部分，带 ❄️ 的部分是冻结的部分，简单而言，除了 LLM 本身，都在训练\n压缩器（绿色部分，Perceiver 架构）：每个模块包含一个交叉注意力层，其后是两层带残差连接的 MLP，将 x 输入模型时，x 被随机截断，其中\\(e_C\\)是未输入模型的那一部分的 embedding。h0 是长度为 k（超参数，实验中设置为 64 和 256）的一组可学习的 query features\n举例来说，假如一个模型（如 LLaMA）的上下文只有 4k，但是我的 input 却有 192k，在输入模型时 input 被随机截断，但确保较小的那一段在模型的上下文范围内（如 190K 和 2K），则 e_C 就是 190K 的那部分 但是由于 \\(e_C\\)很长，一次性计算出 h 的消耗是很大的，所以采用一种循环的方式计算出 h⬇️，其中 e_C 被分割为 S 个互不相交的段\n最后，将 h 们连接到一起\n下图是大图中蓝色区域的计算：\na 和 b 是两个标量参数，并且初始化为 0，以保证不损失原有模型性能\ne_l 代表最终被保留的序列在第_l_个 transformer 块上的 embeddng，CA 表示 Cross Attention\n这个_l_是什么呢？ 训练阶段 # 仅使用超过原模型上下文的数据进行训练，冻结 LLM 模块，仅训练其他模块\n推理阶段 # 当且仅当上下文超过原模型的上下文限制时激活 LCIRC，否则就是一个正常的普通模型\n当激活 LCIRC 时：\n如果模型的输出的长度在上下文窗口之中——直接输出 如果模型的输出又超出了上下文窗口——迭代压缩之前生成的部分，比如压缩一半的最大窗口长度 改进：依赖 Query 的 Context Model # 简单来说，将上方纵览图中的绿色部分换成下图右边部分\n每次除了输入 h_(i-1)和 si 外，还输入了 e_query，相当于根据 query 为 s 分配不同的 attention 改进 + 训练： # 使用 Random Selective BPTT 进行训练，随机选择几个 h 计算 loss（实验部分选了 8 个），这样可以在减少计算量的同时保持模型关注长上下文的能力。\n实验： # 数据集：FineWeb-Edu（筛出长度大于 4k 的数据）、FineWeb-LQA（基于 Edu 作者合成的长 QA 数据集）、InfiniteBench（Focuse on 长文本问答和长文本多选）、LongBench、L-Eval\n模型：LLaMA2-7B\nbaseline：原模型（4k）+ 通过修改 RoPE θ 将 token 长度限制扩展到 8K 的 LLaMA2-7B（ExtendedFA，8k）+AutoCompressor（84k）（而 Ours 可以实现 815K）\n所有模型均在 FineWeb-Edu 上 Finetune 过，且对于 QD-LCIRC，我们使用 LCIRC 在 FineWeb-Edu 上的预训练权重初始化模型，并在 FineWeb-LQA 上对其进行微调，以实现查询相关的建模。在 baseline 上如果超出了最长上下文则直接截断\n其他 # AutoCompressor：\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/lcirc_-%E9%95%BF%E6%96%87%E6%A1%A3%E5%BE%AA%E7%8E%AF%E5%8E%8B%E7%BC%A9%E6%96%B9%E6%B3%95-llm-training-free/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eLCIRC: 长文档循环压缩方法 （LLM Training Free）\n    \u003cdiv id=\"lcirc-长文档循环压缩方法-llm-training-free\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#lcirc-%e9%95%bf%e6%96%87%e6%a1%a3%e5%be%aa%e7%8e%af%e5%8e%8b%e7%bc%a9%e6%96%b9%e6%b3%95-llm-training-free\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eLCIRC: A Recurrent Compression Approach for Efficient Long-form Context and Query Dependent Modeling in LLMs\u003c/p\u003e","title":"LCIRC: 长文档循环压缩方法 （LLM Training Free）","type":"posts"},{"content":" LLM 在连续 Latent 空间中推理 # Training Large Language Models to Reason in a Continuous Latent Space\n摘要 # 大型语言模型（LLMs）受限于“语言空间”，通常通过思维链（CoT）来表达推理过程以解决复杂的推理问题。然而，我们认为语言空间并不总是最优的推理选择。例如，大多数 token 主要用于文本连贯性而非推理，而一些关键词元需要复杂的规划并对 LLMs 构成巨大挑战。为了探索 LLMs 在不受限潜在空间中的推理潜力，而不是局限于自然语言，我们引入了一种新的范式——椰子（Chain of Continuous Thought，Coconut）。**我们利用 LLM 的最后一个 作为推理状态的表示（称为“连续思维”）。我们将其直接作为下一个 token 输入 llm。**实验表明，椰子能够在多个推理任务中有效增强 LLM 的表现。这种新颖的潜在推理范式导致了高级推理模式的涌现：连续思维能够编码多个替代的下一步推理步骤，使模型能够在推理过程中进行广度优先搜索（BFS），而非像思维链那样过早地锁定单一确定路径。在某些需要大量回溯的逻辑推理任务中，椰子的表现优于思维链，并且在推理过程中使用的思考 token 更少。这些发现展示了潜在推理的潜力，并为未来研究提供了宝贵的见解。\n动机 # CoT 中大多数 token 仅仅保持行文流畅，对于实际推理过程没啥作用。但是 LLM 为预测每个 token 分配了几乎相同的算力。理想的情况是能够在没有任何语言约束的情况下自由推理，仅在必要时将其发现转化为语言。\n简言之，CoT 大多数 Token 仅仅是为了保持行文流畅的，LLM 没必要在上面浪费算力，可是实际是浪费了 方法 # 核心思路 # 和是两个特殊 token，begin of thought 和 end of thought\n训练阶段 # 训练分为多个阶段：\n初始阶段（Stage 0）：在常规 CoT 上训练\n第 k 阶段（Stage k）：CoT 中前 k 个推理步骤的文本替换成 k * c 个连续思维（thought token），其中 c 是一个超参数，表明每个 step 替换成多少个 token\n没看到 step 是怎么划分的，还想或许可以和 lightthinker 结合一下 step 看行文逻辑感觉是数据集里自带的 训练过程中舍弃了 Question 和 thought 的损失\n推理阶段 # 将最后一个隐藏状态作为下一个输入的 embedding\n关于什么时候结束 thought 作者提出两种方案，一种是在 thought 上训练一个二分类器，另一种是将 thought 填充到固定长度。作者发现两种方式的表现都很不错，为了简化实验后续采用第二种方式\n实验 # 主实验 # 模型：GPT-2\n任务：数学推理、逻辑推理\n数学推理 # 数据集：在 GSM8k 合成的数据（自带 step）\n超参数：设置 c=2，也就是每个 step 被抽象为 2 个 thought；在 Stage 3 后面添加一个 Stage 3+1，移除了后续所有的语言推理链，thought 和 Stage 3 完全相同\n逻辑推理 # 数据集：ProsQA(Proof with Search Question-Answering) 和 ProntoQA\n我们使用 5-hop ProntoQA（Saparov 和 He，2022）问题，并采用虚构的概念名称。对于每个问题，随机生成一个树状结构的本体，并以自然语言描述为一组已知条件。模型被要求根据这些条件判断给定陈述是否正确。这作为更高级推理任务（如自动化定理证明，Chen 等人，2023；DeepMind，2024）的一种简化模拟。\n超参数：设置 c=1，也就是每个 step 被抽象为 1 个 thought；一共 6 个 Stage，最后一阶段没有可读的 CoT，都是 thought\niCoT：该模型采用语言推理链进行训练，并遵循一个精心设计的 schedule，以“内化”CoT。随着训练的进行，推理链起始部分的标记逐渐被移除，直到只剩下答案。在推理阶段，模型直接预测答案。\n表格中 COCONUT 下方的斜体字是 COCONUT 方法的其他变体\nw/o curriculum 是不采用多阶段训练，直接使用最后一阶段的数据\nw/o thought 是不使用任何 thought token，但是推理内容还是被逐步移除了（需要读一下 iCOT）\npause 是采用token 而非 thought token\n数据集格式：\n其他发现 # 超参数 c 的选择 # c 越高，acc 越高\n在两个逻辑推理任务上，CoT 对于 No-CoT 提升并不明显 # GSM8k 和 ProntoQA 由于直观的问题结构和有限的分支，对于下一步预测相对简单。相比之下，ProsQA 随机生成的有向无环图（DAG）结构显著挑战了模型的规划能力。latent 推理在需要大量规划的任务中具有明显优势。\n超参数 k（thought 的个数）的选择 # ProsQA\nCoconut 变体 # 结论 # 哪怕是让 COCONUT 直接生成完整的思维链，其效果还是优于 CoT。因为 CoT 的训练目标在立刻生成下一步，模型“近视”；但是 COCONUT 的训练后期，前几步被隐藏了，模型更加关注未来的步骤，所以增强了其提取规划能力 实验 # 在 ProsQA 上测试了 k 从 0 到 5 的所有 Coconut 变体，仅在推理过程中修改 k，没有重新训练模型\n设计两组评价指标，一种是判断最终答案正确与否，另一种是判断路径正确与否\n关于路径，作者提出有 6 种：\n正确路径（Correct Path）：达到正确答案的最短路径之一（） 长路径（Longer Path）：对了，但是路径更长 幻觉（Hallucination）：路径中存在不存在的边、或路径断了 错误目标（Wrong Target）：所答非所问 对于 k=0 或者 CoT，由于这两者会生成推理路径，则直接使用前 4 以上方法分类即可\n对于 k\u0026gt;0，由于仅仅使用语言输出部分路径，则：如果能补全成完整的正确的推理，则分类为正确路径；也用类似的方法可以分类为长路径和错误目标；如果没法补全成完整的正确推理，就分类为幻觉\n正确 错误 对于 no-Cot 和较大的 k（输出的推理少），采用以上两种分类方案\n这六种类别涵盖了所有情况且无重叠。\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/llm%E5%9C%A8%E8%BF%9E%E7%BB%ADlatent%E7%A9%BA%E9%97%B4%E4%B8%AD%E6%8E%A8%E7%90%86/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eLLM 在连续 Latent 空间中推理\n    \u003cdiv id=\"llm-在连续-latent-空间中推理\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#llm-%e5%9c%a8%e8%bf%9e%e7%bb%ad-latent-%e7%a9%ba%e9%97%b4%e4%b8%ad%e6%8e%a8%e7%90%86\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eTraining Large Language Models to Reason in a Continuous Latent Space\u003c/p\u003e","title":"LLM在连续Latent空间中推理","type":"posts"},{"content":" Pause Token：隐式 CoT # Think before you speak: Training Language Models With Pause Tokens\n摘要 # 基于 Transformer 的语言模型通过连续生成一系列 token 来生成响应：**第(K + 1)个 token 是通过对每层的 K 个隐藏向量进行操作的结果，每个 preceding token 对应一个隐藏向量。但如果我们在模型输出第(K + 1)个 token 之前，让它处理比如说 K + 10 个隐藏向量会怎样？**我们通过在语言模型上进行带有（可学习的）暂停 token 的训练和推理来实现这个想法，将暂停 token 序列附加到输入前缀中。然后，我们延迟提取模型的输出，直到看到最后一个暂停 token，从而允许模型在承诺给出答案之前处理额外的计算。我们在 C4 数据集上使用因果预训练对参数量为 1B 和 130M 的仅解码器模型进行了 pause 训练，并评估了下游任务，包括推理、问答、一般理解和事实回忆。我们的主要发现是在模型既经过预训练又经过微调的情况下，推理时间延迟在我们的任务上显示出增益。对于 1B 模型，我们在八个任务上观察到了提升，其中最显著的是 SQuAD 问答任务上的 EM 得分提高了 18%，CommonSenseQA 上的提升了 8%，GSM8k 推理任务上的准确率提高了 1%。我们的工作引发了关于将延迟下一个 token 预测作为广泛应用的新范式的概念性和实践性未来研究问题。\n动机 # Transformer 生成文本时，通常是基于前 K 个 token，立即预测第 K+1 个 token，其内部每层执行 K 次操作（每个 token 一次）。这种设计在模型架构初始提出时是合理的，但限制了每层的计算宽度。作者提出：**如果模型在输出下一个 token 之前，能够执行更多次操作，会不会获得更好的表达能力？**于是，他们提出通过引入 \u0026lt;pause\u0026gt; token 来打破这个限制\n方法 # 核心思想 # 引入 \u0026lt;pause\u0026gt; token（模型可学习的 token），将其插入输入序列中，延迟模型的输出，从而让模型在每层中额外计算更多 hidden states 用于生成下一个 token。\n具体 # Pretrain with pause token # 由于预训练数据中没有标注哪一部分是答案，所以无法在提取答案前附加 pause token。\n问题 推理 答案\n问题 答案\n这里的哪一部分是答案感觉有两种解释（论文中没有指明）， 不知道这里的答案是相对于推理过程来说的，还是相对于问题来说的 不过感觉前者的可能性更大一点 因此作者的做法是对于给定的预训练序列 p 在均匀随机的位置插入 M_pt 个 pause token（如下图 b）。然后，在加入了 pause 的 token 序列上使用标准的 next token prediction loss 来训练模型，同时在计算损失时跳过 pause token。最后，更新模型及其所有 token（包括标记）的参数。\n我们跳过了对于 pause token 的 loss 的计算，原因在于，我们只希望使用作为一种方式来强制模型计算延迟；要求模型自身生成这些标记只会造成无谓的干扰。\nFinetune with pause token # 在微调时，使用了带有 prefix（问题）和 target（答案）的数据（没有上一步的无法区分哪一部分是答案的问题了），于是直接在 prefix 后添加 M_ft（实验中分别设置为 10 和 50）个 pause token 作为新的 prefix，如下图\n与上一个步骤一样，在看到最后一个之前忽略模型的输出。\n使用上述构建的数据微调模型，更新模型的参数以及整个词汇表的参数，还有生成 pause token 的模块的参数\nPausing during inference # 在推理时，在 prefix 后添加 M_inf（实验中与 M_ft 一致）个 pause token，并忽略模型输出直到计算到最后一个 pause token 才开始输出。\n实验 # 模型：选择 1B 和 130M 的 decoder-only 的模型\n数据集：C4 英文混合数据集上进行预训练\n2048 + 10 - 10\n数据集预处理：在序列长度（2048）的 10% 位置随机插入，并将现在更长的序列裁剪回原始序列长度。然后，对 pause 预训练和标准预训练进行相同数量的总 token 数（200B）训练。单一的嵌入，有效地增加了参数数量 1024（即标记嵌入的大小），但这一数量相对于总计 10 亿的参数量来说微不足道（该 token 占模型大小的 10⁻⁶）。\n1B 模型：\n1B 模型除了 HellaSwag 数据集上，Pause 预训练-PauseFT 的组合（蓝色）均优于标准预训练-标注 FT（黄色）的组合\n但是在 130M 模型上，只有 6 个数据集优于 baseline：\n下图：\nA. 对比 baseline 和填充省略号\u0026hellip;而非（pause win！）\nB. 不同下游数据集上有适合的不同 M_ft 数量\nCD. 当 M_inf 不等于 M_ft 的时候，模型相比较与 baseline 的表现\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/pause-token%E9%9A%90%E5%BC%8Fcot/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003ePause Token：隐式 CoT\n    \u003cdiv id=\"pause-token隐式-cot\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#pause-token%e9%9a%90%e5%bc%8f-cot\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eThink before you speak: Training Language Models With Pause Tokens\u003c/p\u003e","title":"Pause Token：隐式CoT","type":"posts"},{"content":" 面向模型推理思考优化的 Test time scaling # Towards Thinking-Optimal Scaling of Test-Time Compute for LLM Reasoning\n摘要 # 近期研究表明，让模型花费更多时间通过更长的 Chain of Thoughts（CoTs）可以显著提升其在复杂推理任务中的表现。尽管目前的研究仍在继续探索通过扩展 Large Language Models（LLMs）的 CoT 长度来增加测试时计算量的好处，但我们关注到当前追求测试时扩展可能隐藏的一个潜在问题：过度扩展 CoT 长度是否真的会对模型的推理性能带来负面影响？我们在数学推理任务上的探索揭示了一个意外发现，即在某些领域中，过度使用更长的 CoTs 确实会损害 LLMs 的推理能力。此外，我们还发现存在一个在不同领域中有所差异的最佳扩展长度分布。基于这些洞察，我们提出了 ThinkingOptimal Scaling 策略。我们的方法首先使用一组具有不同响应长度分布的小规模种子数据，教导模型根据不同推理需求采取不同的思考努力；然后，模型在额外的问题上，根据不同的推理努力选择最短的正确回答进行自我改进。我们的自优化模型基于 Qwen2.5-32B-Instruct 构建，在各种数学基准测试中超越了其他基于蒸馏的 32B o1 类模型，并且性能达到了与 QwQ-32B-Preview 相当的水平。\nMotivation # 类似 o1 的模型会出现 over-thinking 迹象、且更长的 CoT 可能对模型性能产生负面影响（研究问题）\n我们的目标是探讨和研究过度的测试时扩展是否可能损害大型语言模型(LLMs)在数学领域中的推理性能。\n研究问题 1——过长 CoT 影响 llm 性能 # 实验 1 # 使用 MATH500 和 AIME2024 数据集，统计平均 token 数，使用 Qwen2.5 tokenizer 计算每个模型生成的 CoTs 的 token 数量以进行公平比较。\n对于无法获取内部 CoT 的模型（如 o1-mini），使用 summary、推理 token 数和总补全 token 数估计 token 数，\n\\(n^{qwen}_s\\)代表 qwen tokenizer 估计出的 token 数， \\(n^{o1}_r\\)代表 o1 返回的 Reasoning token 数， \\(n^{o1}_c\\)代表 o1 返回的 summary token 数 + \\(n^{o1}_r\\)\n$$ token总数=n^{qwen}_s \\times \\frac{n^{o1}_r}{n^{o1}_c - n^{o1}_r} $$ 后续的 o1-like 模型（QwQ32B-Preview 和 Gemini2.0-Flash-Thinking）相比于 o1-mini 显示出较少的有效扩展效果，因为它们生成了更多的 token，但在从其对应的 System-1 思维模型扩展时获得的改进却更少。QwQ-32B-Preview 在这方面存在最严重的问题。这一初步分析在一定程度上表明，过度扩展到更长的 CoT 并不能最大化测试时间的扩展效果。\n实验 2 # 使用三个 system prompt，对应不同努力程度（“低”、“中”、“高”），让 QwQ-32B-Preview 为从 NuminaMath 数据集中的问题生成不同数量 token 的解决方案 筛选出在三种推理努力下均正确回答且推理路径长度不同的问题， QwQ-32B 的指令跟随能力相对较差，体现在对同一问题生成的响应长度分布与指定的系统提示不完全匹配。对于给定的问题，进一步根据三个响应的长度重新排序，并在它们的成对长度差异始终超过 300 个 token 时保留它们。\n使用上述所有 问题-推理-答案 数据微调 LLaMA3.1-8B 和 Qwen2.5-32B，命名为 LLaMA3.1-8B-Tag 和 Qwen2.5-32B-Tag。 Finally, we curate a set of 1.3K problems, each accompanied by three o1-like responses of varying lengths. The data statistics of each set for each model is shown in Table 1.\n没懂，是使用不同的数据集微调模型吗？\nlr=1e-5，batch_size=32, Qwen 的 epochs 为 3， LLaMA 为 5\n对于 Tag 模型，分别使用三种提示词，测试问题回答 o1-like model temperature 设置为 1.0。对于 Qwen 和 LLaMA 分别比较 temperature 为 1.0 和 0.0 的情况，对于 temperature 为 1.0 计算 5 次随机 seed 的平均值\n在 GSM8K 和 MATH500 数据集上，不同的 Token 数得出的 Acc 相差不大，但是在 AIME2024 上相差较多\nINFTYTHINK：打破大型语言模型长上下文推理长度限制提到 AIME2024 难度较大，需要更长的推理链 我们可以从这些结果中得出几个有趣的结论：\n少量的 o1-like 响应已经能够显著提升 LLMs 的推理性能，这与之前的研究结果一致[22, 14]。 在某些领域，特别是简单任务上，随着 CoT 长度的增加可能会对模型的推理性能带来负面影响。例如，LLaMA3.1-8B-Tag 和 Qwen2.5-32B-Tag 在高推理努力下表现不如其他两种推理努力，同时消耗了显著更多的 token，特别是在 GSM8K 和 MATH500 数据集上。 存在一个最佳的推理努力程度，它因任务难度的不同而有所差异。正如我们所见，在 GSM8K 上低推理努力始终表现最佳，而在较难的问题上，中等和高推理努力则更为有益。 分析——为什么过长 CoT 反而会影响性能？ # 我们观察到当推理努力增加时，错误推理轮次的数量也增加。在更多错误步骤上训练模型会对模型的推理能力带来负面影响，这可以解释为什么高推理努力的扩展会导致更差的结果。因此，我们可以得出结论，虽然包含某些错误且具有反思性的步骤可以帮助模型在推理过程中学习纠正错误，但过多的错误步骤可能会对模型的学习产生有害影响。\n研究问题 2——Thinking-Optimal Test-Time Scaling # 简称 TOPS\n主要解决，如何让 llm 在复杂问题上投注更多精力（更长的 CoT），在简单问题上少一点\n方法 # 格式模仿-有条件的不同努力推理生成-自我改进\n格式模仿 # 一组 o1-like 的回复进行冷启动，使模型可以学习 system 2 的思维模式，可以由人工书写 or 模型生成，后续实验中选择 QwQ-32B-Preview 的不同努力程度的思维链\n但是以往研究采用的是固定长度分布的 seed sample（即直接由现有的 o1 类模型生成），本篇工作选择创建包含不同推理努力下的响应的种子数据（即不同的长度分布）。\n作者构建数据集\n其中 D_{si}表示在特定推理努力 ei 下对种子问题的响应。\n并基于此数据集训练基础 tag 模型\n有条件的不同努力推理生成 # 然后我们使用标记模型在不同的推理努力 ei 下为大量的额外数学问题 Pa 生成解决方案。\n其中 π 是 tag 模型（使用上述数据集微调出的模型）的输出分布。接着在所有的 Pa 的 y 中选择正确的且最短的 y，作为 Pa 的 thinking-optimal response，基于此构建了一个数据集\n自我改进 # 基于上述构建的数据集，再 SFT 基础模型\n实验 # 简单问题上 Token 少了\nBaseline\nQwQ-32B-Preview STILL-2-32B：一个基于 QwQ-32B-Preview 和 DeepSeek-R1-Lite 生成的 3.9K 个具有挑战性的数学例子训练的 System-2 思维模型 Sky-T1-32B-Preview：训练使用的推理模型基于 QwQ-32B-Preview 生成的 17K 个样本，其中包括 10K 个数学示例。 Qwen2.5-32B-Random：在 tag 模型基于推理努力生成解之后，我们在每个问题上随机选择一个正确的解而不是最短的解来构建思维次优数据集，并在此数据集上训练基础模型。 为了进一步提升模型在具有挑战性问题上的推理性能，我们在 Qwen2.5-32B-TOPS 上进行迭代自改进。具体而言，我们选择了额外的 4500 个 MATH 问题[13]（这些问题是之前使用的问题中未出现过的）以及 AIME1983-2023 的问题。对于每个问题，我们从 Qwen2.5-32B-TOPS 采样 8 个响应。然后，在这 8 个响应中选择最短的正确响应作为选定响应。一种迭代自改进的方法是对由所有选定响应（最短正确响应）组成的数据集进一步监督微调 Qwen2.5-32B-TOPS，从而得到 Qwen2.5-32B-TOPSIter-SFT。此外，我们还可以执行偏好优化。具体来说，如果有最终答案错误的响应，我们选择最长的错误响应作为拒绝响应以提高推理能力。另外，如果存在比最短正确响应更短的错误响应，我们将这些错误响应中最短的一个作为拒绝响应，并包含这些偏好对，以避免模型思考不足。在获得偏好数据集后，我们在 Qwen2.5-32B-TOPS 上进行直接偏好优化（DPO）[28]，得到 Qwen2.5-32BTOPS-Iter-DPO。\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/%E9%9D%A2%E5%90%91%E6%A8%A1%E5%9E%8B%E6%8E%A8%E7%90%86%E6%80%9D%E8%80%83%E4%BC%98%E5%8C%96%E7%9A%84test-time-scaling/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003e面向模型推理思考优化的 Test time scaling\n    \u003cdiv id=\"面向模型推理思考优化的-test-time-scaling\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#%e9%9d%a2%e5%90%91%e6%a8%a1%e5%9e%8b%e6%8e%a8%e7%90%86%e6%80%9d%e8%80%83%e4%bc%98%e5%8c%96%e7%9a%84-test-time-scaling\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eTowards Thinking-Optimal Scaling of Test-Time Compute for LLM Reasoning\u003c/p\u003e","title":"面向模型推理思考优化的Test time scaling","type":"posts"},{"content":" CCoT：通过密集表示实现高效推理 # Compressed Chain of Thought: Efficient Reasoning Through Dense Representations\n摘要 # 提出了一种新的推理框架“Compressed Chain-of-Thought（CCOT）”，旨在在不显著增加解码时间的前提下提升大语言模型的推理能力。该方法通过生成**“沉思（contemplation）token”**——压缩版的推理链条表示，替代传统显式语言推理路径，实现在连续空间中高效推理。CCOT 可灵活地调节推理质量与计算效率的平衡，并可适用于现有的解码器型语言模型。实验显示，CCOT 在保持较低延迟的同时显著提升了准确率。\nMotivation # 链式思维（CoT）技术通过让模型“逐步思考”以提高其复杂推理能力，但代价是极高的生成延迟。例如，使用 CoT 提示时 GPT-4o 的响应时间是普通方式的约 7 倍。其他工作尝试通过类似“沉思 token”来缩短显式推理路径，例如 pause token、filler token 等，这些 token 大多数是非语义性的，提供额外计算但缺乏语义表示。\n本工作指出，使用语义有内容的沉思 token（compressed reasoning chain 的表示）可以在更短时间内保留推理能力，并能被模型用于后续解码或可解释分析。通过对 CoT 链条进行连续空间的压缩表达，可获得一种新的高效推理机制，同时减少计算成本和生成长度。\nContentful Token： 如果 token 本身是有内容的 或 token 所对应的隐藏状态是从前者派生而来的 方法 # 训练阶段\n这种架构包含两个模块：CCOT φ（生成沉思 token）和 DECODE ψ（基于 query 和沉思 token 生成最终答案）。\n打分器 # 其中打分器的核心是一个 linear，来自另一篇 paper 发布的 checkpoint，作用是评价输入的隐藏状态的重要性，后续作者依据重要性选出 top-k 的隐藏状态作为沉思 token（沉思 token 定义：是推理链条压缩后的连续向量序列，具有语义意义，长度可调。），k 由超参数 r（压缩率，k=r*原始 CoT 的 token 数）指定。在具体实验中，作者选择 Transformer 第 T 层（实验中选择 3）的隐藏状态作为打分器的输入，并将打分器选出来的隐藏状态当做 ground truth 的沉思 token，使用 query 的隐藏状态和这些沉思 token 来训练 CCOT 模块\n关于压缩率 r r=0 时，数据包括 Query 和 Answer（直接删除 CoT） r=1 时，数据包括 Query、Reasoning、Answer（完整 CoT） 当 r 在 0 到 1 之间时，数据包括 Query、部分 Reasoning（并非选取重要 token，而是使用隐藏状态）和 Answer CCOT # CCOT 的初始输入是第 l 层（实验中选择 15）的 query 的最后一个 hidden state，后续自回归生成\n下图右侧的 END 是一个二分类器，用于判断是否还要继续生成沉思 token，除此之外，沉思 token 还有一个终止条件，就是生成了 h=200*r 个\n下图有符号滥用，在其他地方 ^ 表示 ATTN，但是在这里表示预测\n其中 σ²(z) 表示 z 的方差，MSE 表示两个向量之间的常规均方误差。\nDECODE # DECODE 也是自回归的，传入 query、沉思 token 和目前为止的答案 token \\(a_{1:o}\\)计算下一个答案 token 的分布 \\(p_{1:o}\\)\n使用以下来训练 DECODE\n实验中取压缩率 r=0.05 和 r=0.10 实验 # 数据集：GSM8K\n模型：LLAMA2-7B-Chat\n分别在 r=0.05 和 r=0.1 的情况下 finetune 了 CCOT，基线选择 r=0（直接输出答案）和 r=1（传统 CoT），也对比了 Pause Token\nACC 相比完整的 CoT 下降还是蛮多的 讨论 # 超参数选择 # **r：**增加 r 会提高 acc 和解码时间，但是当 r=0.2 的时候 acc 就趋于平稳了，作者推测这是因为连续的沉思 token 是利用第 l 层的隐藏状态自回归解码的，这会传播对下一个沉思 token 生成的近似值。作者怀疑近似误差带来的噪声最终会超过沉思 token 提供的信号。\n**l：**当 l 接近 0 或最后一层 L 时，我们无法为 CCOT 学习到良好的权重。我们推测，较早层（小 l）中的隐藏状态仍然包含大量关于 token 本身的局部信息，而较晚层（大 l）中反而融入了大量关于下一个 token 的局部信息。作者发现 l ≈ L/2 时表现最佳；推测中间层的隐藏状态编码了全局信息，使其适合我们用于生成沉思 token 的自回归解码方案。\n**打分器：**使用了一个预训练的评分模块来做子集选择，将选择出来的结果作为 CCOT 的 ground truth。在实践中，作者发现简单地选取 k 个等间距的 token 即可获得相似的性能。但是实际上使用打分器从原理上来说能实现无损性能。因此或许可以训练一个更好的打分器\n一些备注 # Related Work 里有一些相关文章可以去读一下\n记忆槽 https://arxiv. org/abs/2307.06945 动态压缩成小块 https://arxiv.org/abs/2310. 02409 低级缓存编码 https://doi. org/10.1145/3651890.3672274 仅使用 API 的 LLM（Prompt 水平） https: //arxiv.org/abs/2310.05736 Filler tokens：发现一种现象，在 CoT 中，如果仅使用……填充推理过程，也能提高模型的回答正确率\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/ccot%E9%80%9A%E8%BF%87%E5%AF%86%E9%9B%86%E8%A1%A8%E7%A4%BA%E5%AE%9E%E7%8E%B0%E9%AB%98%E6%95%88%E6%8E%A8%E7%90%86/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eCCoT：通过密集表示实现高效推理\n    \u003cdiv id=\"ccot通过密集表示实现高效推理\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#ccot%e9%80%9a%e8%bf%87%e5%af%86%e9%9b%86%e8%a1%a8%e7%a4%ba%e5%ae%9e%e7%8e%b0%e9%ab%98%e6%95%88%e6%8e%a8%e7%90%86\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eCompressed Chain of Thought: Efficient Reasoning Through Dense Representations\u003c/p\u003e","title":"CCoT：通过密集表示实现高效推理","type":"posts"},{"content":" Token 预算意识的 llm 推理 # Token-Budget-Aware LLM Reasoning\n摘要 # llm 使用推理更容易在各种任务上取得出色表现。但是像 CoT 这种推理方法会导致 token 开销的大幅增加，增加成本。作者发现当 llm 的推理过于冗长的情况下，可以通过在提示中包含合理的 token 预算来压缩（王新昀：更确切的说是减少推理输出），但是 token 预算的大小对于“压缩”效果上起着至关重要的作用。\n作者提出了一种能够感知 token 预算的 llm 推理框架，这个框架根据每个问题的推理复杂度动态调整 token 预算的数量。\n实验表明这种方法在 CoT 推理中有效降低了 token 的成本，但是也略微降低了性能。\nMotivation # CoT 能显著提升 llm 性能，但是也产生了大量的额外开销，比如 token 数量的增加、延时增加等等，最终导致额外的金钱和能源消耗。\n发现可以使用在 prompt 中声明 token 预算来是的 llm 按照 token 预算数量进行输出\n你的问题 Let\u0026rsquo;s think step by step and use less than β tokens:\n直接回复（15 个输出 token） 原版 CoT（258 个输出 token） 不合理 token 预算的 CoT（157 个输出 token） 合理 token 预算的 CoT(87 个 token)\n方法 # token 冗余现象 # LLM 有能力遵循 prompt 中的长度约束 我们发现，提供合理的标记预算可以显著降低推理过程中的标记成本 在 post-training 阶段，例如 Ouyang 等人（2022）提出的 RLHF 过程中，标注者可能更偏好来自大型语言模型的更详细的响应，并将其标记为首选。 Token 预算搜索 # 二分查找，使用二分查找的方式，找寻解决某个问题的最小 token 预算，isFeasible 实际上是在判断模型输出是否正确以及模型对于预算遵循情况 对于 token 弹性的观察 # 我们发现如果预算降低到某个范围之外，token 成本会增加，这表明进一步减少预算会导致 token 消耗的增加。下图横轴代表搜索轮次，轮次越大，预算越小。不同颜色表示从 MathBench-College（Liu 等人，2024）中随机选取的不同样本。在合理的令牌预算范围内，令牌成本显著较低。当令牌预算小于合理范围时，令牌成本逐渐增加。\n基于 token 弹性的搜索策略（修改了 isFeasible 函数，实际还是二分） # isFeasible 同时检查模型输出是否正确 + 本次实际 token 是否小于上次 token\n压缩 CoT 的方式 # Token 预算估计与 Prompt（TALE-EP） # 给定一个问题，TALE-EP 首先使用预算估计器估计 token 预算。然后，它通过将问题与估计的预算相结合，创建一个 token 预算意识的 prompt。最后，将提示输入到 LLM 中，生成答案作为最终输出。默认 llm 就是 budget 估计器。\ntoken 预算意识的 prompt：\nPost-training 的 token 预算意识内化（TALE-PT） # 对于预训练 llm 进行微调，使其具有 token 预算意识。这个过程分为两个关键阶段：目标输出生成和 LLM 后训练。\n目标输出生成 # 使用包含我们所搜索到的最优 token 预算的 CoT 提示，来激发 model 生成 y_i（回答）\n最优 token 预算的 CoT 提示:\n接着使用 y_i 来训练 model\n基于 SFT 的内化 # 构建数据集，数据集中包含原始的 x_i 和模型生成的 y_i\n基于 DPO 的内化 # 使用模型生成的 y_i 作为正样本，原版不带预算的 CoT 的 y_i_hat 作为负样本，正负样本对被用来创建 DPO 训练所需的双向偏好数据。\n实验 # 数据集：GSM8K、GSM8K-Zero、Math-Bench GSM8K-Zero，源自 GSM8K 数据集，专门用于分析大型语言模型生成的输出中的过度推理和冗余。简而言之，GSM8K-Zero 的设计使得答案本身就内嵌于问题之中。大型语言模型可以轻松生成正确的回应，而无需复杂额外的推理或冗余的计算。\n模型：GPT-4o、GPT-4o-mini、Yi-lightning、o3-mini、LLama-3.1-8B-Instruct 基于提示的 # 4o-mini（问题越复杂，性能下降越多，但是 Output Token 下降更明显 + 花费更少） MathBench-College 数据集（对推理或非推理模型均有效） 基于 post-training 的 # SFT 完胜 DPO，且 SFT 完胜原版 CoT（wxy：没说 SFT 的训练数据是基于哪个数据集构建的 +baseline 没有做过其他 SFT)\n我的思考 # 设计一个数据集，每条格式如下：\n问题 token 预算 推理 回答\n进行 SFT，在推理阶段使用 Bert 预测 token 预算，并作为输入\n类似 TokenSkip\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/token%E9%A2%84%E7%AE%97%E6%84%8F%E8%AF%86%E7%9A%84llm%E6%8E%A8%E7%90%86/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eToken 预算意识的 llm 推理\n    \u003cdiv id=\"token-预算意识的-llm-推理\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#token-%e9%a2%84%e7%ae%97%e6%84%8f%e8%af%86%e7%9a%84-llm-%e6%8e%a8%e7%90%86\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eToken-Budget-Aware LLM Reasoning\u003c/p\u003e","title":"Token预算意识的llm推理","type":"posts"},{"content":" INFTYTHINK：打破大型语言模型长上下文推理长度限制 # InftyThink: Breaking the Length Limits of Long-Context Reasoning in Large Language Models\n摘要 # 大规模语言模型的高级推理在具有挑战性的任务上性能优异，但当前占主导地位的长文本推理范式存在关键局限性：计算复杂度随序列长度平方增长，推理受最大上下文边界限制，以及超出预训练上下文窗口后的性能下降，而且现有方法主要压缩推理链而未解决根本性的规模问题。为了克服这些，我们提出了 INFTYTHINK 方法，该方法将单一推理转化为带有中间摘要的迭代过程。通过交织简短的推理片段与简洁的进度摘要，我们的方法能够在保持计算成本有界的同时实现无限推理深度。这形成了一种特有的锯齿形记忆模式，与传统的推理方法相比，显著降低了计算复杂性。此外，我们开发了一种方法，将长上下文推理数据集重构为我们的迭代格式，将 OpenR1-Math 转换为 333K 个训练实例。跨多种模型架构的实验表明，我们的方法在降低计算成本的同时提高了性能，其中 Qwen2.5-Math-7B 在 MATH500、AIME24 和 GPQA_diamond 基准测试中展示了 3-13% 的性能提升。我们的工作挑战了推理深度与计算效率之间假设之间的权衡，提供了一种无需架构修改的更具可扩展性的复杂推理方法。\nMotivation # 在 CoT 的时候，LLM 往往表现出 over-thinking 的迹象，导致其生成出远远超过解决问题所需的实际 token 数量，会撞上以下三个效率瓶颈：\n过多的 token 造成了大量的内存和处理开销 推理过程受到 max_len 限制，常常导致推理被截断，无法得出结论性的答案 大多数 llm 在 4~8k 的 context 中训练，当推理超出这个范围的时候性能会下降 现在有以下几个方法来试图解决这种局限性，但是也各有问题：\nCoT-Valve 使用 Chain-compression 效果不错，但是需要在训练期间预设压缩率\n王新昀：感觉这篇文章可以去读读\nTokenSkip 通过评估每个 token 的重要性来减少冗余 Token，但是会影响推理性能\nTokenSkip:可控的 CoT 压缩 in LLMs\nTokenSkip 计算出每个 Token 的重要性，然后按照压缩率将没那么重要的 token 删除，并构建数据集，格式为 问题 [EOS] 压缩率 [EOS] 压缩过的 CoT 未压缩过的答案 然后使用该数据集 LoRA 微调 Instruct Model，Input 为问题和压缩率，Output 为压缩过的 CoT 和未压缩的答案\nLightThinker 使用特殊 token 来动态压缩，但缺乏为每一步自适应确定压缩需求的能力 LightThinker: 每个想法压缩成两个 token\nLightThinker 是将每个 Thought（每个句子或段落，或者林老师提到的让另一个 llm 抽取出每个 thought）压缩成固定个 token，或者是将固定个 token 压缩成更少个固定个 token（比如每 6 个 token 压缩成 2 个 token），具体方法是修改数据集中的 Y 为以下格式： S（一段 thought 或固定个 token） C（压缩成的 token） [o]（引导 llm 基于 C 输出的特殊 token）…… 并且通过修改 Attention mask 来使得 llm 在压缩出 C 以后就 mask 掉 S 不去计算，节省计算量\n以上这几种方法都是局限在生成一个单一、连续的推理链，贡献仅仅是让 CoT 更加紧凑，但是没有解决实际问题（只是缓解了，但是没解决），所以提出问题：\n我们是否能够彻底重新构想推理过程本身，而不是在单体推理的约束下进行优化？\nContribution # INFTYTHINK 将单一的长篇推理转化为带有总结的迭代推理，模仿了人类工作记忆模式，将基于 Transformer 的 llm 二次计算复杂度降低 开发了一种技术，将现在的长 context 的数据集重构为迭代推理格式，在保持推理质量的同时，无需架构修改即可实现更高效的计算。 性能提高 + 计算成本降低，挑战了推理深度与效率之间公认的权衡 方法 # 核心思路 # 模型生成部分推理链，总结当前的思考，并在后续迭代中基于这些总结进行构建。\n被下划线标记的片段代表作为包含在 prompt 中、将输入 model 的内容，而非下划线部分显示的是模型生成的输出。\n每一次 INFTYTHINK 的迭代包括：（1）总结之前的推理进度，（2）在高效的 token 预算内生成一个专注的推理片段，以及（3）生成一个简洁的进度总结。\n具体： # 具体就是如核心思路部分所讲，但是在此基础上引入 max_epochs 超参，来限制最大迭代次数。\n构建数据集 # 原数据集为 OpenR1-Math，构建过程如上图包含三大阶段：\n推理分割 分段方法类似 lightthinker，在句子边界或自然段边界分，然后将这些小段按顺序拼接成一个个大段，每个大段不超过 η 个 token，η 是一个超参。\n总结生成 总结模型接收的不仅是当前的推理片段 RPi，还包括所有先前片段及其总结，这使得它能够生成保持推理连续性的总结。完整的提示模板：\n构建训练实例 简言之，将每个原始示例转化为 n 个训练实例，其中 n 是推理片段的数量。\n将此方法应用于 OpenR1-Math 数据集，并设置 η = 4096，我们将原始的 22 万个示例扩展为 33 万个训练实例，形成 OpenR1-Math-Inf 数据集。\n实验 # 基模：Qwen2.5-Math-1.5B、Qwen2.5-Math-7B、Qwen2.5-14B、Qwen2.5-32B 和 Meta-Llama-3.1-8B\n操作：分别在 OpenR1-Math 和 OpenR1-Math-Inf 数据集上 Instruction-based fine-tuning。\n训练超参：max_len=16384, batch_size=32, warmup=0.03, lr-scheduler=cosine to reach zero\nTo accelerate training, we pack all SFT samples to the maximum sequence length. Each packed sample retains its original positional embeddings, and attention values are computed independently for each instance.\n在 MATH500、AIME24 和 GPQA_diamond 上评估，\n评估超参：对于 baseline max_len=16384，对于 inftythink，max_epochs=50，max_len=8192\n其他：每个评估案例以 0.7 的 temperature 跑 16 次，并计算平均 acc\n总 Acc # 对小模型影响更为显著\n对 GPQA 和 AIME24 数据集效果更明显，因为这两个数据集中问题比较复杂，通常需要超过标准上下文窗口的更长的推理链。\ntoken 数量和 Acc 关系 # 在 Qwen2.5-Math-7B 上进行\n蓝线表示模型计算的总 token 数: \\(\\sum{token}\\)\n红线表示在多次推理迭代中计算的标记数的平方和: \\(\\sum{token^2}\\)\n灰线是 baseline，同时表示在两个维度上传统长上下文推理的效果。\n灰蓝对比展示模型在推理一定数量的 token 时的准确性趋势，灰红对比是为了突出 token 的计算成本(n^2 的复杂度)和 acc 的关系\n超参 η 的选择 # 较大值会减少迭代次数，但增加每次迭代的计算成本，而较小值则能更均匀地分配计算，但可能会使推理碎片化。\n所有 η 均优于 baseline，但是没有一个通用的最优 η\n在 AIME24 这一具有挑战性的基准测试中，所有（η）设置下，从第 1 次迭代到第 10 次迭代，性能稳步提升，表明复杂问题从超越传统上下文限制的扩展推理中获益匪浅。\n特定基准的缩放属性：迭代过程中改进的速度和程度因基准难度而显著不同。在 MATH500 上，性能曲线在 4-6 次迭代后趋于平坦，表明对于更简单的问题，收益递减。相比之下，AIME24 和 GPQA_diamond 在迭代到 10 次时仍显示出持续的改进，这表明问题复杂性直接影响了从额外的推理迭代中获得的益处。\n即使在较小的上下文设置(η)=2k 下，INFTYTHINK 最终在所有基准测试中达到了与较大(η)值相当的性能。这在 AIME24 上尤为明显，到第 10 次迭代时，(η)=2k 配置的性能接近(η)=6k 的性能，尽管使用的推理片段大小仅为三分之一。这表明有效的摘要即使在频繁压缩的情况下也能保留关键的推理信息。\n具有较大 (η) 值 (6k) 的模型在所有基准测试的早期迭代中始终优于较小分段 (2k) 的模型。然而，这种优势在后期迭代中逐渐减弱，有时甚至逆转，特别是在 GPQA_diamond 上，(η)=4k 最终超过了 (η)=6k。这表明，虽然较大的分段在初期提供了优势，但它们可能使模型陷入难以修正的推理路径，而较小的分段则允许在多次迭代中进行更灵活的探索。\n与其他扩展上下文的方法（RoPE）对比 # 作者认为 Inftythink 与人类思考过程吻合 + 实现了自适应推理深度\n但是推理质量在很大程度上依赖于模型的摘要能力 + 将推理分割成多个部分可能会打断某些问题类型中保持完整推理链的有益连贯思维流程 + 引入了额外的推理步骤增加延迟\n未来方向：\n整合强化学习技术如 GRPO 可以帮助模型更好地学习何时以及如何进行总结，可能会在迭代过程中提高信息保留率。 探索基于问题复杂性的可变长度推理片段，可以进一步优化计算效率与推理连贯性之间的权衡 将 INFTYTHINK 应用于多模态推理任务，可以将其适用性扩展到需要整合视觉、文本和数值推理的领域 研究如何在 INFTYTHINK 框架内并行化不同的推理路径，可以进一步加快复杂问题的解决速度。 我的思考 # 感觉和 Lightthinker 有一样的缺陷，划分的 thought 不是真 thought\n能不能在隐藏状态实现 Inftythink？\n","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/inftythink%E6%89%93%E7%A0%B4%E5%A4%A7%E5%9E%8B%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B%E9%95%BF%E4%B8%8A%E4%B8%8B%E6%96%87%E6%8E%A8%E7%90%86%E9%95%BF%E5%BA%A6%E9%99%90%E5%88%B6/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eINFTYTHINK：打破大型语言模型长上下文推理长度限制\n    \u003cdiv id=\"inftythink打破大型语言模型长上下文推理长度限制\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#inftythink%e6%89%93%e7%a0%b4%e5%a4%a7%e5%9e%8b%e8%af%ad%e8%a8%80%e6%a8%a1%e5%9e%8b%e9%95%bf%e4%b8%8a%e4%b8%8b%e6%96%87%e6%8e%a8%e7%90%86%e9%95%bf%e5%ba%a6%e9%99%90%e5%88%b6\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eInftyThink: Breaking the Length Limits of Long-Context Reasoning in Large Language Models\u003c/p\u003e","title":"INFTYTHINK：打破大型语言模型长上下文推理长度限制","type":"posts"},{"content":" TokenSkip:可控的 CoT 压缩 in LLMs # TokenSkip: Controllable Chain-of-Thought Compression in LLMs\n摘要 # 链式思维（CoT）已被证明能够有效提升大型语言模型（LLMs）的推理能力。如 OpenAI 的 o1 和 DeepSeek-R1，表明在推理过程中增加 CoT 序列的长度可能进一步提升 LLM 的推理性能。然而，由于 LLM 解码的自回归特性，较长的 CoT 输出导致推理延迟线性增加，从而对用户体验产生不利影响。为此，我们分析了 CoT 输出中 tokens 的语义重要性，并揭示了它们对推理的贡献各不相同。基于这一洞察，我们提出了 TokenSkip，这是一种简单但有效的方法，允许 LLMs 有选择地跳过不太重要的 tokens，从而实现可控的 CoT 压缩。在各种模型和任务上的广泛实验表明，TokenSkip 在减少 CoT tokens 使用的同时，能够保持较强的推理性能。值得注意的是，当应用于 Qwen2.514B-Instruct 时，TokenSkip 在 GSM8K 上将推理 tokens 减少了 40%（从 313 减少到 181），且性能下降不足 0.4%\nhttps://github.com/hemingkx/TokenSkip\nMotivation # 已经有一些研究探讨了选择性跳过推理步骤的方法，但是这种方法可能会损害 llm 性能，因此在效率和性能中找一个平衡点。\nContributions # 首个研究通过跳过 Token 来提升 CoT 效率的潜力，灵感来自于 LLMs 的 CoT 轨迹中令牌的不同语义重要性。 引入了 TokenSkip，这是一种简单而有效的方法，能够使大型语言模型在链式推理中跳过冗余的标记，并学习关键标记之间的捷径，从而实现可调比例的链式推理压缩。 实验验证了 TokenSkip 的有效性。当应用于 Qwen2.5-14BInstruct 时，TokenSkip 在 GSM8K 上将推理令牌减少了 40%（从 313 减少到 181），且性能下降不到 0.4%。 背景 # Token 重要性 # CoT 输出的每个 Token 对得到答案的贡献是不对等的，且 Token 的冗余已被认定为大型语言模型效率的一个长期且根本性的问题（Hou et al., 2022; Zhang et al., 2023; Lin et al., 2024; Chen et al., 2024）。Selective Context（Li et al., 2023）提出了一项研究，删除冗余的输入的 token 以减少 API token 的使用，并且这项研究提出了衡量 token 重要性的公式\\(I_1(x_i)=-\\log{P(x_i|x_{","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/tokenskip_%E5%8F%AF%E6%8E%A7%E7%9A%84cot%E5%8E%8B%E7%BC%A9-in-llms/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eTokenSkip:可控的 CoT 压缩 in LLMs\n    \u003cdiv id=\"tokenskip可控的-cot-压缩-in-llms\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#tokenskip%e5%8f%af%e6%8e%a7%e7%9a%84-cot-%e5%8e%8b%e7%bc%a9-in-llms\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003eTokenSkip: Controllable Chain-of-Thought Compression in LLMs\u003c/p\u003e","title":"TokenSkip:可控的CoT压缩 in LLMs","type":"posts"},{"content":" LightThinker: 每个想法压缩成两个 token # 如果 lt 确实靠谱\n改进：thinking 拆解（原文比较粗暴）\nLightThinker: Thinking Step-by-Step Compression\n摘要 # 大型语言模型（LLMs）在复杂推理任务中表现出色，但它们的效率受到与生成长序列相关的大量内存和计算成本的阻碍。在本文中，我们提出了一种名为 LightThinker 的新方法，该方法使 LLMs 能够在推理过程中动态压缩中间思维。受到人类认知过程的启发，LightThinker 将冗长的思维步骤压缩为紧凑的表示形式，并丢弃原始推理链，从而显著减少存储在上下文窗口中的令牌数量。这是通过在数据构建时训练模型何时以及如何进行压缩，将隐藏状态映射到浓缩的主旨令牌，并创建专门的注意力掩码来实现的。此外，我们引入了依赖性（Dep）指标来量化压缩程度，通过测量生成过程中对历史令牌的依赖来衡量。在四个数据集和两种模型上的大量实验表明，LightThinker 减少了峰值内存使用量和推理时间，同时保持了有竞争力的准确性。我们的工作为在保持性能的前提下，提高 LLMs 在复杂推理任务中的效率提供了新的方向。\n动机 # CoT、类 O1 的思考模式（试错、回溯、修正和迭代）等方式可以大幅提高复杂问题解决能力，但是代价是消耗大量 Token。由于 Transformer 架构限制，Attention 的计算复杂度为与上下文长度呈二次增长、KV-Cache 大小与上下文长度呈线性增长，如在 Qwen32B（杨等，2024）的情况下，当上下文长度达到 10^4 时，KV 缓存占用的空间与模型本身相当。因此，token 生成量的增加导致内存开销和计算成本急剧上升，严重限制了 LLMs 在长文本生成和复杂推理任务中的实际效率。\n动机源自两个观察到的现象：\nllm 生成的 token 同时具备确保语言流畅和标记思路的作用（所以想砍掉确保语言流畅的功能） 人类思考时往往只写下关键步骤（下图黄色部分），但是其他思考过程放在脑子里面（相当于脑内推理，推理到一个关键节点是压缩成一个关键步骤，并写下） 背景（wxy 学习用） # 慢思考 Slow Thinking # CoT、O1 的 reasoning 以及 R1 的尝试 + 反思 + 回溯 + 修正策略，但是 O1-like 的模式提升更大，这种慢思考能力可以使用 SFT 构造的数据注入模型来产生，但是输出 token 大大增加\n推理挑战 Inference Challenges # 详见摘要，token 长了 Attention 计算复杂度二次方增长，Cache size 线性增长\n方法 # 大致过程： # 核心思路： # 训练 llm 动态压缩推理过程中的当前的想法\n核心问题： # 压缩哪里？ # 一种方法是固定个 token 后压缩，容易实现但是这样可能会忽略语义边界；另一个方法是每到一个思维（一个句子或一个段落）结束压缩。\n如何压缩？ # 一种方法是文本压缩，把当前的思考压缩成短文本或连续的向量。需要额外的编码模型，增加了计算开销。\n另一种方法是隐藏状态压缩，将当前思维压缩成几个特殊 token（gist tokens）\n通过构建数据集来解决压缩哪里的问题，通过基于 thought 的 attention mask 解决如何压缩的问题\n思路： # 数据重构： # 对于已有的一个数据集，将 output 分成 k 个子序列（可以在 token 水平或 thought 水平上分），然后往子序列之间条件特殊 token（可选的压缩触发器，告诉 llm 开始压缩，如果是在 token 水平上分段的或在子序列当中，则可以省略；[c_i]是压缩成的 token（C 是[c_i]序列）；[o]强制 llm 基于压缩的内容输出）。\n在 X 不变的情况下，数据集中的输出变成了下面的样子：\nX 代表输入的 token，D 是推理的 dataset，内含 |D| 个样本，x 和 y 分别代表问题和输出。SFT 过的 D 能显著增强 LLM 的推理能力(Team, 2025; DeepSeek-AI et al., 2025)\n为了简单，假设在子序列当中，所以直接忽略了这个 token，因此 Y_h 中没有。\n基于思维的 Attention Mask 构造 # 在生成过程中，[o]只能关注 X 和被压缩的 token（因为 S_i 被 mask 掉了）\n训练 # 最大化下面的值：θ 是 llm 的参数\n在训练过程中，LLM 不允许预测输入 X 以及特殊标记 C 和[o]。训练样本来自 D_h，我们使用注意力掩码来鼓励 LLM 学习压缩和解析压缩内容。整个训练过程仍然基于下一个标记的预测。\n讨论 # 什么数据被压缩了？ # 感觉有点答非所问 目的不是无损压缩，而是尽可能保留重要信息\n与 AnLLM 的不同 # LightThinker 引入了[o]这个 token 用于生成后续内容，而 AnLLM 使用[c]同时代表压缩历史信息和生成后续内容 AnLLM 只能访问压缩过程中的当前思维（S_i）。而 LightThinker 允许访问 X、历史压缩内容、以及压缩过程中的当前思维，从而增强了上下文理解。消融实验表明，这些设计显著提高了性能。 实验 # 5 个 baseline：在 Bespoke-Stratos-17k 数据集上全量微调过的 Qwen2.5-7B 和 Llama3.1-8B（Vanilla）；使用 H2O（training-free 方法）加速 Vanilla；基于特定策略保留重要 KV-Cache 的 SepLLM 加速 Vanilla；AnLLM；CoT+instruction Model;CoT+R1-Distill。\n在 GSM8K、MMLU、GPQA、BBH 这些数据集上随机取样一些数据进行评估，评估有效性（Acc）和效率（Time、Peek——推理过程中上下文中的最大标记数、Dep——生成的每个标记对前一个标记的依赖总和）\n设计了两个分割 Y 的方法（详见数据重构）\ntoken 水平：每 6 个 token 压缩成 2 个 token（还是固定数量的压缩，能不能改成动态，比如训一个 bert 或者简单点 gru 判断当前是否可以压缩了等等） thought 水平：每个段落压缩一次（以\\n\\n 分割）。对于 Qwen，压缩成 9 个 token；对于 LLama，压缩成 7 个（能不能考虑考虑压缩成动态个 token）。decoder 使用最大 output 为 10k 个 token 的贪婪 decode 有效性 # 最优，次优\ntoken 水平的 Acc 相比较于 Vanilla 都降了\n效率 # 当前压缩方法对数字并不敏感**（也是可以考虑的一个点）**\n这是 Solution 中的错误，最开始是 8000，但是到后面变成了 4000\nLimitation # 实验采用的是全量微调，未尝试 LoRA 或 QLoRA+LightThinker 的组合 LLama 系上显著性能下降 [c]的数量是固定的，不确定某个固定数量的[c]的泛化能力 分段方法设计过于简单 ","date":"2025 Sep 2","externalUrl":null,"permalink":"/posts/lightthinker_-%E6%AF%8F%E4%B8%AA%E6%83%B3%E6%B3%95%E5%8E%8B%E7%BC%A9%E6%88%90%E4%B8%A4%E4%B8%AAtoken/","section":"Posts","summary":"\u003ch2 class=\"relative group\"\u003eLightThinker: 每个想法压缩成两个 token\n    \u003cdiv id=\"lightthinker-每个想法压缩成两个-token\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none\"\u003e\n        \u003ca class=\"text-primary-300 dark:text-neutral-700 !no-underline\" href=\"#lightthinker-%e6%af%8f%e4%b8%aa%e6%83%b3%e6%b3%95%e5%8e%8b%e7%bc%a9%e6%88%90%e4%b8%a4%e4%b8%aa-token\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e\n    \n\u003c/h2\u003e\n\u003cp\u003e如果 lt 确实靠谱\u003c/p\u003e","title":"LightThinker: 每个想法压缩成两个token","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]