1부에서는 Amazon EKS의 GPU 노드에서 Gemma 4 31B를 vLLM으로 서빙할 때의 콜드 스타트를 다뤘습니다. 파드가 Ready가 되기까지의 시간을 428초에서 226초로 줄인 과정입니다. 스트리밍 로더로 가중치를 S3에서 직접 읽고 컴파일 캐시를 hostPath와 S3에 남기고 유휴 상태는 sleep/wake로 전환하는 구성이었습니다. 모델은 NVIDIA가 공개한 NVFP4 체크포인트 nvidia/Gemma-4-31B-IT-NVFP4입니다. 가중치 약 31GiB가 g7e.2xlarge의 96GB GPU 1개에 올라갑니다. 2부는 Ready 이후입니다. […] ||
1부에서는 Amazon EKS의 GPU 노드에서 Gemma 4 31B를 vLLM으로 서빙할 때의 콜드 스타트를 다뤘습니다. 파드가 Ready가 되기까지의 시간을 428초에서 226초로 줄인 과정입니다. 스트리밍 로더로 가중치를 S3에서 직접 읽고 컴파일 캐시를 hostPath와 S3에 남기고 유휴 상태는 sleep/wake로 전환하는 구성이었습니다. 모델은 NVIDIA가 공개한 NVFP4 체크포인트 nvidia/Gemma-4-31B-IT-NVFP4입니다. 가중치 약 31GiB가 g7e.2xlarge의 96GB GPU 1개에 올라갑니다.
2부는 Ready 이후입니다. 같은 GPU 한 장이 요청을 얼마나 처리할까요? 양자화 정밀도, speculative decoding, prefix caching, 스케줄러 파라미터를 하나씩 바꾸며 처리량과 지연을 측정했습니다. 원칙은 1부와 같습니다. 한 번에 하나만 변경하고 같은 환경에서 다시 측정합니다. 결과를 요약하면 3가지입니다.
NVFP4 체크포인트는 최대 처리량으로는 BF16의 1.9배지만 대화형 SLO(Service Level Objective, 서비스 수준 목표) 안에서는 6.3배입니다.
speculative decoding은 처리량을 최대 2.1배 올리는 대신 토큰 간 지연을 나쁘게 합니다.
같은 서버 구성이라도 prefix cache 적중률에 따라 GPU당 처리량이 10배 차이가 납니다.
이 글은 vLLM으로 LLM을 서빙하면서 GPU 한 장당 처리량과 지연 SLO를 함께 맞추려는 엔지니어를 위한 글입니다. 설정별 측정 결과와 그에 따른 서빙 풀 구성 원칙을 정리합니다. 수치는 모두 g7e.2xlarge 단일 GPU에서 나온 결과값입니다.
1. 시험 환경과 SLO 정의
측정은 1부와 별도 클러스터(us-west-2)의 g7e.2xlarge에서 진행했습니다. vLLM v0.26.0과 NVFP4 체크포인트는 1부와 같습니다. 정밀도 비교에는 BF16 원본과 FP8 체크포인트를 함께 썼습니다.
항목
값
GPU 노드
g7e.2xlarge (NVIDIA RTX PRO 6000 Blackwell 96GB, GPU 1개), us-west-2
서빙
vLLM v0.26.0
모델
nvidia/Gemma-4-31B-IT-NVFP4. 정밀도 비교에 google/gemma-4-31B-it(BF16), RedHatAI/gemma-4-31B-it-FP8-dynamic(FP8)
부하 도구
vllm bench serve
데이터셋
정밀도, speculative decoding, 스케줄러 파라미터: random(입력 1,024, 출력 128 토큰), 동시성 1, 4, 8, 32(스케줄러 파라미터는 64 포함). prefix caching: prefix_repetition(공통 프리픽스 90%), 동시성 8. 텍스트 전용 풀, priority, 적중률: 운영 토큰 분포(입력 평균 약 2K 토큰, 출력 수십 토큰의 혼합 트래픽) 재현
반복 편차
같은 조건 반복 측정 최대 1.2%
지표
출력 처리량(tok/s), TTFT(첫 토큰까지의 시간), ITL(토큰 사이 간격)
대화형 SLO
TTFT p99 500ms와 ITL p99 50ms를 함께 만족
표 1. 2부 시험 환경
SLO(Service Level Objective, 서비스 수