Ollama vs vLLM vs SGLang: 오픈 LLM 서빙 초보자 가이드
오픈 웨이트 모델을 내 머신에 받는 일은 쉽습니다. 초보자가 막히는 지점은 어떻게 돌릴지—특히 한 명 이상이 동시에 답을 원할 때—를 고르는 일입니다.
셀프 호스팅 이야기마다 거의 등장하는 세 이름이 Ollama, vLLM, 그리고 SGLang입니다. 같은 제품의 세 가지 맛이 아닙니다. 각각 다른 서빙 문제를 풀고, 잘못 고르면 대개 "GPU는 괜찮은데 API가 느리다"는 느낌이 됩니다.
이 가이드는 각 엔진이 무엇을 위한 것인지, 내부 차이를 쉬운 말로 어떻게 다른지, 인터넷의 벤치 차트를 외우지 않고 고르는 간단한 방법을 안내합니다.
추론 엔진이 실제로 하는 일
모델 파일은 가중치입니다. 추론 엔진은 그 가중치를 실제 트래픽 아래 토큰으로 바꾸는 런타임입니다. 모델을 올리고, Attention 상태(KV 캐시)용 GPU 메모리를 관리하고, 어떤 요청을 함께 돌릴지 정한 뒤 토큰을 스트리밍으로 돌려줍니다.
노트북에서 채팅하는 것은 요청 하나입니다. 제품을 서빙하는 것은 시작과 끝이 서로 다른 수많은 겹치는 요청입니다. 엔진 차이는 주로 그 요청을 얼마나 똑똑하게 배치하고, 이미 한 일을 얼마나 재사용하느냐에 있습니다.
세 엔진, 세 가지 역할
노트북이나 워크스테이션에서 몇 분 만에 모델을 올리고 싶은 개발자를 위한 로컬 우선 런타임.
- GGUF / 받아서 바로 실행
- OpenAI 호환 로컬 API
- 단일 사용자 / 가벼운 동시성에 적합
많은 동시 사용자 아래에서도 GPU를 바쁘게 유지하도록 설계된 고처리량 프로덕션 서버.
- 연속 배치(continuous batching)
- PagedAttention 스타일 KV 메모리
- 범용 멀티유저 API의 기본 선택
프리픽스 재사용에 강한 처리량 엔진—에이전트, 멀티턴 채팅, 구조화 출력에 맞춰 만들어졌습니다.
- 프리픽스 인식 스케줄링
- RadixAttention 캐시
- JSON / 정규식 제약 생성
Ollama: 먼저 로컬 데모를 내보내기
Ollama는 설치 속도와 개발자 경험을 최적화합니다. 모델을 받으면 OpenAI 호환 엔드포인트가 뜨고, CUDA 빌드와 씨름하지 않고 프롬프트를 반복할 수 있습니다. 내부적으로는 llama.cpp 계열 GGUF 실행에 기대며, 프로덕션 GPU 서버보다 보수적인 요청 경로를 씁니다.
그 설계는 의도적입니다. 동시 사용자가 사실상 본인이거나 소규모 팀이 프로토타입할 때 뛰어납니다. 수십·수백 개의 겹치는 요청에 안정적인 지연이 필요하면 맞지 않습니다. "API"가 사실상 공유 노트북 프로세스라면, 모델 품질보다 먼저 대기열과 들쭉날쭉한 속도를 느낄 것입니다.
vLLM: GPU를 계속 먹이기
vLLM이 프로덕션 기본값이 된 데는 이유가 있습니다. 연속 배치는 끝난 요청이 배치를 떠나고 새 요청이 다른 모두가 끝날 때까지 기다리지 않고 합류하게 합니다. PagedAttention은 KV 캐시를 고정 크기 블록으로 관리해—요청마다 거대한 연속 슬랩을 예약하기보다 OS 페이징에 가깝게—단편화로 VRAM이 낭비되는 일을 줄입니다.
실무에서는 한 장의 GPU가 순진한 루프보다 훨씬 많은 동시 사용자를 감당합니다. 트래픽이 서로 독립적인 프롬프트(사용자도 다르고 공유 컨텍스트도 적음)라면, vLLM이 보통 가장 안전한 첫 프로덕션 선택입니다. 모델 지원 폭도 넓어 로드맵이 분기마다 바뀌는 팀에 유리합니다.
SGLang: 이미 계산한 것을 재사용하기
SGLang은 vLLM과 같은 고처리량 계열에 있지만, 시그니처는 RadixAttention입니다. 계산된 KV 프리픽스를 기수(radix) 트리에 두고, 새 요청이 같은 프롬프트 앞부분을 공유하면 재사용합니다. 긴 시스템 프롬프트, 공유 RAG 문서, 커지는 멀티턴 히스토리를 매번 처음부터 다시 계산할 필요가 없습니다.
스케줄러도 프리픽스를 인식해 캐시에 잘 맞는 작업을 선호합니다. 에이전트 툴 루프, 고정 서문이 있는 챗봇, 같은 구조가 반복되는 제약 디코딩(JSON 스키마, 정규식)에서 특히 이득입니다.
거의 모든 요청이 처음부터 끝까지 유니크하면 이점은 줄어들고, 운영 익숙도와 모델 지원으로 고르면 됩니다. 토큰의 절반 이상이 공유 프리픽스에 있다면 SGLang은 본격적인 비교 검증 가치가 있습니다.
나란히 비교
| 기준 | Ollama | vLLM | SGLang |
|---|---|---|---|
| 주요 사용자 | 로컬 개발자 | 많은 동시 사용자 | 다수 사용자 + 공유 컨텍스트 |
| 스케줄링 아이디어 | 단순 / FIFO 스타일 | 연속 배치 | 프리픽스 인식 스케줄링 |
| 메모리 기법 | GGUF / 노트북 친화 경로 | PagedAttention KV 블록 | RadixAttention 프리픽스 캐시 |
| 도입 마찰 | 가장 낮음 | 중간 (GPU 서버 운영) | 중간 (GPU 서버 운영) |
| 최적 지점 | 프로토타입, 데모, 로컬 앱 | 고QPS 범용 API | 에이전트, RAG, 멀티턴 채팅 |
실무에서 고르는 법
오늘 노트북에서 동작하는 엔드포인트가 필요하고, 프롬프트나 제품 UX를 검증 중이며, 동시성은 사실상 한 번에 한 사람이라면.
공유 GPU API를 공개하고, 트래픽이 높으며, 요청이 같은 긴 프리픽스를 크게 재사용하지 않는다면.
에이전트, 툴 루프, 멀티턴 채팅, RAG가 같은 시스템 프롬프트/문서를 반복 재생하고, 실제 프리픽스 적중률을 측정할 수 있다면.
공개 처리량 수치는 릴리스마다 움직입니다. 운명이 아니라 방향으로 보세요. 표준화하기 전에 당신의 프롬프트에서 첫 토큰 시간(TTFT)과 초당 토큰을 측정하고, 가능하면 프리픽스 캐시를 켠 뒤 결정하세요.
초보자가 자주 하는 실수
OpenAI JSON은 말할 수 있지만, 높은 동시성에서 GPU 점유율을 극대화하도록 만들어지지 않았습니다. 프로토타입은 거기서, 사용자가 쌓이면 졸업하세요.
RadixAttention은 프롬프트가 줄기를 공유할 때 빛납니다. 호출마다 유니크하면 맞지 않는 캐시를 최적화하는 셈입니다.
vLLM과 SGLang에는 실제 GPU 드라이버, 모니터링, 용량 계획이 필요합니다. 모델 품질에만 시간을 쓰지 마세요.
엔진 순위는 하드웨어, 모델 크기, 워크로드 형태에 따라 바뀝니다. 가능하면 프로덕션 트레이스 재생으로 bake-off 하세요.
빠른 요약
Ollama는 거의 마찰 없이 로컬 채팅 API까지 데려갑니다. vLLM은 범용 트래픽에서 같은 GPU로 더 많은 동시 사용자를 짜냅니다. SGLang은 공유 프리픽스가 지배할 때—에이전트, RAG, 멀티턴 시스템—에 이득이 납니다.
차트상 "승자"가 아니라 오늘 워크로드가 있는 곳에서 시작하세요. 동시성이나 프리픽스 재사용이 병목이 될 때 엔진을 옮기세요—블로그 글이 시켜서가 아닙니다.
최신 소식을 받아보세요
뉴스와 업데이트를 가장 먼저 확인하세요
