(폐쇄망 LLM 4) vLLM, Ollama, llama.cpp
폐쇄망/내부망에서 로컬 LLM 서버를 구축할 때 어떤 서빙 프레임워크를 선택해야 하는지 비교합니다. vLLM, SGLang, llama.cpp, Ollama의 장단점을 정리합니다.
이전 글: 추론 속도와 MoE 모델
이 글은 망분리 환경 AI 배포 시리즈의 네 번째 글입니다.
다음 글: 양자화와 정밀도 선택
서빙 프레임워크가 뭔가요?
모델을 골랐으면 이제 실제로 돌려야겠죠?
서빙 프레임워크는 쉽게 말해 모델을 API로 띄워주는 도구입니다. 모델 파일만 있으면 추론이 되는 게 아니거든요. 모델을 메모리에 올리고, 요청이 들어오면 처리하고, 여러 요청을 효율적으로 배치 처리하는 등의 작업이 필요합니다.
대표적인 프레임워크로 vLLM, SGLang, llama.cpp, Ollama가 있습니다. 하나씩 살펴보겠습니다.
llama.cpp: 가볍고 어디서든 돌아간다
llama.cpp는 순수 C/C++로 작성된 추론 엔진입니다. GGUF라는 자체 모델 포맷을 사용하고, CPU에서도 꽤 괜찮은 속도가 나옵니다. 가장 큰 장점은 이식성입니다. Windows, Linux, macOS는 물론이고 라즈베리 파이에서도 돌아갑니다. GPU가 없는 환경이나 엣지 디바이스에서 LLM을 돌려야 한다면 사실상 유일한 선택지입니다.
1
2
3
4
# 서버 실행 예시
# -m : model.gguf : 모델 파일 경로
# -ngl : number of gpu layer 의 약자 -1 은 전부 gpu 사용
./llama-server -m model.gguf -ngl -1 --port 8080
양자화 옵션도 Q2부터 Q8까지 다양해서, 메모리가 부족하면 품질을 좀 희생하고 더 작은 모델을 돌릴 수 있습니다. 다만 동시에 여러 요청을 처리하는 데는 최적화가 덜 되어 있어서, 혼자 쓰기엔 좋지만 여러 명이 동시에 쓰는 서버용으로는 부적합합니다.
Ollama: 5분 만에 시작하기
Ollama는 llama.cpp 기반으로 사용성을 극대화한 도구입니다. 추론 엔진은 llama.cpp를 사용합니다. Docker처럼 ollama run llama3.3 한 줄이면 모델 다운로드부터 실행까지 알아서 됩니다.
1
2
3
4
5
6
7
# 이게 끝입니다
ollama run llama3.3
# OpenAI 호환 API도 기본 제공
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "llama3.3", "messages": [{"role": "user", "content": "Hello"}]}'
로컬에서 빠르게 모델을 테스트해보고 싶을 때 최고입니다. 다만 llama.cpp 기반이라 동시 처리 성능은 마찬가지로 제한적이고, 세밀한 설정이 어렵습니다. 개발 중 테스트용으로는 좋지만, 본운영에 쓰기엔 아쉽습니다.
vLLM: 프로덕션의 표준
vLLM은 UC Berkeley에서 개발한 고처리량 서빙 프레임워크입니다. 핵심은 PagedAttention이라는 기술인데, KV Cache 메모리를 운영체제의 페이징처럼 관리합니다.
1
2
3
4
5
6
7
8
9
10
┌─────────────────────────────────────────────┐
│ PagedAttention Concept │
├─────────────────────────────────────────────┤
│ Before: Contiguous memory per request │
│ → Memory fragmentation, waste │
│ │
│ PagedAttention: Block-based management │
│ → Non-contiguous memory utilization │
│ → Optimized for concurrent requests │
└─────────────────────────────────────────────┘
쉽게 말해, 여러 사람이 동시에 쓸 때 메모리를 효율적으로 나눠 쓴다는 겁니다. 4명이 동시에 긴 대화를 해도 KV Cache가 효율적으로 관리됩니다. vLLM 은 저희가 실전 예제로 나중에 사용해 볼 모델이기 때문에 옵션을 조금 자세히 적어 보겠습니다. 나중에는 훨씬 옵션이 방대해 집니다 ^^;
1
2
3
4
5
6
7
# vllm serve [모델명] : HuggingFace 모델 또는 로컬 경로
vllm serve mistralai/Devstral-Small-2-24B-Instruct-2512 \
--dtype auto \ # 데이터 타입 자동 선택 (fp16/bf16)
--max-model-len 4096 \ # 최대 컨텍스트 길이
--tensor-parallel-size 2 \ # 텐서 병렬화 GPU 수 (2개 GPU 사용)
--max-batch-size 8 \ # 동시 처리할 최대 요청 수
--max_num_batched_tokens 2048 # 한 번에 처리할 최대 토큰 수
2025년 1월에 V1이 출시되면서 이전 버전 대비 1.7배 빨라졌고, HuggingFace Transformers 대비 최대 24배 높은 처리량을 보여줍니다. Red Hat 같은 기업에서도 프로덕션용으로 vLLM을 권장하고 있습니다.
SGLang: 가장 빠른 신예
SGLang은 Stanford LMSYS 팀에서 개발한 프레임워크입니다. 단일 요청 처리 속도가 가장 빠릅니다. 일반적으로 vLLM대비 SGLang 이 단일 요청에서 30%정도 빠른 속도를 보여 주는것 같습니다.
1
2
3
4
5
# Python 서버 실행 예시
python -m sglang.launch_server \
--model-path mistralai/Devstral-Small-2-24B-Instruct-2512 \
--dtype auto \ # 데이터 타입 자동 선택
--tp 2 # 텐서 병렬화 GPU 수 (2개 GPU 사용)
다만 vLLM에 비해 커뮤니티가 작고, 새 모델에 대한 지원은 빠르지만, 문서화나 안정성 면에서는 아직 vLLM이 앞섭니다.
비교 요약
| 상황 | 추천 |
|---|---|
| 혼자 테스트하기 | Ollama |
| GPU 없이 CPU로 | llama.cpp |
| 팀원 여러 명이 동시에 | vLLM |
| 단일 요청 최고 속도 | SGLang |
결론: vLLM 추천
여러 프레임워크를 써본 결론은 vLLM이 현시점 가장 안전한 선택이라는 겁니다.
- 업데이트 속도: 새 모델 지원이 빠름. 생각보다 처음에 모델이 나오면 버그가 많습니다. chat-template, tool-call-parser 등등 안정이 되려면 시간이 필요하고 모델을 만든 곳에서 가장 먼저 지원하는 곳이 vLLM 입니다.
- 동시 처리: PagedAttention으로 여러 사용자 서빙에 최적화
- 성숙도: 가장 오래되고 검증된 프로젝트
SGLang이 단일 속도는 더 빠르지만, 팀 단위로 쓴다면 동시 처리 성능이 더 중요합니다. 저도 현재 vLLM으로 Devstral-Small-2-FP8을 서빙하고 있습니다. 시리즈 첫 글에서 설정한 목표대로 망분리 환경에서도 잘 돌아갑니다.
다음 글
모델과 서빙 프레임워크를 선택했다면, 이제 메모리를 절약하면서도 성능을 유지하기 위한 양자화 전략을 결정할 차례입니다. FP8, AWQ, GPTQ, GGUF 중 어떤 것을 선택해야 할까요?
시리즈 목차
전체 목차는 AI 활용에서 확인하실 수 있습니다.