LLM 성능 최적화: 긴 프롬프트 차단 및 디코드 지연 해결

TL;DR

LLM 서빙에서 긴 프롬프트는 프리필 큐를 차단하고 동시에 처리되는 요청들의 토큰 생성 속도를 늦출 수 있습니다. 이를 완화하기 위해 요청 병렬 프리필은 짧은 프롬프트의 첫 토큰까지 걸리는 시간을 줄이고, 분산 프리필은 프리필과 디코드 단계를 별도의 GPU에서 분리하여 간섭을 없애고 지연 시간을 안정화합니다.

긴 프롬프트 차단의 도전 과제

표준 LLM 서빙에서는 프리필 단계(초기 프롬프트 처리)가 연산 집약적이며 GPU 활용도를 포화시킬 수 있는 반면, 디코드 단계(후속 토큰 생성)는 연산 부담이 적습니다. vLLM에서 사용되는 기본 청크형 프리필 전략에서는 서로 다른 요청들의 프리필 청크가 순차적으로 스케줄됩니다.

매우 긴 프롬프트를 가진 요청이 스케줄되면 프리필 큐가 차단됩니다. 이후의 모든 요청은 자신의 프리필 단계가 시작되기 전에 긴 프리필이 완료될 때까지 기다려야 하며, 이로 인해 해당 요청들의 첫 토큰까지 걸리는 시간(TTFT)이 크게 증가합니다.

요청 병렬 프리필

큐 차단을 해결하기 위해 vLLM은 여러 요청에 대해 병렬 프리필을 허용하는 전략을 구현했으며, 동시에 처리되는 긴 프롬프트 수에 제한을 두고 있습니다(예: 4개의 병렬 프리필을 허용하지만 10,000 토큰을 초과하는 프리필은 하나만 허용).

  • Impact on Short Prompts: 짧은 프롬프트는 이제 "빠른 경로"를 통해 긴 프리필을 우회할 수 있어 TTFT가 크게 감소합니다.
  • Impact on Long Prompts: 긴 프롬프트는 여전히 순차적으로 처리되어, 여러 연산 집약적 프리필을 동시에 배치했을 때 발생할 수 있는 심각한 시스템 지연을 방지합니다.
  • Limitation: TTFT는 감소했지만, 동시 프리필이 여전히 GPU 자원을 소모하기 때문에 토큰당 출력 시간은 여전히 높게 유지되어 기존 요청들의 디코드 단계가 느려집니다.

근본적인 결함: 프리필-디코드 간섭

같은 GPU 작업 내에서 서로 다른 요청에 대한 프리필과 디코드 작업을 동시에 실행하면 토큰 생성 속도가 느려집니다. 긴 프롬프트를 가진 단일 요청만으로도 현재 디코드 단계에 있는 이전에 스케줄된 모든 요청의 성능이 저하됩니다.

완화 전략

  1. Priority Penalization: 긴 프롬프트는 고우선순위 또는 짧은 요청이 완료될 때까지 대기하도록 강제할 수 있습니다. 이는 긴 프롬프트의 지연 시간을 증가시키며, 실제로 긴 프롬프트가 스케줄되면 간섭 문제를 해결하지 못합니다.
  2. Dedicated Inference Servers: 긴 프롬프트 요청을 별도의 서버로 라우팅합니다. 이를 위해 정교한 라우터와 추가 GPU 자원이 필요하지만, 짧은 컨텍스트 서버는 적은 수의 GPU에 배치할 수 있습니다(예: Llama-3.3-70B는 130k 컨텍스트에 4개의 H100이 필요하지만 <10k 컨텍스트에는 2개의 H100만 필요).
  3. Disaggregated Prefill: 프리필과 디코드에 별도의 추론 엔진을 사용합니다. 이 아키텍처는 여러 vLLM 배포를 포함하며, 하나의 워커는 프리필만 담당하고 다른 워커는 디코드만 담당합니다. 프리필이 완료되면 KV 캐시가 디코드 워커로 전달됩니다.

지연 최적화를 위한 분산 프리필

분산 프리필은 동시 프리필로 인한 디코드 단계의 직접적인 방해를 없애며, 토큰 생성 지연 시간을 안정화하는 가장 효과적인 전략이 됩니다.

트레이드오프 및 현재 상황

  • Resource Cost: 이 접근 방식은 각 역할마다 별도의 전체 규모 vLLM 배포가 필요합니다(예: Llama-3.3-70B는 프리필용 4개, 디코드용 4개의 H100, 총 8개).
  • GPU 활용도: 프리필이 디코드보다 연산 집약적이기 때문에 활용도가 종종 고르지 않습니다. 그러나 대규모 클러스터에서는 로드 패턴에 따라 프리필과 디코드 워커의 비율을 조정하여 균형을 맞출 수 있습니다.
  • Goal: 주된 목표는 전체 원시 처리량보다 지연 목표를 충족하는 요청 비율인 "goodput"을 높이는 것입니다.
  • Experimental Status: vLLM v0.7.3 기준으로 이 기능은 실험 단계에 있습니다. 현재 제한 사항으로는 짧은 컨텍스트 길이 제한과 디코드 워커에서 CUDA 그래프 사용이 일관되지 않아 통합 배포에 비해 디코드 속도가 느려질 수 있습니다.

Sources