후보개수N은실행방식이아니며N=8도생성스케줄에따라GPU에너지가4.6~4.9배다르다.

Sample Count Is Not Enough: Candidate-Generation Strategy Shapes the Energy and Performance of LLM Test-Time Scaling

HF Daily2609.19499

Mobina Kashaniyan, Ali Jannesari2026-09-16조회 4

무엇인가

이 논문이 다루는 문제는 테스트타임 스케일링의 비용 회계 방식이다. self-consistency나 best-of-N처럼 여러 후보 응답을 샘플링해 결합하는 방법에서 추론 예산은 흔히 후보 수 N으로 요약된다. 그러나 N은 후보를 몇 개 만들었는지만 말해줄 뿐, 그것이 어떻게 실행됐는지는 말해주지 않는다. 같은 N=8을 한 번의 배치 생성 호출로 만들 수도 있고, 작은 배치 크기의 순차 호출 여러 번으로 나눠 만들 수도 있다. 저자들은 이 문제가 특히 HPC 환경에서 중요하다고 본다. LLM 추론이 연속 서빙이 아니라 유한한 배치 잡으로 돌아가고, 로깅이나 결정론적 시드, 제어 로직, 중간 분석 때문에 후보 생성을 호출 단위로 쪼개는 일이 실제로 생기기 때문이다. 논문은 세 가지 질문을 세운다. 배치된 N이 1에서 8로 늘 때 정확도와 시스템 비용이 어떻게 변하는가, N=8을 고정했을 때 생성 스케줄이 지연·처리량·GPU-hours·활용도·에너지에 어떤 영향을 주는가, 그리고 이 효과가 다른 GPU 노드와 짧은 출력 워크로드에서도 유지되는가.

어떻게 동작하나

방법의 핵심은 후보를 몇 개 만드는가와 그 후보를 어떻게 실행하는가를 분리하는 것이다. 생성 스케줄을 S = (b_1, ..., b_C), Σ b_c = N 으로 형식화한다. 여기서 C는 생성 호출 수, b_c는 호출 c에서 만드는 후보 수다. N=8에 대해 1x8, 2x4, 4x2, 8x1 네 가지 스케줄을 비교하는데, axb는 생성 호출 a번, 호출당 후보 b개를 뜻한다. 즉 각각 S=(8), (4,4), (2,2,2,2), (1,1,1,1,1,1,1,1)에 해당한다. 호출은 같은 GPU에서 순차 실행되고, 한 호출 안의 후보들은 배치로 함께 생성된다. 모든 스케줄이 같은 프롬프트, 디코딩 설정, 답 추출, 투표 절차를 쓴다. 저자들은 스케줄 간 차이가 응답 길이 차이 때문에 생긴 게 아님을 확인하려고 논리적 토큰량도 추적한다. 후보별 논리적 입력량은 T_input_logical(q) = N·P_q로 모든 스케줄에서 8·P_q로 같고, 논리적 생성 토큰 수는 T_gen_logical(q,S) = Σ_c Σ_j L_{q,c,j}로 계산한다. 에너지 측정 경계도 명시한다. 각 측정 쿼리는 GPU 동기화와 NVML 누적 에너지 초기 판독으로 시작해 프롬프트 처리, prefill, 디코딩, 모든 생성 호출, 답 추출, 다수결 투표를 포함하고, 마지막 투표 후 다시 동기화해 누적 에너지를 기록한다. 모델 로딩, 워밍업, 보고용 토큰 카운팅, 최종 채점은 제외한다. 총 GPU-디바이스 에너지는 E_gross = E_NVML,end − E_NVML,start이며 유휴 에너지는 빼지 않는다. 평균 GPU 전력은 총 에너지를 쿼리 지연으로 나눈 값이다.

무엇과 다른가

실험은 Phi-3-mini-4k-instruct와 Qwen2.5-1.5B-Instruct 두 모델, GSM8K와 SciQ 두 데이터셋에서 이뤄졌다. 정확도 연구는 GSM8K 500개 프롬프트에 대해 각 모델이 후보 8개를 생성하고, 작은 N의 정확도는 같은 집합에서 앞의 N개 후보로 계산하는 짝지은 비교다. 시스템 실험은 GSM8K 100개 프롬프트를 3회 반복하고, 주 스케줄 실험은 N=8을 고정한 채 호출 수와 호출당 후보 수만 바꾼다. 네 스케줄은 같은 A100 잡 안에서 실행되며, 두 반복은 1x8, 2x4, 4x2, 8x1 순서로, 한 반복은 역순으로 돌려 순서·열 효과를 줄인다. 1x8과 8x1 양 끝점은 모델당 추가 A100 노드 두 개에서 반복해 총 3개의 독립 스케줄 A100 잡을 확보한다. SciQ 500개 프롬프트에 대해서는 V100에서 전체 N=8 스윕을 3회 반복한다. 하드웨어는 A100-SXM4 80GB(500W 전력 제한, 1275MHz 고정 클록)와 V100 PCIe 32GB(250W, 1230MHz)이고, 잡마다 GPU 하나를 배타적으로 예약한다. 샘플링은 temperature 1.0, top-p 0.95이며 GSM8K 최대 출력 512 토큰, SciQ 64 토큰이다.

어떻게 쓰나

정확도 결과는 예상대로 후보를 늘리면 좋아진다. Phi-3는 N=1에서 81.4%로 N=8에서 89.8%가 되어 8.4pp 상승했고(95% 짝지은 부트스트랩 구간 [5.8, 11.2]pp), Qwen은 51.4%에서 69.8%로 18.4pp 상승했다([14.8, 22.0]pp). 흥미로운 지점은 N=1과 N=2의 정확도가 같다는 것인데, 이는 동점 처리 규칙 때문이다. 첫 두 후보가 불일치하면 각각 한 표를 받고 첫 후보가 선택되므로, 다수결이 형성되기 시작하는 N=3부터 정확도가 오른다. 저자들은 동점 처리나 답 추출이 이득을 설명하는지도 확인했는데, 무작위 동점 처리는 기대 정확도를 최대 1.4pp 바꿨고 추출 성공 조건부 분석도 작은 변화만 줬다.

전제와 한계

배치된 N을 늘릴 때의 비용은 정확도와 다른 그림을 보여준다. Phi-3는 쿼리당 에너지가 631J에서 1286J로 늘고 토큰당 에너지는 2.634J에서 0.655J로 줄었다. Qwen은 596J에서 975J로, 토큰당 2.222J에서 0.459J로 변했다. 큰 배치는 토큰 처리량을 높이지만 쿼리 전체 지연은 여전히 증가한다. N=1에서 N=8로 갈 때 평균 지연은 Phi-3가 5.06초에서 8.91초, Qwen이 5.26초에서 7.64초가 됐고, 1,000 쿼리당 GPU-hours도 1.41에서 2.47, 1.46에서 2.12로 늘었다. 즉 배칭은 토큰당 효율을 개선하지만 후보를 더 만들면 쿼리 총비용은 커진다.

핵심 결과는 N=8을 고정하고 스케줄만 바꾼 실험에 있다. 스케줄 간 논리적 생성 토큰량 차이는 Phi-3 0.8%, Qwen 1.0%에 불과했다. 그런데 같은 8개 후보를 더 많은 호출로 쪼갤수록 에너지와 P95 지연이 함께 증가했고, 중간 스케줄들도 같은 경향을 보여 효과가 완전 직렬 끝점에서만 나타나는 게 아니라 점진적이었다. 완전 직렬인 8x1은 1x8 대비 총 GPU-디바이스 에너지를 Phi-3에서 4.64배(95% CI [4.48, 4.79]), Qwen에서 4.86배([4.71, 5.02]) 썼다. P95 지연은 각각 5.77배([5.38, 5.99]), 6.12배([5.70, 6.75])에 도달했고 처리량은 배치 기준선의 16.7%와 17.9%로 떨어졌다. 1,000 쿼리 기준 측정 GPU 시간은 Phi-3가 2.09에서 12.49 GPU-hours, Qwen이 2.13에서 11.76 GPU-hours로 늘었다. 평균 전력이 낮아져도 이 손해는 사라지지 않는다. Phi-3 평균 전력은 177.8W에서 139.8W로 줄었지만 평균 지연이 5.97배 늘어 총 에너지는 오히려 커졌다.

이 효과의 견고성도 확인했다. 모델당 3개의 독립 스케줄 A100 잡에서 직렬 처리량은 매번 배치 처리량의 약 17~18%로 유지됐다. 응답 길이 4분위로 나눠도 Phi-3의 에너지 비율은 4.40~4.77, 지연 비율은 5.45~6.16이었고 Qwen은 에너지 4.51~5.09, 지연 5.15~5.88로, 비율이 길이에 단조롭지 않게 모든 구간에서 나타났다. 짧은 출력 검증인 SciQ/V100에서도 1x8에서 8x1로 갈 때 총 에너지가 Phi-3 2.57배, Qwen 3.34배 늘고 지연은 2.88배, 4.42배 늘었으며 처리량은 36%와 23%로 떨어졌다. 다만 SciQ는 V100, GSM8K는 A100이라 비율 크기 차이가 출력 길이 때문이라고 단정하지 않고, 고정 N 스케줄 효과가 두 설정 모두에서 나타난다는 좁은 결론만 지지한다. 저자들은 규모 확장 시 효과를 선형 예시로 계산해, 100만 쿼리에 1x8 대신 8x1을 쓰면 Phi-3에서 약 1.37MWh와 10,401 GPU-hours, Qwen에서 약 1.00MWh와 9,631 GPU-hours가 추가된다고 제시한다. 이는 측정된 구성의 선형 예시일 뿐 다른 배포에 대한 예측은 아니라고 못 박는다.

개발자에게 주는 실무 지침은 명확하다. 후보 생성은 N 하나로 지정할 문제가 아니라 스케줄링 문제로 다뤄야 한다. 독립적인 후보라면 사용 가능한 GPU 메모리에 맞는 가장 큰 배치를 쓰는 것이 간단한 휴리스틱이다. b_max를 메모리와 시스템 제약 안에서 들어가는 최대 후보 수라 할 때 b = min(N, b_max), C = ceil(N/b)로 호출당 후보 수와 호출 수를 정하고, N이 b로 나누어떨어지지 않으면 마지막 호출에 나머지를 담는다. 예컨대 8개가 모두 메모리에 들어가면 1x8이 유리하고, 4개만 들어가면 2x4가 더 잘게 쪼갠 스케줄보다 낫다. 저자들이 밝힌 한계도 분명하다. 실험은 모델 2개, GPU 아키텍처 2종, Hugging Face 배치 생성 방식에 한정되므로 더 큰 모델, 다른 GPU 세대, 연속 배칭 시스템, 멀티 GPU 추론에 같은 비율이 유지된다고 가정하지 않는다. 고정 N 스케줄은 후보를 독립적으로 샘플링했고 논리적 생성 토큰량은 비슷하게 맞췄지만, 호출 오버헤드, 프롬프트 재처리, 동기화, 배칭 효과 같은 개별 메커니즘의 기여도를 분리하지는 못했다. 따라서 결과는 각 생성 스케줄의 종단 간 비용으로 해석해야 한다. 에너지 측정은 측정 구간의 총 GPU-디바이스 에너지로, 노드 전체 에너지가 아니고 유휴 GPU 전력도 빼지 않았다. 그래서 저자들은 다중 후보 추론 실험을 보고할 때 N뿐 아니라 쿼리당 생성 호출 수, 호출당 후보 수, 배칭 모드, 지연, 처리량, GPU-hours, 에너지 측정 경계를 함께 밝히라고 권고한다. 같은 모델, 데이터셋, 디코딩 설정, 후보 수를 쓴 두 실험도 생성 스케줄이 다르면 시스템 비용이 크게 달라질 수 있기 때문이다.