가이드

작성자 Matt Connor 2026-07-30 · 업데이트됨 2026-08-01

Ollama vs vLLM, LLM 서버 선택 기준

Q: 두 시스템을 전환하려면 application code를 변경해야 합니까?

대개 base URL, API key, model name만 변경하면 됩니다. Ollama는 http://127.0.0.1:11434/v1에서 OpenAI 호환 interface를 제공하며 key를 무시합니다. vLLM은 http://localhost:8000/v1에서 제공하며, key를 설정한 경우 이를 적용합니다. Model name의 형식은 서로 다릅니다. Ollama에서는 llama3.1:8b를 사용하고, vLLM에서는 Qwen/Qwen2.5-1.5B-Instruct와 같은 전체 repository id를 사용합니다.

Ollama는 CPU에서도 단일 사용자에게 적합하고, vLLM은 GPU 처리량에 맞습니다. %%C10%%, %%C11%%, %%C12%% 기본값 1과 실제 실행 명령으로 작업에 맞는 서버를 선택합니다.

Ollama와 vLLM 비교, 한 문단으로

Ollama는 서버가 포함된 모델 관리자입니다. 양자화된 가중치를 다운로드하고 로드한 다음, 127.0.0.1:11434에서 응답합니다. 시스템에 CPU만 있어도 CPU를 사용합니다. vLLM은 처리량 엔진입니다. 여러 요청을 동시에 실행하여 GPU를 최대한 활용합니다. GPU가 없는 시스템에서는 적합하지 않습니다. 판단 기준은 이것이 전부입니다. 한 사용자가 로컬 어시스턴트와 대화하는 경우는 Ollama 작업입니다. 팀을 대상으로 애플리케이션을 제공하는 경우는 vLLM 작업입니다.

둘 다 OpenAI 호환 HTTP API를 사용하므로 base URL을 변경하면 클라이언트 코드를 서로 전환할 수 있습니다. API가 차이를 만드는 것은 아닙니다. 첫 번째 요청이 토큰을 계속 생성하는 동안 두 번째 요청이 도착했을 때 어떤 일이 발생하는지가 차이입니다.

Ollama의 실제 역할

Ollama는 편의 계층입니다. 설치 명령 1개로 모델 레지스트리(ollama pull llama3.1:8b), 로컬 가중치 저장소, 채팅 프롬프트, systemd 서비스, HTTP API를 제공합니다. Ollama가 제공하는 모델은 GGUF 파일이며, 일반적으로 4-bit 양자화가 적용됩니다. 따라서 7B 또는 8B 모델은 디스크에서 16 GB가 아니라 약 5 GB를 차지합니다. 양자화가 있어야 CPU 추론이 가능합니다.

Ollama의 실행기는 일반 하드웨어에서 GGUF 양자화를 실용적으로 만든 C++ 추론 라이브러리인 llama.cpp를 기반으로 합니다. 이후 Ollama는 일부 최신 모델 제품군을 위해 자체 엔진도 추가했습니다. 하지만 Ollama가 제공하는 기능 대부분의 기반에는 여전히 llama.cpp가 있습니다. 따라서 Ollama와 llama.cpp를 비교할 때는 대부분 Ollama가 감싼 대상과 사용 편의성 계층을 비교하는 것입니다.

이 설계의 대상은 단일 사용자입니다. 2026년 7월 기준 OLLAMA_NUM_PARALLEL의 기본값은 1입니다. 이는 하나의 모델이 한 번에 하나의 요청을 처리하고, 나머지 요청은 기본적으로 512개 항목을 보관하는 대기열(OLLAMA_MAX_QUEUE)에서 기다린다는 의미입니다. 병렬 처리 설정을 높일 수 있지만, 아래 섹션에서 그에 따른 비용을 설명합니다. Ollama를 아직 실행한 적이 없다면 VPS에서 Ollama를 호스팅하고 port 11434를 닫아 두기부터 시작합니다. API에는 어떤 종류의 인증도 없기 때문입니다.

vLLM의 실제 역할

vLLM은 추론 서버이며 그 외의 기능은 제공하지 않습니다. 모델 라이브러리를 관리하지 않으며, 채팅 프롬프트도 없고, 요청 시점에 모델을 가져오지도 않습니다. 시작할 때 Hugging Face repository를 지정하면 vLLM은 해당 모델 하나를 로드하고, 프로세스를 중지할 때까지 모델을 제공합니다.

이처럼 기능 범위를 좁혀 얻는 이점은 처리량입니다. 이를 수행하는 메커니즘은 2가지입니다. PagedAttention은 KV cache(키-값 캐시, 모델이 활성 요청마다 유지하는 토큰별 attention 상태)를 운영 체제가 메모리를 페이지 단위로 관리하는 방식처럼 고정 크기 블록에 저장합니다. 이제 요청마다 최악의 경우에 맞춘 하나의 큰 연속 메모리 영역을 예약할 필요가 없습니다. 따라서 이전에는 예약된 채 사용되지 않던 메모리를 더 많은 동시 요청에 사용할 수 있습니다. Continuous batching을 사용하면 새 요청이 현재 batch가 완료될 때까지 기다리지 않고 다음 decoding 단계에서 실행 중인 batch에 참여할 수 있습니다. 시퀀스가 완료되면 즉시 batch에서 제거되고 해당 슬롯은 새 요청으로 채워집니다.

실제 결과는 다음과 같습니다. 단일 GPU에서 동시 사용자를 1명에서 30명으로 늘리면 초당 전체 토큰 수가 크게 증가하는 반면, 사용자별 속도는 예상보다 훨씬 적게 감소합니다. Ollama의 기본 동작에서는 사용자를 1명에서 30명으로 늘리면 29명이 대기하게 됩니다.

연속 배칭이 모든 차이를 만듭니다

동일한 하드웨어에서 각 서버에 5개의 요청이 동시에 도착한다고 가정합니다.

Ollama는 기본 설정에서 첫 번째 요청을 끝까지 처리한 다음 두 번째 요청을 처리하는 방식으로 실행됩니다. 따라서 다섯 번째 호출자는 4번의 전체 생성을 기다립니다. 프로세서는 한 번에 하나의 시퀀스만 처리하므로, 전체 처리량은 대략 단일 생성 속도와 같습니다.

vLLM은 5개 요청을 동일한 forward pass에서 디코딩합니다. 5개 시퀀스에 대해 토큰 1개를 생성하는 비용은 시퀀스 1개에 대해 토큰 1개를 생성하는 비용보다 거의 크지 않습니다. 비용이 큰 작업은 모델 가중치를 메모리에서 읽는 작업이며, 이 읽기 작업은 전체 배치에서 공유되기 때문입니다. CPU 추론을 느리게 만드는 원인도 동일한 메모리 대역폭 특성입니다. 산술 연산이 아니라 가중치를 이동하는 데 비용이 발생합니다.

OLLAMA_NUM_PARALLEL=4을 설정하면 이 효과를 일부 얻을 수 있습니다. 비용은 메모리입니다. 각 병렬 슬롯에는 자체 KV cache가 필요합니다. 또한 Ollama는 슬롯 전체에 context window를 나눕니다. 따라서 8192 tokens로 구성된 모델에 대해 4개의 병렬 요청을 처리하면 각 요청에 할당되는 context는 2048 tokens가 됩니다. vLLM의 paged cache는 요청이 실제로 증가하는 시점에 맞춰 블록을 할당하므로 이러한 절충이 필요하지 않습니다.

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 행은 해당 시스템에서 실제로 측정된 초당 토큰 수입니다. 게시된 수치보다 이 값을 신뢰해야 합니다.

동시성을 높이려면 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가 느리다는 대부분의 보고에 대한 정확한 원인입니다.

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 repository id를 사용합니다.

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

처음 시작할 때는 가중치를 다운로드한 후, GPU에서 수용할 수 있는 KV cache 블록 수를 결정하기 위해 프로파일링하므로 시간이 오래 걸립니다. 포트 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는 프로세스 간에 텐서를 전달할 때 shared memory를 사용하며, Docker의 기본 shared-memory 할당은 tensor-parallel 추론에 너무 작습니다.

프로덕션 환경에서 가장 중요한 플래그는 --max-model-len(사용할 context window의 크기), --gpu-memory-utilization(vLLM이 사용할 수 있는 GPU 메모리 비율이며 2026년 7월 기준 기본값은 0.92), 여러 GPU에 하나의 모델을 분할하기 위한 --tensor-parallel-size, 그리고 --api-key입니다.

vLLM에서는 인증이 하나의 플래그이고 Ollama에는 없습니다

vLLM은 bearer token을 지정하면 해당 토큰을 적용합니다.

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

동일한 값은 VLLM_API_KEY 환경 변수에서 가져올 수도 있습니다. 토큰이 없는 요청에는 HTTP 401이 반환됩니다. 그렇다고 공개 인터페이스에서 port 8000을 노출해도 된다는 뜻은 아닙니다. vLLM에는 rate limiting이 없고 일반 HTTP token은 전송 중에 읽을 수 있기 때문입니다. 다만 서버에 요청 주체라는 개념이 있다는 의미는 됩니다.

Ollama에는 이러한 기능이 전혀 없습니다. key도 없고, login도 없으며, allow-list도 없습니다. 11434에 연결할 수 있는 모든 프로세스가 model을 실행하거나, pull하거나, 삭제할 수 있습니다. loopback에서만 실행하고 직접 호스팅하는 WireGuard VPN을 통해 접속하거나, TLS(transport layer security)를 종료하는 인증 reverse proxy를 사용합니다.

하드웨어: 각 소프트웨어에 필요한 사항

Ollama는 CPU에서 실행됩니다. 4-bit 양자화 모델은 매개변수 10억 개당 대략 0.5 GB의 RAM을 사용합니다. 여기에 약 1 GB의 런타임 오버헤드와 컨텍스트에 필요한 추가 메모리가 더 필요합니다. 따라서 3B 모델에는 약 4 GB의 여유 메모리가 필요하고, 8B 모델에는 약 8 GB가 필요합니다. 공유 vCPU에서의 속도는 초당 한 자릿수에서 낮은 두 자릿수 토큰 수준입니다. 이는 메모리 대역폭의 문제이지 잘못된 설정의 문제가 아닙니다. 어떤 flag로도 해결할 수 없습니다.

vLLM은 GPU를 전제로 합니다. 기본 경로는 16-bit 정밀도의 비양자화 weight를 제공하며, 매개변수 10억 개당 대략 2 GB가 필요합니다. 따라서 8B 모델은 weight만으로 약 16 GB의 비디오 메모리가 필요합니다. 여기에 vLLM을 설치한 이유인 동시 요청 처리를 위한 KV cache는 포함되지 않았습니다. 24 GB 카드에서는 사용할 수 있는 cache가 남습니다. 16 GB 카드에서는 그렇지 않으므로 더 작은 모델을 선택하거나, 양자화된 checkpoint와 함께 --quantization를 전달해야 합니다. CPU backend도 있지만 표준 wheel은 CPU용으로 빌드되지 않았습니다. 또한 CPU에서 실행하면 애초에 vLLM을 사용하는 이유가 사라집니다.

따라서 대부분의 경우 하드웨어에 대한 답이 곧 소프트웨어에 대한 답입니다. GPU가 없으면 Ollama를 사용합니다. 임대한 GPU에서 요청이 직렬화되어 사용률이 5 percent에 머문다면 vLLM을 사용합니다.

워크로드에 적합한 선택

1명이 CPU VPS에서 초안 작성과 요약을 수행하는 경우: Ollama입니다. 처리 속도는 충분하며, 이보다 간단한 선택지는 없습니다.
코딩 지원 도구 또는 로컬 모델과 도구를 연결하는 MCP 서버를 혼자 호출하는 경우: Ollama입니다. 실제 워크로드의 동시성은 1입니다.
이번 주에 5개의 모델을 비교하는 경우: Ollama입니다. 태그가 지정된 모델을 가져오고 삭제하는 작업은 Ollama의 강점입니다. 반면 vLLM은 모델마다 프로세스를 다시 시작해야 합니다.
실제 사용자가 있는 내부 앱, 채팅 제품 또는 검색 파이프라인인 경우: vLLM입니다. 이 경우 배칭으로 GPU 비용을 정당화할 수 있습니다.
밤새 100000개의 문서를 평가하는 배치 작업인 경우: 높은 --max-num-seqs을 사용하는 vLLM이 적합합니다. 중요한 지표는 처리량뿐이며 문서별 지연 시간은 중요하지 않습니다.
여러 자체 호스팅 AI 에이전트가 동시에 모델에 요청하는 에이전트 플랫폼인 경우: vLLM이 적합합니다. 에이전트 트래픽은 본질적으로 버스트 형태이며 병렬로 발생하기 때문입니다.

확인해야 할 오류 메시지별 장애 유형

vLLM이 KV cache 오류와 함께 시작되지 않습니다. 메시지에 2개의 숫자가 모두 표시됩니다.

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.

모델이 weights를 로드한 후 남은 메모리보다 큰 context window를 선언합니다. --max-model-len 8192로 값을 낮추거나, GPU를 사용하는 다른 프로세스가 없다면 --gpu-memory-utilization를 높입니다. 사용률을 약 0.95보다 높이면 시작 오류 대신 부하가 걸렸을 때 CUDA out-of-memory 오류로 중단될 가능성이 높습니다. 후자가 더 심각한 문제입니다.

Ollama가 생성 중간에 Killed을 출력합니다. Linux out-of-memory killer가 모델에 필요한 RAM이 시스템에 설치된 RAM보다 많아서 프로세스를 중지했습니다. sudo dmesg | grep -i oom로 확인합니다. 해결 방법은 더 작은 모델이나 더 높은 수준으로 양자화된 모델을 사용하는 것입니다. 설정을 변경해서 해결할 수 있는 문제가 아닙니다.

Ollama가 단독으로는 정상적으로 응답하지만 부하가 걸리면 멈춘 것처럼 보입니다. 어디에도 오류가 표시되지 않습니다. 호출하는 클라이언트가 많을수록 요청 처리 시간이 길어집니다. OLLAMA_NUM_PARALLEL=1가 요청을 직렬화하기 때문입니다. OLLAMA_NUM_PARALLEL=1를 높이고 요청별 context를 줄이거나, workload를 vLLM으로 이전합니다.

vLLM이 모든 호출에 401을 반환합니다. --api-key와 함께 시작했지만 클라이언트가 Authorization header를 보내지 않았습니다. 대부분의 OpenAI client library는 key로 전달한 값을 그대로 전송합니다. 따라서 flag를 제거하지 말고 client에서 해당 값을 설정합니다.

vLLM이 model을 찾을 수 없다고 표시합니다. Ollama는 필요할 때 model을 pull하지만, vLLM은 그렇지 않습니다. request body의 model field가 실행할 때 지정한 repository id 또는 --served-model-name를 설정한 경우 해당 값과 일치해야 합니다. curl http://localhost:8000/v1/models으로 정확한 문자열을 확인합니다.

둘 다 실행하는 것이 합리적인 방법입니다

둘 중 하나만 선택해야 하는 것은 아닙니다. 일반적인 구성은 GPU 인스턴스에서 vLLM을 실행해 애플리케이션에 서비스를 제공하고, 일반 VPS에서는 Ollama를 실행해 로컬 스크립트, cron 작업, 새로운 모델 릴리스 테스트에 사용하는 방식입니다. 두 엔드포인트 모두 OpenAI 호환성을 제공하므로, 하나의 클라이언트 라이브러리와 base URL 전환만으로 두 환경을 사용할 수 있습니다. 여기서는 어느 엔진을 선택하는지보다 비용 관리가 더 중요합니다. 유휴 GPU에도 사용 중인 GPU와 동일한 비용이 발생하기 때문입니다. 또한 에이전트 및 추론 비용을 예측 가능하게 유지하는 것은 서버를 선택하는 일과 별개의 운영 분야입니다.

FAQ

vLLM은 Ollama보다 빠릅니까?

동일한 GPU에서 단일 요청을 처리할 때는 두 시스템이 동일한 연산을 수행하므로 차이가 크지 않습니다. 동시 요청이 많을 때는 vLLM이 훨씬 빠릅니다. 연속 배칭을 사용하여 활성 상태인 모든 시퀀스를 한 번의 forward pass에서 디코딩하기 때문입니다. 반면 Ollama의 기본 동작은 요청을 하나씩 처리합니다. CPU만 사용하는 시스템에서는 이 질문이 적용되지 않습니다. Ollama는 CPU에서 실행되지만 vLLM은 사실상 실행되지 않습니다.

vLLM은 GPU 없이 실행할 수 있습니까?

실용적으로는 어렵습니다. 표준 wheel은 NVIDIA 또는 AMD GPU를 대상으로 합니다. 배치 요청으로 accelerator를 포화 상태로 유지하는 것이 vLLM의 목적이므로, CPU에서는 vLLM이 필요한 이유가 사라집니다. 개발 작업을 위한 CPU backend는 존재합니다. 실제 CPU 추론에는 Ollama 또는 llama.cpp를 직접 사용합니다.

Ollama와 llama.cpp의 차이는 무엇입니까?

llama.cpp는 추론 library이고, GGUF는 해당 library의 양자화된 weight 형식입니다. Ollama의 runner는 llama.cpp를 기반으로 구축되었으며, llama.cpp에서 사용자가 직접 처리해야 하는 기능을 추가합니다. 여기에는 model registry, 자동 다운로드, 상주 server, systemd unit, OpenAI 호환 endpoint가 포함됩니다. Ollama는 일부 최신 model family에 자체 engine을 추가했으므로 두 시스템의 내부 구현은 더 이상 동일하지 않습니다.

8B model에 필요한 GPU memory는 얼마입니까?

16-bit precision에서는 weight만 약 16 GB가 필요합니다. 이는 parameter 1 billion당 대략 2 GB이며, 여기에 KV cache를 위한 공간이 추가로 필요합니다. 24 GB card는 충분합니다. 16 GB card를 사용하려면 quantized checkpoint 또는 더 작은 model이 필요합니다. vLLM은 --gpu-memory-utilization에 따라 설정된 card memory의 일부를 사용합니다. 2026년 7월 기준 기본값은 0.92입니다.

두 시스템을 전환하려면 application code를 변경해야 합니까?

대개 base URL, API key, model name만 변경하면 됩니다. Ollama는 http://127.0.0.1:11434/v1에서 OpenAI 호환 interface를 제공하며 key를 무시합니다. vLLM은 http://localhost:8000/v1에서 제공하며, key를 설정한 경우 이를 적용합니다. Model name의 형식은 서로 다릅니다. Ollama에서는 llama3.1:8b를 사용하고, vLLM에서는 Qwen/Qwen2.5-1.5B-Instruct와 같은 전체 repository id를 사용합니다.

#ollama#vllm#llm #inference #self-hosting