vLLM으로 Qwen2.5 셀프호스팅 중인데 동시 요청 늘리면 TTFT가 확 튑니다
온프레 A100 80GB 1장에 Qwen2.5-14B-Instruct를 vLLM으로 띄워서 사내 도구 백엔드로 쓰고 있습니다. 단건 요청은 빠른데 동시 사용자가 10명 넘어가면 첫 토큰까지 지연(TTFT)이 갑자기 몇 초씩 튀어요.
--max-num-seqs 기본값으로 돌리고 있고, 입력 프롬프트가 긴 편(평균 6~8k 토큰)입니다. 처리량(throughput)은 나쁘지 않은데 인터랙티브 응답성이 문제라 원인이랑 튜닝 포인트 좀 짚어주실 분 계실까요.
답변 2개
- 채택된 답변에디터 검증
전형적인 prefill 병목이에요. TTFT는 입력 prefill 시간이 지배하는데, 6~8k 프롬프트가 동시에 여러 개 꽂히면 GPU가 prefill로 포화되면서 신규 요청 첫 토큰이 계속 뒤로 밀립니다. throughput은 멀쩡한데 TTFT만 튀는 게 딱 그 증상이고요.
레버 순서대로:
- chunked prefill — 이게 1번 처방. 긴 prefill을 잘게 쪼개서 decode랑 인터리빙하니까 디코딩 중이던 요청들이 안 굶어요. vLLM 버전에 따라 기본 on/off가 다르니 실제로 켜졌는지 로그로 확인하세요.
- prefix caching — Qwen2.5면 시스템 프롬프트/공통 프리앰블 겹치는 부분 prefill 재사용됩니다. 6~8k 중 공통부가 크면 효과 큼. RAG 컨텍스트가 매번 다르면 효과는 제한적이고요.
--max-num-batched-tokens낮추기 — 배치당 토큰 상한 줄이면 한 스텝이 짧아져서 신규 요청이 끼어들 틈이 생깁니다.--max-num-seqs만 만지지 말고 이쪽도 같이 보세요. throughput이랑 trade-off라 p95 보면서 조정.- 6~8k가 정말 다 필요한지. RAG면 top-k 줄이거나 리랭킹으로 컨텍스트 압축하는 게 제일 직접적입니다.
A100 1장에 14B면 동시성 한계가 분명히 있어요. SLA 빡세면 TTFT p95를 SLO로 박고 거기서 max-num-seqs를 역산하는 식으로 가는 게 현실적입니다. 무작정 동시성 올리면 preemption 터지면서 오히려 더 튀어요.
튜닝 들어가기 전에 메트릭부터 박으세요. vLLM이
/metrics로 prometheus 메트릭 다 뱉습니다 —vllm:time_to_first_token_seconds,time_per_output_token, 그리고num_requests_waiting/num_requests_running. TTFT 튈 때 waiting 큐가 쌓이는지만 봐도 prefill 병목인지 단순 스케줄링인지 1초 만에 갈립니다. 이거 없이 옵션 만지면 그냥 깜깜이 튜닝이에요.그리고 KV 캐시가 빡빡하면 AWQ나 GPTQ로 양자화해서 14B 메모리 줄이고 동시 시퀀스를 더 태우는 것도 방법인데, 양자화는 품질 미묘하게 깎입니다. 본인 평가셋으로 꼭 돌려보고 넣으세요. 한국어 파인튜닝 모델이면 양자화 후 한국어 쪽이 더 흔들리는 경우 봤어요.