vLLM으로 서빙하는데 동시 요청 늘리면 첫 토큰 지연(TTFT)이 급격히 나빠집니다
사내 GPU 서버(A100 80GB 1장)에 vLLM으로 한국어 파인튜닝한 모델을 올려서 사내 챗봇으로 쓰고 있습니다. 단일 요청일 때는 TTFT(첫 토큰까지 시간)가 괜찮은데, 동시 사용자가 10~20명으로 늘면 첫 토큰이 나올 때까지 몇 초씩 걸립니다.
throughput 자체는 continuous batching 덕에 나쁘지 않은데, 체감 응답성(처음 글자 뜨는 속도)이 확 떨어져서 사용자 불만이 나옵니다.
--max-num-seqs, --gpu-memory-utilization 정도만 만져봤는데 뭘 더 봐야 할까요? 입력 프롬프트가 긴 편입니다(RAG라서 컨텍스트가 길어요).
답변 3개
- 채택된 답변에디터 검증
긴 프롬프트 + 동시성에서 TTFT 무너지는 건 prefill과 decode가 같은 스텝을 두고 싸워서예요. RAG로 컨텍스트가 길면 prefill 비용이 크고, 새 요청 들어올 때마다 그 prefill이 진행 중인 decode를 밀어내서 이미 생성 중이던 요청들 토큰 간격(ITL)까지 같이 출렁입니다.
핵심 레버:
- chunked prefill 켜기. 긴 프롬프트를 한 스텝에 통째로 처리하지 않고 쪼개서 decode랑 섞어 돌립니다. 최근 vLLM은 켜지는 방향이지만 버전 따라 명시 활성화/튜닝 필요할 수 있어요. TTFT 스파이크엔 이게 1번입니다.
--max-num-seqs무작정 올리지 마세요. 동시 시퀀스 너무 많이 허용하면 배치당 prefill 부하 커지고 KV 캐시 압박으로 preemption(요청이 중간에 쫓겨남) 생기면서 오히려 지연이 튑니다. 올렸다가 더 나빠지면 이게 원인.- prefix caching. RAG 시스템 프롬프트/공통 지시문이 매 요청 앞에 똑같이 붙으면 automatic prefix caching으로 그 부분 재사용됩니다. 입력 길수록 효과 큼.
그리고 측정할 때 TTFT랑 ITL을 꼭 분리해서 보세요. throughput 한 숫자만 보면 체감 저하 원인을 영영 못 잡습니다. /metrics에서 waiting 큐도 같이 보시고요.
--gpu-memory-utilization도 생각보다 관련 있어요. 너무 낮게(0.7 같은) 잡으면 KV 캐시 블록이 적어져서 동시에 태울 시퀀스가 줄고, 남는 요청은 큐에서 대기하다 그게 TTFT로 잡힙니다. 0.9 안팎까지 올려보되 OOM 마진은 남기세요. nvidia-smi로 실제 점유 보면서 조절하시길. 단 이건 캐시 여유 만드는 거지 prefill 병목 자체를 푸는 건 아니라, chunked prefill이랑 같이 가야 합니다.운영 관점 하나 더. 위 튜닝 다 해도 A100 1장에 동시 20명 + 긴 RAG 컨텍스트면 그냥 물리적으로 빡셉니다. 두 가지 권해요.
- 컨텍스트부터 줄이세요. RAG에서 top-k 8~10개 그냥 다 욱여넣는 경우 많은데, 리랭커로 3~4개로 줄이면 prefill 부하가 거의 비례해서 빠지고 TTFT가 직접 좋아집니다. 품질도 보통 안 떨어져요. 오히려 노이즈 청크 빠져서 답이 나아지는 경우도 봤고요. 제일 가성비 좋은 한 방.
- 트래픽을 분리하세요. 인터랙티브 챗이랑 배치성(요약·분류) 트래픽을 같은 엔드포인트로 받으면 배치 작업이 챗 TTFT를 잡아먹습니다. 별도 인스턴스나 우선순위 큐로 가르세요.