Ollama vs vLLM 비교: LLM 서버 선택 기준과 차이점

Ollama와 vLLM 비교

Ollama는 모델 관리자이자 서버 역할을 수행하며, 양자화된 가중치를 다운로드하고 로드하여 127.0.0.1:11434에서 응답을 생성하는데, 시스템에 GPU가 없다면 CPU를 사용합니다. 반면 vLLM은 처리량 최적화 엔진으로, 다수의 요청을 동시에 처리하여 GPU 자원을 최대한 활용하도록 설계되었으므로 GPU가 없는 환경에는 적합하지 않습니다. 이것이 선택의 핵심 기준입니다. 로컬 어시스턴트와 대화하는 개인 사용자에게는 Ollama가 적합하며, 팀 단위의 서비스를 운영하는 애플리케이션에는 vLLM이 적합합니다. 두 도구 모두 OpenAI 호환 HTTP API를 지원하므로 베이스 URL만 변경하면 클라이언트 코드를 그대로 사용할 수 있습니다. 따라서 API 호환성보다는 첫 번째 요청이 토큰을 생성하는 도중 두 번째 요청이 들어왔을 때 어떻게 처리하는지가 두 도구의 결정적인 차이점입니다.

Ollama의 실제 정체

Ollama는 편의성을 제공하는 계층입니다. 단일 설치 명령어로 모델 레지스트리(ollama pull llama3.1:8b), 로컬 가중치 저장소, 채팅 프롬프트, systemd 서비스, HTTP API를 모두 제공합니다. Ollama가 서비스하는 모델은 일반적으로 4비트 양자화된 GGUF 파일입니다. 이 때문에 7B 또는 8B 모델의 디스크 용량이 16GB가 아닌 5GB 내외가 됩니다. 양자화는 CPU 추론을 가능하게 만드는 핵심 기술입니다.

Ollama의 실행 엔진은 일반 하드웨어에서 GGUF 양자화를 실용적으로 만든 C++ 추론 라이브러리인 llama.cpp를 기반으로 합니다. 이후 Ollama는 일부 최신 모델군을 위해 자체 엔진을 추가했지만, 여전히 서비스하는 대부분의 모델은 llama.cpp를 기반으로 작동합니다. 따라서 사람들이 Ollama와 llama.cpp를 비교할 때, 사실상 편의성 계층과 그 계층이 감싸고 있는 핵심 엔진을 비교하는 셈입니다.

이 도구의 설계 목표는 단일 사용자 환경입니다. 2026년 7월 기준으로 OLLAMA_NUM_PARALLEL의 기본값은 1입니다. 이는 한 번에 하나의 모델이 하나의 요청을 처리하며, 나머지 요청은 기본적으로 512개까지 대기열(OLLAMA_MAX_QUEUE)에 머무른다는 의미입니다. 병렬 처리 설정을 높일 수 있으나, 그에 따른 비용은 아래 섹션에서 설명합니다. Ollama를 처음 사용한다면 VPS에서 Ollama 호스팅하기 및 11434 포트 닫기를 먼저 확인하십시오. API에는 어떠한 인증 기능도 포함되어 있지 않기 때문입니다.

vLLM의 실체

vLLM은 오직 추론 서버 역할만 수행합니다. 모델 라이브러리를 관리하지 않으며, 자체적인 채팅 프롬프트 기능도 없고, 요청 시점에 모델을 자동으로 내려받지도 않습니다. 실행 시 Hugging Face 저장소를 지정하면 해당 모델을 불러오며, 프로세스를 종료할 때까지 해당 모델을 서비스합니다.

이러한 단순함을 통해 얻는 이점은 처리량(throughput)입니다. 이를 위해 두 가지 메커니즘이 작동합니다. PagedAttention은 운영체제가 메모리를 페이징하는 방식과 유사하게, KV 캐시(key-value cache, 모델이 활성 요청마다 유지하는 토큰별 어텐션 상태)를 고정 크기 블록으로 저장합니다. 따라서 요청마다 최악의 상황을 대비해 큰 연속 메모리 공간을 예약할 필요가 없으며, 기존에 예약만 해두고 사용하지 않던 메모리를 더 많은 동시 요청을 처리하는 데 활용할 수 있습니다. Continuous batching은 현재 배치 작업이 끝날 때까지 기다릴 필요 없이, 다음 디코딩 단계에서 새로운 요청이 실행 중인 배치에 즉시 합류할 수 있게 합니다. 완료된 시퀀스는 즉시 배치에서 빠져나가고 해당 슬롯은 다시 채워집니다.

실질적인 결과는 다음과 같습니다. 단일 GPU에서 동시 사용자를 1명에서 30명으로 늘리면 초당 전체 토큰 처리량은 급격히 증가하며, 사용자당 속도 저하는 예상보다 훨씬 적습니다. Ollama의 기본 설정에서는 사용자가 1명에서 30명으로 늘어나면 29명의 사용자가 대기 상태에 빠지게 됩니다.

연속 배치 처리가 모든 차이를 만듭니다

동일한 하드웨어에서 5개의 요청이 동시에 서버에 도달하는 상황을 가정해 보겠습니다.

기본 설정의 Ollama는 첫 번째 요청을 완료한 뒤 두 번째 요청을 처리하는 방식으로 순차적으로 실행합니다. 다섯 번째 사용자는 앞선 4번의 전체 생성 과정을 모두 기다려야 합니다. 프로세서가 한 번에 하나의 시퀀스만 처리하므로 전체 처리량은 대략 한 번의 생성 속도와 같습니다.

vLLM은 5개의 요청을 동일한 포워드 패스(forward pass)에서 디코딩합니다. 5개의 시퀀스에 대해 토큰 하나를 생성하는 비용은 1개의 시퀀스에 대해 생성하는 비용과 거의 차이가 없습니다. 비용이 많이 드는 작업은 모델 가중치를 메모리에서 읽어오는 것인데, 이 읽기 작업이 전체 배치에서 공유되기 때문입니다. 이는 CPU 추론이 느린 이유와 동일한 메모리 대역폭의 원리입니다. 즉, 연산이 아니라 가중치를 이동하는 데 비용을 지불하는 것입니다.

OLLAMA_NUM_PARALLEL=4를 설정하면 이러한 이점의 일부를 얻을 수 있습니다. 이때 발생하는 비용은 메모리입니다. 각 병렬 슬롯은 고유한 KV 캐시가 필요하며, Ollama는 컨텍스트 윈도우를 슬롯별로 나눕니다. 따라서 8192 토큰으로 설정된 모델에 4개의 병렬 요청이 들어오면 각 요청은 2048 토큰의 컨텍스트만 사용할 수 있습니다. 8192라는 수치 자체가 고정된 값이 아니라 선택 사항이므로, num_ctx를 높이고 이에 필요한 RAM 크기를 조정하는 것이 4개의 슬롯을 실제로 사용할 수 있을지 결정하는 핵심 단계입니다. vLLM의 페이징된 캐시(paged cache)는 요청이 실제로 증가함에 따라 블록을 할당하므로 이러한 트레이드오프를 피할 수 있습니다. 어느 경우든 단일 서버가 동시에 처리할 수 있는 사용자 수의 상한은 KV 캐시 크기, 프리필(prefill) 비용, 큐 깊이에 의해 결정되며, 이것이 바로 한 명에게는 충분했던 서버가 다섯 명에게는 매우 느려지는 이유입니다.

Ollama 설치 및 서비스 운영

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

설치 스크립트는 ollama 시스템 사용자를 생성하고, 바이너리를 설치하며, 127.0.0.1:11434에 바인딩된 ollama.service을 등록합니다. --verbose가 출력하는 eval rate 라인은 해당 장비에서 실제로 처리하는 초당 토큰 수입니다. 공개된 수치보다 이 값을 신뢰하십시오. 단일 프롬프트에서 얻은 측정값은 용량 수치라기보다 시작점에 가깝습니다. 따라서 동시성 스윕을 통한 초당 토큰 처리 시간 측정을 수행해야 장비가 예상 부하를 견딜 수 있는지, 그리고 GPU를 대여하는 것이 토큰당 비용을 지불하는 것보다 유리한지 판단할 수 있습니다.

동시성을 높이려면 systemd 드롭인(drop-in) 설정을 사용하여 업그레이드 시 변경 사항이 덮어쓰이지 않도록 하십시오.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps은 로드된 상태를 보여주며, PROCESSOR 열이 실제 상태를 나타냅니다. 100% CPU는 GPU가 사용되지 않음을 의미하며, 이는 Ollama가 느리다는 대부분의 보고에 대한 정직한 설명입니다. 해당 드롭인 설정의 OLLAMA_KEEP_ALIVE=30m 라인은 유휴 상태의 장비에서도 매우 중요합니다. 기본 설정은 요청이 없으면 5분 후에 모델을 메모리에서 해제하기 때문입니다. 요청 사이에 모델을 상주시키는 것은 한 시간 동안 유휴 상태가 지난 후 첫 번째 프롬프트를 입력할 때 전체 로드 시간을 다시 기다리지 않게 해줍니다.

vLLM 설치 및 서비스

vLLM은 Linux와 Python 3.10에서 3.13 버전을 요구합니다. 특정 PyTorch 빌드를 불러오므로 전용 가상 환경에 설치하십시오.

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

그다음 모델을 서비스합니다. 모델 이름은 짧은 태그가 아니라 Hugging Face 저장소 ID를 사용해야 합니다.

vllm serve Qwen/Qwen2.5-1.5B-Instruct

처음 시작할 때는 가중치를 다운로드하고 GPU를 프로파일링하여 KV 캐시 블록을 얼마나 할당할지 결정하므로 시간이 걸립니다. 기본적으로 8000번 포트에서 대기합니다. 클라이언트 코드를 작성하기 전에 다음 명령으로 확인하십시오.

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

서버에 Docker가 이미 설치되어 있다면 공식 이미지를 사용하여 CUDA 의존성 문제를 피할 수 있습니다.

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host는 장식이 아니라 필수입니다. PyTorch는 프로세스 간에 텐서를 공유 메모리로 전달하는데, Docker의 기본 공유 메모리 할당량은 텐서 병렬 추론을 수행하기에 너무 작기 때문입니다.

운영 환경에서 가장 중요한 플래그는 --max-model-len(사용할 컨텍스트 윈도우 크기), --gpu-memory-utilization(vLLM이 점유할 GPU 메모리 비율, 2026년 7월 기준 기본값 0.92), --tensor-parallel-size(하나의 모델을 여러 GPU에 분할), 그리고 --api-key입니다.

인증은 vLLM에는 플래그로 존재하지만 Ollama에는 없습니다

vLLM은 토큰을 제공하면 Bearer 토큰을 강제합니다:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

동일한 값을 VLLM_API_KEY 환경 변수에서 가져올 수도 있습니다. 토큰 없이 요청하면 HTTP 401 오류가 발생합니다. vLLM은 속도 제한(rate limiting) 기능이 없고 일반 HTTP 토큰은 전송 중에 읽힐 수 있으므로, 이것이 포트 8000을 공용 인터페이스에 노출해도 된다는 근거가 되지는 않습니다. 하지만 서버가 호출자를 식별하는 개념을 가지고 있다는 점은 의미가 있습니다.

Ollama에는 이러한 기능이 전혀 없습니다. 키도, 로그인도, 허용 목록도 없습니다. 11434 포트에 접근할 수 있는 모든 프로세스는 모델을 실행, 다운로드, 삭제할 수 있습니다. 루프백(loopback) 주소로 유지하고 직접 호스팅하는 WireGuard VPN을 통해 접근하거나, TLS(전송 계층 보안)를 종료하는 인증된 리버스 프록시를 거쳐 접근해야 합니다.

하드웨어: 각 서비스별 요구 사항

Ollama는 CPU에서 실행됩니다. 4비트 양자화 모델은 10억 개의 파라미터당 약 0.5 GB의 RAM을 소모하며, 여기에 런타임 오버헤드로 약 1 GB가 추가되고 컨텍스트 길이에 따라 더 많은 메모리가 필요합니다. 따라서 3B 모델은 약 4 GB, 8B 모델은 약 8 GB의 여유 메모리가 필요합니다. 공유 vCPU에서의 속도는 초당 한 자릿수에서 낮은 두 자릿수의 토큰 수준입니다. 이는 설정 오류가 아니라 메모리 대역폭의 한계이며, 어떤 플래그로도 해결할 수 없습니다. 일반적인 기준 대신 특정 릴리스에서 이러한 연산이 어떻게 이루어지는지 확인하려면 VPS에서 Nemotron 3.5 Lightning 실행하기를 참조하십시오. 여기에서 가져올 정확한 태그, 로드 후 점유하는 RAM 용량, 그리고 CPU만으로 실사용이 가능한 수준인지 확인할 수 있습니다.

vLLM은 GPU를 전제로 합니다. 기본 경로에서는 16비트 정밀도의 비양자화 가중치를 사용하며, 이는 10억 개의 파라미터당 약 2 GB를 차지합니다. 즉, 8B 모델은 가중치만으로도 약 16 GB의 비디오 메모리가 필요하며, vLLM을 설치한 목적인 동시성 처리를 위한 KV 캐시 공간은 별도입니다. 24 GB 카드에서는 적절한 캐시를 확보할 수 있지만, 16 GB 카드에서는 부족하므로 더 작은 모델을 선택하거나 --quantization 플래그와 함께 양자화된 체크포인트를 사용해야 합니다. CPU 백엔드도 존재하지만, 표준 휠(wheel)은 이를 위해 빌드되지 않았으며 CPU 사용은 vLLM을 실행하는 근본적인 이유를 상쇄합니다.

따라서 하드웨어 사양은 대부분의 경우 소프트웨어 선택의 기준이 됩니다. GPU가 없다면 Ollama를 선택하십시오. 요청이 직렬화되어 GPU 사용률이 5퍼센트에 머물고 있다면 vLLM을 도입할 시점입니다.

워크로드에 적합한 도구 선택

• 1인 사용자, CPU VPS 환경에서 초안 작성 및 요약 작업: Ollama. 속도가 적절하며 이보다 더 간단한 도구는 없습니다.
• 코딩 보조 도구 또는 도구와 로컬 모델을 연결하는 MCP 서버를 혼자 사용하는 경우: Ollama. 동시성 1이 실제 워크로드입니다.
• 이번 주에 5개의 모델을 비교해야 하는 경우: Ollama. 태그가 지정된 모델을 가져오고 삭제하는 작업에 최적화되어 있습니다. 반면 vLLM은 모델을 바꿀 때마다 프로세스를 재시작해야 합니다.
• 내부 애플리케이션, 채팅 서비스 또는 실제 사용자가 있는 검색 파이프라인: vLLM. 배치 처리를 통해 GPU 비용을 효율적으로 사용할 수 있는 영역입니다.
• 하룻밤 사이에 10만 개의 문서를 처리하는 배치 작업: vLLM (높은 --max-num-seqs 설정). 처리량(throughput)이 유일한 지표이며 문서당 지연 시간은 중요하지 않습니다.
• 여러 자체 호스팅 AI 에이전트가 동시에 모델을 호출하는 에이전트 플랫폼: vLLM. 에이전트 트래픽은 본질적으로 버스트(bursty)하고 병렬적이기 때문입니다.

실패 유형 및 확인 가능한 메시지

vLLM이 KV cache 오류로 시작되지 않습니다. 메시지에는 두 가지 숫자가 모두 표시됩니다.

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

모델이 가중치를 로드한 후 남은 메모리보다 더 큰 컨텍스트 윈도우를 선언했습니다. --max-model-len 8192로 값을 낮추거나, 다른 프로세스가 GPU를 사용하지 않는다면 --gpu-memory-utilization을 높이십시오. 사용률을 0.95 이상으로 올리면 이 시작 오류 대신 부하 발생 시 CUDA out-of-memory 충돌이 발생할 가능성이 높으며, 후자가 더 심각한 문제입니다.

Ollama가 생성 도중 Killed를 출력합니다. 모델이 시스템 RAM보다 더 많은 메모리를 요구하여 Linux의 out-of-memory killer가 프로세스를 강제 종료한 것입니다. sudo dmesg | grep -i oom로 이를 확인하십시오. 해결책은 설정을 변경하는 것이 아니라 더 작거나 더 많이 양자화된 모델을 사용하는 것입니다.

Ollama가 단독 실행 시에는 잘 작동하나 부하가 걸리면 멈춥니다. 별도의 오류 메시지는 나타나지 않습니다. OLLAMA_NUM_PARALLEL=1이 요청을 직렬화하기 때문에 호출자가 많아질수록 응답 시간이 길어집니다. 긴 답변은 대기열을 악화시킵니다. 모델이 생성을 멈출 때까지 한 명의 호출자가 슬롯을 독점하면 뒤에 있는 모든 요청이 차단되기 때문입니다. 따라서 num_predict로 응답 길이 제한을 설정하여 단일 요청이 서버를 점유하는 시간을 제한하십시오. 병렬 처리 설정을 높이고 요청당 컨텍스트 크기를 줄이거나, 작업 부하를 vLLM으로 이전하십시오.

vLLM이 모든 호출에 대해 401 오류를 반환합니다. --api-key 옵션으로 서버를 시작했으나 클라이언트가 Authorization 헤더를 보내지 않았기 때문입니다. 대부분의 OpenAI 클라이언트 라이브러리는 전달하는 값을 키로 사용하므로, 플래그를 제거하는 대신 클라이언트 설정에서 키를 지정하십시오.

vLLM이 모델을 찾을 수 없다고 합니다. Ollama는 필요할 때 모델을 자동으로 가져오지만, vLLM은 그렇지 않습니다. 요청 본문의 model 필드는 서버를 시작할 때 사용한 저장소 ID와 일치해야 하며, --served-model-name을 설정했다면 해당 값과 일치해야 합니다. curl http://localhost:8000/v1/models을 사용하여 정확한 문자열을 확인하십시오.

두 서비스를 모두 실행하는 것은 합리적인 해결책입니다

두 서비스는 상호 배타적이지 않습니다. 일반적인 구성은 애플리케이션을 서비스하는 GPU 인스턴스에 vLLM을 배치하고, 로컬 스크립트나 cron 작업, 새로운 모델 릴리스 테스트를 위해 일반 VPS에 Ollama를 함께 두는 방식입니다. 두 엔드포인트 모두 OpenAI와 호환되므로, 하나의 클라이언트 라이브러리에서 base-URL만 변경하여 두 서비스 모두를 사용할 수 있습니다. 여기서는 어떤 엔진을 선택하느냐보다 비용 관리가 더 중요합니다. 유휴 상태의 GPU도 가동 중인 GPU와 동일한 비용이 청구되기 때문이며, 에이전트 및 추론 비용을 예측 가능하게 유지하는 것은 서버 선택과는 별개의 영역입니다.

FAQ

vLLM이 Ollama보다 빠른가요?

동일한 GPU에서 단일 요청을 처리할 때는 두 도구 모두 동일한 연산을 수행하므로 성능 차이가 크지 않습니다. 하지만 동시 요청이 많아지면 vLLM이 훨씬 앞섭니다. vLLM은 continuous batching을 통해 활성화된 모든 시퀀스를 한 번의 forward pass로 디코딩하지만, Ollama는 기본적으로 요청을 순차적으로 처리하기 때문입니다. CPU 전용 환경에서는 이 질문이 성립하지 않습니다. Ollama는 CPU에서 동작하지만 vLLM은 사실상 동작하지 않기 때문입니다.

vLLM을 GPU 없이 실행할 수 있나요?

실용적이지 않습니다. 표준 wheel 파일은 NVIDIA 또는 AMD GPU를 대상으로 하며, vLLM이 존재하는 이유인 '배치 요청으로 가속기를 포화 상태로 유지하는 것'이 CPU에서는 의미가 없기 때문입니다. 개발 작업을 위한 CPU 백엔드가 존재하기는 합니다. 실제 CPU 추론이 필요하다면 Ollama나 llama.cpp를 직접 사용하십시오.

Ollama와 llama.cpp의 차이점은 무엇인가요?

llama.cpp는 추론 라이브러리이며, GGUF는 해당 라이브러리의 양자화 가중치 형식입니다. Ollama의 러너는 이를 기반으로 구축되었으며, llama.cpp가 사용자에게 맡겨두었던 모델 레지스트리, 자동 다운로드, 상주 서버, systemd 유닛, OpenAI 호환 엔드포인트 등의 기능을 추가한 것입니다. Ollama는 일부 최신 모델 제품군을 위해 자체 엔진을 추가했으므로, 이제 두 도구의 내부 구조가 완전히 동일하지는 않습니다.

8B 모델을 실행하려면 vLLM에 GPU 메모리가 얼마나 필요한가요?

16비트 정밀도에서 가중치만 약 16 GB(파라미터 10억 개당 약 2 GB)를 차지하며, 여기에 KV 캐시를 위한 공간이 추가로 필요합니다. 24 GB 카드라면 여유가 있습니다. 16 GB 카드를 사용하려면 양자화된 체크포인트나 더 작은 모델을 사용해야 합니다. vLLM은 --gpu-memory-utilization로 설정된 만큼의 카드 메모리를 점유하며, 2026년 7월 기준으로 기본값은 0.92입니다.

두 도구 사이를 전환하려면 애플리케이션 코드를 수정해야 하나요?

보통 기본 URL, API 키, 모델 이름만 수정하면 됩니다. Ollama는 http://127.0.0.1:11434/v1에서 OpenAI 호환 인터페이스를 제공하며 키를 무시하지만, vLLM은 http://localhost:8000/v1에서 서비스를 제공하며 키가 설정된 경우 이를 강제합니다. 모델 이름 형식도 다릅니다. Ollama는 llama3.1:8b를 사용하고, vLLM은 Qwen/Qwen2.5-1.5B-Instruct과 같은 전체 저장소 ID를 사용합니다.