vLLM vs Ollama vs SGLang: LLM 서빙 프레임워크 선택

인프라 AI
5 분 소요

자체 호스팅을 하기로 정했다면(손익분기 계산 참조) 다음 질문은 “무엇으로 서빙하느냐"입니다. 같은 GPU에 같은 모델을 올려도 프레임워크에 따라 처리량이 몇 배씩 차이 납니다. 결론을 먼저 적으면, 노트북·로컬 실험은 Ollama, 다중 사용자 프로덕션은 vLLM이 기본값이고, 복잡한 프롬프트 구조나 에이전트 워크로드는 SGLang을 검토합니다. 서버 규모 추정은 LLM 서버 규모에서 다뤘고, 이 글은 그 위에서 도는 소프트웨어의 선택입니다.

두 갈래: 로컬 실행 vs 프로덕션 처리량 #

프레임워크는 목적이 다른 두 갈래입니다. 하나는 “한 대에서 쉽게 돌리기”, 하나는 “여러 사용자를 높은 처리량으로 받기"입니다. 이 둘을 섞으면 선택이 어긋납니다.

  • Ollama는 llama.cpp 위에 만든 로컬 실행 도구입니다. ollama pull로 모델을 받고 바로 OpenAI 호환 API가 로컬에 뜹니다. 설치와 사용이 가장 단순하고, CPU+GPU 혼합 실행으로 VRAM이 부족한 환경에서도 돕니다. 대신 연속 배칭도, PagedAttention도, 다중 노드도 없습니다. 동시 사용자를 높은 처리량으로 받는 용도가 아닙니다.
  • vLLM은 프로덕션 처리량을 위한 엔진입니다. PagedAttention과 연속 배칭으로 같은 GPU에서 Ollama 대비 3〜4배 처리량을 냅니다. 다중 사용자 서빙의 사실상 표준입니다.
  • SGLang은 vLLM과 같은 고처리량 계열이면서, 복잡한 프롬프트 구조(분기, 다단계, 구조적 출력)와 프리픽스 캐싱에 강점이 있습니다. 에이전트·복합 파이프라인 워크로드에서 유리한 구간이 있습니다.

처리량은 왜 갈리나: PagedAttention과 연속 배칭 #

vLLM·SGLang이 Ollama를 크게 앞서는 이유는 두 가지 기법입니다.

  • 연속 배칭(continuous batching): 배치가 끝나기를 기다리지 않고, 생성 스텝마다 새 요청을 돌아가는 배치에 끼워 넣습니다. 요청마다 길이가 제각각인 LLM 특성상, 짧은 요청이 먼저 끝나 빈 자리가 나면 즉시 새 요청으로 채웁니다. GPU가 노는 시간이 줄어듭니다.
  • PagedAttention: KV 캐시를 운영체제의 페이지처럼 조각내어 관리합니다. 메모리 단편화가 줄어 같은 VRAM에 더 많은 동시 요청이 들어갑니다.

수치로 보면 벤치마크에서 vLLM이 초당 수백 토큰대, Ollama가 수십 토큰대로 나오는 사례가 흔합니다. 부하가 높을수록 격차가 벌어지고, 동시 사용자 5〜10명 수준의 가벼운 부하에서는 격차가 좁습니다. 즉 소수 사용자면 어느 쪽이든 되지만, 사용자가 늘수록 vLLM 계열이 필수가 됩니다. 이 처리량이 곧 손익분기의 토큰당 원가를 정합니다.

2026년 지형 변화: TGI가 유지보수 모드로 #

한동안 vLLM의 대안으로 꼽히던 Hugging Face의 TGI(Text Generation Inference)는 2025년 12월 유지보수 모드로 전환됐습니다. 이제 버그 수정과 문서 PR만 받고, Hugging Face는 새 Inference Endpoint에 vLLM 또는 SGLang을 권장합니다. 오래된 비교 글이 TGI를 주요 선택지로 놓고 있다면 그 부분은 낡았습니다. 지금의 프로덕션 3파전은 사실상 vLLM, SGLang, 그리고 특수 목적의 TensorRT-LLM(NVIDIA 스택 최적화)입니다.

기능 축: 양자화, 구조적 출력, 호환성 #

처리량 외에 실무에서 갈리는 축들입니다.

  • 양자화 지원: vLLM은 AWQ·GPTQ·FP8 등 주요 방식을 폭넓게 받습니다(양자화 비교 참조). Ollama는 GGUF 중심입니다. 어떤 양자화 파일을 서빙할지가 프레임워크 선택을 좁히기도 합니다.
  • 구조적 출력: JSON 스키마 강제, 문법 제약 디코딩이 필요한 경우 SGLang과 vLLM 모두 지원하지만 구현 성숙도가 다릅니다. 에이전트 도구 호출처럼 출력 형식이 엄격한 워크로드라면 이 부분을 먼저 봅니다.
  • API 호환성: 셋 다 OpenAI 호환 API를 제공하므로, 클라이언트 코드 변경 없이 API에서 자체 호스팅으로 갈아탈 수 있습니다. 손익분기에서 말한 하이브리드 전환이 쉬운 이유입니다.
  • 운영 성숙도: vLLM은 커뮤니티가 크고 신모델 지원이 빠릅니다. 새 모델이 나온 직후 서빙해야 한다면 지원 속도가 실질적 기준이 됩니다.

선택 순서 #

  1. 용도부터 가릅니다: 로컬 실험·프로토타입·1인 사용이면 Ollama로 충분합니다. 다중 사용자 프로덕션이면 vLLM 계열입니다.
  2. 처리량 요구를 셉니다: 동시 사용자가 소수면 무엇이든 되지만, 늘어날 계획이면 처음부터 vLLM으로 시작해 재작성을 피합니다.
  3. 워크로드 성격을 봅니다: 단순 채팅·완성이면 vLLM, 분기·다단계·구조적 출력이 많은 에이전트 파이프라인이면 SGLang을 비교합니다.
  4. 양자화 파일과 맞춥니다: 서빙할 모델의 양자화 형식(GGUF vs AWQ/GPTQ)이 프레임워크 지원과 맞는지 확인합니다.
  5. 낡은 선택지를 거릅니다: TGI 신규 도입은 피하고(유지보수 모드), NVIDIA 스택 극한 최적화가 필요할 때만 TensorRT-LLM을 검토합니다.

정리 #

  • 프레임워크는 로컬 실행(Ollama)과 프로덕션 처리량(vLLM·SGLang) 두 갈래입니다. 목적을 섞으면 선택이 어긋납니다.
  • vLLM·SGLang이 Ollama를 3〜4배 앞서는 이유는 연속 배칭과 PagedAttention입니다. 사용자가 늘수록 격차가 벌어집니다.
  • TGI는 2025년 12월 유지보수 모드로 전환됐습니다. 지금의 프로덕션 표준은 vLLM, 대안은 SGLang입니다.
  • 양자화 형식 지원, 구조적 출력 성숙도, 신모델 지원 속도가 처리량 외의 선택 축입니다.
  • 로컬은 Ollama, 다중 사용자는 vLLM 기본, 복잡한 에이전트 워크로드는 SGLang을 비교하는 것이 실무 기본선입니다.
X