推理算力不该"广撒网"：Gambit 用思维级束搜索把 GPU 每一分钱花在对的前缀上

你有没有过这种体验：让推理模型跑 self-consistency，256 条 trace 撒下去，GPU 风扇狂转几个小时，结果绝大多数轨迹都在错误的方向上越走越远，最后多数投票出来的答案还是错的。钱花了不少，事没办成。

上周看到的这篇论文让我挺兴奋的，因为它把这个问题从一个模糊的"效率焦虑"变成了一个干净的优化问题：test-time 推理的核心矛盾已经从"花多少算力"变成"算力花在哪些前缀上"这件事。顺着这个思路，作者搞出了一个叫 Gambit 的推理算法——把经典的 beam search 从 token 粒度抬升到"思维"粒度，周期性地剪掉烂 trace、立刻从好前缀分叉补位，让 GPU 全程满负荷地只为最有希望的推理路径打工。

效果相当能打：同样的硬件预算下，HMMT-24 上比最强的剪枝基线高 6.7 个点，AIME-25 高 3.3 个点，token 消耗最多砍掉 68.5%，trace 吞吐翻倍还多。

核心摘要

并行采样（self-consistency 那一路）把每条推理轨迹当独立试验，几百条 trace 同时跑，KV-cache 直接被打爆，排队延迟翻倍；而最近流行的"置信度剪枝"路线（STEP、DeepConf 这类）只杀不补——剪掉低分 trace 之后，释放出来的算力就那么闲置着，输出分布几乎没变。Gambit 的思路是剪枝和分支严格配对：每杀掉一条烂 trace，立刻从当前最高分的前缀分叉出一条新 trace 顶上，活跃 trace 数恒等于容量上限，一份算力都不浪费。评分用一个探测 hidden state 的轻量 scorer，算法开销不到 1%。我的判断：这不是又一篇刷榜论文，而是一个真正从系统视角重新思考推理时计算的扎实工作，思路干净、实验硬核、代码开源，值得细读。

论文信息

• 标题：Thought-Level Beam Search for Reasoning
• 作者：Lijie Yang、Hongyin Luo、Jiawei Zhao、Tri Dao、Ravi Netravali
• 机构：Princeton University、MIT CSAIL、Meta AI
• 链接：https://arxiv.org/abs/2608.08020 （arXiv ID: 2608.08020，v2，2026 年 8 月 11 日）
• 代码：https://github.com/Dao-AILab/Gambit

Tri Dao 的名字一出现，这个工作的"系统味"就说得通了——这位是 FlashAttention 的作者，骨子里就是算硬件账的人。

🎯 问题：两条技术路线，各有各的死法

先把背景铺清楚。现在想让推理模型在数学竞赛题上拿高分，主流做法就是 test-time scaling：同一个问题采样很多条推理轨迹，然后投票。但这条路有两个已经暴露得很充分的死法。

死法一：并行采样的内存墙。 一块 NVIDIA B300（目前最顶的推理卡，275GB 显存）上用 vLLM 跑 Qwen3-8B，一道 AIME-2025 题目生成 512 条 trace 要几个小时——而且最难的题照样答错。瓶颈不在 FLOPs，在 KV-cache：几百条长推理轨迹并发，显存瞬间饱和，之后的请求全部排队，延迟直接膨胀。

死法二：剪枝路线的"只杀不补"。 STEP、DeepConf、Slim-SC 这类方法给每条 trace 打个置信分，低分的提前杀掉。token 确实省了，但释放出来的 GPU 容量就那么空着——论文里叫 hardware starvation。更要命的是，剪枝只是一个"负向过滤器"，它从来不会主动增加好 trace 的数量，输出分布该什么样还是什么样。

这两个死法放在一起，构成一个挺尴尬的二分困境：要么撑爆内存，要么饿着硬件。

图 1：三种 test-time 算力分配拓扑。左：并行采样把 trace 当独立试验，吞吐 1.0×、准确率 1/3，大部分算力喂给了错误方向；中：基于分数的剪枝杀掉烂 trace（红色叉），吞吐提升到 1.4×，但释放的容量闲置，准确率只到 1/2；右：Gambit 在剪掉低分 trace 的瞬间从高分前缀（绿色箭头 Branch）分叉补位，吞吐 2.0×、准确率 3/3。

那"从好前缀分叉"这个操作到底有多值钱？论文 Figure 2 给了一个让我愣了一下的动机实验：AIME 2025 第 27 题，独立采样的 pass@1 只有 6.2%；但如果先跑一小段、挑出当前得分最高的前缀，从这个前缀分叉出 64 条延续，pass@1 直接干到 87.5%——14 倍的差距。而且子 trace 通过 prefix caching 继承父级的 KV-cache，内存消耗还减半。另一道题（Q12）上是从 1.6% 涨到 39.1%。

图 2：AIME 2025 Q27 上的动机实验。绿色区域是共享的父级 KV-cache，从最高分前缀分支 64 条延续达到 87.5% pass@1，是独立采样基线 6.2% 的 14 倍，同时内存减半。

这个数据其实点破了整篇论文的核心洞察：成功和失败的推理轨迹，在分道扬镳之前，往往共享一大段完全正确的中间前缀。 独立采样每次都从头掷骰子，等于把这段已经验证过的高质量前缀反复浪费掉。

🧠 方法：把 beam search 抬升到"思维"粒度

Gambit 的形式化很克制。把 test-time 推理写成一个受约束的算力分配问题：

\(\Omega(\pi)\) 是峰值计算与内存开销，预算 \(B\) 具体体现为最大并发 trace 数和 KV-cache 占用。一句话：在硬件预算 \(B\) 内，把算力分配给最可能产出正确答案 \(y^*\) 的推理前缀。

经典 beam search 优化的是序列似然、粒度是 token；Gambit 的 thought-level beam search 以推理步骤为粒度——一个 "thought" 就是一次 \n\n 分隔的推理段落。整个算法由四个部件咬合起来。

部件一：Scorer——给中间状态打分

每条轨迹 \(\tau = (s_1, s_2, \dots, s_n)\)，在每个 thought 边界处取最后一层 hidden state \(\mathbf{h}_{i,j}\)，过一个小网络 \(f_\theta\) 得到这一步的分数，轨迹分为逐步累积的平均分 \(\bar{s}_i\)。主实验直接复用 STEP 的 2 层 MLP scorer——这是故意的，为了把算法本身的贡献和 scorer 的贡献隔离开。附录里作者还训练了一个 history-aware 的序列 scorer（带 RoPE 的紧凑 Transformer，因果掩码保证第 \(t\) 步只能看到前 \(t\) 步），Table 2 显示换 scorer 之后 Gambit 的优势照样成立，这个我们后面细聊。

还有一个很工程但很关键的设计：warmup 阈值 \(w\)。所有评分和分支都要等 trace 生成至少 \(w\) 个 token 之后才启用——他们设的是 12,000 token。理由是太早的 checkpoint 建立在逻辑还不稳定的前缀上，分支会在错误的方向上级联爆炸。说实话看到 12K 这个数字我第一反应是"这么晚？"，但想想推理模型的 thought 本来就长，12K 大概也就几个 thought 的量级，合理。

部件二：Tournament——剪枝与分支的零和配对

每过 \(\Delta\) 个 token（默认 200）触发一次锦标赛，按当前分数给所有活跃 trace 排名，然后分两种情况：

情况一，池子没满（\(N \lt C\)）：有空位就从合格 trace（生成长度超过 warmup 的）里挑 top 分叉，直到填满容量。

情况二，池子满了（\(N = C\)）：执行大小为 \(K\) 的秩交换——剪掉得分最低的 \(K\) 条，同时从得分最高的 \(K\) 个前缀各分叉一条子 trace。剪掉和补上严格配对，活跃 trace 总数永远是 \(C\)。

这就是论文里反复强调的 zero-sum 内存不变式。子 trace 通过 prefix caching 继承父级 KV-cache，分叉本身的成本几乎为零；还可以给子 trace 加个温度乘数，避免分叉出来的兄弟轨迹长得一模一样。

部件三：解耦的内存管理——ghost trace 这个设计挺妙

这是我个人觉得全文最精巧的一处。系统里维护两个视图：Scheduler View 只追踪真正占着物理 KV-cache 块的 trace；Tree View 追踪所有逻辑上活跃的 trace。当显存快满时，调度器会机会性地把当前最低分的运行中 trace 踢出物理内存——但它不"死"，变成一条 ghost trace：不生成新 token、不占显存，但在 Tree View 里逻辑位置保留。

为什么需要这个？坦白讲第一遍读我没 get 到，后来想明白了：如果容量检查只看物理内存里的 trace，系统会误以为"池子没满"，然后反复在当前 Top-1、Top-2 的 trace 上贪婪分叉，搜索分布直接坍缩——所有算力都堆在一两条路上，多样性归零。Ghost trace 占住逻辑位置，直到它自然跌到 bottom-K 被永久剪枝。一个很小的机制，防住了一整个病理反馈循环。

部件四：终止与聚合

物理运行的 trace 归零、或者 \(C\) 条 trace 完成时停止。最终答案不是简单多数投票，而是分数加权多数投票：

图 3：Gambit 在 AIME 题上的端到端流程（容量 C=5，swap size K=2）。Warmup 阶段并行评估 5 条 trace，颜色深浅代表实时分数；Tournament R1 中最低分的 T1、T2 被剪枝，立刻从最高分的 T5 分叉出 T5.1 补位；R2 继续零和交换；最终 5 条完成的 trace 做分数加权投票，答案 29 以总分 1.78 对 1.43 胜出。

🔧 系统层面：算力利用率才是隐藏主线

这篇论文有一半的血统是系统论文，Figure 3 是证明。在 HMMT-25 Q7 上开 256 条 trace 的 batch：

• 并行采样：KV-cache 打满，排队导致延迟膨胀约 3 倍；
• 纯剪枝（STEP）：不排队了，但 trace 越剪越少，并发度一路流失，硬件在后面半程基本闲着；
• Gambit：剪一条补一条，全程高利用率，延迟只有约 1.1 倍。

图 4：batch=256 时在 HMMT-25 Q7 上的显存利用率与延迟曲线。并行采样耗尽 KV-cache 后延迟膨胀约 3×；STEP 消除排队但并发持续下降；Gambit 全程保持高利用率，延迟仅约 1.1×。

还有一点值得交代：整个 beam search 的算法开销——评分、hidden state 传输、树管理、调度——加起来占 wall clock 的 0.97%，GPU 前向计算占 99.03%。这套调度基本白送。

📊 实验：严格优于所有基线

实验配置：三个模型（Qwen3-4B-Thinking-2507、DeepSeek-R1-0528-Qwen3-8B、Phi-4-reasoning-plus-14B），五个 benchmark（AIME 2025/2026、HMMT 2024/2025、GPQA-Diamond），全部跑在单块 B300 上，每题严格预算 256 条完整 trace。基线是 SC@256、Slim-SC、DeepConf、STEP 四个。Gambit 超参全程固定：C=256、K=16、Δ=200、w=12K。

主表（Table 1）

数字太多，挑最有代表性的贴。先看 Phi-4-14B，这是 Gambit 优势最夸张的模型（Tok 单位为百万）：

注意 HMMT-25 那一列：Gambit 用 1.75M token 拿到 75.8，SC 用 5.56M 才拿 73.3——token 砍掉 68.5%，准确率还反涨 2.5 个点。Phi-4 五个 benchmark 的 token 消耗全部是所有方法里最低的。

Qwen3-4B 上的故事略有不同，更有意思：

HMMT-24 上 Gambit 拿 65.0，比 STEP 的 61.7 高 3.3 个点，比 DeepConf 高 6.7 个点，比 SC 高了 14.2 个点——而且 token 比 SC 少 60.6%。这个提升幅度在 256 条 trace 的预算下是很实在的，不是方差噪声能解释的。

DeepSeek-R1-8B 上结论一致：AIME-25 拿 85.8（STEP 是 83.3），HMMT-24 拿 65.6（STEP 是 63.3），token 在 HMMT-24 上砍掉 64%。

效率前沿与吞吐

图 5：全部 benchmark 上的效率-准确率前沿。(a) 平均延迟 vs 准确率；(b) 平均 token 消耗 vs 准确率。Gambit（红色系）主导效率前沿——用最低的总 token 和极具竞争力的延迟拿到最高准确率。

延迟上，Gambit 比并行采样快 2 倍以上，比 DeepConf、Slim-SC 这类削减式基线快约 1.5 倍，和 STEP 相当。trace 完成吞吐在 Qwen3-4B 上是 0.216 对 SC 的 0.098，翻倍还多。

图 6：AIME-26 上的 trace 完成吞吐。Gambit 把完成率有效翻倍（Qwen3-4B 上 0.216 vs SC 的 0.098），单位时间产出更多完整推理轨迹。

消融一：换 scorer，优势还在（Table 2）

这是我最关心的消融——Gambit 主实验用的 scorer 和 STEP 一模一样，那它的提升到底来自算法还是来自 scorer？作者换上自己训练的序列 scorer（SeqScorer）再跑一遍：

R1-8B 配自研 scorer，HMMT-24 上拉开 7.7 个点。结论很清楚：提升来自"分支放大"这个机制本身，不依赖特定 scorer。削减式系统只能当负向过滤器，scorer 再准，它也没法把准的信号变成更多的好 trace。

消融二：超参敏感度（Figure 10）

K ∈ {4, 8, 16, 32}、Δ ∈ {100, 200, 400}、w ∈ {8K, 12K, 16K} 全扫了一遍，选定配置 (K=16, Δ=200, w=12K) 落在一片很宽的高性能区域里，各维度平滑变化、全部压过 SC@256 的 83.3% 虚线。不用精细调参就能 work，这对工程落地是好消息。

一个让人印象深刻的运行时案例

附录 A.5 拆了一道 AIME 2025 Q12（答案 204）的完整锦标赛树：1595 个节点、1339 次分支、1083 条被剪、256 条完成。完成 trace 里只有 42 条答对——如果做简单多数投票，42/256 是必输的。但分数加权投票以 24.02 对 21.81 把 204 选了出来。

最漂亮的是那条答对的 trace：它是 depth-2 的分支，从一条答 203 的父 trace 分叉出来，继承了 31,404 个 token 的前缀，自己只新生成了 3,649 个 token——在这短短一段里做了个小规模 sanity check，发现父代在计算 1+2+25·8 时漏掉了磁盘本身的初始 1 个区域，补上这个 1 之后修正为 204。这条 trace 恰好是全部 256 条里得分最高的（0.632），对加权投票贡献最大。

同一个问题，SC@512 烧了 21M token、15K 秒 wall clock（约是 Gambit 的 13 倍 token、3.4 倍时间），512 条里只有 34 条答对，最后投票输给了错误答案。算力多 13 倍，答案还是错的——这个对照把"算力分配"这个命题讲得透透的。

🔬 一个不能忽略的"代价"：更长的有效推理链

Figure 7 和 Figure 8 放在一起看很有意思。Gambit 每条完成 trace 的新增 unique token 中位数大幅低于 SC 和 STEP（Phi-4 上 5.2K 对 14.5K）——前缀共享确实省 token。但看总序列长度（含继承的前缀），Gambit 反而比 STEP 深得多（R1-8B 上 35.8K 对 16.5K）。

图 7：AIME-2026 上每条完成 trace 生成的新增 unique token 分布。Gambit 从共享的高质量 KV-cache 前缀分叉，探索替代推理路径所需的新 token 中位数大幅降低。

图 8：含继承前缀的总序列长度分布。Gambit 维持了比 STEP 明显更深的推理链——存活 trace 的分布整体右移。

这说明两件事。好的一面：分支机制让算力集中在"能走更远"的 trace 上，推理链更深更严谨，这正是准确率提升的来源。代价的一面：这也解释了为什么 token 省了 60% 多，延迟却没有等比例下降——串行解码的深度成了新瓶颈。作者很诚实地把这个写进了论文，没有藏着。

💡 我的判断

这篇论文值钱的地方，在于它把一个被系统细节掩盖的算法问题给挖了出来。 过去一年 test-time scaling 的优化大多是"怎么早停、怎么去重、怎么置信度过滤"——全是减法。Gambit 第一个把"释放的算力该立刻投到哪"当成一等公民，而且剪枝-分支的零和配对、ghost trace 防坍缩、warmup 防级联爆炸，每个设计都对应一个真实的系统病理，不是拍脑袋堆 trick。跟 Tri Dao 团队一贯的风格一致：算法和系统联合设计，账算得明明白白。

问题也有。 说几个我皱眉的地方：

第一，warmup 12K token 说明前 12K token 是纯并行采样，这段算力完全没有被引导。对短推理任务（比如 GPQA 那种几 K token 就完的），warmup 还没结束 trace 就跑完了，Gambit 基本退化成 SC——这也解释了为什么 GPQA 上提升最小（Qwen3-4B 上只有 +2.0）。这套机制是为长思维链量身定做的。

第二，整个方法的天花板是 scorer 的质量。所有分支决策都押在 hidden state 探针的排序能力上，如果 scorer 在 OOD 题型上失准，分支就会系统性地放大错误方向——13 倍 token 的 SC 只是浪费钱，Gambit 可能自信地错。论文用两个 scorer 做了泛化验证，但"scorer 错了会怎样"这个对抗性问题没有正面回答。

第三，评测全在数学和 GPQA 这类有唯一标准答案的任务上。加权投票这个聚合方式天然适配闭式答案，换成开放式生成、代码或者 agent 轨迹，"答案聚类 + 加权投票"怎么推广，论文没碰。

但瑕不掩瑜。如果你在做推理服务或者 RL 的 rollout 系统，这个思路值得立刻试：它不需要改模型、不需要训练（scorer 可以是现成的）、纯推理时调度，vLLM 上加一层就能跑。我甚至会猜，"beam search 的复兴"可能是接下来推理系统的一个方向——经典 NLP 的那些搜索思想，套上现代 LRM 的 hidden state 信号和 prefix caching 的系统底座，还有很多矿可挖。

最后一个更本质的问题留给大家：Gambit 的分支信号来自 scorer，scorer 来自 offline 数据。那能不能让分支决策本身也从推理时的反馈里在线学习？这个问题一旦解决，test-time 的搜索就真的变成 RL 了。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我