| 항목 | vLLM | Ollama |
|---|---|---|
| 적합 사용처 | SaaS, 사내 LLM 서빙, 고동시성 | 프로토타입, 개인 PC, 엣지 |
| 주 목적 | 고성능 프로덕션 서빙 | 로컬 개발/개인 사용 |
| 핵심 기술 | PagedAttention, Continuous Batching | llama.cpp 래퍼 (GGUF) |
| 처리량 | 매우 높음 (동시 요청 최적화) | 낮음~중간 (단일 사용자 위주) |
| 지연시간 | 낮음 (대규모 동시 처리 시) | 낮음 (단일 요청 시) |
| 하드웨어 | NVIDIA GPU 중심 (AMD/TPU 일부) | CPU/GPU/Apple Silicon 모두 |
| 모델 포맷 | HuggingFace (FP16/BF16, AWQ, GPTQ) | GGUF (양자화 중심) |
| 양자화 | AWQ, GPTQ, FP8, INT8 등 | Q4_K_M 등 다양한 GGUF 양자화 |
| 메모리 효율 | KV 캐시 페이징으로 매우 효율적 | 양자화 기반 저메모리 |
| 설치/운영 | Docker/k8s, 설정 복잡 | ollama run 한 줄, 매우 쉬움 |
| API | OpenAI 호환 REST | OpenAI 호환 REST + 자체 API |
| 멀티 GPU | Tensor/Pipeline Parallelism 지원 | 제한적 (단일 노드 위주) |
| 확장성 | 수평 확장, 프로덕션급 | 단일 머신 |
| 라이선스 | Apache 2.0 | MIT |
Function/Tool Calling 관점 비교
| 항목 | vLLM | Ollama |
|---|---|---|
| OpenAI tools API 호환 | ✅ tools, tool_choice 완전 지원 | ✅ 지원 (v0.3+) |
| 지원 모델 | Llama 3.1/3.3, Mistral, Hermes, Qwen2.5, Granite 등 다수 | Llama 3.1/3.2, Qwen2.5, Mistral, Firefunction 등 |
| Tool parser | 모델별 전용 파서 (--tool-call-parser 플래그: hermes, mistral, llama3_json, pythonic 등) | 모델 템플릿(tools Jinja)에 내장, 자동 파싱 |
| 스트리밍 tool call | ✅ 지원 (파서별 차이 있음) | ⚠️ 부분 지원 (모델/버전 의존) |
| 병렬 tool calls | ✅ 모델이 지원하면 가능 | ✅ 가능하나 모델 의존도 큼 |
| 구조화 출력(JSON schema) | ✅ Outlines/xgrammar로 강력 | ⚠️ format: "json" 수준, schema 강제 약함 |
| 에이전트 프레임워크 호환 | LangChain, LlamaIndex, OpenAI SDK 그대로 | 동일하게 호환, 단 정확도는 모델·양자화에 좌우 |
권장 사용 시나리오
| 상황 | 추천 |
|---|---|
| 다수 사용자에게 LLM API 서빙 | vLLM |
| Tool calling 정확도/스키마 강제가 핵심인 에이전트 | vLLM (guided decoding) |
| GPU 클러스터에서 처리량 극대화 | vLLM |
| 맥북/미니PC에서 로컬 실험·프로토타입 | Ollama |
| 단일 사용자 챗봇/IDE 통합 | Ollama |
| 양자화 모델로 저사양에서 빠르게 가동 | Ollama |
- 처리량·동시성·tool calling 신뢰성이 중요하면 vLLM.
- 간편함·로컬 실행·하드웨어 유연성이 중요하면 Ollama.
- Tool calling은 둘 다 OpenAI 호환 인터페이스를 제공하지만, 스키마 강제와 강제 호출(
required/특정 함수 지정) 측면에서 vLLM이 우위. Ollama는 모델 템플릿에 의존하므로 양자화·모델 선택에 따라 결과 품질 편차가 큼.