저는 둘 다 매일 씁니다. Ollama는 제 노트북과 사무실 GPU 워크스테이션에서 개발용으로, 그리고 제가 쓰는 도구용으로 돌아갑니다. vLLM은 프리랜스 프로젝트에서 96 GB GPU 한 장으로 채팅 모델을 서빙하는데, 처음엔 Docker Compose로 띄웠고 지금은 작은 Kubernetes 클러스터에서 돌립니다. 이 글에서는 각각 무엇을 잘하는지, 어떻게 설치하는지, 그리고 vLLM 쪽에서 시간을 잡아먹은 것들을 다룹니다.

vLLM vs Ollama 한눈에 비교

#

Ollama란?

#

Ollama는 제가 아는 한 내 기계에서 모델이 답하게 만드는 가장 쉬운 방법입니다. llama.cpp에서 출발했고 양자화된 GGUF 모델을 돌리는데, 그래서 8B 모델이 5 GB 정도에 들어가고 MacBook에서도 무리 없이 돌아갑니다. 모델을 이름으로 받아 두면 처음 호출할 때 로드되고, 5분 동안 할 일이 없으면 메모리에서 내려갑니다. 덕분에 같은 기계에서 돌고 있는 다른 것들과 얌전하게 자원을 나눠 씁니다.

그 얌전함이 곧 트레이드오프입니다. Ollama는 한 번에 한 사람이 쓰는 걸 전제로 만들어졌습니다. 몇 개의 요청에 병렬로 답할 수는 있지만 병렬 슬롯마다 메모리가 들고, 수십 명의 사용자를 GPU 한 장에 배치로 몰아넣으라고 만든 물건은 애초에 아닙니다.

vLLM이란?

#

vLLM은 서빙 엔진이고, 바로 그 배칭을 위해 만들어졌습니다. 핵심 아이디어는 두 가지입니다. PagedAttention은 요청마다의 KV 캐시(모델이 토큰을 읽고 쓰면서 쌓아 가는 어텐션 상태)를 작은 고정 크기 블록에 나눠 저장해서, GPU 메모리가 패딩과 단편화로 버려지지 않게 합니다. 연속 배칭은 새 요청이 지금 배치가 끝나기를 기다리지 않고 생성 단계 사이사이에 배치에 끼어들게 해 줍니다. 이 둘 덕분에 vLLM을 돌리는 GPU 한 장은, 같은 GPU가 요청을 하나씩 처리할 때보다 훨씬 많은 동시 사용자를 감당합니다.

대가는 vLLM이 카드를 자기 것처럼 쓴다는 점입니다. 시작할 때 GPU 메모리에서 자기 몫을 차지하고, 가중치가 쓰고 남은 공간은 KV 캐시로 채우고, 호출하는 사람이 있든 없든 그 전부를 쥐고 있습니다. 모델도 Ollama가 쓰는 GGUF 파일이 아니라 Hugging Face 원본 가중치나 FP8 같은 GPU 친화적인 양자화를 원합니다.

API는 하나, 서버는 둘

#

둘 다 OpenAI chat completions API를 제공하기 때문에, 제 코드는 자기가 어느 쪽과 이야기하고 있는지 모릅니다. URL과 모델 이름은 환경 변수에서 가져옵니다.

import os
from openai import OpenAI

# 노트북:   LLM_URL=http://localhost:11434/v1  LLM_MODEL=qwen3:8b
# GPU 서버: LLM_URL=http://localhost:8000/v1   LLM_MODEL=qwen3-8b
client = OpenAI(base_url=os.environ["LLM_URL"], api_key="not-needed")

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Say hello in Korean."}],
)
print(reply.choices[0].message.content)

큰 GPU가 없는 제 노트북에서는 앱이 Ollama를 가리킵니다. 서버에서는 vLLM을 가리킵니다. 그 밖에는 아무것도 바뀌지 않고, GPU 머신을 아예 켜지 않고도 앱을 개발할 수 있습니다. vLLM 쪽에서는 --served-model-name으로 모델에 짧은 이름을 붙여 두면, 클라이언트가 Hugging Face 전체 경로를 보낼 필요가 없습니다.

잊기 쉬운 거라 하나 짚어 두겠습니다. 같은 모델이라도 두 서버에서 같은 답을 내지는 않습니다. Ollama의 qwen3:8b는 4비트 양자화본이고, vLLM에서는 보통 16비트나 FP8 가중치를 돌립니다. 한쪽에 맞춰 다듬은 프롬프트가 다른 쪽에서는 다르게 동작할 수 있으니, 답변 품질이든 거절이든 JSON이 제대로 파싱되는지든, 측정하는 게 무엇이든 프로덕션이 실제로 쓸 서버에서 확인해야 합니다.

Ollama 설치 방법

#

Mac이나 Windows에서는 ollama.com에서 앱을 내려받으면 됩니다. Linux에서는 이렇게 합니다.

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

이게 전부입니다. 이제 API는 http://localhost:11434에 떠 있고, OLLAMA_HOST를 설정하지 않는 한 localhost에서만 듣습니다. 바라던 그대로죠. 제 것은 사무실 워크스테이션에서 127.0.0.1에 바인딩해 두고, 어디서든 터널로 접속합니다(Cloudflare WARP로 이걸 구성한 방법).

vLLM 설치 방법

#

NVIDIA GPU와 최신 드라이버를 갖춘 Linux에서는 이렇게 합니다.

python -m venv .venv && source .venv/bin/activate
pip install vllm
vllm serve Qwen/Qwen3-8B --served-model-name qwen3-8b --max-model-len 16384

첫 실행 때 Hugging Face에서 가중치를 내려받습니다. 로그에 Application startup complete가 찍히면 curl localhost:8000/v1/models가 모델을 보여 주고, 위의 Python 코드도 그대로 동작합니다.

Docker로 vLLM 띄우기

#

계속 떠 있어야 하는 서비스라면 pip 설치 대신 공식 이미지를 씁니다. 주된 이유는 CUDA, PyTorch, vLLM이 서로 맞는 버전으로 묶여서 오기 때문입니다. 범용 Compose 서비스는 이렇습니다.

services:
  vllm:
    image: vllm/vllm-openai:v0.30.0   # 태그를 고정할 것. 이미지는 약 30 GB
    restart: unless-stopped
    ipc: host                          # PyTorch에 공유 메모리가 필요함
    command: >
      --model Qwen/Qwen3-8B
      --served-model-name qwen3-8b
      --gpu-memory-utilization 0.85
      --max-model-len 16384
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    ports:
      - "127.0.0.1:8000:8000"          # LAN이 아니라 ssh -L로 접속
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 10s
      timeout: 5s
      retries: 90
      start_period: 120s

태그는 고정하세요. vLLM은 빠르게 바뀌고 릴리스마다 플래그와 기본값이 달라지니, 그 변화를 언제 받아들일지는 내가 정해야 합니다. ipc: host(또는 넉넉한 shm_size)는 vLLM의 공식 Docker 안내에도 나와 있습니다. 긴 start_period는 아래에 나올 문제들 중 첫 번째 때문입니다.

vLLM 운영하면서 발목 잡힌 것들

#

시작하는 데 몇 분이 걸립니다. 가중치 로드, 컴파일, CUDA 그래프 캡처까지 제 서버에서 190초가 걸렸고, 큰 모델이라면 3~5분이 보통입니다. 웹 앱에 맞춰 짠 헬스 체크는 준비가 끝나기도 전에 vLLM을 죽여 버립니다. Compose에서는 긴 start_period가, Kubernetes에서는 startup probe가 필요하다는 뜻입니다. 재시작할 때마다 몇 분씩 모델이 없는 상태가 된다는 뜻이기도 하니, 재시작을 가볍게 하면 안 됩니다.

GPU 메모리는 시작할 때 준 만큼 가져갑니다. --gpu-memory-utilization은 vLLM이 쓸 수 있는 카드의 비율로 최근 버전의 기본값은 0.92이고, 가중치가 쓰고 남은 공간은 KV 캐시가 됩니다. vLLM이 카드를 혼자 쓴다면 문제없습니다. 제 경우는 옆에서 작은 모델들이 같이 돌아서 혼자가 아니라, 96 GB 카드에 0.70을 줬습니다. 모델은 FP8로 된 35B MoE(mixture-of-experts)였는데, 로드하고 나니 47.7 GiB를 차지했고 KV 캐시로 15 GiB가 남았습니다. 16k 컨텍스트라면 넉넉한 양이죠. 최대 시퀀스 길이가 KV 캐시에 들어가지 않는다며 vLLM이 시작을 거부하면, 더 큰 GPU를 찾아보기 전에 --max-model-len부터 낮춰 보세요.

LoRA 슬롯은 메모리를 미리 잡아 둡니다. vLLM은 베이스 모델 하나에 LoRA 어댑터 여러 개를 얹어 서빙하고, 요청마다 모델 이름으로 어댑터를 바꿀 수 있습니다. Ollama로는 사실상 못 하는 일이죠. 그런데 시작할 때 --max-lora-rank 기준으로 --max-loras개만큼 어댑터 자리를 예약하고, MoE 모델에서는 그 예약이 전문가(expert)들까지 덮기 때문에 금방 불어납니다. 0.70에서 랭크 64 어댑터 네 개는 들어가지 않았습니다. 두 개는 들어갔습니다.

기본 시퀀스 한도가 하이브리드 모델과 맞지 않았습니다. 제가 서빙하는 모델은 어텐션 사이에 Mamba 계열 레이어가 섞여 있고, 시퀀스마다 그 레이어용 캐시 블록이 따로 필요합니다. 그 카드에서 vLLM 기본 --max-num-seqs로는 시작에 실패했고, --max-num-seqs 256으로 해결됐습니다. 새로운 아키텍처의 모델이 뜨지 않는다면, 더 특이한 원인을 찾기 전에 이 플래그부터 확인해 보세요.

vllm이라는 이름의 Kubernetes Service가 vLLM을 죽입니다. 개인적으로 제일 마음에 드는 문제입니다. Kubernetes는 네임스페이스 안의 모든 Service에 대해 그 Service 이름을 딴 환경 변수를 주입합니다. 그래서 vllm이라는 Service가 있으면 모든 pod에 VLLM_PORT=tcp://<cluster-ip>:8000이 들어갑니다. vLLM은 VLLM_PORT를 자기 설정 중 하나로 읽는데, 거기 URL이 들어 있으니 해석하지 못하고 죽었습니다. 그것도 당연히 모델을 전부 로드한 다음에요. 그래서 시도할 때마다 3분씩 날아갔습니다. vLLM 문서에 이 경고가 있다는 건 나중에야 알았습니다. 해결책은 pod에 enableServiceLinks: false를 주거나, Service 이름을 다르게 짓는 것입니다.

동작하는 Deployment의 뼈대를 중요한 부분만 남겨 옮기면 이렇습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm
spec:
  replicas: 1
  strategy:
    type: Recreate               # 이전 pod가 먼저 GPU를 놓아야 함
  selector:
    matchLabels: {app: vllm}
  template:
    metadata:
      labels: {app: vllm}
    spec:
      enableServiceLinks: false  # Service가 넣는 VLLM_PORT=tcp://... 막기
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.30.0
          args: ["--model=Qwen/Qwen3-8B", "--served-model-name=qwen3-8b"]
          resources:
            limits:
              nvidia.com/gpu: "1"
              memory: 32Gi       # 로드할 때는 서빙할 때보다 호스트 RAM이 훨씬 많이 듦
          volumeMounts:
            - {name: shm, mountPath: /dev/shm}
          startupProbe:          # 모델이 다 올라오기 전에는 판정하지 않음
            httpGet: {path: /health, port: 8000}
            initialDelaySeconds: 120
            periodSeconds: 10
            failureThreshold: 90
          livenessProbe:         # 재시작은 곧 전체 재로드이니 느긋하게
            httpGet: {path: /health, port: 8000}
            periodSeconds: 30
            timeoutSeconds: 5
            failureThreshold: 10
      volumes:
        - name: shm
          emptyDir: {medium: Memory, sizeLimit: 16Gi}

가져다 쓸 만한 건 probe 부분입니다. startup probe는 2분을 기다린 다음, 모델이 올라올 때까지 15분을 더 주고 나서야 Kubernetes가 죽었다고 판단하게 합니다. liveness probe는 5분쯤 실패가 이어져야 재시작합니다. 바쁜 엔진에서는 /health 응답이 느릴 수 있고, 어차피 재시작하면 전체를 다시 로드해야 하니까요. GPU가 한 장일 때는 Recreate가 중요합니다. 롤링 업데이트는 새 pod를 먼저 띄우는데, 그 pod는 이전 pod가 아직 쥐고 있는 GPU를 기다리며 마냥 서 있게 됩니다. 메모리 제한이 넉넉해 보인다면, 실제로 넉넉하게 잡은 겁니다. 가중치가 GPU에 올라가고 나면 호스트 RAM은 7 GiB 정도에서 안정되지만, 로드하는 동안에는 그보다 훨씬 많이 필요합니다.

Ollama 쓸 때 알아 둘 것

#

놀랄 일은 적습니다. 대체로 하는 일 자체가 적어서죠.

한동안 조용하다가 들어온 첫 요청은 느립니다. 모델이 내려가 있어서 다시 로드해야 하기 때문입니다. OLLAMA_KEEP_ALIVE는 마지막 요청 이후 모델이 메모리에 머무는 시간을 정합니다. 그 멈칫거림이 거슬리면 값을 늘리고, 다른 일을 하지 않는 기계라면 -1로 두세요.

컨텍스트 윈도우는 GPU 메모리가 얼마나 있느냐에 따라 달라집니다. 24 GiB 미만이면 Ollama의 기본값은 4k 토큰으로, 대부분의 모델이 지원하는 길이보다 한참 짧습니다. 게다가 들어가지 않는 프롬프트는 거부되지 않고 조용히 잘립니다. 긴 프롬프트의 앞부분을 답변이 무시하는 것 같다면, OLLAMA_CONTEXT_LENGTH(또는 요청별 num_ctx)를 실제로 필요한 만큼 설정하세요.

원격 Ollama를 노트북으로 포워딩한다면 11434에 두지 마세요. Ollama의 기본 포트라서, 로컬 Ollama가 한 번이라도 뜨면 둘이 그 포트를 두고 경쟁하고, 모르는 사이에 엉뚱한 쪽과 이야기하고 있을 수 있습니다. 저는 11435로 포워딩합니다.

그리고 Ollama는 다중 사용자 서버가 아닙니다. 몇 명이 쓰는 내부 도구라면 괜찮습니다. 진짜 동시 요청이 몰리기 시작하면, 그때가 vLLM으로 옮길 시점입니다.

GPU 메모리는 얼마나 필요할까

#

가중치만 놓고 본 대략적인 크기입니다.

16비트에서는 파라미터당 약 2바이트, 8비트에서는 1바이트, Q4_K_M에서는 0.5바이트를 조금 넘습니다. 가중치 위에 KV 캐시가 더해지는데, 이건 컨텍스트 길이와 동시에 처리 중인 요청 수에 따라 커집니다. 같은 모델이라도 vLLM으로 50명을 서빙할 때가 Ollama로 나 혼자 쓸 때보다 메모리가 훨씬 많이 드는 건 이 두 번째 부분 때문입니다.

어느 쪽을 쓸까

#

내 기계에서 모델을 돌리고 싶은 거라면 Ollama를 설치하고 거기서 멈추세요. 10분이면 답하는 모델이 생깁니다. GPU 서버가 있고 하루 종일 호출할 사용자나 앱이 있다면 vLLM을 쓰고, 느린 시작과 잡아먹는 메모리를 받아들이고, probe를 제대로 잡으세요. 결국 둘 다 쓰게 되는 경우도 많은데, 저도 그렇습니다. 코드를 쓰는 곳에는 Ollama, 요청이 도착하는 곳에는 vLLM.

다른 선택지도 있습니다. SGLang이 vLLM의 대안으로 흔히 꼽히지만 프로덕션에서 돌려 본 적이 없어서, 짐작으로 쓰느니 빼 두었습니다. 그리고 모델이 폰에서 돌아야 한다면 다시 llama.cpp인데, 이건 React Native에서 LLM을 온디바이스로 돌리기에 썼습니다.