가이드

작성자 Matt Connor 2026-10-30

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

Q: 두 도구 사이를 전환할 때 애플리케이션 코드를 수정해야 하나요?

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

Ollama는 개인용 CPU 환경과 편의성에 최적화되어 있으며, vLLM은 GPU 기반의 대규모 처리량과 동시 요청 처리에 특화된 엔진입니다. 서비스 규모와 하드웨어 사양에 따라 어떤 도구를 선택해야 하는지, 각각의 실행 명령어와 아키텍처 차이를 상세히 분석합니다.

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가 서비스하는 대부분의 모델은 GGUF 파일이며, 보통 4비트 양자화가 적용되어 있습니다. 이 덕분에 7B 또는 8B 모델이 16GB가 아닌 5GB 정도의 디스크 용량을 차지합니다. 양자화는 CPU 추론에 필요한 메모리를 줄여줍니다. Apple Silicon Mac에서는 MLX 엔진을 통해 safetensors 기반 모델을 실행할 수 있으며, v0.40.0(2026년 9월)부터는 지원되는 아키텍처가 MLX에서 자동으로 실행됩니다.

Ollama의 GGUF 러너는 일반 하드웨어에서 GGUF 양자화를 실용적으로 만든 C++ 추론 라이브러리인 llama.cpp를 기반으로 구축되었습니다. 2026년 10월 기준으로 Ollama는 llama.cpp와 MLX라는 두 가지 엔진을 지원하며, Linux 빌드는 CUDA를 사용한 MLX 추론도 지원합니다. 개발 가이드는 cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13를 통해 해당 백엔드를 활성화하며, CUDA 13+ 및 cuDNN 9+가 전제 조건입니다. 따라서 사람들이 Ollama와 llama.cpp를 비교할 때, 사실상 편의 계층과 그 계층이 감싸고 있는 핵심 라이브러리를 비교하는 셈입니다.

설계 목표는 단일 사용자입니다. 2026년 10월 기준으로 OLLAMA_NUM_PARALLEL의 기본값은 1입니다. 이는 한 번에 하나의 모델이 하나의 요청을 처리하며, 나머지는 기본적으로 512개 항목을 담을 수 있는 큐(OLLAMA_MAX_QUEUE)에서 대기함을 의미합니다. 병렬 처리 설정을 높일 수 있으며, 아래 섹션에서 그에 따른 비용을 설명합니다. Ollama를 처음 사용한다면 VPS에서 Ollama를 호스팅하고 11434 포트를 닫아두는 방법부터 시작하십시오. 로컬 API는 인증을 요구하지 않기 때문입니다.

vLLM의 실제 정체

vLLM은 추론 서버 그 이상도 이하도 아닙니다. 모델 라이브러리를 관리하지 않으며, 실행 중인 서버를 위한 vllm chat 클라이언트를 제공할 뿐, 요청 시점에 모델을 자동으로 내려받지 않습니다. 실행 시 Hugging Face 저장소 이름을 지정하면 해당 모델 하나를 불러오고, 프로세스를 중단할 때까지 해당 모델을 서비스합니다.

이러한 제한적인 기능 덕분에 높은 처리량을 얻을 수 있습니다. 두 가지 메커니즘이 이 역할을 수행합니다. PagedAttention은 운영 체제가 메모리를 페이징하는 방식과 유사하게, KV 캐시(모델이 활성 요청마다 유지하는 토큰별 어텐션 상태)를 고정 크기 블록으로 저장합니다. 요청마다 최악의 상황을 대비해 큰 연속 메모리 공간을 예약할 필요가 없으므로, 이전에는 예약만 해두고 사용하지 않던 메모리를 더 많은 동시 요청을 처리하는 데 활용할 수 있습니다. 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는 컨텍스트 할당량을 나누는 대신 곱합니다. FAQ에 따르면 필요한 RAM은 OLLAMA_NUM_PARALLEL 곱하기 OLLAMA_CONTEXT_LENGTH만큼 확장됩니다. 따라서 8192 토큰으로 설정된 모델에 4개의 병렬 요청이 들어오면 각각 8192 토큰을 유지해야 하므로, 서버는 총 32768 토큰에 해당하는 캐시를 보유해야 합니다. 8192라는 값 자체가 고정된 것이 아니라 선택 사항이므로, num_ctx를 높이고 이에 따른 RAM 비용을 산정하는 것이 4개의 슬롯을 수용할 수 있을지 결정하는 핵심 단계입니다. vLLM의 페이징된 캐시는 요청이 실제로 증가함에 따라 블록을 할당하므로, 모든 슬롯에 대해 전체 윈도우를 미리 예약할 필요가 없습니다. 어느 쪽이든, 단일 서버가 동시에 처리할 수 있는 사용자 수의 상한선은 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분 후에 모델을 언로드하기 때문이며, 요청 사이에 모델을 상주시키는 것은 최대 30분 정도의 공백 이후 첫 번째 프롬프트에서 전체 로드 시간을 다시 소모하지 않게 해줍니다. 만약 유휴 시간이 그보다 길다면 더 긴 값을 설정하십시오.

vLLM 설치 및 서비스

vLLM의 GPU 빌드는 Linux 환경이 필요합니다(Apple Silicon 기반 macOS는 0.32.0 릴리스에서 CPU 전용 휠을 지원하며, 해당 Mac에서의 GPU 가속은 MLX 기반의 별도 커뮤니티 유지 관리 플러그인인 vLLM-Metal을 통해 제공됩니다). Python의 경우 현재 릴리스(0.32.0, 2026년 10월)는 3.11부터 3.14까지 지원하며, 설치 가이드에도 동일한 범위가 명시되어 있습니다. Python 3.10은 0.32.0에서 지원이 중단되었으므로 아래에서 사용하는 3.12가 안전한 선택입니다. 특정 PyTorch 빌드를 불러오므로 전용 가상 환경에 설치하십시오.

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

마지막 줄은 2026년 10월 기준 vLLM의 NVIDIA 설치 가이드에 포함된 내용입니다. 이 명령은 FlashInfer의 사전 컴파일된 커널을 설치합니다. 이 커널이 없으면 vLLM은 시작 시 커널을 다운로드하고 컴파일하는데, 가이드에 따르면 Hopper 및 최신 GPU에서는 이 과정으로 인해 수 분이 추가될 수 있습니다. 커널이 일치하지 않으면 FlashInfer를 가져올 수 없으므로, vLLM을 업그레이드할 때마다 이 명령을 다시 실행하십시오.

그다음 모델을 서비스합니다. 모델 이름은 짧은 태그가 아니라 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은 컨테이너가 호스트 공유 메모리에 접근할 수 있게 합니다. --shm-size를 늘리는 것도 다른 방법입니다. PyTorch는 특히 텐서 병렬 추론을 위해 공유 메모리를 통해 프로세스 간에 텐서를 전달합니다.

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

vLLM은 인증 플래그를 지원하지만 Ollama 로컬 API는 인증이 없음

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

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

동일한 값을 VLLM_API_KEY 환경 변수에서 가져올 수 있습니다. 토큰 없이 /v1 경로로 요청을 보내면 HTTP 401 오류가 발생합니다. 하지만 이 키가 서버 전체를 보호하지는 않습니다. vLLM 보안 가이드와 0.32.0 소스 코드의 인증 코드는 /v1, /v2, /inference, /cohere 경로 접두사 아래의 엔드포인트에만 이를 적용합니다. vllm serve 페이지의 --api-key 도움말 텍스트에는 처음 세 가지만 나열되어 있지만, 코드는 네 가지 모두를 확인합니다. 가이드와 도움말 텍스트 모두 /v1와 동일한 추론 기능을 노출하는 /invocations와 같은 다른 엔드포인트는 인증되지 않는다고 명시합니다. 이것만으로도 8000 포트를 공용 인터페이스에 노출해서는 안 될 충분한 이유가 됩니다. 또한 vLLM 보안 가이드는 속도 제한(rate limiting)을 앞단의 리버스 프록시에 맡기며, 일반 HTTP로 전송된 토큰은 전송 중에 읽힐 수 있습니다. 다만 해당 플래그는 서버가 호출자를 식별하는 개념을 가지고 있음을 의미합니다.

Ollama의 로컬 API는 인증을 요구하지 않습니다. 클라우드 모델, 모델 게시, 비공개 모델 다운로드는 로그인이 필요하며, ollama.com에 대한 직접적인 API 접근은 API 키가 필요합니다. 11434 포트에 접근할 수 있는 모든 프로세스는 모델을 실행, 가져오기(pull), 삭제할 수 있습니다. 루프백 인터페이스에 유지하고 직접 호스팅하는 WireGuard VPN을 통해 접근하거나, TLS(전송 계층 보안)를 종료하는 인증 기반 리버스 프록시를 통하십시오.

하드웨어: 각 항목별 요구 사항

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

vLLM은 GPU를 전제로 합니다. 기본 경로에서는 16비트 정밀도의 비양자화 가중치를 사용하며, 이는 10억 개의 파라미터당 약 2GB를 소모합니다. 즉, 8B 모델은 가중치만으로도 약 16GB의 비디오 메모리가 필요하며, 이는 vLLM을 설치한 목적인 동시성 처리를 위한 KV 캐시를 확보하기 전의 수치입니다. 24GB 카드에서는 캐시를 운용할 여유가 있지만, 16GB 카드에서는 부족합니다. 이 경우 더 작은 모델을 선택하거나, --quantization 플래그를 전달하여(양자화된 체크포인트를 사용하거나 로드 시점에 전체 정밀도 가중치를 양자화) 해결해야 합니다. 또는 --cpu-offload-gb 플래그를 사용하여 가중치 일부를 시스템 RAM으로 밀어낼 수 있습니다. 이 방식은 정밀도는 유지되지만, 순전파(forward pass)가 일어날 때마다 가중치가 GPU로 이동해야 하므로 속도가 느려집니다. CPU 백엔드도 별도의 휠(wheel)로 존재하지만, 이는 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 캐시 오류로 시작되지 않습니다. 메시지에는 두 숫자가 모두 표시됩니다.

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

모델이 선언한 컨텍스트 윈도우가 가중치를 로드한 후 남은 메모리보다 큽니다. --max-model-len 8192으로 값을 낮추거나, 다른 프로세스가 카드를 사용하지 않는다면 --gpu-memory-utilization를 높이십시오.

Ollama가 생성 도중 Killed를 출력합니다. Linux의 OOM(Out-of-memory) 킬러가 프로세스를 중단시킨 경우입니다. 모델이 시스템의 전체 RAM보다 더 많은 메모리를 필요로 했기 때문입니다. sudo dmesg | grep -i oom로 이를 확인하십시오. 해결 방법은 설정을 변경하는 것이 아니라 더 작거나 더 많이 양자화된 모델을 사용하는 것입니다.

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

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

vLLM이 모델을 찾을 수 없다고 표시합니다. Ollama는 필요할 때 모델을 가져오지만(pull), 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) 기술을 통해 활성화된 모든 시퀀스를 한 번의 포워드 패스로 디코딩하지만, Ollama는 기본적으로 요청을 순차적으로 처리하기 때문입니다. CPU 전용 환경에서도 두 도구 모두 추론 경로를 지원하며, vLLM은 별도의 CPU용 휠(wheel)을 사용합니다.

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

네, CPU 백엔드를 통해 가능합니다. 표준 휠은 NVIDIA 또는 AMD GPU를 대상으로 하며, 배치 요청으로 가속기를 포화 상태로 유지하는 vLLM의 존재 이유는 CPU 환경에서는 사라집니다. x86 및 Arm용 휠이 별도로 제공되는 CPU 백엔드가 존재하기는 합니다. 실제 CPU 추론이 목적이라면 Ollama나 llama.cpp를 직접 사용하는 것이 좋습니다.

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

llama.cpp는 추론 라이브러리이며, GGUF는 해당 라이브러리의 양자화 가중치 형식입니다. Ollama는 GGUF 추론을 위해 llama.cpp를 사용하며, 여기에 모델 레지스트리, 태그 기반 다운로드, 모델 관리 기능, systemd 유닛을 추가한 형태입니다. 또한 Ollama는 Apple Silicon에서 safetensors 기반 모델을 실행하는 MLX 엔진을 포함하고 Linux에서 CUDA 빌드를 지원하므로, 내부적으로 항상 동일한 것은 아닙니다.

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

16비트 정밀도에서 가중치만 약 16 GB를 차지하며, 이는 파라미터 10억 개당 약 2 GB에 해당합니다. 여기에 KV 캐시를 위한 추가 공간이 필요하므로 24 GB 카드라면 여유롭습니다. 16 GB 카드를 사용하려면 양자화된 모델이나 더 작은 모델을 사용해야 하며, 혹은 --cpu-offload-gb를 사용하여 가중치 일부를 시스템 RAM으로 옮겨야 하는데 이 경우 속도 저하가 발생합니다. vLLM은 --gpu-memory-utilization으로 설정된 만큼의 GPU 메모리를 점유하며, 2026년 10월 기준으로 기본값은 0.92입니다.

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

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

이 글이 도움이 되었나요?

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