CNCF: Goodput 지표, 처리량 최적화된 LLM 서빙의 p95 지연이 거의 10배 나쁘다는 사실 드러내

goodput이란 무엇이며 왜 처리량과 다른가?

goodput은 미리 정해진 목표 지연 시간을 충족하며 완료된 초당 요청 수를 측정하는 반면, 처리량은 충분히 빠른지와 무관하게 처리된 모든 요청을 집계합니다. Akamas 엔지니어 Graziano Casto는 CNCF 블로그에서 처리량이 높다고 해서 반드시 더 나은 서비스를 의미하지는 않는다는 점을 보여줍니다. 어떤 구성은 전체적으로 더 많은 요청을 처리할 수 있지만, 그중 일부는 최종 사용자에게 받아들이기 어려울 만큼 긴 지연 시간을 동반할 수 있습니다.

벤치마크: 처리량 50% 향상, 지연 시간은 거의 10배 악화

EKS(Amazon Elastic Kubernetes Service) 클러스터 내 NVIDIA A10G GPU 한 대에서 vLLM 서빙 엔진과 GuideLLM 부하 시뮬레이션 도구를 사용해 Qwen2.5-7B 모델로 테스트한 결과, 총 처리량이 50% 더 높은 구성은 p95 time-per-output-token—95%의 요청이 속하는 지연 시간—이 약 50밀리초에서 약 494밀리초로 거의 10배 악화되는 것으로 나타났습니다. 테스트는 세 가지 워크로드 유형을 다루었습니다. TTFT(time-to-first-token, 첫 토큰까지의 시간)에 엄격한 요구 사항을 가진 챗봇, 약 4,000개 토큰을 출력하는 reasoning, 그리고 짧은 연쇄 호출을 특징으로 하는 agentic입니다.

권장 사항: 매개변수 자동 탐색

Casto는 서빙 구성을 원시 처리량이 아닌 goodput에 직접 맞춰 최적화하기 위해, gpu_memory_utilization, max_num_batched_tokens, max_num_seqs 같은 매개변수에 대한 자동화된 탐색을 권장합니다. 챗봇, reasoning, agentic 시나리오는 각기 다른 목표 지연 시간과 허용 범위를 가지므로, 이 접근 방식은 워크로드 유형별로 개별 테스트가 필요하며 하나의 만능 구성으로는 모든 경우를 동등하게 다룰 수 없습니다.

모델과 GPU 조합마다 매개변수 조합을 수동으로 탐색하는 것은 가능한 설정의 수가 방대하여 현실적이지 않습니다. 그래서 Casto는 구성을 체계적으로 테스트하고 목표 워크로드 유형에 가장 적합한 goodput을 보이는 구성을 선택하는 자동화된 프로세스를 주장합니다. 프로덕션 환경에서 LLM을 서빙하는 팀은 이를 통해 처리량만을 최적화하는 함정—벤치마크에서 최종 사용자의 p95 지연 시간을 거의 10배 악화시킨 그 함정—을 피할 수 있는 구체적인 방법을 얻게 됩니다.