Amazon EKS에서 vLLM으로 Gemma 4 서빙 최적화하기 [2부: GPU 한 장의 처리량과 지연 SLO]

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 체크포인트를 함께 썼습니다.

표 1. 2부 시험 환경

SLO(Service Level Objective, 서비스 수준 목표)는 지연처럼 사용자가 체감하는 지표에 대해 지키기로 정한 목표값입니다. p99는 요청의 99%가 그 값 안에 들어오는 지연입니다. 평균이 아니라 느린 꼬리를 기준으로 삼는다는 뜻입니다. 이 글의 대화형 SLO는 TTFT p99 500ms와 ITL p99 50ms를 함께 만족하는 조건입니다. TTFT(Time To First Token)는 요청을 보낸 뒤 첫 토큰이 나오기까지의 시간입니다. ITL(Inter-Token Latency)은 이어지는 토큰 사이의 간격입니다. 사용자는 TTFT를 응답이 시작되는 속도로, ITL을 글자가 흐르는 속도로 느낍니다. SLO 하 처리량은 두 조건을 모두 지키는 최대 동시성에서의 처리량을 말합니다.

요청 수는 정밀도 비교에서 동시성마다 100건입니다. 그 뒤 시험에서는 동시성의 6배로 바꿨습니다. 그래서 같은 조건이라도 절대값은 표마다 조금 다릅니다. 각 표 안에서의 비교로 읽어야 합니다.

2. 정밀도 – 최대 처리량과 SLO 처리량은 다른 답을 냅니다

BF16, FP8, NVFP4 세 체크포인트를 같은 설정(max-model-len 8192, gpu-memory-utilization 0.90, prefix caching과 speculative decoding 없음)으로 비교했습니다.

표 2. 정밀도별 출력 처리량과 지연. 동시성마다 요청 100건, 반복 2회 편차 0.5% 미만

최대 처리량(동시성 32)만 보면 NVFP4는 BF16의 1.86배, FP8의 1.20배입니다. 그러나 대화형 SLO를 지키는 조건으로 보면 차이가 훨씬 커집니다. BF16은 동시성 4에서 TTFT p99가 829ms로 SLO를 넘습니다. 그래서 동시성 1(21.4 tok/s)에 머뭅니다. FP8도 동시성 1(37.3 tok/s)에 머뭅니다. 반면 NVFP4는 동시성 4(135.3 tok/s)까지 버팁니다. SLO 하 처리량으로는 BF16 대비 6.3배입니다.

표 3. 대화형 SLO(TTFT p99 500ms, ITL p99 50ms) 하 최대 처리량

그림 1. 정밀도별 최대 처리량과 대화형 SLO 하 처리량. 최대 처리량 차이는 1.9배에 그치지만 SLO를 지키는 조건에서는 6.3배로 벌어집니다.

동시성 1에서는 NVFP4와 FP8이 사실상 같습니다. 이 구간이 메모리 대역폭 병목이기 때문입니다. 가중치 크기가 2% 차이라 처리량도 그만큼만 벌어집니다. 동시성 32에서는 병목이 연산으로 옮겨갑니다. FP4 텐서코어가 일하면서 1.20배 차이가 납니다. 1부가 NVFP4 체크포인트를 쓴 이유는 크기보다 이 SLO 하 처리량에 있습니다.

3. speculative decoding – 처리량의 기법이지 지연의 기법이 아닙니다

Gemma 4의 MTP(Multi-Token Prediction) draft 모델 google/gemma-4-31B-it-assistant를 --speculative-config에 num_speculative_tokens 4로 붙여 비교했습니다. 이 draft는 vLLM v0.26.0 stable에서 동작했습니다. nightly 빌드는 필요하지 않았습니다.

표 4. MTP n=4 적용 전후의 출력 처리량과 ITL p99. NVFP4, random 데이터셋

처리량은 전 구간에서 올라갑니다. 동시성 1에서 2.13배, 동시성 32에서 1.46배입니다. 그러나 ITL p99는 크게 나빠집니다. 동시성 4에서 27.0ms가 112.4ms로, 동시성 8에서 29.3ms가 184.6ms로 늘어납니다. draft 검증 단계에서 토큰이 뭉쳐 나와 간격이 불균등해지기 때문입니다. 대화형 SLO 하 최대 처리량은 speculative decoding 없이 동시성 4에서 134.6 tok/s입니다. MTP n=4로는 동시성 1에서 81.0 tok/s입니다. 처리량과 지연 중 무엇을 사는지가 갈립니다. 그래서 대화형 트래픽과 배치성 트래픽은 풀을 나누는 것이 맞습니다.

4. prefix caching – 공유 프리픽스가 있으면 켜는 것이 기본입니다

프롬프트의 90%가 공통 프리픽스인 조건(prefix_repetition 데이터셋)에서 동시성 8로 on과 off를 비교했습니다. off는 180.4 tok/s에 TTFT p99 2,856ms입니다. on은 253.5 tok/s에 1,353ms입니다. 처리량 40.5% 상승과 TTFT 2.1배 단축입니다. 고정 시스템 프롬프트가 큰 워크로드일수록 효과가 커집니다. 한 가지만 유의하면 됩니다. 캐시도 KV 메모리를 쓰므로 고부하에서 축출이 시작되면 적중률이 떨어집니다.

5. max-num-seqs와 gpu-memory-utilization

--max-num-seqs는 튜닝 값이 아니라 상한선입니다. 실제 동시성보다 작으면 그 값에서 처리량이 잘립니다. 실제 동시성 이상으로 키우면 그 위로는 아무 차이가 없습니다. 동시성 32에서 max-num-seqs 16은 367.4 tok/s, 32와 64와 128은 모두 518 tok/s였습니다. 동시성 64에서는 32가 520.4, 64와 128이 671 tok/s였습니다. 피크 동시성 이상으로만 두면 됩니다.

--gpu-memory-utilization은 KV 캐시 용량만 바꿉니다. 0.85, 0.90, 0.95에서 KV 토큰은 114,240, 125,537, 136,833으로 늘어납니다. 하지만 동시성 32 처리량은 셋 다 518.1 tok/s로 같습니다. 1부에서 sleep mode 때문에 0.85로 둔 설정은 이 측정 범위에서는 처리량 손실이 없습니다. 여유 용량이 의미를 갖는 것은 긴 컨텍스트, 더 높은 동시성, prefix cache가 축출되기 시작하는 고부하 구간입니다. 그 경우는 텍스트 전용 풀 부분에서 다룹니다.

6. 텍스트 전용 풀에서는 image encoder를 끄고 KV 캐시를 넓힙니다

Gemma 4는 이미지 입력을 받는 모델입니다. 그래서 vLLM이 vision encoder용 메모리를 미리 예약합니다. 텍스트만 처리하는 서버라면 --limit-mm-per-prompt '{"image":0}'으로 이 예약을 풀 수 있습니다. gpu-memory-utilization을 0.90에서 0.95로 올려 그 공간을 KV 캐시로 돌립니다. 운영 토큰 분포를 재현한 혼합 트래픽(max-model-len 131072, prefix caching, MTP n=4)에서 이 두 설정으로 KV 토큰 용량이 566K에서 637K로 12.6% 늘었습니다. 캐시 축출이 일어나는 동시성 256에서는 처리량이 3%, 캐시 적중률이 1%포인트 올랐습니다. 설정 두 줄로 얻는 개선입니다. 단, 이미지 요청은 별도 풀로 분리한다는 전제가 필요합니다.

플래그 형식은 vLLM 버전에 따라 다릅니다. v0.26.0에서는 --limit-mm-per-prompt가 JSON 형식입니다. --disable-log-requests는 제거되었고 async scheduling은 기본으로 켜져 있습니다. 공개 레시피를 그대로 복사하면 이 지점에서 서버가 뜨지 않을 수 있습니다. 사용하는 버전의 vllm serve --help 출력과 대조해야 합니다.

7. priority 스케줄링으로 배치성 요청을 뒤로 보냅니다

vLLM은 기본이 선착순입니다. 출력이 긴 배치성 요청이 앞에 서면 빠른 응답이 필요한 요청이 밀립니다. --scheduling-policy priority를 켜고 라우터가 지연에 둔감한 요청에만 낮은 우선순위 값을 붙였습니다. 포화의 81% 부하에서 후순위로 밀려난 요청의 e2e(end-to-end) p99는 1% 늘어났습니다. 대화형 요청은 영향이 없었습니다. 가장 느리던 워크로드의 e2e p99는 15.1초에서 11.5초로 24% 줄었습니다. 서버 플래그 하나와 요청의 priority 필드 하나로 적용됩니다. async scheduling과도 함께 쓸 수 있습니다.

8. 워크로드별 캐시 적중률이 GPU당 처리량을 정합니다

같은 서버 구성이라도 워크로드마다 GPU당 처리량은 크게 다릅니다. 고정 시스템 프롬프트 비중이 큰 워크로드는 prefix cache 적중률이 높아 prefill을 거의 하지 않습니다. 가변 본문이 긴 워크로드는 적중률이 낮아 prefill 연산이 병목이 됩니다. 운영 토큰 분포를 재현한 워크로드를 하나씩 동시성 32로 돌렸습니다. 입력 길이가 비슷한데도 적중률 96%와 40% 사이에서 처리량이 10배 차이가 났습니다.

표 5. 캐시 적중률에 따른 GPU당 처리량. NVFP4 + MTP n=4 + prefix caching, 워크로드 단독 실행, 동시성 32

그림 2. 캐시 적중률에 따른 GPU당 처리량. 입력 길이가 비슷한 두 워크로드(2,863 토큰과 2,923 토큰)도 적중률 96%와 40%에서 처리량이 10배 차이가 납니다.

적중률이 낮은 워크로드는 서버 플래그로는 풀리지 않습니다. 방법은 2가지입니다. 프롬프트에서 고정부를 앞으로, 가변부를 최소로 유지하는 구조 개선, 또는 그 워크로드만의 풀 분리입니다. 적중률이 40%에서 80%가 되면 GPU당 처리량은 배 단위로 변합니다. GPU 대수를 산정할 때는 평균이 아니라 가장 느린 워크로드가 전체 규모를 정한다는 점을 감안해야 합니다.

9. 서빙 풀 구성 의사결정표

측정 결과를 서빙 풀 구성으로 옮기면 아래 표와 같습니다. 핵심은 대화형 트래픽과 배치성 트래픽에 같은 설정을 쓰지 않는 것입니다.

표 6. 트래픽 특성별 서빙 풀 권고 설정

그림 3. 트래픽 특성별 서빙 풀 분리. 라우터가 요청을 대화형 풀과 배치 풀로 나누고, 배치 풀에는 MTP n=4와 낮은 priority를 적용합니다. 텍스트 전용 풀은 image encoder 예약을 풀어 KV 캐시를 넓힙니다.

마치며

Amazon EKS의 GPU 노드 한 장에서 Gemma 4 31B를 vLLM으로 서빙할 때 처리량과 지연을 함께 최적화하려는 분들께 이 글의 결론은 3가지입니다.

• 정밀도: 최대 처리량이 아니라 SLO 하 처리량으로 골라야 합니다. NVFP4는 BF16 대비 최대 처리량 1.9배, SLO 하 처리량 6.3배입니다. 정확도 차이는 측정 오차 안입니다.
• speculative decoding과 priority 스케줄링: 배치성 트래픽의 기술입니다. MTP n=4는 처리량을 최대 2.13배 올리지만 ITL p99를 4배 이상 늘립니다. 그래서 대화형 풀과 배치 풀을 나눠야 합니다.
• prefix cache 적중률: GPU당 처리량은 서버 플래그보다 적중률이 정합니다. 적중률 96%와 40% 사이의 처리량 차이가 10배입니다. 프롬프트 구조와 풀 분리가 GPU 대수를 좌우합니다.

1부의 시작 시간 최적화와 2부의 처리량, 지연 최적화는 같은 원칙으로 진행했습니다. 한 번에 하나만 변경하고 같은 환경에서 다시 측정합니다. 분석과 시험이 없이 넣은 설정은 효과를 주장하지 않았습니다. vLLM으로 대형 모델을 서빙하는 팀이 GPU 한 장의 처리량과 지연 SLO를 함께 설계하는 데 이 글의 측정 기록이 실질적인 참고가 되기를 바랍니다.

참고 자료

• Amazon EC2 G7e instances – 인스턴스 사양(g7e.2xlarge GPU 1개, 96GB)
• nvidia/Gemma-4-31B-IT-NVFP4 – Hugging Face. 시험에 사용한 NVFP4 체크포인트
• google/gemma-4-31B-it – Hugging Face. BF16 원본 체크포인트
• RedHatAI/gemma-4-31B-it-FP8-dynamic – Hugging Face. FP8 비교용 체크포인트
• google/gemma-4-31B-it-assistant – Hugging Face. Gemma 4 MTP draft 모델
• Google/gemma-4-31B-it – vLLM Recipes. 정밀도 변형과 speculative decoding 설정 안내