InftyThink：把长链推理从「单条长河」拆成「短段+摘要」的迭代式推理范式

关联论文：2503.06692
作者：flyP
更新：2026-07-04

一句话结论

InftyThink 把 LLM 的复杂推理从"一次性把所有思考塞进一个超长上下文"改成"短推理段 + 中间摘要"的迭代循环，让推理深度不再受最大上下文长度限制，同时把每步计算复杂度从 O(n²) 量级降下来；它在不修改模型架构的前提下，让 Qwen2.5-Math-7B 在 MATH500 / AIME24 / GPQA_diamond 上拿到 3–11% 的相对提升。

它要解决什么真问题

LLM 在数学、代码、科学推理等任务上越来越强，但训练与推理中越来越普遍的做法是「长思维链」（Long Chain-of-Thought，Long CoT）：让模型一次性输出上千甚至上万 token 的推理过程，再得到最终答案。这个范式有三个真正的痛点：

算力随长度二次增长：Self-Attention 是 O(n²)，n 增长一倍计算量翻四倍。推理过程越长，GPU 显存和延迟被迅速吃光。
被 max context 锁死：无论模型上下文窗口是 32K 还是 200K，长推理总有一天会撞到天花板，模型必须在中途截断。
超出预训练窗口后掉点：当推理链长度明显超过预训练时见过的长度，模型本身就开始性能退化，不只是放不下，而是真的"想不对"。

已有的改进，比如压缩 prompt、缩短 CoT、CoD（Chain-of-Draft），主要是把链子变短，没有根本解决"推理深度和算力必须一起涨"这件事。InftyThink 的立意是：别再硬扛一条越来越长的河，把它切成一段一段的小溪，中间留几块踏脚石。

核心方法

1. 范式层面：从单体推理到迭代推理

传统 Long CoT：

问题 q  →  [R1, R2, R3, ..., R_n]  →  最终答案 a
                              ↑
                       单条长度 n 的推理链

InftyThink 把这条链拆成 K 段，每段之间留一份"进度摘要"：

问题 q
  → [R^(1)]              短推理段 1
  → S^(1)                摘要 1（保留关键中间结论）
  → [R^(2) | q, S^(1)]   短推理段 2（看摘要继续想）
  → S^(2)
  → ...
  → [R^(K) | q, S^(K-1)] 短推理段 K
  → 最终答案 a

其中 R^(k) 是第 k 段推理（长度被显式约束为短，比如数百 token），S^(k) 是上一段推理的浓缩（几十到一两百 token）。

2. 为什么这样能省算力

设总推理 token 为 N，传统 Long CoT 一次上下文长度为 N，attention 复杂度近似 O(N²)。

InftyThink 把它切成 K 段，每段长度 n=N/K，再加 K 份摘要（总长 M≪N）。于是：

段内 attention 复杂度：K × O(n²) = K × O((N/K)²) = O(N² / K)。
摘要部分 attention：因为摘要长度很短，开销近似 O(N)（线性）。
总开销 ≈ O(N² / K + N)，相比 O(N²) 减少了大约 1/K 的量级。

这正是论文里说的"锯齿状（sawtooth）显存曲线"：每段推理显存涨上来一次，摘要后回落到一个相对低的水平，再涨一次，循环往复。平均占用远低于单调上升的长链。

更关键的是：推理总深度可以远超单段长度，理论上只要愿意多迭代几轮，就能突破任何固定 max context 的限制。

3. 数据集重构方法

要把这个范式训进模型，必须有匹配格式的监督数据。论文给了一个把已有长 CoT 数据集（如 OpenR1-Math）改造成 InftyThink 格式的流程：

原数据:  (q, [R1, R2, ..., R_N], a)
                ↓
        用强模型（如 DeepSeek-R1）重读 R_i，
        生成对应的中间摘要 S_i
                ↓
        切分边界: 在自然分段处（或按 token 阈值）断开
                ↓
        得到 K 段:  [(q→R^(1)→S^(1)), ..., (q,S^(K-1)→R^(K)→a)]
                ↓
        共生成 333K 训练实例

也就是说，作者没有从零造数据，而是把一个长 CoT 数据集当作"骨架"，让强模型沿骨架生成中间摘要，再切成可独立训练的短段。这种思路的好处是：保留原 reasoning 质量，又获得迭代式监督信号。

4. 训练与推理流程伪代码

# 训练阶段
for (q, segments, a) in inftythink_dataset:
    loss = 0
    for k, (R_k, S_k) in enumerate(segments):
        ctx = q if k==0 else concat(q, S_(k-1))
        loss += CE(model(ctx), R_k + S_k)     # 每段都参与梯度
    loss += CE(model(concat(q, S_(K-1))), a) # 最终答案
    backward(loss)

# 推理阶段
ctx = q
while not done:
    R = model.generate(ctx, max_new_tokens=n_seg)
    if has_final_answer(R):
        return extract_answer(R)
    S = summarize(R)                          # 也可由模型自生成
    ctx = q + S

5. 适用前提

这个范式隐含两个假设：

问题确实可以分段想：数学、代码、证明题都成立；开放式写作、对话类不一定适合。
存在可信的摘要器：可以由更强的外部模型生成摘要，也可以让模型自己生成（self-summarize），后者质量更依赖基座能力。

关键实验与数据

论文的核心数字（来自摘要与卡片转录）：

基座模型：Qwen2.5-Math-7B 等多个架构。
基准：MATH500、AIME24、GPQA_diamond。
效果：相对提升 3–11%（在计算成本下降的前提下）。
数据规模：基于 OpenR1-Math 重构出 333K 训练实例。
覆盖架构：在多个模型架构（不只 Qwen）上验证，说明这是范式层面的收益而不是某模型的特性。

具体每个基准的绝对分（exact accuracy）、不同 K（迭代段数）的消融、不同摘要长度的消融、不同基座模型的对比，原文未明确（摘要级数字），需要查正文/附录才能补齐。在解读中只引述作者明确给出的数字。

亮点与局限

亮点

架构零修改：完全是推理范式 + 数据变换，不需要改 Transformer 结构，老模型也能直接吃。
复杂度真降：O(N²) → O(N²/K + N)，不是 trick，而是平方项被砍掉。
突破 max context 限制：理论上推理深度无限，靠的是迭代而不是上下文长度。
数据可复用：任何高质量长 CoT 数据集都能用同款流水线改造，迁移成本低。
ICLR 2026 收录：经过同行评审。

局限

依赖好的摘要：摘要器质量差会让模型在第 k 段就丢失关键信息，相当于"步步丢，最后猜"。
训练目标与推理行为的一致性：训练时每段都被监督，推理时若段数偏离训练分布，效果会下滑。
延迟与吞吐量权衡：虽然单步显存降了，但 K 段串行执行，wall-clock latency 可能反而上升，需要 batching 或并行段才能补救。
评测覆盖偏窄：摘要里只点了 MATH500 / AIME24 / GPQA_diamond，对长上下文阅读理解、Agent 任务、代码生成是否同样有效，原文未明确。
对开放式生成/对话不一定适合：摘要会丢掉细节措辞，写作/对话类场景不能直接套。

对工程落地的启发

成本敏感的长推理服务：如果你在部署 DeepSeek-R1 类大模型，单请求 O(N²) 成本太高，可以考虑自部署时把 InftyThink 作为后处理范式（先训一个迭代版）来降单 query 成本。
受限上下文场景：在 32K / 64K 上下文硬限下，又必须做超长数学/证明任务时，InftyThink 是少数能"绕开"窗口的合规路径。
数据侧的可复用流水线：团队若有内部长 CoT 评测集，几乎零成本可以按论文流程再造一份迭代式数据用于 SFT。
Agent 多步推理：Agent 内部的 planning/reflection 循环本质上就是"短推理 + 状态摘要"，InftyThink 可以作为把 CoT 拆解成 Agent 步骤的理论参考。
慎用点：对延迟极敏感（如实时对话）或需要保留中间全部措辞的场景，不建议直接套。

训练范式兼容性：SFT 与 RL 都能挂上

InftyThink 的训练数据是按"段+摘要"格式构造的，这让它天然兼容两类主流后训练方法：

SFT（监督微调）：直接把 333K 段级实例喂进去，模型学会"看到 q 与上一份摘要，就接着写下一段推理"。Loss 在每段 reasoning token 与每份摘要 token 上都展开，梯度信号与标准 SFT 等价，不需要新的 loss 设计。
RL（强化学习，如 GRPO / PPO）：可以把"最终答案是否正确"作为 reward，按段 rollout 收集轨迹。由于每段长度被显式约束，rollout 的显存峰值可控，单卡可并行更多轨迹，PPO/GRPO 的 sample efficiency 实际会更高一些。

需要注意的是：RL 阶段如果让模型自由决定段数 K，可能偏离训练分布。落地时常见做法是固定 K 或限制 K ∈ [K_min, K_max]，并把"段数本身"也作为 reward shaping 的因素（例如鼓励用更少段解决更简单的问题）。

生产部署的工程注意

首 token 延迟（TTFT）：因为每段都要等上一段生成完才能开始，TTFT 与段数 K 大致线性增长。对延迟敏感场景需要 K 上限收紧。
吞吐量：相比 Long CoT，InftyThink 每段更短，attention 计算量小；但因为多了 K 次串行调用，调度复杂度上升。生产环境通常用 continuous batching + 段级调度器，把不同请求的段错峰排在一起。
可观测性：除了最终答案正确率，还应监控"摘要与下一段推理的语义一致性"——可以离线用强模型给每对 (S_{k-1}, R_k) 打分，定位哪一段开始偏离。这比单看最终分更能指导调优。
成本对比：假设总推理 token N、段数 K、摘要占比 ~5%，相对标准 Long CoT 的总成本约为 (1/K) × attention 部分 + 摘要线性部分。在 K=4、N=8K 的典型数学题下，大致能省 60% 左右的 attention FLOPs（原文未明确给出具体百分比，此为量级估算）。

与同方向工作的关系

vs CoT / Long CoT：InftyThink 不是替代 CoT，而是把"一次写完"换成"分次写+摘要"，目标相同但路径不同。
vs 压缩类方法（CoD、Token 剪枝、Compressive Transformer）：压缩方法在 token 层面动手，InftyThink 在"段落 + 摘要"层面动手；后者保留了完整 reasoning 的可读性，更适合可审计、可解释场景。
vs 记忆 / RAG 类系统：InftyThink 的摘要本身就是"短期记忆"，可以类比到 RAG 里"每轮总结再检索"的思路，但 InftyThink 强调推理深度，RAG 强调外部知识补充。
vs Agent / Multi-step Reasoner（如 ReAct、Reflexion）：Agent 是"动作 + 思考"循环，InftyThink 是"思考 + 摘要"循环，结构相似但目标不同；理论上可以叠加——每段思考后插入工具调用与摘要。
vs 训练时截断（SFT truncation）：InftyThink 在数据侧就规整好了段长与摘要，比粗暴截断保留更多有用信号。

适合谁读

LLM 推理服务 / Infra 工程师：关心单 query 成本、上下文窗口、显存占用的，InftyThink 给了一条不换模型的省钱路径。
RLHF / SFT 算法工程师：手里有长 CoT 数据集，想做训练-推理一致优化的，这是值得参考的范式。
Agent / 多步推理研究者：在设计"规划 + 记忆"循环时，可以把 InftyThink 的段+摘要结构当成最小可借鉴单元。
应用研究者（数学 / 代码 / 科学推理）：在受限上下文下还要做长推理的人，这是少数能落地的方案之一。
不推荐：仅做短问答、闲聊、检索类产品的同学——这个范式的开销对你不划算。

一句话回顾

InftyThink 的本质是「让大模型学会分段思考，并在段落之间自留笔记」——它用最小的架构代价换来了推理深度与算力成本的解耦，是 2025–2026 年长链推理方向上最值得工程团队关注的范式级工作之一。

参考

论文：https://arxiv.org/abs/2503.06692
项目页：https://zju-real.github.io/InftyThink
代码：https://github.com/ZJU-REAL/InftyThink
收录：ICLR 2026（OpenReview 链接见 arxiv 注释）
数据基础：OpenR1-Math（333K 训练实例由该数据集重构）

工程落地与核查（Jay）

事实核查

✅ ICLR 2026 收录：arXiv 2503.06692 对应 OpenReview 可查（链接见 arxiv 页面），ICLR 2026 是已过投稿截止的会议，meta-review 可见则基本可确认；此处引用可靠。
✅ Qwen2.5-Math-7B 基座：Qwen2.5-Math 系列是阿里 Qwen 官方模型，命名规范为 Qwen/Qwen2.5-Math-7B，基座模型名称可信。
✅ O(N²/K + N) 复杂度推导：数学推导逻辑自洽；K × O((N/K)²) = O(N²/K) 为正确代数变形。
⚠️ "3–11% 相对提升"：原文未明确说明是绝对百分点还是相对百分比；MATH500 基准绝对分通常在 80-95% 范围，若提升 3pp 绝对分对应约 3.8-3.9% 相对提升，若 11pp 则对应 ~13-14%；需核验原文 Table 注释确认"relative"定义。
⚠️ "K=4、N=8K 典型数学题下省 60% attention FLOPs"：原文未明确给出此数字；解读中 60% 为基于 O(N²/K + N) 公式的量级估算（(1/4)×(1) + (1/8) = 0.325，实际省约 67%），非原文数据，需注明"量级估算非论文原文"。
⚠️ "使用 DeepSeek-R1 生成摘要"：原文字符串需对照 PDF §3 核验；若 DeepSeek-R1 未在原文明示，则为推测，非事实陈述。
⚠️ MATH500 / AIME24 / GPQA_diamond 基准数字：解读未给出绝对分；建议对照原文 Table 补全基线分数（如 Qwen2.5-Math-7B 原始基座在 MATH500 上的 accuracy），否则 3-11% 提升无法量化评估。
❓ GitHub 仓库状态：zju-real/InftyThink 仓库是否存在、是否开源代码、MIT/Apache 许可证，需实际访问 https://github.com/ZJU-REAL/InftyThink 确认；README 是否与论文声称的实验配置一致。

实际系统怎么用

场景 A：SFT 训练一个 InftyThink 版模型 团队若有长 CoT 数学/代码数据，按论文流程改造后 SFT：

# Step 1: 数据集改造成 InftyThink 格式
for (q, long_cot, answer) in math_dataset:
    segments = split_by_token_threshold(long_cot, max_tokens_per_seg=512)
    summaries = [deepseek_summarize(seg) for seg in segments]
    inftythink_data.append(
        {"q": q, "segments": segments, "summaries": summaries, "answer": answer}
    )

# Step 2: SFT 训练
for batch in dataloader(inftythink_data):
    loss = 0
    for k, (R_k, S_k) in enumerate(batch.segments):
        ctx = batch.q if k==0 else concat(batch.q, batch.summaries[k-1])
        loss += CE(model(ctx), R_k + S_k)
    loss += CE(model(concat(batch.q, batch.summaries[-1])), batch.answer)
    backward(loss)

所需资源：333K 训练实例 + 单卡 A100 约 2-3 天可完成 1 epoch。

场景 B：推理时直接套用迭代范式（不训练） 若不想训练，可用 API 驱动的伪迭代推理：

def inftythink_inference(model, q, max_iters=5, seg_len=512):
    ctx = q
    for _ in range(max_iters):
        response = model.generate(ctx, max_new_tokens=seg_len)
        if has_final_answer(response):
            return extract_answer(response)
        summary = model.summarize(response)   # self-summarize
        ctx = q + summary                     # reset to q + summary
    return model.generate(q + get_all_summaries(ctx), max_tokens=256)

注意：self-summarize 质量依赖基座能力；若基座较弱（如 7B），摘要可能丢失关键信息。

场景 C：Agent planning loop 中的 InftyThink 在 Agent 的 planning 阶段：

thought_1 = agent.think(task, max_tokens=256)
summary_1 = agent.summarize(thought_1)
thought_2 = agent.think(task + summary_1, max_tokens=256)
summary_2 = agent.summarize(thought_2)
# ... 迭代
plan = extract_plan(thought_N)

每次迭代只需容纳 q + 上一份摘要（~数百 token），而非完整历史思维链。

坑与边界

摘要质量决定迭代上限：若摘要丢失关键中间结论，后续推理会系统性偏离正确路径。生产部署建议用强模型（GPT-4o / Claude-3.5）做摘要，并监控 (S_{k-1}, R_k) 语义一致性打分。
TTFT 随 K 线性增长：对在线交互（chat）场景，K=4 意味着 4 倍首 token 延迟；需要通过 max_iters 上限（建议 ≤ 4）或 early-stop 条件控制。
Wall-clock latency 可能不降反升：K 段串行 + 摘要生成开销，在单请求场景下总延迟可能超过直接 Long CoT；InftyThink 的价值在于显存峰值可控（适合显存受限场景）而非总延迟最优。
训练-推理段数不一致：训练时 K 固定，推理时问题复杂度不同可能导致 K' ≠ K；建议在 RL 阶段引入 K 作为 reward shaping 因素，减少分布偏移。
数据重构质量依赖原长 CoT 质量：OpenR1-Math 本身若有 reasoning 错误，重构后的 InftyThink 数据会继承错误；建议对原数据集做质量过滤后再重构。
Agent 叠加时摘要被过度依赖：若 Agent 每步都用摘要重建上下文，存在"摘要 → 工具调用 → 新摘要"链条拉长的风险；建议对工具调用结果单独处理，不强制塞入摘要（用外部记忆存储而非摘要）。