自洽性推理通过并行生成多条思维链并对最终答案进行投票，能显著降低单条链的随机波动，但代价是每一轮采样都需要执行完整的前向解码。假设一次回答消耗约 800 个 token，固定采样 10 次意味着 10 倍的计算与计费，而很多简单问题在第 3 次采样后答案分布已经稳定。为了让自洽性推理真正落到生产环境，需要把采样次数从固定值改为动态调整，并配合早停机制来降低平均调用量。

一、自洽性推理的成本为什么随采样次数线性增长

自洽性推理的流程通常是：对同一个问题，用较高的温度参数重复采样 k 条推理路径，然后统计每条路径给出的最终答案，把出现次数最多的答案作为结果。由于语言模型是自回归的，每条路径都要逐 token 生成，且路径之间虽然可以在一个 batch 中并行，但计算量、显存占用和计费 token 数并不会因此减少。换句话说，k 次采样就是 k 份完整的解码成本。

从信息增益的角度看，投票结果的稳定性会随着采样次数增加而上升，但边际收益递减。假设某个问题的真实答案在模型分布中占比为 p，当采样数 k 较小时，少数几条采样可能因随机性给出错误答案，导致投票结果不稳定；当 k 增大到一定程度后，最高票答案的领先幅度已经很难被后续采样翻转。此时继续采样只是在为很小的准确率提升支付固定比例的额外成本。

因此，早停的核心思想是：在采样过程中持续观察答案分布，一旦有充分证据表明继续采样不会改变最终投票结果，就立即停止。这个策略可以在几乎不损失准确率的前提下，把平均采样次数从固定值降下来。对在线服务来说，降低的不只是算力成本，还有用户感知的响应延迟。

二、如何确定最优采样次数：自适应阈值比固定值更划算

过去很多实现会直接设置一个固定采样次数，例如 5、10 或 20。固定值的好处是逻辑简单，也便于离线评估，但问题在于：不同请求的难度差异很大。简单算术题可能 3 次采样就足够稳定，复杂多跳推理可能需要 15 次以上才能覆盖不同路径。统一按最高难度设置 20 次，会造成大量浪费；统一按较低难度设置 5 次，又会在困难样本上出现明显准确率下降。

更合理的做法是设置一个自适应区间，例如最小采样次数 n_min 为 3 到 5，最大采样次数 n_max 为 20 到 40。先采样 n_min 条路径，统计答案分布。如果最高频答案的占比已经超过预设阈值 tau，比如 0.65，就提前停止；否则继续按小批量补充采样，每次补充 2 到 4 条，直到达到 n_max。这样简单问题可能在 4 次采样时结束，复杂问题仍能获得足够的采样数量。

阈值 tau 的取值是平衡点。tau 越低，早停越激进，成本节省越多，但错误提前停止的风险也越大；tau 越高，早停越保守，准确率更接近全量采样，但节省效果有限。通常可以在开发集上画出平均采样次数与准确率的关系曲线，选择两者交点附近的阈值。实际经验中，tau 设为 0.6 到 0.75 配合 n_min 为 3 到 5，能在准确率损失小于千分之五的情况下减少约 30% 到 50% 的采样次数。

下表给出了几种典型参数组合的对比，其中成本节省按平均采样次数相对固定 20 次计算：

需要注意的是，表格中的数值只是示意，实际效果取决于任务类型、模型温度和答案空间大小。落地时应基于自己的验证集做一次扫描。

三、早停机制的核心实现与统计判断

早停的实现并不复杂，本质上是一个循环：每次采样一批答案，更新计数，然后判断是否满足停止条件。下面的 Python 代码演示了自适应采样与早停的基本流程。代码中 generate_func 表示一次生成多条答案的接口，实际项目中可以替换为批量调用大模型 API 的函数。

def adaptive_self_consistency(
    generate_func,
    question,
    n_min=3,
    n_max=20,
    tau=0.65,
    batch_delta=2,
):
    answers = []
    counts = {}
    total = 0
    while total < n_max:
        batch_size = n_min if total == 0 else batch_delta
        batch_size = min(batch_size, n_max - total)
        new_answers = generate_func(question, batch_size)
        answers.extend(new_answers)
        total += batch_size
        counts.clear()
        for ans in answers:
            counts[ans] = counts.get(ans, 0) + 1
        top_count = max(counts.values())
        top_ratio = top_count / total
        if total >= n_min and top_ratio >= tau:
            break
    final_answer = max(counts, key=counts.get)
    return final_answer, total

上面的逻辑在前几次采样时使用 n_min 作为初始批量，后续每次补充 batch_delta 条。停止条件有两个：总采样数达到 n_min，并且最高频答案占比达到 tau。这样可以避免刚开始采样就因偶然一致而提前结束。返回的 total 是实际采样次数，记录这个值有助于后续评估早停节省了多少成本。

更严格的判断可以引入统计检验。例如当最高票答案与第二高票答案的票数差为 d 时，如果继续采样 m 次，翻转结果所需的新增票数至少为 d，可以用二项分布或正态近似估计这种翻转发生的概率。如果该概率低于风险阈值，比如 0.01，就可以更放心地停止。这种方法比单纯看比例的阈值法更稳健，尤其适合答案分布比较均匀的场景。但实现复杂度也更高，一般只有在高吞吐、高成本压力下才需要。

四、工程落地中的批量调度与成本核算

实际系统中，自洽性推理的多次采样并不是简单串行调用，而是通过批量请求来降低延迟。早停机制要求动态调度：不能一开始就请求 n_max 条，否则早停就没有意义。通常的做法是先请求一个小的 batch，例如 n_min 条，拿到结果后计算是否停止；如果不停，再请求下一批。这样会增加几轮网络往返，但换来的成本节省通常远大于额外延迟。

批量大小 batch_delta 的选择也会影响效率。设置过小，比如每次补充 1 条，会增加请求轮数；设置过大，则可能最后一次采样超过实际需要，造成少量浪费。比较折中的方案是让 batch_delta 等于 2 到 4，并配合 n_max 的上限。对于延迟敏感的服务，也可以采用异步流水线，在第一轮结果返回前就预判是否需要第二批，但这会增加调度复杂度。

成本核算方面，假设固定采样 20 次的平均成本为 1.0，采用早停后平均采样次数降到 8 次，则成本降为 0.4。需要注意的是，早停本身不产生额外推理成本，它只是减少了无效采样。因此只要阈值设置得当，节省的部分几乎就是净收益。建议上线后持续记录每个请求的实际采样次数、最终投票比例和用户反馈，定期回看是否有异常提前停止的案例，再微调 n_min 和 tau。