로컬 LLM, Ollama와 vLLM 중 무엇으로 운영할까?

로컬 LLM 운영, Ollama와 vLLM 중 무엇을 선택할까?

노트북이나 개인용 어시스턴트, 이미 충분히 빠르게 응답하는 소규모 내부 서비스라면 Ollama를 계속 사용합니다. 동시 요청이 꾸준히 발생하는 공유 GPU 서비스나 분산 추론을 세밀하게 제어해야 하는 환경이라면 vLLM을 선택합니다. 서버에서 돌린다는 이유만으로 엔진을 바꿀 필요는 없습니다.

Ollama는 모델 다운로드부터 설정, 서빙까지 간결한 작업 흐름으로 묶어 주는 모델 실행 도구입니다. vLLM은 여러 요청의 처리 순서를 조율하고, 처리 중에 필요한 메모리를 관리하는 데 초점을 맞춘 추론 엔진입니다. 둘 다 모델 자체는 아닙니다. 같은 애플리케이션을 다른 엔진으로 옮기면 모델이 실행되는 방식이 달라집니다.

판단 기준은 네 가지입니다. 최대 동시 요청 수, 사용 가능한 GPU 메모리, 실제로 배포할 모델 파일과 구성, 사용자에게 보장하려는 지연 시간입니다. 가입자 수로 이를 대신 판단하기는 어렵습니다. 에이전트를 실행하는 소규모 개발팀이 가끔 질문하는 훨씬 큰 사용자 집단보다 더 많은 동시 작업을 만들 수도 있습니다.

소프트웨어 비용과 문서는 2026년 10월 12일에 확인했습니다. 이 글은 공식 문서 비교와 비용 계산 예시를 바탕으로 작성했으며, 추론 벤치마크를 직접 실행하지는 않았습니다. Ollama의 현재 요금 페이지에는 무료 로컬 사용이 명시되어 있고, vLLM의 프로젝트 라이선스는 소프트웨어 사용료 없이 이용할 수 있도록 허용합니다. Ollama 요금, vLLM 라이선스.

기능 비교는 공식 Ollama 동시 처리 문서, vLLM 기능 개요, vLLM 확장 가이드를 기준으로 합니다. 추천은 문서에 나온 기능을 용도에 맞춰 평가한 편집 판단이며, 실측 속도 순위가 아닙니다.

사용자 수·GPU·모델 크기로 선택 범위 좁히기

아래 상황은 무엇부터 검토할지 정하는 출발점이며, 처리 용량을 보장하는 기준은 아닙니다. 여기서 ‘사용자’는 작업이 겹치도록 요청을 보내는 사람이나 에이전트를 뜻하며, 구간은 계획 수립을 위한 예시입니다. 8B 모델은 모델을 정의하는 저장된 수치인 파라미터를 약 80억 개 갖고 있습니다.

모델 크기만으로 구매할 GPU를 정할 수는 없습니다. 모든 가중치를 4비트로 저장한다고 단순화한 덴스 8B 모델은 가중치만 최소 4 GB, 70B 모델은 최소 35 GB가 필요합니다. 계산식은 파라미터 수 × 비트 수 ÷ 8이며, 바이트 단위는 십진법 기준입니다. 여기에 양자화 메타데이터, 더 높은 정밀도로 저장하는 텐서, 런타임, 대화 메모리가 추가됩니다. 어느 쪽도 권장 VRAM 용량을 뜻하지는 않습니다.

따라서 ‘모델을 메모리에 올렸다’는 것만으로는 검증이 충분하지 않습니다. 가중치는 들어가도 사용자가 이어 가는 대화를 담을 공간이 부족할 수 있습니다. 먼저 로컬 코딩 모델 가이드에서 체크포인트를 고른 뒤, 실제 서빙 부하에 맞춰 용량을 산정합니다.

설치와 하드웨어: 첫 컴퓨터에서는 Ollama가 간편합니다

지금 가진 하드웨어에서 유용한 모델을 실행하는 것이 당장의 목표라면 Ollama가 유리합니다. 데스크톱용 다운로드와 명령줄 작업 흐름 덕분에 배포 과정에서 결정할 사항이 줄어듭니다. Linux의 공식 설치 명령은 다음과 같습니다.

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2

서버가 실행 중이 아니라면 ollama serve를 사용합니다. Linux 가이드에는 시작 시 실행되는 서비스 설정도 나옵니다. 다른 사람의 요청을 받는 용도라면 터미널을 계속 열어 두는 것보다 상시 실행 서비스가 적합합니다.

Ollama는 Metal을 통한 Apple GPU 가속, ROCm을 통한 일부 AMD 하드웨어, NVIDIA GPU를 지원하며, Vulkan을 통해 추가 Windows/Linux 기기도 지원합니다. 현재 NVIDIA 안내 페이지에는 컴퓨트 능력 5.0 이상이 명시되어 있으며, 구형 카드의 드라이버 요구 사항은 카드에 따라 다릅니다. Ollama 하드웨어 목록에서 정확한 카드와 운영체제 조합을 확인합니다.

설치부터 체계적으로 관리할 서빙 환경을 구축하려는 경우에는 vLLM이 유리합니다. 현재 NVIDIA용 빠른 시작 가이드는 격리된 Python 환경을 사용합니다. uv와 호환되는 GPU 드라이버가 설치되어 있다면, 문서의 설치 순서는 다음과 같습니다.

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

위 명령은 공식 문서에서 가져온 설치 예시이며, 이 비교를 위해 직접 실행한 명령은 아닙니다. AMD와 Intel 환경에서는 각 백엔드의 설치 안내를 따라야 합니다. vLLM 빠른 시작.

vLLM의 NVIDIA 설치 경로는 Linux와 컴퓨트 능력 7.5 이상을 요구합니다. 이 경로에서는 Windows 네이티브 실행을 지원하지 않으며, 문서는 Windows 사용자에게 WSL을 안내합니다. NVIDIA만 사용할 수 있는 것은 아닙니다. 설치 목차에는 AMD ROCm, Intel XPU, CPU 환경, 커뮤니티가 유지하는 vLLM-Metal 플러그인을 통한 Apple Silicon 지원도 포함되어 있습니다. GPU 요구 사항, 설치 목차.

Apple용 경로는 MLX와 MLX에 최적화된 모델을 사용합니다. CUDA 서버와 같은 동작을 한다고 가정하지 말고 별도의 백엔드로 평가해야 합니다. Mac 중심의 작업 환경에서는 여전히 Ollama가 더 간편한 출발점입니다. 주된 고민이 데스크톱 작업 환경이라면 별도의 Ollama vs LM Studio 비교를 참고합니다.

vLLM vs Ollama 성능, 동시 요청이 선택을 가릅니다

동시 요청이 지속되는 환경에서는 vLLM을 우선 검토하는 편이 좋습니다. 문서에 명시된 스케줄링 기능이 바로 이 부하를 처리하도록 설계되어 있기 때문입니다. 처리량은 일정 시간 동안 완료한 작업의 총량입니다. 요청 하나의 답변이 얼마나 빨리 나타나는지와는 다른 지표입니다.

vLLM의 주요 기능에는 실행 중인 요청이 진행되는 동안 새 작업을 받아들이는 연속 배칭과, 텍스트 생성에 사용하는 키/값 캐시를 관리하는 PagedAttention이 있습니다. 보통 KV 캐시라고 부르는 이 캐시는 대화 토큰을 처리하는 모델의 작업 메모리입니다. vLLM 기능 개요.

청크 단위 프리필은 긴 프롬프트를 읽는 작업을 작은 단위로 나눠, 진행 중인 답변 생성과 처리 시간을 나눠 쓰게 합니다. 프리픽스 캐싱은 반복되는 시스템 프롬프트처럼 프롬프트 앞부분이 일치할 때 기존 처리 결과를 재사용합니다. 프리픽스 캐싱은 프롬프트 처리에 도움이 되지만, 새로운 답변 토큰을 생성하는 작업까지 없애 주지는 않습니다. 스케줄링과 튜닝, 프리픽스 캐싱의 한계.

Ollama도 이미 병렬 요청을 지원합니다

Ollama 공식 문서에 따르면, 메모리가 허용하는 범위에서 모델별 병렬 요청과 여러 모델의 동시 적재를 지원합니다. 전자는 OLLAMA_NUM_PARALLEL, 후자는 OLLAMA_MAX_LOADED_MODELS로 제어합니다. OLLAMA_MAX_QUEUE는 대기 작업 수를 제한하며, 서버가 과부하 상태이면 HTTP 503을 반환할 수 있습니다. 현재 FAQ에 명시된 병렬 요청 기본값은 1입니다. Ollama 동시 처리 설정.

소규모 고객 지원 어시스턴트라면 동시 처리 허용량을 늘리는 것으로 충분할 수 있습니다. 다만 대기열을 늘린다고 연산 용량이 늘어나지는 않습니다. 첫 토큰이 도착하기까지 고객이 기다리는 시간만 길어질 수도 있습니다. 서버가 허용하는 최대 대기열 길이가 아니라 목표 응답 시간을 기준으로 튜닝합니다.

사용자를 더 받을 메모리를 컨텍스트가 먼저 쓸 수 있습니다

엔진을 비교하기 전에 컨텍스트 길이를 명시적으로 설정합니다. Ollama의 컨텍스트 전용 문서는 메모리에 따라 달라지는 기본값을 설명하지만, FAQ에는 여전히 고정 기본값이 나옵니다. 문서끼리도 설명이 다른 만큼, 노트북과 서버의 설정이 같을 것이라고 가정하지 말고 실제 적용된 값을 확인해야 합니다. ollama ps에서 적재된 컨텍스트와 CPU/GPU 배치를 확인할 수 있습니다. Ollama 컨텍스트 안내.

예를 들어 대화당 8,192토큰으로 네 개의 대화를 병렬 처리하도록 설정하면 총 32,768개의 컨텍스트 토큰을 수용할 공간을 확보합니다. 4,096토큰 대화 하나와 비교하면 전체 컨텍스트 용량은 여덟 배지만, 프로세스 전체 RAM 사용량이 여덟 배라는 뜻은 아닙니다. 모델 가중치와 다른 메모리 할당은 같은 비율로 늘어나지 않습니다. Ollama 동시 처리 문서에서도 이처럼 병렬 처리 수에 따라 컨텍스트 용량이 늘어나는 관계를 설명합니다.

vLLM도 메모리 한계에 부딪힙니다. 튜닝 가이드는 KV 공간이 부족하면 작업 선점과 재계산이 발생해 지연 시간이 나빠질 수 있다고 경고합니다. 동시 시퀀스 수나 배치의 토큰 한도를 줄이는 방법도 있고, GPU를 추가하는 방법도 있습니다. 더 뛰어난 스케줄러라도 하드웨어에 없는 메모리를 만들어 낼 수는 없습니다.

합리적으로 튜닝한 뒤에도 실제 사용을 대표하는 최대 부하에서 서비스 목표를 충족하지 못할 때가 전환을 검토할 시점입니다. 첫 토큰까지 걸린 시간, 답변 완료 시간, 성공한 요청 수, 대기열 증가, 오류를 기록합니다. 사용자는 느린 응답을 체감하므로 중앙값과 함께 지연 시간 상위 백분위수도 비교합니다. vLLM은 이런 검증을 위한 운영 지표를 제공합니다.

모델 리비전, 정밀도, 프롬프트 길이, 출력 한도, 트래픽 패턴을 동일하게 맞춥니다. Ollama의 작은 양자화 모델과 vLLM의 더 큰 고정밀도 체크포인트를 비교하면 배포 구성의 차이를 보는 것이지, 엔진만의 차이를 측정하는 것이 아닙니다.

양자화 형식: 모델을 옮기는 일도 마이그레이션의 일부입니다

기존 로컬 모델 패키지를 유지하기에는 Ollama가, 하드웨어에 맞는 서빙 형식을 선택하기에는 vLLM이 유리합니다. 양자화는 모델의 수치를 더 낮은 정밀도로 저장해 메모리 요구량을 줄이는 방법입니다. 파일 컨테이너, 양자화 방식, 실행 백엔드는 각각 따로 호환성을 확인해야 합니다.

Ollama 공식 문서는 Safetensors 가중치와 단일 파일·분할 파일 형태의 GGUF 모델 가져오기를 안내합니다. GGUF는 로컬 추론에 널리 쓰이는 모델 파일 형식입니다. Ollama의 현재 가져오기 가이드에 따르면 GGUF 양자화는 가져오는 도중이 아니라 가져오기 전에 완료해야 합니다. 한편 create API에서는 가져오기 시 양자화하는 예시로 nvfp4를 별도로 제시합니다. 그렇다고 모든 아키텍처와 GPU에서 그 경로를 지원한다는 뜻은 아닙니다. Ollama 모델 가져오기 가이드, create API.

Ollama는 KV 캐시 설정으로 f16, q8_0, q4_0도 명시합니다. 이는 캐시 설정값이며, 모델 가중치 형식과 혼용할 수 있는 목록이 아닙니다. 양자화된 캐시를 사용하려면 Flash Attention이 필요합니다. Ollama 캐시 문서.

vLLM은 AWQ/GPTQ, FP8, INT8, INT4, MXFP4/MXFP8, NVFP4 등 여러 양자화 통합을 지원 목록에 올려 두고 있습니다. 구현과 하드웨어에 따라 지원 범위가 달라지므로, ‘4비트 지원’이라는 설명만으로 구매를 결정하기는 어렵습니다. 정확한 체크포인트와 커널 조합을 검증해야 합니다. vLLM 양자화 문서, 형식 개요.

토크나이저는 텍스트를 모델이 이해하는 토큰 ID로 바꿉니다. 가중치, 토크나이저, 채팅 형식, 양자화를 바꾸면 답변과 툴 호출, 메모리 사용량도 달라질 수 있습니다. 모델 계열 이름이 같아도 회귀 검증에 필요한 시간과 비용을 잡아야 합니다.

Mellum2.1 사례로 보는 모델 배포 패키지의 중요성

JetBrains의 2026년 10월 8일 Mellum2.1 발표는 서버용 구성이 먼저 나오는 출시 패턴을 보여 줍니다. 발표 글은 Ollama, llama.cpp, LM Studio용 GGUF 빌드가 곧 제공될 예정이라고 설명했습니다. 해당 릴리스의 모델 페이지에는 vLLM 서빙 구성이 있으며, 출시 시점의 연동 대상에는 vLLM과 또 다른 추론 서버인 SGLang이 포함되어 있습니다. JetBrains 출시 발표, 릴리스 페이지.

출시 당시의 격차는 이미 줄어들었습니다. 10월 12일에 확인한 JetBrains 공식 GGUF 저장소에는 다운로드할 수 있는 양자화 파일이 있습니다. 발표 글의 ‘곧 제공 예정’을 현재의 제공 상태로 받아들이면 안 됩니다. 새 모델을 쓰기 위해 엔진부터 바꾸기 전에, 현재 제공되는 파일과 서빙 구성을 확인해야 한다는 것이 이 사례의 교훈입니다. 공식 GGUF 파일.

OpenAI 호환 서버: 클라이언트를 유지해도 동작은 검증해야 합니다

두 엔진 모두 OpenAI 호환 서버를 문서화하고 있지만, 요청 형식이 같다고 동작까지 같지는 않습니다. Ollama의 로컬 기본 URL은 http://localhost:11434/v1/이고, vLLM 예시에서는 http://localhost:8000/v1을 사용합니다. 애플리케이션이 Ollama 고유의 /api/chat을 사용한다면 포트만 바꾸는 것으로는 부족하며 API에 맞춰 코드를 수정해야 합니다. Ollama 호환성 문서, vLLM 서버 문서.

예를 들어 호환되는 하드웨어에 vLLM을 설치한 뒤 아래 명령을 실행하면, 공식 서버 예시의 모델을 명시적인 컨텍스트 한도와 애플리케이션에서 사용할 이름으로 서빙할 수 있습니다.

vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --served-model-name app-model

이는 설치·설정 예시입니다. 앞서 나온 Ollama 명령과 동일한 체크포인트를 사용한 것도, 운영 환경의 용량을 권장하는 것도 아닙니다. --served-model-name을 사용하면 배포 구성을 바꿔도 클라이언트는 같은 모델 이름을 유지할 수 있습니다. vLLM 엔진 인수.

메시지 역할을 모델 입력 형식으로 변환하는 채팅 템플릿을 검토하고, 샘플링 파라미터를 명시적으로 설정합니다. vLLM은 저장소의 generation_config.json 기본값을 적용할 수 있습니다. --generation-config vllm을 지정하면 이 기본값 덮어쓰기를 비활성화합니다. 툴 호출 파싱, 구조화된 출력, 스트리밍, 취소, 오류 처리는 애플리케이션이 실제로 보내는 요청을 기준으로 비교합니다.

인증도 이전 작업에 포함해야 합니다. Ollama의 로컬 호환성 예시는 클라이언트가 전달한 API 키 값을 무시합니다. vLLM은 API 키를 지원하지만, 보안 문서는 이 키가 모든 엔드포인트를 보호하지는 않는다고 경고합니다. 백엔드는 비공개로 유지하고 서비스 진입 지점에 인증, TLS, 경로 제한을 적용합니다. vLLM API 키의 한계.

베이스 모델을 자주 바꾸는 앱이라면 또 다른 전환 비용도 고려해야 합니다. vLLM FAQ는 여러 베이스 모델을 사용하려면 별도의 서버 인스턴스와 라우팅 계층을 운영하는 방식을 안내합니다. API에서 모델의 별칭을 지정한다고 다른 모델이 적재되는 것은 아닙니다. 사용량이 적은 내부 툴이라면 여러 적재 모델을 관리하는 Ollama의 기능이 더 편리할 수 있습니다. vLLM의 다중 모델 제약.

가격 차이: 같은 작업에서도 운영 비용은 달라집니다

셀프 호스팅에서는 어느 엔진도 더 저렴한 토큰 요금으로 우위를 갖지 않습니다. 엔진이 청구하는 토큰 요금 자체가 없기 때문입니다. Ollama의 유료 클라우드 요금제는 별도의 서비스이며, 로컬 모델을 서빙하는 데 필요한 조건이 아닙니다. 이 차이는 Ollama 요금 가이드에서 다룹니다. 현재 클라우드 상품은 앞서 링크한 공식 요금 페이지를 확인합니다.

보유한 하드웨어를 사용한다면 월 비용에는 전기료, 하드웨어 비용의 월별 배분액, 운영에 쓰는 시간이 포함됩니다. 하드웨어를 임대한다면 견적의 장비 가동 시간 요금에서 시작해 스토리지, 네트워크, 운영 비용을 더합니다. 추론 효율이 높아져도 확보해야 할 자원이 줄거나, 과금되는 실행 시간이 짧아지거나, 금전적 가치를 평가할 수 있는 사업상 이득이 생겨야 비용 절감으로 이어집니다.

같은 조건으로 계산한 예산 예시

다음은 예산 계산을 위해 명시한 가정이며, 공급업체 요금이나 벤치마크 결과가 아닙니다. GPU 요금은 시간당 $1, 월 사용 시간은 730시간, 성공적으로 완료한 작업은 100,000건으로 가정합니다. 작업 하나는 프롬프트 2,000토큰과 출력 1,000토큰으로 구성되며, 두 엔진에 같은 모델, 양자화, 품질 기준, 지연 시간 목표를 적용합니다.

두 엔진 모두 GPU 한 개를 상시 임대하는 구성으로 목표를 충족한다면, 각각 월 컴퓨팅 비용은 $730입니다. 성공한 작업당 비용과 출력 1,000토큰당 비용은 모두 $0.0073입니다. 출력 토큰을 분모로 삼은 계산은 프롬프트 처리량을 고정한 것이며, 입력과 출력을 합산한 토큰 단가는 아닙니다.

여기에 vLLM 운영을 위해 매월 두 시간이 추가로 들고, 시간당 비용은 $100이라고 가정합니다. 이전 작업에는 일회성으로 네 시간이 든다고 계산합니다.

• 기준이 되는 Ollama 배포: 양쪽에 공통으로 드는 비용을 제외하면 월 $730입니다.
• 같은 하드웨어에서 운영하는 vLLM: 월 $930, 출력 1,000토큰당 $0.0093입니다.
• 이전 비용을 포함한 vLLM 첫 달: $1,330, 출력 1,000토큰당 $0.0133입니다.

이 시간은 각자의 추정치로 바꿔 넣을 계산 입력값이며, 실제 이전 소요 시간을 단정한 수치가 아닙니다. 공통 운영 작업, 스토리지, 네트워크 요금, 세금은 양쪽 모두에서 제외했습니다.

어느 지점에서 더 저렴한 선택이 바뀔까?

위 시간당 요금에서는 vLLM이 가정한 추가 운영 비용을 상쇄하려면 매월 GPU 사용 시간을 200시간 넘게 줄여야 합니다. 첫 달에 이전 비용 $400까지 모두 회수하려면 절감 시간이 600 GPU시간을 넘어야 합니다.

상시 운영 예시로, 직접 수행한 부하 테스트에서 동일한 작업량과 응답 목표를 충족하려면 Ollama는 같은 사양의 GPU 복제본 두 개, vLLM은 한 개가 필요하다고 나왔다고 가정합니다. 이 경우 Ollama의 컴퓨팅 비용은 $1,460이 되고, vLLM의 컴퓨팅 비용과 추가 운영 비용 합계는 $930으로 유지됩니다. 이 조건에서 월 절감액은 $530이며, 이전 비용 $400을 회수하는 데 약 0.75개월이 걸립니다.

이는 손익분기점 계산이며, vLLM이 필요한 GPU 수를 절반으로 줄여 준다는 주장이 아닙니다. 두 엔진에 같은 하드웨어가 필요하고 전환을 정당화할 다른 이점도 없다면, 소프트웨어 사용료만 비교해서 vLLM이 유리해지는 일은 없습니다. 특정 사용자 수를 모든 환경에 통하는 전환 기준으로 제시할 근거도 없습니다.

Ollama에서 vLLM으로 옮기기 전 확인할 사항

모델과 API의 동작을 검증한 뒤, 되돌릴 수 있는 경로 뒤에서 전환합니다. 사용자가 의존하는 것은 다운로드한 가중치만이 아닙니다.

Ollama가 서비스 목표를 충족하거나, 필요한 모델에 검증된 vLLM 실행 경로가 없거나, 이전의 결과가 잘 작동하는 패키지를 익숙하지 않은 백엔드로 바꾸는 데 그친다면 아직 전환하지 않습니다. 노트북에서는 Ollama, 공유 서버에서는 vLLM을 사용하는 것도 합리적일 수 있습니다. 다만 개발 환경과 운영 환경이 같다고 가정하지 말고 차이를 테스트해야 합니다. 후보를 더 넓게 살펴보려면 Ollama 대안을 참고합니다.

다음 행동은 명확합니다. 실제 사용을 대표하는 가장 바쁜 시간대의 부하를 기록하고, 허용할 응답 시간을 정한 뒤, 용량을 추가로 구매하기 전에 도입하려는 서버에서 그 부하를 재현합니다.

자주 묻는 질문

AI 비즈니스 워크플로 진단 체크리스트로 어떤 사내 작업에 공유 모델 서버가 필요한지 판단하고, 이후의 툴 변화를 받아보려면 뉴스레터를 구독합니다.