TNG가 vLLM의 청크 프리필 전략을 request-parallel prefills과 disaggregated prefill로 개선해 장문 프롬프트로 인한 큐 블로킹 제거 및 time-to-first-token 단축

Context

vLLM의 기본 chunked-prefill 전략에서 긴 프롬프트를 가진 요청이 프리필 큐를 차단하면서 이후 요청들의 첫 토큰 생성까지 대기 시간이 길어지는 문제가 발생했다. 프리필 단계는 병렬 처리로 GPU를 포화시킬 수 있어 여러 요청의 프리필을 동시에 처리할 수 없는 구조적 제약이 있었다.

Technical Solution

• 기본 동작 변경: vLLM 기본 설정에서는 디코드 단계가 진행 중일 때 새 요청의 프리필을 순차 처리하는 partial prefill 구조를 default로 실행 → 이로 인해 장문 프롬프트가 다음 요청의 프리필 시작을 지연
• Request-parallel prefills 도입: 다양한 요청의 프리필 청크를 병렬로 처리하되 장문 프롬프트(10,000 토큰 초과) 요청은 최대 1개만 동시 처리하도록 제한하는 정책 적용 → 단문 프롬프트 요청이 fast lane으로 진행되어 장문 요청의 영향 최소화
• Disaggregated prefill 구현: 프리필과 디코드 워커를 서로 다른 GPU에 분리 배포 → 장문 프롬프트 프리필이 동시 진행 중인 요청의 토큰 생성 속도 저하를 대부분 제거
• 리소스 할당 전략: Llama-3.3-70B 모델 기준으로 최대 컨텍스트 길이 130k 토큰 지원 시 프리필 워커에 4개 H100 GPU, 디코드 워커에 4개 H100 GPU를 별도로 할당하는 방식으로 운영

Impact

• Time-to-first-token: request-parallel prefills 적용 시 세 번째 요청의 time-to-first-token이 sequential partial prefill 대비 명확히 감소
• Disaggregated prefill 적용 시 장문 프롬프트(30,000 토큰) 요청과 함께 처리되는 다른 요청의 토큰 생성 지연이 표준 chunked-prefill 대비 대부분 제거

Key Takeaway

LLM 서빙 시스템에서 프리필과 디코드 단계의 계산 특성 차이(프리필은 compute-intensive 병렬 처리, 디코드는 sequential 저계산)로 인한 스케줄링 충돌을 인식하고, latency 목표가 있는 환경에서는 프리필-디코드 분리 배포(disaggregated prefill)가 짧은 대기 시간을 위해 추가 GPU 리소스를 투자할 가치가 있다는 설계 원칙을 확립할 수 있다.