候选数量不足:候选生成策略影响LLM测试时扩展的能耗与性能

arXiv cs.LG 论文

摘要

本文探讨了不同候选生成计划对大语言模型在测试时扩展过程中的能耗和性能的影响,表明更大的批次大小可以减少能耗和延迟。

arXiv:2609.19499v1 Announce Type: new 摘要:测试时扩展可以通过生成并组合多个候选响应来提升大语言模型的推理能力。在基于采样的方法中,推理预算通常由生成的候选数量N来描述。然而,N仅告诉我们生成了多少候选,而未说明它们如何执行。相同的候选预算可以通过一次批量生成调用产生,或分为多次顺序调用,每次调用较小的批次大小。我们首先使用Phi-3-mini和Qwen2.5-1.5B在500个GSM8K提示上研究增加N对推理准确性的影响。正如预期,将N从1增加到8使Phi-3-mini的准确性提高了8.4个百分点,Qwen2.5-1.5B提高了18.4个百分点。然而,仅准确性并不能体现使用更大候选预算的系统成本。因此,我们固定N=8,比较四种生成计划:1x8、2x4、4x2和8x1,其中axb表示每次调用b个候选的生成调用。我们在保持总候选数固定的情况下,测量延迟、吞吐量、GPU小时和总GPU设备能耗。在A100 GPU上,八次顺序调用的总GPU设备能耗是一次批量调用(八个候选)的4.64-4.86倍,P95延迟是其5.77-6.12倍。相同的模式出现在每个模型的三个独立调度的A100节点上,以及在短输出SciQ/V100实验中。这些结果表明,仅候选数量不足以描述多候选测试时扩展的系统成本。当候选独立且内存允许时,更少的生成调用配合更大的批次大小更高效。因此,评估应不仅报告候选数量和准确性,还应报告生成计划和GPU级系统指标。
查看原文
查看缓存全文

缓存时间: 2026/09/18 08:57

# 样本数量不足:候选生成策略如何影响LLM测试时缩放的能耗与性能
来源:https://arxiv.org/html/2609.19499
Mobina Kashaniyan 与 Ali Jannesari  
所属机构:美国爱荷华州立大学计算机科学系 \{mobina, jannesar\}@iastate\.edu

###### 摘要

测试时缩放可以通过生成和组合多个候选响应来提升大语言模型的推理能力。在基于采样的方法中,推理预算通常用生成的候选数量 \(N\) 来描述。然而,\(N\) 仅告诉我们生成了多少候选响应,而非它们如何被执行。相同的候选预算可以通过一次批处理生成调用完成,也可以分配到多次较小批次大小的顺序调用中。我们首先研究了在Phi-3-mini和Qwen2.5-1.5B模型上,针对500个GSM8K提示,增加 \(N\) 对推理准确性的影响。正如预期,将 \(N\) 从1增加到8,使Phi-3-mini的准确率提高了8.4个百分点,Qwen2.5-1.5B提高了18.4个百分点。然而,仅凭准确率无法体现使用更大候选预算的系统成本。因此,我们固定 \(N=8\) 并比较四种生成调度:\(1\times8\)、\(2\times4\)、\(4\times2\) 和 \(8\times1\),其中 \(a\times b\) 表示 \(a\) 次生成调用,每次调用包含 \(b\) 个候选。我们测量了延迟、吞吐量、GPU小时数和GPU设备总能耗,同时保持总候选数固定。在A100 GPU上,八次串行调用比一次包含八个候选的批处理调用多消耗 \(4.64\!-\!4.86\times\) 的GPU设备总能耗,且P95延迟是其 \(5.77\!-\!6.12\times\)。这种模式出现在每个模型独立调度的三个A100节点以及短输出的SciQ/V100实验中。这些结果表明,仅靠候选数量不足以描述多候选测试时缩放的系统成本。当候选之间相互独立且内存允许时,使用更大批次大小、更少次数的生成调用更为高效。因此,评估报告不仅应包括候选数量和准确率,还应包括生成调度和GPU级别的系统指标。

###### 关键词:

大语言模型,测试时缩放,候选生成,GPU推理,能耗测量,性能,高性能计算

## I 引言

测试时缩放通过分配额外的推理计算(通常通过多个采样响应)来提升大语言模型(LLM)的推理能力。例如,自一致性方法生成多个推理路径,并选择出现频率最高的最终答案[1 (https://arxiv.org/html/2609.19499#bib.bib1)]。在这些方法中,推理预算通常总结为候选数量 \(N\)。然而,\(N\) 仅告诉我们生成了多少候选,而非它们如何被执行。相同的候选预算可以通过一次批处理调用生成,也可以分配到多次较小批次大小的顺序调用中。尽管这些调度使用相同数量的候选和相同的聚合规则,但它们需要不同数量的生成调用并使用不同的批次大小。这可能导致延迟、吞吐量、GPU小时数、利用率和能耗的显著差异。我们在 \(N=8\) 的情况下,使用 \(1\times8\)、\(2\times4\)、\(4\times2\) 和 \(8\times1\) 调度研究了这种执行选择。这个问题在高性能计算(HPC)环境中尤为重要,因为LLM推理可能作为有限批量作业而非连续服务工作负载运行。候选生成也可能因为日志记录、确定性种子、控制逻辑或中间分析而被分配到多次调用中。尽管服务研究已经表明批处理和调度影响推理效率[26 (https://arxiv.org/html/2609.19499#bib.bib26), 27 (https://arxiv.org/html/2609.19499#bib.bib27), 28 (https://arxiv.org/html/2609.19499#bib.bib28)],但表I (https://arxiv.org/html/2609.19499#S2.T1)显示,代表性的测试时缩放研究通常报告候选预算,而不报告每次查询的调用次数、每次调用的候选数量或测量能耗。这使得系统结果难以复现和比较。我们解决了三个问题:

1.  随着批处理 \(N\) 从1增加到8,准确率和系统成本如何变化?
2.  在固定 \(N=8\) 的情况下,生成调度如何影响延迟、吞吐量、GPU小时数、利用率和能耗?
3.  这些影响是否在不同的GPU节点和短输出工作负载中依然存在?

本文做出三项贡献:
- **执行调度与报告缺口**:我们将候选生成调度形式化为 \(\mathcal{S}=(b_1,\ldots,b_C)\),并表明仅靠候选数量 \(N\) 无法完全描述多候选推理工作负载。我们还表明,代表性的测试时缩放研究中常常缺失每次查询的调用次数和每次调用的候选数量。
- **固定预算下的系统特性表征**:在固定 \(N=8\) 时,我们测量了 \(1\times8\)、\(2\times4\)、\(4\times2\) 和 \(8\times1\) 调度对延迟、吞吐量、GPU小时数、利用率和GPU设备总能耗的端到端影响。在A100 GPU上,串行执行比一次包含八个候选的批处理调用多消耗 \(4.64\!-\!4.86\times\) 的能量。
- **稳健性与实践指导**:我们评估了额外的A100节点、两个模型和一个短输出的SciQ/V100案例研究。结果支持一个实用的指导原则:当候选之间相互独立且内存允许时,使用更大批次大小、更少次数的生成调用更为高效。我们还为多候选推理实验提供了最低报告建议。

这些结果表明,测试时缩放的系统成本不仅取决于生成了多少候选,还取决于这些候选如何被分组到生成调用中。

## II 背景与相关工作

### II-A 测试时缩放

测试时缩放通过在推理过程中使用额外的计算来改进LLM输出。一些方法将此计算用于扩展或精炼推理轨迹,而其他方法则生成并组合多个候选响应。先前的研究表明,额外的测试时计算可以改善推理能力,并且有时能帮助较小模型在相似的推理预算下达到较大模型的性能[2 (https://arxiv.org/html/2609.19499#bib.bib2), 4 (https://arxiv.org/html/2609.19499#bib.bib4), 3 (https://arxiv.org/html/2609.19499#bib.bib3)]。然而,这种效益取决于提示难度、推理策略、停止条件和聚合方式等因素[5 (https://arxiv.org/html/2609.19499#bib.bib5)]。我们的工作聚焦于另一个因素:多候选推理预算如何在底层硬件上执行。

### II-B 多候选采样

自一致性方法采样多个推理路径,并选择出现频率最高的答案[1 (https://arxiv.org/html/2609.19499#bib.bib1)],而“最佳N选一”方法则使用验证器、奖励模型或置信度度量来选择一个候选[6 (https://arxiv.org/html/2609.19499#bib.bib6)]。先前的研究考察了更大或自适应的采样预算、停止规则和不同的选择方法[7 (https://arxiv.org/html/2609.19499#bib.bib7), 8 (https://arxiv.org/html/2609.19499#bib.bib8), 9 (https://arxiv.org/html/2609.19499#bib.bib9), 10 (https://arxiv.org/html/2609.19499#bib.bib10), 11 (https://arxiv.org/html/2609.19499#bib.bib11), 12 (https://arxiv.org/html/2609.19499#bib.bib12), 13 (https://arxiv.org/html/2609.19499#bib.bib13), 14 (https://arxiv.org/html/2609.19499#bib.bib14)]。这些工作主要研究生成多少候选或如何在它们之间选择。相比之下,我们保持候选预算固定,研究在不同的生成调用次数和批次大小下执行相同的候选如何影响系统成本。

### II-C 推理调度与能耗

LLM推理效率取决于批处理、调度、内存管理和资源分配[16 (https://arxiv.org/html/2609.19499#bib.bib16)]。ORCA、vLLM和Sarathi-Serve通过不同的批处理和调度策略提高了利用率和吞吐量[26 (https://arxiv.org/html/2609.19499#bib.bib26), 27 (https://arxiv.org/html/2609.19499#bib.bib27), 28 (https://arxiv.org/html/2609.19499#bib.bib28)]。其他工作研究了异构调度和KV缓存约束[18 (https://arxiv.org/html/2609.19499#bib.bib18), 19 (https://arxiv.org/html/2609.19499#bib.bib19)]。能耗也取决于模型大小、硬件、批次大小、序列长度、并行性和利用率[25 (https://arxiv.org/html/2609.19499#bib.bib25), 24 (https://arxiv.org/html/2609.19499#bib.bib24), 21 (https://arxiv.org/html/2609.19499#bib.bib21), 23 (https://arxiv.org/html/2609.19499#bib.bib23), 22 (https://arxiv.org/html/2609.19499#bib.bib22)]。近期的研究还比较了不同AI加速器和批次大小下LLM推理的性能和能效[17 (https://arxiv.org/html/2609.19499#bib.bib17)]。这些研究表明执行选择会强烈影响推理成本。我们的工作通过测量在固定 \(N\) 下,生成调用结构如何影响延迟、GPU小时数、利用率和GPU设备总能耗,将这些系统因素与多候选测试时缩放联系起来。

### II-D 先前工作的报告实践

表I (https://arxiv.org/html/2609.19499#S2.T1)审计了代表性的基础性研究、自适应预算研究和重复采样研究。我们仅在论文或其补充材料中明确说明了相应的执行细节时,才记录该字段为已报告。“NR”表示未报告。该审计旨在表征代表性工作的报告实践,而非提供详尽的系统性综述。代表性研究通常报告候选预算,但未完全指定生成调用结构或测量能耗成本。

TABLE I:代表性多候选和测试时缩放研究中的报告实践。HW指候选生成硬件;“NR”表示未报告。本研究报告了 \(N\)、每次查询的调用次数、每次调用的候选数量、推理硬件和GPU设备总能耗。

## III 方法

### III-A 候选生成策略

我们的目标是将生成多少候选与如何执行这些候选区分开来。设 \(N\) 为针对一个提示生成的总候选数量。我们将生成调度表示为
\(\mathcal{S}=(b_1,\ldots,b_C),\qquad\sum_{c=1}^{C}b_c=N,\)
其中 \(C\) 是生成调用次数,\(b_c\) 是第 \(c\) 次调用中生成的候选数量。图1 (https://arxiv.org/html/2609.19499#S3.F1)展示了 \(N=8\) 的工作流程。我们比较 \(1\times8\)、\(2\times4\)、\(4\times2\) 和 \(8\times1\) 调度。在 \(a\times b\) 调度中,\(a\) 是生成调用次数,\(b\) 是每次调用生成的候选数量。调用在同一分配的GPU上顺序执行,而每次调用内的候选则作为一批一起生成。因此,四种调度分别对应 \(\mathcal{S}=(8)\)、\((4,4)\)、\((2,2,2,2)\) 和 \((1,1,1,1,1,1,1,1)\)。

参见图注 图1:固定候选预算 \(N=8\) 的生成调度。所有调度使用相同的提示,生成八个候选,并应用相同的多数投票。它们在顺序生成调用次数和每次生成的候选数量上有所不同。重复的LLM块表示在同一GPU上的连续调用。所有调度使用相同的提示、解码设置、答案提取和投票程序。在系统实验中,候选响应在调度之间独立采样。我们还研究了候选预算增加时准确率的变化。对于每个提示,我们生成八个候选,并使用前 \(N\) 个候选计算 \(N\in\{1,2,3,4,8\}\) 时的准确率。这提供了跨候选数量的配对比较。这些候选仅用于准确率分析。系统测量通过在GPU上运行每个调度单独收集。

### III-B Token 计算

我们跟踪逻辑token量,以检查调度之间的差异是否不是由生成响应长度的显著差异引起的。设 \(P_q\) 为查询 \(q\) 的提示长度。由于每个候选都由相同的提示生成,候选关联的逻辑输入量为
\(T_{\mathrm{input}}^{\mathrm{logical}}(q)=NP_q.\)
在固定 \(N=8\) 时,每个调度的输入量都是 \(8P_q\)。设 \(L_{q,c,j}\) 为第 \(c\) 次调用中候选 \(j\) 的生成长度。生成的逻辑token数为
\(T_{\mathrm{gen}}^{\mathrm{logical}}(q,\mathcal{S})=\sum_{c=1}^{C}\sum_{j=1}^{b_c}L_{q,c,j}.\)
在固定 \(N\) 的实验中,候选数量在各调度之间相同,且生成的逻辑token量保持紧密匹配。这使我们能够在固定总体候选预算的情况下,比较不同生成调度的系统成本。

### III-C 答案提取与投票

生成后,所有候选使用相同的答案提取和多数投票程序。具有相同提取答案的候选形成一个组,最大的组决定最终预测。我们不使用验证器、奖励模型或token级分数。对于GSM8K,我们通过检查最终答案分隔符、boxed表达式、明确答案语句、尾随数字表达式和最后一行非空内容来提取数值最终答案。然后将数值答案规范化为通用形式。对于SciQ,我们不区分大小写地提取A-D选项中的一个。提取失败仍可能成为投票结果,如果被选中则计为不正确。如果多个答案获得相同票数,我们选择在生成的候选中首先出现的答案。在准确率分析中,此规则可能使 \(N=2\) 与 \(N=1\) 相同(当前两个候选不一致时)。因此,我们也评估 \(N=3\) 并使用均匀随机打破平局的方法报告敏感性分析。

### III-D 测量边界与能耗

每个测量的查询开始于GPU同步和初始NVML累计能量读数。测量区间包括提示处理、预填充、解码、所有生成调用、答案提取和多数投票。最终投票后,我们再次同步GPU并记录最终累计能量值。模型加载、预热、报告时间token计数和最终评分被排除在外。GPU设备总能耗计算为
\(E_{\mathrm{gross}}=E_{\mathrm{NVML,end}}-E_{\mathrm{NVML,start}}.\)
未减去空闲能耗。因此,报告的值表示整个测量查询区间的GPU设备总能耗,而非隔离的动态计算能耗或整个节点能耗。平均GPU功率计算为总能耗除以查询延迟。因此,一个调度可能具有较低的平均功率,但如果它使GPU活动时间更长,则可能消耗更多总能量。

## IV 实验设计与测量

### IV-A 研究概述

我们围绕三个目标组织评估。首先,我们测量准确率随候选预算增加的变化。其次,我们测量系统成本随候选数量和生成调度的变化。第三,我们检查主要的调度效应是否在不同GPU节点和短输出工作负载中依然存在。表II (https://arxiv.org/html/2609.19499#S4.T2)总结了用于这些目标的五个实验。

TABLE II:实验研究总结。对于准确率研究,每个模型为500个GSM8K提示生成八个候选。较小 \(N\) 值的准确率使用同一集合的前 \(N\) 个候选计算。

相似文章

用 LLM 优化 LLM:面向测试时扩展的智能体发现方法

Hugging Face Daily Papers

本文提出了 AutoTTS,这是一种环境驱动的框架,通过将测试时扩展(TTS)策略的发现过程形式化为控制器合成,自动发现用于大型语言模型(LLM)的测试时扩展策略。该框架在数学推理基准测试上展示了更优的准确率-成本权衡,且计算开销极小。