LLM 서빙 환경에서 샘플링 파라미터를 다루는 조직 분업 구조가 있다. 모델 품질 담당자가 "Temperature=1.2로 설정해야 창의적 응답이 나온다"고 결정하면 서빙 엔지니어는 그 값을 그대로 받아 운영한다. p99 latency가 폭등하는 사고가 났을 때 원인을 찾다 보면 샘플링 파라미터에서 멈추는 경우가 있다. Temperature가 텍스트 품질만 조정한다는 인식이 서빙 비용 구조를 가리고 있기 때문이다.
Temperature가 출력 길이 분포를 바꾸는 경로
Temperature는 softmax 직전에 logit을 T로 나눈다. T > 1이면 logit 간 격차가 줄어들고 확률 분포가 평탄해진다. 어휘 전체에 확률이 더 균등하게 퍼진다. 문제는 EOS 토큰도 이 평탄화에서 예외가 없다는 점이다. 모델이 내부적으로 "이쯤에서 끝내는 게 맞다"고 판단해도, T=1.5 환경에서는 EOS의 상대 확률이 희석되어 다른 어휘 토큰에 밀려 더 뒤로 밀릴 가능성이 올라간다. 결과적으로 같은 프롬프트 셋에서도 T=0.7 조건의 평균 출력 길이보다 T=1.5 조건의 평균 출력 길이가 길어진다.
평균보다 더 나쁜 건 분산이다. T=0.7에서 50~150 토큰 사이에 몰려 있던 출력 길이 분포가, T=1.5에서는 30 토큰짜리와 800 토큰짜리가 같은 배치에 공존하는 모양이 된다. T=0.0(greedy)에서는 매 스텝 최고 확률 토큰이 선택되므로 출력 길이 분산이 사실상 0이다. T=1.0까지는 분산 증가가 완만하다가 그 이후부터 비선형적으로 커진다.
Continuous batching이 분산을 비용으로 바꾸는 구조
Orca (OSDI 2022)의 iteration-level scheduling은 decode 스텝마다 배치를 재구성한다. 요청이 EOS를 생성하는 즉시 슬롯을 반납하고 대기 중인 신규 요청이 들어온다. static batching 대비 GPU 활용률을 높이는 핵심 메커니즘이다. 논문에서는 FasterTransformer 대비 최대 36.9배 throughput 향상을 보고했다.
이 구조에서 출력 길이 분산이 크면 배치 효율이 무너진다. 배치 내 어떤 요청은 50 토큰 만에 끝나고 어떤 요청은 800 토큰을 계속 생성 중이면, 짧게 끝난 슬롯은 재사용되지만 오래 살아남는 요청이 배치에 붙어 있는 동안 전체 decode 스텝이 그 요청을 위해 돌아간다. 배치 크기가 16이라면, 700 토큰 이상 생성 중인 요청 23개가 나머지 1314개 요청의 TPOT ceiling을 끌어올린다.
max_new_tokens=512로 고정해도 문제가 사라지지 않는다. Temperature를 높이면 실제로 512 토큰 근처까지 가는 요청의 비율이 늘어난다. 짧게 끝날 수 있었던 요청들이 EOS를 늦게 만나기 때문이다. 결과적으로 배치에 오래 살아남는 요청이 증가하고 신규 요청을 수용할 슬롯이 줄어들며 throughput이 하락한다. Temperature를 높이는 것이 사실상 유효 배치 크기를 줄이는 효과를 낳는 구조다.
Top-p, Top-k, Min-p: decode 커널에서 어디가 다른가
softmax 이후에 어떤 연산을 하느냐가 각 전략의 커널 비용을 가른다.
Top-k는 어휘에서 확률 상위 k개를 고른다. torch.topk()는 partial sort로 처리되어 k가 작으면 전체 어휘를 정렬할 필요가 없다. 어휘 크기가 128k 토큰이어도 k=50이면 전체 정렬 없이 완료된다. vLLM topk_topp_sampler.py의 apply_top_k_only 경로가 이 방식을 사용한다.
Top-p는 다르다. 누적 확률 합이 p에 도달하는 지점까지 토큰을 포함시키는 방식인데, 그 지점이 어디인지를 알려면 확률을 내림차순으로 정렬하고 누적합(cumsum)을 계산해야 한다. vLLM 소스에서는 logits.sort(dim=-1, descending=False) → torch.cumsum(probs_sort, dim=-1) 순서로 구현된다. 어휘 크기가 클수록 이 full sort + cumsum의 비용이 정비례하여 증가한다.
vLLM PR #11394에서 이 오버헤드가 직접 측정됐다. ShareGPT 데이터셋 기준:
| 조건 | throughput |
|---|---|
| 샘플링 없음 | 47.40 req/s |
| PyTorch 네이티브 top-p | 40.20 req/s (−15.2%) |
| FlashInfer 커널 top-p | 47.15 req/s (−0.5%) |
PyTorch 네이티브 구현이 high-throughput 환경에서 ~20% 성능 손실을 유발했다. FlashInfer는 rejection sampling 기반으로 전체 정렬 없이 처리해 이 오버헤드를 사실상 없앴다. 현재 vLLM v1은 CUDA 환경에서 FlashInfer를 기본 경로로 사용하지만, per-request generator나 post-filtering logprob이 요구되는 경우 PyTorch fallback이 발생한다.
Min-p는 2024년 제안된 방식이다(arXiv:2407.01082, ICLR 2025 Oral). 고정 임계값 대신 최고 확률 토큰의 확률을 기준으로 동적으로 필터링한다. Top-p가 높은 Temperature에서 너무 많은 어휘를 포함시키는 문제를 완화하면서, 연산 구조상 전체 정렬 없이도 처리할 수 있어 Top-k에 가까운 커널 비용을 유지한다.
SqueezeBits의 측정에서 샘플링을 켰을 때 vLLM은 request rate 8 기준으로 throughput이 15.4% 하락하고 TPOT가 20.6% 증가했다. 같은 조건에서 TensorRT-LLM은 throughput 7.1% 하락, TPOT 9.2% 증가였다. vLLM 오버헤드가 약 2배 더 큰 이유는 당시 vLLM이 Python 기반 구현에 의존한 반면 TensorRT-LLM이 커스텀 CUDA 커널을 사용했기 때문이다. FlashInfer 통합 이후 이 격차는 상당 부분 줄었다. 또한 해당 측정에서 개별 샘플링 방법의 오버헤드는 Top-K > Top-P > repetition penalty 순으로 나타났는데, 이는 FlashInfer 이전 PyTorch 네이티브 vLLM 기준임을 감안해야 한다.
presence_penalty · frequency_penalty는 스텝당 비용이 증가한다
Temperature나 Top-p는 decode 스텝 수에 영향을 주지만 스텝당 연산량은 일정하다. presence_penalty와 frequency_penalty는 구조가 다르다. 매 decode 스텝마다 지금까지 생성된 토큰 집합을 스캔해 logit을 수정한다. 출력 50 토큰 시점에는 50개를 스캔하고, 500 토큰 시점에는 500개를 스캔한다. 스텝당 비용이 출력 길이에 비례해 선형으로 증가하는 구조다.
Temperature를 높이면 출력 자체가 길어지고, 거기에 frequency_penalty까지 걸면 긴 출력의 후반 decode 스텝이 갈수록 느려진다. 두 파라미터가 동시에 작용할 때 tail latency가 배로 악화되는 이유다. Temperature로 인한 decode 스텝 수 증가와 penalty로 인한 스텝당 비용 증가가 곱해지기 때문이다. 장문 생성 엔드포인트에서 presence_penalty / frequency_penalty를 기본값으로 두는 설정은 한 번 재검토할 필요가 있다.
샘플링 파라미터는 서빙 엔지니어가 함께 설계해야 한다
이 비용 경로는 조직이 나뉘어 있으면 보이지 않는다. "창의성을 높이려고 Temperature=1.5를 설정했다"는 결정이 서빙 층에서 얼마나 큰 throughput 손실로 이어지는지 전달되는 채널이 없다. API 요청 로그에서 출력 토큰 수 분포를 먼저 확인하고, 분산이 비정상적으로 크면 Temperature를 의심하는 것이 p99 latency 급등 디버깅의 첫 번째 단계가 된다.
운영 기준으로 정리하면:
- Temperature 상한을 서빙 레이어에서 강제한다. 프로덕션에서는 최대 1.0으로 clamp하고, 그 이상은 별도 실험 엔드포인트에서만 허용한다.
max_new_tokens와 Temperature는 함께 설계한다.max_new_tokens=2048에 Temperature=1.5를 허용하면 배치 최대 점유 시간이 해당 조합에서 최대가 된다. Temperature 상한을 낮추거나max_new_tokens를 줄이거나 둘 중 하나다.- presence_penalty / frequency_penalty는 단문 생성(200 토큰 이하) 엔드포인트에서만 기본 허용한다. 장문 엔드포인트에서는 후반 decode의 선형 비용 증가가 SLO를 위협한다.
- Top-p와 Top-k를 동시에 지정하면 두 조건의 교집합으로 필터링된다. vLLM은 단일 커널 패스로 처리하지만 불필요한 조합은 걸지 않는 것이 낫다.