LLM temperature 설정 고르기, API별 지원표와 다중 샘플 비용 계산

호출 코드에 temperature=0.2를 적어 두고 잘 먹힌다고 믿고 계신가요? 결론부터 말하면 2026년 10월 기준 최신 상용 모델 상당수는 그 값을 무시하거나 에러로 돌려보내요. Claude는 API 버전 2026-10-21부터 temperature·top_p·top_k를 보내면 400 에러를 내고, Gemini 3.6 Flash 이후 모델은 세 값을 조용히 무시해요. OpenAI GPT-6 계열도 추론(reasoning)을 켜 둔 상태에서는 temperature·top_p를 빼라고 안내해요. 손잡이를 돌릴 곳은 이제 추론을 끈 일부 모델과 직접 서빙하는 오픈 모델뿐이에요.

이 글은 샘플링의 내부 원리 대신 고를 때 필요한 숫자를 다뤄요. API별 지원 현황, 넣을 값, 다수결 비용, 재현성의 지연 비용을 공식 문서와 논문 숫자로 정리했어요.

API별 샘플링 파라미터 지원 현황 (2026년 10월)

먼저 내 모델에서 손잡이가 살아 있는지 확인해요. 최근 큰 상용 API들이 하나둘 샘플링 파라미터를 닫았어요. Google은 Gemini 3의 추론 능력이 기본 설정에 맞춰 최적화돼 있다는 이유를 들어요.

Anthropic API 2026-10-21 마이그레이션 문서는 세 값을 기본값으로 보내도 400 에러가 나고 대신할 설정은 없다고 적어요. Claude Opus 5.5 마이그레이션 가이드는 이전 모델에서도 temperature = 0이 같은 출력을 보장하지 않았다고 덧붙여요. OpenAI는 최신 모델 가이드에서 추론 강도가 none이 아니면 세 값을 제거하라고 하고, 범위와 "둘 중 하나만" 권장은 Responses API 레퍼런스에 있어요.

Gemini 3 개발자 가이드는 temperature를 기본값 1.0으로 두라고 강하게 권하며, 1.0 아래에서 복잡한 수학·추론의 반복(looping)이나 성능 저하를 경고해요. generateContent 레퍼런스는 세 필드가 Gemini 3.6 Flash 이후 모델에서 조용히 무시된다고 적어요.

손잡이가 살아 있을 때 고르는 설정값

추론을 끈 OpenAI 모델, 옛 API 버전의 Claude, 직접 띄운 오픈 모델에서는 여전히 값을 골라야 해요. 모델 제작사가 권장값을 냈으면 그것부터 쓰고, 없으면 작업 성격에 맞춰 아래 표에서 출발해요.

Qwen3-8B 모델 카드는 생각 모드에서 그리디를 쓰면 성능이 떨어지고 끝없는 반복이 생길 수 있다고 굵게 적어요. "정확해야 하니 온도 0"이라는 습관이 추론 모델에서는 역효과를 낼 수 있어요.

vLLM 모델 설정 소스에서 generation_config의 기본값은 "auto"이고, 이때 모델 폴더의 generation_config.json을 읽어 기본 샘플링 값으로 써요. Qwen3-8B라면 요청에 값을 안 넣어도 vLLM SamplingParams 소스의 기본값(온도 1.0, top_k 0)이 아니라 파일에 든 온도 0.6, top_k 20, top_p 0.95가 걸려요. 엔진 기본값을 쓰려면 --generation-config vllm을 줘요.

높은 온도의 품질 — top-p와 min-p 숫자 비교

min-p 논문(Nguyen 외, ICLR 2025) 표 2는 Mistral 7B로 GPQA Main(5-shot)과 GSM8K CoT(8-shot) 정답률을 온도별로 쟀어요. min-p는 0.05·0.1, top-p는 0.9·0.95 중 좋은 쪽을 골랐다고 적혀 있어요.

• 온도 1.0 아래에서는 무엇을 써도 비슷해요. GPQA 온도 0.7에서 세 방식은 27.23~29.18%로 2%p 안쪽이에요. GSM8K CoT에서도 온도 0.7일 때 top-p 36.09%, min-p 35.18%로 top-p가 조금 높았어요.
• 온도를 1.5 이상 올릴 때만 차이가 벌어져요. GPQA 온도 2.0에서 top-p 6.47%, min-p 26.34%였어요. 다만 GSM8K처럼 긴 풀이를 쓰는 작업은 min-p도 온도 1.5에서 18.42%, 2.0에서 6.21%로 떨어졌어요. 긴 추론에서 높은 온도는 min-p로도 다 막지 못해요.

여러 번 뽑아 다수결하기 — self-consistency 비용 계산

self-consistency 논문(Wang 외, ICLR 2023)은 풀이를 40개 뽑아 가장 많이 나온 답을 고르는 방식으로 PaLM 540B의 GSM8K 정답률을 56.5%에서 74.4%로, code-davinci-002는 60.1%에서 78.0%로 올렸어요(둘 다 +17.9%p). 이때 PaLM은 온도 0.7·top_k 40, GPT-3는 온도 0.7(top-k 없음)으로 뽑았어요. 이미 94.7%였던 MultiArith는 +4.6%p에 그쳤어요. 기본 정답률이 낮고 답이 짧게 떨어지는 작업일수록 이득이 커요.

비용은 단순해요. 표본 수 N배예요. 계산 조건은 이렇게 잡았어요.

• 작업: 풀이를 쓰고 숫자 답을 내는 문제. 입력 800토큰, 출력 400토큰.
• 단가: OpenAI 공식 가격표 Standard, 짧은 문맥 기준 100만 토큰당 gpt-6-luna 입력 0.10달러·출력 0.50달러, gpt-6-sol 입력 2.00달러·출력 10.00달러(2026-10-25 확인). 두 모델 모두 추론 none에서 temperature를 쓸 수 있어요.
• 표본은 따로 요청, 캐시 할인 제외.

한 번 호출 비용은 gpt-6-luna가 800 × 0.10 + 400 × 0.50 = 280달러(100만 건당), gpt-6-sol이 800 × 2 + 400 × 10 = 5,600달러예요.

표본을 병렬로 보내면 지연은 N배까지 늘지 않지만, 가장 늦은 응답을 기다려야 해서 p95·p99가 나빠지고 분당 요청 한도도 N배로 써요. 실무 순서는 이래요.

1. 큰 모델 1번과 작은 모델 N번을 같은 비용으로 맞춰 내 평가 세트에서 비교해요. 어느 쪽이 나은지는 작업마다 달라 직접 재야 하고, 비슷하면 1번 호출 쪽이 운영이 단순해요.
2. 다수결을 쓴다면 표본 수를 3·5·10으로 늘려 가며 정답률 곡선이 꺾이는 지점에서 멈춰요.
3. 요약·글쓰기처럼 답이 긴 작업은 다수결로 고를 "같은 답"이 없어 맞지 않아요.

추론 강도를 조절할 수 있는 모델이라면 표본 수를 늘리는 것과 추론 강도를 한 단계 올리는 것도 같은 비용으로 맞춰 비교해 보세요. 추론 토큰도 출력 단가로 청구되니 응답의 usage로 실제 토큰을 확인해야 해요. 한국어 서비스라면 한국어 LLM 토큰 비용 비교로 토큰 수를 먼저 재 보세요.

temperature 0 재현성의 지연 비용

회귀 테스트·평가 재현처럼 "같은 입력이면 같은 답"이 필요할 때 temperature 0을 떠올리기 쉽지만, 서버가 요청을 묶어 처리하는 한 보장되지 않아요.

Thinking Machines Lab의 비결정성 분석 글(2025-09-10)에서 Qwen3-235B-A22B-Instruct-2507에 온도 0으로 같은 프롬프트를 1,000번 보냈더니 서로 다른 완성문이 80개 나왔어요. 가장 흔한 답도 78번뿐이었어요. 배치 불변(batch-invariant) 커널을 켜자 1,000개가 모두 같아졌는데, 대가로 처리 시간이 늘었어요. Qwen3-8B로 출력 90~110토큰짜리 1,000개를 GPU 한 장에서 처리한 측정이에요.

지금은 vLLM에 이 기능이 들어와 있어요. vLLM 배치 불변성 문서에 따르면 VLLM_BATCH_INVARIANT=1 환경 변수로 켜고, 연산 능력 8.0 이상 NVIDIA GPU와 일부 AMD Instinct GPU에서 지원해요.

대부분은 응답 저장이 가장 싸요. 형식은 Structured Outputs·JSON 모드 비교에서 정리한 스키마 제약으로 묶고 내용은 필드 단위로 검증하는 편이 현실적이에요.

상황별 추천 — 무엇을 돌리고 무엇을 둘까

Claude·Gemini 최신 모델과 추론을 켠 GPT-6은 ①에서 끝나요.

도입 체크리스트

1. 모델별로 파라미터가 살아 있는지 확인해요. 받지 않는 값은 요청에서 지워요.
2. 조용히 무시되는지 직접 확인해요. 같은 프롬프트를 온도 0.2와 1.5로 몇십 번씩 보내 서로 다른 답의 개수를 비교해요.
3. 오픈 모델은 generation_config.json부터 열어요. 서버에서 덮어쓰는 값도 함께 기록해요.
4. 손잡이는 하나만 돌려요. OpenAI 레퍼런스도 temperature와 top_p 중 하나만 바꾸라고 권해요.
5. 비교는 같은 비용으로 해요. 다수결 N번, 큰 모델 1번, 추론 강도 올리기를 비용을 맞춰 비교해요.
6. 운영 지표를 정해요. 반복으로 길이 한도에 걸린 비율, 형식 실패율, 응답 길이를 봐요. 온도를 낮춘 뒤 반복이 늘면 되돌려요.
7. 재현성 기대치를 문서로 남겨요. "temperature 0이면 같은 답"이라는 가정을 테스트 코드에서 지우고, 저장된 응답이나 필드 검증으로 바꿔요.

직접 서빙하면서 지연까지 줄여야 한다면 투기적 디코딩 방식별 속도·비용 비교도 함께 보세요.

자주 묻는 질문

Claude에서 temperature를 못 쓰면 출력을 어떻게 일정하게 하나요?

Anthropic 마이그레이션 가이드는 샘플링 파라미터 대신 프롬프트로 동작을 이끌라고 안내하고, 생각의 깊이는 effort 파라미터로 조절하게 해요. 출력 형식이 일정해야 한다면 구조화 출력으로 스키마를 묶는 편이 확실해요. 이전 모델에서도 temperature 0이 같은 출력을 보장하지는 않았다고 문서에 적혀 있어요.

Gemini에서 temperature를 낮추면 더 정확해지지 않나요?

Gemini 3 가이드는 반대로 1.0 미만에서 반복이나 성능 저하가 생길 수 있다며 기본값 유지를 강하게 권해요. 3.6 Flash 이후 모델은 값을 넣어도 조용히 무시해요. 정확도는 thinking 수준과 프롬프트로 조절하는 쪽이 맞아요.

min_p는 어디서 쓸 수 있나요?

vLLM SamplingParams에 min_p가 있고 기본값은 0.0(끔)이에요. 상용 API 대부분은 받지 않으니, 직접 서빙하는 오픈 모델에서 높은 온도를 쓸 때 검토하면 돼요.

다수결 표본은 몇 개가 적당한가요?

self-consistency 논문은 40개를 썼지만 비용이 40배예요. 3·5·10개로 늘려 가며 내 평가 세트의 정답률이 더 오르지 않는 지점을 찾고, 같은 비용의 큰 모델 1번과 비교해 보세요.

정리

• 2026년 10월 기준 Claude 최신 API는 샘플링 파라미터를 400 에러로 막고, Gemini 3.6 Flash 이후는 조용히 무시하고, GPT-6은 추론을 끈 경우에만 받아요.
• 손잡이가 살아 있으면 제작사 권장값이 출발점이에요. vLLM은 모델의 generation_config.json을 기본으로 읽어요. 높은 온도가 필요할 때만 min-p를 붙여요(GPQA 온도 2.0에서 top-p 6.47% vs min-p 26.34%).
• 다수결은 정답률을 올리지만 비용이 표본 수만큼 늘어요. gpt-6-luna 20번이 gpt-6-sol 1번과 같은 5,600달러(100만 건)이니, 같은 비용으로 비교해서 정해요.
• temperature 0은 재현성을 보장하지 않아요. 배치 불변 커널은 처리 시간을 62~112% 늘렸으니, 대부분은 응답 저장과 필드 검증으로 해결해요.