서빙 구조가 LLM 처리량을 바꾸는 방식

Ray Serve·Triton·KServe를 비교하며 엔진 설정과 서빙 구조가 처리량에 미치는 영향을 분리해 측정

<aside> 🎯

핵심 결과

Ray Serve 구성에서는 엔진 설정을 바꿔도 처리량 증가가 제한적이었지만, vLLM 단독 구성에서는 같은 설정 변경의 효과가 크게 나타났습니다.
이번 환경에서는 vLLM 단독 ≈ KServe RawDeployment > Triton >> Ray Serve 순으로 처리량이 측정됐습니다.
따라서 엔진 설정만 조정하기보다 서빙 구조와 요청 경로를 함께 점검한 뒤 엔진을 최적화해야 합니다. </aside>

1. 무엇을 확인하려 했나

LLM 서빙의 처리량을 높일 때는 보통 엔진 설정부터 조정합니다. vLLM은 max_num_seqs, max_model_len, gpu_memory_utilization 같은 설정을 제공하며, 값을 바꿔가며 비교하기도 쉽습니다.

지난 실험에서는 max_num_seqs(동시에 처리할 요청 슬롯 수)를 1에서 64로 늘렸을 때 처리량이 23배 증가했습니다. 이 결과만 보면 다음 최적화도 엔진 설정에 집중하기 쉽습니다.

실제 쿠버네티스 환경에서는 vLLM 앞에 배포·헬스체크·라우팅·스케일링을 담당하는 서빙 구조가 추가됩니다. 이 글에서는 Ray Serve, Triton Inference Server, KServe를 비교했습니다.

그래서 이번에는 엔진 설정과 서빙 구조의 영향을 분리해 비교했습니다.

구분	비교 대상	설정·도구
설정	vLLM 엔진 설정	`max_num_seqs`, `max_model_len`, `gpu_memory_utilization`
구조	배포와 요청 처리를 담당하는 서빙 구조	vLLM 단독 / Ray Serve / Triton / KServe

3주차에는 Ray Serve 위에서 vLLM을 실행했습니다. 이 구성에서 max_num_seqs를 16에서 64로 늘렸습니다.

구성	c=64 처리량	TTFT p95	goodput
Ray Serve, 슬롯 16	821.6 tok/s	3.777s	16%
Ray Serve, 슬롯 64	852.3 tok/s	4.006s	19%
차이	+3.7%	—	—

지난 실험에서 큰 차이를 만들었던 설정이 이번에는 처리량을 3.7% 높이는 데 그쳤습니다.

다른 엔진 설정도 확인했습니다. max_num_seqs=64를 유지한 채 컨텍스트 길이와 GPU 메모리 사용 비율을 바꿨습니다. 두 값은 KV Cache 예산에 직접 영향을 주므로 추정 동시성도 크게 달라졌습니다.

추정 동시성은 14.28x에서 64.02x까지 4.5배 달라졌지만, 처리량은 822~964 tok/s 범위에 머물렀습니다.

Maximum concurrency는 실제 동시 사용자 수가 아닙니다. 모든 요청이 최대 컨텍스트를 사용한다고 가정한 추정치입니다. 이번 부하는 짧은 프롬프트를 사용했으므로 이 상한에 도달하지 않았습니다.