Sample Count Is Not Enough: Candidate-Generation Strategy Shapes the Energy and Performance of LLM Test-Time Scaling
Mobina Kashaniyan, Ali Jannesari
cs.LG, cs.DC, cs.PF
2026-09-17
固定N=8、多数投票规则不变,只改生成调用切分,A100上八次串行调用的GPU能耗是一次批量八候选的4.64–4.86倍,P95延迟5.77–6.12倍。
Self-consistency、best-of-N 这类测试时扩展(test-time scaling)方法,把推理预算写成一个数字 N:每个问题生成几条候选。N 说的是生成了多少条,没说这些条是怎么跑出来的。同样 8 条候选,可以一次 batch 出 8 条,也可以分 8 次各出 1 条。候选数和投票规则完全一样,调用次数和 batch size 却差一截,延迟、吞吐、GPU 小时和能耗会跟着走。
Iowa State 的 Kashaniyan 和 Jannesari 把这个执行选择单独拆出来。他们审计了 Self-Consistency、Adaptive-Consistency、Universal Self-Consistency、Large Language Monkeys、Scaling Test-Time Compute、Difficulty-Adaptive SC 等代表性工作:N 几乎都报了,每次查询调几次、每次出几条、能耗几乎都不报,硬件也经常缺。两份实验如果模型、数据集、解码设置和 N 都相同,只因生成调度不同,系统成本可以对不上。
HPC 上的推理经常是有时限的批作业。日志、固定种子、中间分析也会把一次采样拆成多次调用,论文里通常把这个切分当成实现细节。
生成调度写成 S=(b1,...,bC),各次调用的候选数加起来等于 N。固定 N=8,比较四种调度:
调用在同一块 GPU 上串行,同一次调用内部的候选作为 batch 一起解码。模型是 Phi-3-mini-4k-instruct 和 Qwen2.5-1.5B-Instruct,温度 1.0、top-p 0.95。答案用多数投票,不用 verifier。GSM8K 抽出数字答案再归一化;SciQ 抽出 A–D。平票取先出现的候选,所以 N=2 在两人各一票时会退回 N=1。
准确率在 500 道 GSM8K 上用同一组 8 条候选的前缀算 N∈{1,2,3,4,8},只看质量,不把这段延迟和能耗摊到各个 N。系统测量另用 100 道题、3 次重复,四种调度放在同一 A100 作业里,两次按 1×8 到 8×1 的顺序,一次反过来,减轻热节流和排队顺序的干扰。能耗取 NVML 累计读数之差,覆盖 prompt 处理、prefill、解码、全部生成调用、抽答案和投票;模型加载、热身和最终打分排除在外。这是整段查询窗口的 GPU 设备毛能耗,不扣空闲功率,也不含整机功耗。主实验在 A100-SXM4 80GB 上跑,功耗上限 500W,图形时钟锁 1275 MHz,生成走 Hugging Face 批量接口,不是 vLLM 那种连续 batching。SciQ 短输出验证改到 V100。
GSM8K 500 题上,N 从 1 加到 8,Phi-3 准确率从 81.4% 升到 89.8%,加 8.4 个百分点,95% 配对 bootstrap 区间 [5.8, 11.2];Qwen 从 51.4% 升到 69.8%,加 18.4 个百分点,[14.8, 22.0]。N=1 和 N=2 数字相同,因为平票时取先出现的候选。随机平票处理最多改 1.4 个百分点,抽答案失败也解释不了增益。
批量加大 N,每条查询能耗上升,每 token 能耗下降:
| 设置 | N=1 查询能耗 | N=8 查询能耗 | N=1 J/token | N=8 J/token |
| Phi-3/V100 | 631 J | 1286 J | 2.634 | 0.655 |
| Qwen/A100 | 596 J | 975 J | 2.222 | 0.459 |
平均延迟 Phi-3 从 5.06 s 升到 8.91 s,Qwen 从 5.26 s 升到 7.64 s。每 1000 查询的 GPU 小时分别从 1.41 升到 2.47、从 1.46 升到 2.12。batch 把每 token 摊薄了,多采候选仍会把整次查询做贵。
真正的对照是固定 N=8、只改调度。逻辑生成 token 量在 Phi-3 各调度间只差 0.8%,Qwen 差 1.0%。相对 1×8:
| 调度 | Phi-3 相对能耗 | Qwen 相对能耗 | Phi-3 相对 P95 | Qwen 相对 P95 |
| 1×8 | 1.00 | 1.00 | 1.00 | 1.00 |
| 2×4 | 1.63 | 1.66 | 1.81 | 1.97 |
| 4×2 | 2.71 | 2.86 | 3.21 | 3.57 |
| 8×1 | 4.64 | 4.86 | 5.77 | 6.12 |
中间两档跟着调用次数往上走,不是只有全串行那一档才出现。8×1 相对 1×8:Phi-3 能耗 4.64 倍(区间 [4.48, 4.79]),Qwen 4.86 倍([4.71, 5.02]);P95 延迟 5.77 倍和 6.12 倍;吞吐掉到批量基线的 16.7% 和 17.9%。每 1000 查询 GPU 小时,Phi-3 从 2.09 升到 12.49,Qwen 从 2.13 升到 11.76。Phi-3 平均功率从 177.8 W 降到 139.8 W,平均延迟却涨了 5.97 倍,总能耗照样上去。平均功率低,并不等于更省。
三个独立调度的 A100 节点上,能耗比落在 4.43–4.64(Phi-3)和 4.85–4.88(Qwen),吞吐都在 17–18%。按回复长度四分,Phi-3 能耗比 4.40–4.77,Qwen 4.51–5.09,不是长输出独有。SciQ/V100 上 Qwen 均值 1.71 token、Phi-3 均值 3.46 token,8×1 相对 1×8 能耗仍是 2.57 倍(Phi-3)和 3.34 倍(Qwen),吞吐剩 36% 和 23%。SciQ 同时换了 GPU 和输出长度,能下的结论更窄:长短两种负载上都看得到这份调度税。
按这篇测到的单查询差线性推到一百万查询,Phi-3 从 1×8 改到 8×1 大约多 1.37 MWh GPU 毛能耗和 10401 GPU 小时;Qwen 大约 1.00 MWh 和 9631 GPU 小时。这是当前配置的示意,不是别的部署的预测。
做 self-consistency 或 best-of-N 的人,如果在循环里一次采一条再拼起来,报的是 N=8,GPU 付的可能接近 8×1 的账单。候选互相独立、显存又塞得下时,一次 batch 出全部候选。显存不够就用能塞下的最大 batch、最少调用次数:b=min(N, bmax),C=ceil(N/b)。树搜索、交互 agent 这类下一步依赖上一步输出的流程,本来就必须串行,这条规则管不到。
对评测写作者,N 和准确率不够。至少还要写每次查询调几次、每次几条、是不是连续 batching、延迟、吞吐、GPU 小时,以及能耗测的是设备毛能耗还是扣了空闲。否则两篇「N=8」的系统数字没法比。
这是一次测量学提醒,不是新的采样算法。结论当天能用,覆盖范围只到小模型和 Hugging Face 批量生成。
论文自己划了边界:两个小模型、A100 和 V100、Hugging Face 批量生成。测到的倍率不能直接搬到更大模型、更新 GPU、vLLM 连续 batching,或多卡推理。连续 serving 里请求会跟别的流量拼 batch,实验室里「一块卡专门跑这 8 条」的假设会松掉。候选是独立采样的;依赖前一步输出的搜索必须串行。能耗是查询窗口内的 GPU 毛能耗,不含整机、不扣空闲。四种调度的端到端差异已经量出来了,重复 prefill、框架调用开销、同步、利用率各自贡献多少,没有拆开。SciQ 换了卡也换了输出长度,不能把倍率变小单独归因于短输出。