Gemma 4는 Google이 공개한 오픈 웨이트 모델 패밀리로, E2B부터 31B까지 5가지 크기에 텍스트와 이미지 입력(E2B, E4B, 12B는 오디오도 지원), 최대 256K 토큰 컨텍스트(E2B, E4B는 128K), 추론(thinking) 모드를 제공합니다. 그중 31B는 밀집(dense) 구조의 최상위 모델로, NVFP4(4비트 부동소수점)로 양자화한 가중치 약 31GiB가 96GB GPU 1개에 올라가는 대신 시작할 때마다 수십 GB를 S3에서 GPU로 옮겨야 합니다. Amazon EKS에 […] ||
Gemma 4는 Google이 공개한 오픈 웨이트 모델 패밀리로, E2B부터 31B까지 5가지 크기에 텍스트와 이미지 입력(E2B, E4B, 12B는 오디오도 지원), 최대 256K 토큰 컨텍스트(E2B, E4B는 128K), 추론(thinking) 모드를 제공합니다. 그중 31B는 밀집(dense) 구조의 최상위 모델로, NVFP4(4비트 부동소수점)로 양자화한 가중치 약 31GiB가 96GB GPU 1개에 올라가는 대신 시작할 때마다 수십 GB를 S3에서 GPU로 옮겨야 합니다.
Amazon EKS에 이 모델을 오픈소스 서빙 엔진 vLLM으로 배포하면, 기본 구성에서는 GPU 노드가 없는 상태에서 시작해서 첫 요청을 처리할 수 있게 되기까지 7분 이상 소요됩니다. 이 시간은 하나의 병목이 아니라 노드 프로비저닝, 이미지 pull, 가중치 로드, 엔진 초기화가 순서대로 쌓인 합계입니다. 이 콜드 스타트(노드 프로비저닝부터 첫 요청 처리까지 걸리는 시간)를 4단계로 나누어 분석하고 단계별 최적화 기술을 하나씩 구현합니다. 그 결과 콜드 스타트는 428초에서 226초(이미지 사전 pull 포함)로 최적화되었고 웜(Warm) 재시작과 유휴 상태에서 서빙으로 복귀하는 시간도 함께 단축됐습니다.
이 글은 2부로 구성됩니다.
1부(현재글): 파드가 Ready가 되기까지의 시작 시간의 최적화
2부: Ready 이후에 같은 GPU 한 장의 처리량과 지연 SLO (양자화 정밀도, speculative decoding, prefix caching, 스케줄러 설정)
1부는 Amazon EKS에서 vLLM과 같은 LLM 서빙 엔진을 운영하는 엔지니어를 위한 글입니다. 시작 시간과 GPU 비용을 줄이기 위해 Gemma 4 서빙에 적용한 vLLM 최적화 구현(로더와 캐시 설정, 매니페스트, sleep mode)을 정리합니다. 개선율과 단계별 수치는 모두 g7e.2xlarge Spot 단일 환경에서 나온 결과값입니다.
1. 서빙 환경
이 글의 모든 수치는 아래 환경으로 구성되었습니다. 기술 적용과 시험은 같은 클러스터, 같은 인스턴스 계열에서 진행되었습니다. 모델은 NVIDIA가 공개한 NVFP4 체크포인트로, 30.7B 파라미터가 모두 4비트라면 약 15GiB이지만 MLP 계층만 NVFP4로 양자화하고 어텐션과 임베딩 계층은 BF16을 유지하는 구성이라 저장소 크기는 32.7GB(약 30.5GiB), vLLM이 로드 시 보고하는 GPU 메모리 기준으로는 31.22GiB입니다.
항목
값
리전, 클러스터
ap-northeast-2, Amazon EKS 1.36, Karpenter v1.14
GPU 노드
g7e.2xlarge Spot (NVIDIA RTX PRO 6000 Blackwell 96GB, GPU 1개). 전 시험 동일 계열, 웜 시험은 동일 노드
서빙
vLLM v0.26.0 (vllm/vllm-openai:v0.26.0, 이미지 8.9GB)
모델
Gemma-4-31B-IT NVFP4 (nvidia/Gemma-4-31B-IT-NVFP4, NVIDIA Model Optimizer로 양자화한 체크포인트), safetensors, 로드 시 31.22GiB. 리전 내 S3 버킷에 사전 스테이징
모델 접근 자격
EKS Pod Identity로 S3 읽기 권한을 파드의 서비스 계정에 연결
시험 도구
파드 conditions와 events로 Kubernete