Gemma 4 12B 완전분석 2편: vLLM / SGLang / Ollama 서빙 실전 세팅

Gemma 4 12B를 로컬 또는 서버에서 직접 서빙하려면 엔진 선택이 먼저입니다. vLLM, SGLang, Ollama는 모두 OpenAI 호환 API를 제공하지만, 내부 구조와 강점이 완전히 다릅니다. 어떤 엔진을 선택하느냐에 따라 처리량, 메모리 효율, 에이전트 워크플로우 성능이 크게 달라집니다. 이 글에서는 세 엔진을 실제 실행 명령어 기준으로 비교하고, 상황별로 어떤 선택이 맞는지 정리합니다.

엔진 선택 기준 먼저

작업 성격에 따라 엔진이 달라집니다. 멀티유저 환경이나 동시 요청 처리가 필요한 프로덕션 서버에는 vLLM이 표준입니다. 에이전트 루프나 긴 시스템 프롬프트가 반복되는 워크플로우라면 SGLang의 RadixAttention이 압도적으로 유리합니다. 단독 개발 환경에서 빠르게 프로토타이핑하려면 Ollama가 가장 빠른 선택입니다.

상황 선택

멀티유저, 동시 요청 처리, 프로덕션	vLLM
에이전트 루프, 긴 시스템 프롬프트 반복, prefix 재사용	SGLang
단독 개발 환경, 빠른 프로토타이핑	Ollama
멀티모달(이미지·오디오) 배치 파이프라인	vLLM
Function calling + Thinking mode 실험	SGLang

---

VRAM 예산 계산

엔진과 무관하게, 어떤 서빙 방식을 선택하든 모델 웨이트와 KV 캐시, 런타임 오버헤드를 합산해서 VRAM 예산을 잡아야 합니다. 정밀도에 따라 필요한 VRAM이 크게 달라지므로 아래 표를 기준으로 하드웨어를 먼저 확인하세요.

정밀도 웨이트 크기 권장 VRAM 비고

BF16	~26.7GB	40GB+	A100 40GB, H100
SFP8	~13.4GB	24GB	RTX 4090, A10G
Q4_0	~6.7GB	16GB	RTX 4060 Ti 16GB, RTX 3090

KV 캐시는 컨텍스트 길이에 비례해서 커집니다. 256K 풀 컨텍스트를 쓰려면 24GB 이상이 필요하며, --max-model-len 8192로 먼저 안정성을 확인하고 점진적으로 늘려가는 것을 권장합니다.

---

방법 1. vLLM — 프로덕션 멀티유저 서빙 표준

vLLM의 핵심은 PagedAttention입니다. 요청이 여러 개 들어올 때 KV 캐시를 페이지 단위로 분할해 메모리 낭비 없이 배치 처리합니다. 단일 개발자 환경에서도 멀티모달 배치 파이프라인이 필요하다면 vLLM이 가장 적합한 선택입니다.

설치는 pip 한 줄로 끝납니다.

pip install vllm

설치 후 기본 텍스트 전용 서버를 실행합니다. --max-model-len으로 컨텍스트 길이를 제한하고, --gpu-memory-utilization로 VRAM 사용률을 조정합니다.

vllm serve google/gemma-4-12b-it \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92

이미지와 오디오를 함께 처리하는 멀티모달 서버는 --mm-processor-kwargs를 추가합니다. max_soft_tokens는 이미지당 할당하는 비전 토큰 예산으로, 70 / 140 / 280 / 560 / 1120 중 선택합니다. 값이 높을수록 해상도가 올라가지만 VRAM 소비도 함께 증가합니다.

vllm serve google/gemma-4-12b-it \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --mm-processor-kwargs '{"max_soft_tokens": 280}'

오디오는 쓰지 않고 이미지만 사용하거나, 텍스트 전용으로 멀티모달 프로파일링을 완전히 스킵하고 싶을 때는 --limit-mm-per-prompt 플래그로 메모리를 절약할 수 있습니다.

# 이미지만 쓰고 오디오는 안 쓸 때
--limit-mm-per-prompt '{"audio": 0}'

# 텍스트 전용 — 멀티모달 프로파일링 스킵
--limit-mm-per-prompt '{"image": 0, "audio": 0}'

# 요청당 이미지 4개, 비디오 1개로 제한
--limit-mm-per-prompt 'image=4,video=1'

처리량을 더 끌어올리려면 비동기 스케줄링 플래그를 추가합니다. 동시 요청이 많은 환경에서 효과가 두드러집니다.

vllm serve google/gemma-4-12b-it \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --async-scheduling

Python 클라이언트는 OpenAI SDK를 그대로 사용합니다. 아래는 이미지를 base64로 인코딩해 함께 전송하는 예시입니다. 서버 주소만 localhost:8000으로 바꿔주면 기존 OpenAI 코드가 그대로 동작합니다.

import base64
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

with open("diagram.png", "rb") as f:
    img_b64 = base64.b64encode(f.read()).decode()

response = client.chat.completions.create(
    model="google/gemma-4-12b-it",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "이 아키텍처 다이어그램에서 문제점 찾아줘"},
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{img_b64}"}}
        ]
    }],
    temperature=1.0,
    top_p=0.95,
    max_tokens=1024,
)
print(response.choices[0].message.content)

Docker로 실행하고 싶다면 공식 이미지를 사용합니다. CUDA 12.9 기준이며, 모델 경로와 파라미터는 동일하게 적용됩니다.

docker pull vllm/vllm-openai:latest

docker run --gpus all \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model google/gemma-4-12b-it \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92

---

방법 2. SGLang — RadixAttention, 에이전트 워크플로우 특화

SGLang의 핵심은 RadixAttention입니다. 시스템 프롬프트나 공통 컨텍스트처럼 반복되는 prefix를 트리 구조로 캐싱해, 같은 prefix를 가진 요청이 들어올 때 prefill 연산을 통째로 스킵합니다. 에이전트 루프처럼 긴 시스템 프롬프트가 매 턴 반복되는 구조에서 vLLM 대비 처리량이 유의미하게 올라갑니다.

설치는 pip으로 진행합니다.

pip install "sglang[all]"

기본 서버 실행입니다. vLLM과 달리 --max-total-tokens로 전체 토큰 예산을 지정합니다.

python -m sglang.launch_server \
  --model-path google/gemma-4-12b-it \
  --host 0.0.0.0 \
  --port 30000 \
  --max-total-tokens 32768

Gemma 4의 Thinking mode와 Function calling을 사용하려면 파서 옵션을 반드시 추가해야 합니다. --reasoning-parser gemma4를 붙이지 않으면 Gemma 4의 추론 토큰 구분자가 파싱되지 않아 thinking 내용이 응답 텍스트에 그대로 섞입니다.

python -m sglang.launch_server \
  --model-path google/gemma-4-12b-it \
  --host 0.0.0.0 \
  --port 30000 \
  --max-total-tokens 32768 \
  --reasoning-parser gemma4 \
  --tool-call-parser gemma4

MTP(Multi-Token Prediction)를 활용한 speculative decoding은 품질 손실 없이 생성 속도를 1.5~2배 높여줍니다. draft 모델로 gemma-4-12b-assistant를 사용하며, HuggingFace에서 별도 다운로드가 필요합니다.

python -m sglang.launch_server \
  --model-path google/gemma-4-12b-it \
  --speculative-algorithm NEXTN \
  --speculative-draft-model-path google/gemma-4-12b-assistant \
  --host 0.0.0.0 \
  --port 30000 \
  --reasoning-parser gemma4 \
  --tool-call-parser gemma4

Python 클라이언트는 vLLM과 동일하게 OpenAI SDK를 사용합니다. 포트만 30000으로 바꾸면 됩니다.

from openai import OpenAI

client = OpenAI(api_key="EMPTY", base_url="http://localhost:30000/v1")

response = client.chat.completions.create(
    model="google/gemma-4-12b-it",
    messages=[
        {"role": "system", "content": "당신은 시니어 백엔드 엔지니어입니다."},
        {"role": "user", "content": "FastAPI + PostgreSQL 연결 풀 설정 코드 짜줘"}
    ],
    temperature=1.0,
    top_p=0.95,
    max_tokens=2048,
)
print(response.choices[0].message.content)

vLLM과 SGLang 중 어떤 것을 선택할지는 워크플로우 성격으로 결정합니다. 멀티모달 배치 파이프라인이 필요하거나 Docker 공식 이미지를 써야 한다면 vLLM이 낫고, 에이전트 루프나 Function calling, Thinking mode를 중심으로 사용한다면 SGLang이 더 효율적입니다.

항목 vLLM SGLang

멀티유저 배치 처리	PagedAttention	지원
Prefix 재사용 캐싱	부분적	RadixAttention
Thinking mode 파싱	별도 설정 필요	--reasoning-parser gemma4
Function calling 파싱	별도 설정 필요	--tool-call-parser gemma4
멀티모달 메모리 제어	--limit-mm-per-prompt	제한적
Docker 공식 이미지	제공	직접 빌드
에이전트 루프 효율	보통	높음

---

방법 3. Ollama — 단일 개발 환경, 즉시 시작

프로토타이핑이나 로컬 단독 개발에는 Ollama가 가장 빠릅니다. 설치 한 줄, 실행 한 줄로 OpenAI 호환 API가 자동으로 열리기 때문에, 서버 설정에 시간을 쓰고 싶지 않을 때 최선의 선택입니다.

설치와 실행은 아래 순서로 진행합니다.

# 설치
curl -fsSL https://ollama.com/install.sh | sh

# 실행 (자동으로 Q4 선택)
ollama run gemma4:12b

# 서버만 백그라운드로
ollama serve

Ollama는 기본 컨텍스트 윈도우가 4096으로 설정되는 경우가 있습니다. 큰 코드베이스나 긴 문서 작업을 하기 전에 Modelfile로 파라미터를 고정해두지 않으면, 긴 입력이 조용히 잘려나갈 수 있습니다. 반드시 아래 Modelfile을 만들어 두세요.

# Modelfile
FROM gemma4:12b

PARAMETER num_ctx 32768
PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64

Modelfile을 저장한 뒤 커스텀 모델로 등록하고 실행합니다.

ollama create gemma4-12b-dev -f Modelfile
ollama run gemma4-12b-dev

OpenAI SDK 연결은 base_url만 localhost:11434로 바꾸면 됩니다. 기존 코드 수정 없이 그대로 붙일 수 있습니다.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",
)

response = client.chat.completions.create(
    model="gemma4-12b-dev",
    messages=[
        {"role": "system", "content": "한국어로 답변하는 코딩 어시스턴트"},
        {"role": "user", "content": "Redis pub/sub 패턴 Python 예제 짜줘"}
    ],
)
print(response.choices[0].message.content)

---

세 엔진 최종 비교

세 엔진은 모두 OpenAI 호환 API를 제공하기 때문에 클라이언트 코드는 동일하게 재사용할 수 있습니다. 차이는 내부 구조와 최적화 방식에 있습니다. vLLM은 멀티유저 처리량과 멀티모달 제어에서 강점을 보이고, SGLang은 에이전트 루프와 Thinking mode 파싱에서 독보적입니다. Ollama는 프로덕션에는 적합하지 않지만, 로컬 개발 환경에서 가장 빠르게 시작할 수 있다는 점에서 여전히 유용합니다.

항목 vLLM SGLang Ollama

설치 난이도	보통	보통	쉬움
멀티유저 처리량	최고	높음	단일 세션
Prefix 캐싱	부분	RadixAttention	미지원
MTP speculative	미지원	NEXTN	미지원
Thinking mode 파싱	수동	네이티브	미지원
멀티모달 제어	세밀	제한적	projector 자동
Docker 공식 지원	제공	직접 빌드	제공
프로토타이핑 속도	보통	보통	가장 빠름
프로덕션 적합성	적합	적합	부적합

결론은 단순합니다. 프로덕션 멀티유저 서버라면 vLLM, 에이전트·함수 호출 중심이라면 SGLang, 로컬 개발과 프로토타입이라면 Ollama입니다. 세 엔진 모두 OpenAI 호환 API를 사용하므로, 나중에 엔진을 교체해도 클라이언트 코드를 수정할 필요가 없다는 것도 장점입니다.

 

관련 글

• Gemma 4 12B 완전분석 1편 — 아키텍처·벤치마크·E4B 비교
• Gemma 4 12B 완전분석 2편 — vLLM / SGLang / Ollama 서빙 가이드
• Gemma 4 12B 완전분석 3편 — Unsloth 파인튜닝 실전