Github热榜第二：仅靠“自验证”框架让 DeepSeek V4 Flash 反超 Fable 5，成本不到 1/11

作者 | 四月

一个已经训完的大模型，不换参数、不做微调，究竟还能榨出多少性能？

当行业纷纷把目光投向 Test-time Scaling，指望在推理阶段‘大力出奇迹’的当下，一份名为LLM-as-a-Verifier的开源框架在社区引发了现象级讨论，并迅速冲上 GitHub 热榜第二。

当 AI Agent 任务越来越复杂，如何评判大模型输出的对错，一直是个昂贵且棘手的难题。而由 Jacky Kwok 牵头，联合斯坦福大学、加州大学伯克利分校和英伟达研究院学者组成的团队，给出了惊艳的解法。

在极具挑战的 Terminal-Bench 2.1 基准测试上，DeepSeek V4 Flash 仅靠对每个任务采样 5 条候选轨迹，再以自身作为 Verifier 从中挑选最优解（Best-of-5），系统成功率即从 79%飙升到了 88%，一举超越了闭源前沿模型 Claude Fable 5。

更受关注的是调用成本：DeepSeek 自验证单任务成本约 0.11 美元，而 Fable 5 则约 1.3 美元，成本不到后者的十分之一。有网友质疑，11 倍的成本差距可能只来自单 Token 价格差。由于自验证需要多次采样和检查，完成每个任务实际上消耗了多得多的 Token，总价未必便宜。

论文一作 Jacky 回应称，公布的成本已经包含“生成 N 条候选轨迹”与“后续验证”两部分的全部开销。虽然消耗了更多 Token，但得益于开源模型极低的 Token 单价，最终核算下来的“单任务总成本”依然实现了碾压级的优势。

DeepSeek V4 Flash 的自验证实验

早在今年 7 月，研究团队就已发布了论文《LLM-as-a-Verifier: A General-Purpose Verification Framework》，核心突破在于：提出一种不额外训练专门奖励模型（Reward Model）或验证器，就能直接利用现有 LLM 对 Agent 的完整执行轨迹进行细粒度验证和排序的方法。目前该研究已经在 Coding、机器人控制和医疗诊断等多个领域完成验证。（https://arxiv.org/pdf/2607.05391）

这次更新的 v0.2.0 框架，主要新增 DeepSeek V4 Flash 验证支持和 Terminal-Bench 2.1 自验证基准。实验整体架构的巧思之处体现在：LLM-as-a-Verifier 不只用于测试时扩展，验证信号还可以用于进度跟踪和强化学习。过去，我们要对复杂的 AI Agent 进行强化学习微调，最大的阻碍是缺乏高质量的“奖励信号”，而这套框架基于概率加权的“连续验证分数”，恰恰为其提供了极其平滑、高密度的奖励信号（Dense Reward）。

在设计上，在对于每一个具体的终端控制任务，系统首先由 DeepSeek-V4-Flash 生成 5 条mini-swe-agent执行轨迹。随后，模型自身同时承担起“裁判员”的角色，为这些候选轨迹打分，最终由LLM-as-a-Verifier框架完成细粒度排序并挑出最优解。

实验结果呈现出了极其显著的性能跃迁：

•阶梯式涨点：在不介入验证时，模型单次生成的原生成功率仅为 78.7%；而在 Best-of-3 设定下（在前 3 条候选轨迹中筛选），系统成功率跃升至 86.5%；当扩大至 Best-of-5 时，成功率直接被推高到了88.0%。

• 逼近上限的 Oracle 指标：更为关键的一项指标是 Oracle（理想选择上限）达到了 96.6%。原论文进一步汇总不同 Agent 配置后的数据显示，理想选择器下的覆盖率最高甚至可达 98.9%。

换句话说，对于绝大多数复杂任务，只要给模型 5 次尝试机会，正确的解题轨迹其实早就已经包含在候选池中了。大模型从来不缺“生成正确答案”的能力，过去真正限制系统表现的，是一双能把正确答案精准挑出来的“眼睛”。

成本也是这组实验受到关注的重要原因。团队测算中，DeepSeek 一侧使用 DeepSeek V4 Flash Max，价格按照当时 OpenRouter 报价计算，生成多条候选轨迹和后续验证的成本都已经包含在内。

从“粗糙裁判”到“概率显微镜”

有人提出，既然候选池中早已存在正确轨迹，为什么行业沿用已久的“LLM-as-a-Judge（大模型裁判）”方案在此前总是挑不准？

事实上，传统裁判机制的核心痛点，在于离散评分的颗粒度过粗。传统的评判方式通常要求大模型直接输出一个 1 到 5 分的整数分数。然而在处理长逻辑代码或复杂系统操作时，两条存在细微质量差异的执行轨迹，往往会被模型同时判定为 4 分或 5 分。

原论文实测表明，单次离散评分的平局率高达26.7%。当超过四分之一的候选方案陷入平局时，系统根本无法完成最优筛选。

这暴露了离散评分的瓶颈，而后续实验进一步发现，提高评分粒度、增加重复验证和拆分评价标准，都能持续提升验证准确率。这意味着 Test-time Scaling 不只有“多生成”，验证侧计算能力的持续提升本身也可以成为独立的 Scaling 维度。

LLM-as-a-Verifier的破局点，就在于它不再依赖模型吐出的干瘪文本，而是深入截获模型在输出评价时的“潜意识”——底层对数概率分布（logprob）。

核心机制：连续评分

普通 LLM Judge 通常只读取模型最终输出的离散分数，而 LLM-as-a-Verifier 进一步利用不同评分 Token 对应的概率分布，计算一个连续验证分数。

因此即使两条轨迹最终都被判为“4 分”，只要模型对相邻评分档位的概率分布不同，仍然可以继续拉开差距。

验证能力的三维扩展（3D Scaling）

在此基础上，团队还把 Verification Compute 沿三个方向扩展：增加评分粒度、对同一轨迹重复评估、把复杂评价拆成多个 criteria 分别判断。

实验显示，随着三个方向上的验证预算增加，Verification Accuracy 都继续提升。这也是论文把 Verification 定义为一条独立 Scaling 轴的重要依据。

算法与工程降本：PPT 排序与前缀缓存

在落地工程中，伴随候选数量的增加，全量两两比较（Pairwise Comparison）的计算复杂度会呈现可怕的 爆炸。

团队因此提出Probabilistic Pivot Tournament（PPT），避免对所有候选做完整两两比较，用更少的比较完成候选排序；工程侧又通过前缀缓存进一步降低长 Agent 轨迹的重复输入成本。

重新审视 Agent 的算力账本

过去 Test-time Scaling，更多讨论多采样、多搜索，LLM-as-a-Verifier 补上了另一半：候选生成出来以后，验证本身也值得投入计算。对开发者而言，模型选型不再只是看单 Token 价格，而要看单位成功任务的总成本。廉价模型多跑几次，再通过 Verifier 筛选，依然可能比直接调用昂贵旗舰模型更划算。

这对开源模型尤其重要。过去高质量验证往往依赖额外训练 Reward Model、PRM，或者调用更强模型做 Judge；Jacky 团队则证明，现成 LLM 本身就能承担相当一部分细粒度验证工作，甚至可以同时作为生成者和验证者。Verifier 因此有机会进一步进入 Agent Harness，成为运行时基础能力。