셀프 호스팅 서빙 선택 — llama.cpp, Ollama, TGI, vLLM, SGLang
2026년 자체 호스팅(self-hosted) 추론(inference) 시장은 네 개의 엔진(engine)이 주도합니다. 하드웨어, 규모, 생태계(ecosystem)를 기준으로 선택합니다. llama.cpp는 CPU에서 가장 빠릅니다. 지원하는 모델 폭이 가장 넓고, 양자화(quantization)와 스레딩(threading)을 완전히 제어할 수 있습니다. Ollama는 개발용 노트북에서 단일 명령(one-command) 설치를 제공합니다. llama.cpp보다 약 15-30% 느리며(Go + CGo + HTTP 직렬화(serialization)의 오버헤드), 운영 환경에 가까운 부하에서는 처리량(throughput) 격차가 3배까지 벌어집니다. TGI는 2025년 12월 11일부터 유지보수 모드(maintenance mode)에 들어갔습니다. 앞으로는 버그 수정만 제공됩니다. 원시 처리량(raw throughput)은 vLLM보다 약 10% 느리지만, 역사적으로 관측 가능성(observability)과 Hugging Face 생태계(HF-ecosystem) 통합 측면에서는 최상위였습니다. 유지보수 상태로 인해 장기적 선택지로는 위험합니다. 새 프로젝트의 더 안전한 기본값은 SGLang 또는 vLLM입니다. vLLM은 범용 운영(production) 환경의 기본값입니다. v0.15.1(2026년 2월)은 PyTorch 2.10, RTX Blackwell SM120, H200 최적화를 추가합니다. SGLang은 에이전트(agentic) 멀티 턴(multi-turn) / 접두사(prefix) 재사용이 많은 워크로드(workload) 전문 엔진입니다. xAI, LinkedIn, Cursor, Oracle, GCP, Azure, AWS에서 40만 개 이상의 GPU가 운영 환경에 투입되어 있습니다. 하드웨어 제약: CPU 전용 → llama.cpp만 가능. AMD / 비 NVIDIA → vLLM만 가능(TRT-LLM은 NVIDIA 전용입니다). 2026년 파이프라인 패턴: 개발 = Ollama, 스테이징(staging) = llama.cpp, 운영 = vLLM 또는 SGLang. 같은 GGUF/HF weights를 단계 전반에서 그대로 사용합니다.
유형: Learn
언어: Python (stdlib, engine-decision tree walker)
선수 지식: 엔진을 다룬 Phase 17 lesson 전체(04, 06, 07, 09, 18)
예상 시간: 약 45분
학습 목표
- 하드웨어(CPU / AMD / NVIDIA Hopper / Blackwell), 규모(사용자 1명 / 100명 / 10,000명), 워크로드(일반 채팅 / 에이전트 / 긴 컨텍스트(long-context))가 주어졌을 때 엔진을 선택할 수 있습니다.
- 2026년 TGI 유지보수 모드 상태(2025년 12월 11일)와 이로 인해 새 프로젝트가 vLLM 또는 SGLang 쪽으로 기우는 이유를 설명할 수 있습니다.
- 같은 GGUF 또는 HF weights를 그대로 사용하는 개발/스테이징/운영 파이프라인을 설명할 수 있습니다.
- "CPU 전용"이 llama.cpp를 강제하고, "AMD"가 TRT-LLM을 제외시키는 이유를 설명할 수 있습니다.
문제
팀이 새로운 자체 호스팅 LLM 프로젝트를 시작합니다. 한 엔지니어는 Ollama를 추천하고, 다른 엔지니어는 vLLM을 추천하며, 세 번째 엔지니어는 "TGI는 그냥 박스를 열자마자(out of the box) 잘 돌아가지 않나?"라고 말합니다. 세 사람 모두 서로 다른 맥락에서는 옳습니다. 하지만 모든 맥락에 맞는 답은 없습니다.
2026년에는 선택 트리(choice tree)가 중요합니다. 하드웨어가 첫째, 규모가 둘째, 워크로드가 셋째입니다. 그리고 2025년의 한 가지 특정 사건, 즉 12월 11일 TGI가 유지보수 모드에 들어간 일이 새 프로젝트의 기본 선택을 바꿔놓았습니다.
개념
다섯 가지 엔진
| 엔진 | 적합한 용도 | 비고 |
|---|
| llama.cpp | CPU / 엣지(edge) / 의존성 최소화 / 가장 넓은 모델 지원 | CPU에서 가장 빠르고 완전한 제어 가능 |
| Ollama | 개발용 노트북, 단일 사용자, 단일 명령 설치 | llama.cpp 대비 15-30% 느림. 운영 처리량 격차 3배 |
| TGI | Hugging Face 생태계, 규제 산업 | 2025년 12월 11일부터 유지보수 모드 |
| vLLM | 범용 운영, 100명 이상의 사용자 | 폭넓은 운영 기본값. v0.15.1, 2026년 2월 |
| SGLang | 에이전트 멀티 턴, 접두사 재사용 많은 워크로드 | 40만 개 이상의 GPU가 운영 중 |
하드웨어 우선 결정
CPU 전용 → llama.cpp입니다. Ollama도 동작하지만 더 느립니다. 다른 엔진은 CPU에서 경쟁력이 없습니다.
AMD GPU → vLLM(AMD ROCm 지원)입니다. SGLang도 동작합니다. TRT-LLM은 NVIDIA 전용이므로 제외됩니다.
NVIDIA Hopper(H100 / H200) → vLLM, SGLang, TRT-LLM 중 하나입니다. 셋 모두 최상위 등급입니다.
NVIDIA Blackwell(B200 / GB200) → TRT-LLM이 처리량 선두입니다(Phase 17 · 07). vLLM과 SGLang도 근소한 차이로 따라옵니다.
Apple Silicon(M 시리즈) → llama.cpp입니다(Metal). Ollama는 이를 한 번 더 감쌉니다.
규모 차순위 결정
사용자 1명 / 로컬 개발 → Ollama입니다. 단일 명령으로 설치되고, 첫 토큰(first-token)이 수 초 안에 나옵니다.
사용자 10-100명 / 소규모 팀 → vLLM 단일 GPU입니다.
사용자 100-10,000명 / 운영 → vLLM 운영 스택(production-stack)(Phase 17 · 18) 또는 SGLang입니다.
사용자 10,000명 이상 / 엔터프라이즈 → vLLM 운영 스택 + 분리(disaggregated)(Phase 17 · 17) + LMCache(Phase 17 · 18)입니다.
워크로드 후순위 결정
일반 채팅 / 질의응답(Q&A) → 범용 기본값으로는 vLLM이 우세합니다.
에이전트 멀티 턴(도구, 계획, 메모리) → SGLang의 RadixAttention(Phase 17 · 06)이 강력합니다.
접두사 재사용이 많은 RAG → SGLang입니다.
코드 생성 → vLLM도 충분합니다. 캐시(cache) 측면에서는 SGLang이 약간 더 낫습니다.
긴 컨텍스트(128K 이상) → vLLM + 청크 사전 채움(chunked prefill) 또는 SGLang + 계층화 KV(tiered KV)입니다.
TGI 유지보수 함정
Hugging Face TGI는 2025년 12월 11일 유지보수 모드에 들어갔습니다. 앞으로는 버그 수정만 제공됩니다. 역사적으로는 최상위 관측 가능성과 최고 수준의 Hugging Face 생태계 통합(모델 카드(model cards), 안전 도구(safety tools))을 제공했고, 원시 처리량 면에서는 vLLM보다 약간 뒤처졌습니다.
2026년 새 프로젝트에서는 TGI를 기본값으로 두지 않습니다. 기존 TGI 배포는 계속 운영할 수 있지만 결국에는 이전(migrate)해야 합니다. SGLang과 vLLM이 더 안전한 기본 선택입니다.
파이프라인 패턴
개발(Ollama) → 스테이징(llama.cpp) → 운영(vLLM). 같은 GGUF 또는 HF weights를 단계 전반에서 그대로 사용합니다. 엔지니어는 노트북에서 빠르게 반복(iterate)하고, 스테이징은 운영 환경의 양자화 설정을 그대로 거울처럼 비추며(mirror), 운영은 실제 서빙 목표입니다.
Ollama 주의 사항
Ollama는 개발에는 훌륭합니다. 공유 운영 환경에는 좋지 않습니다. Go 기반 HTTP 직렬화가 오버헤드를 더하고, 동시성(concurrency) 관리가 vLLM보다 단순하며, OpenTelemetry 지원도 뒤처집니다. Ollama는 빛나는 자리, 즉 단일 사용자와 단일 명령 환경에 사용하고, 공유 환경에서는 vLLM으로 전환합니다.
자체 호스팅과 매니지드(managed)는 별개의 결정
Phase 17 · 01(매니지드 하이퍼스케일러(managed hyperscalers))과 · 02(추론 플랫폼(inference platforms))은 매니지드를 다룹니다. 이 lesson은 이미 자체 호스팅하기로 결정했다고 가정합니다. 자체 호스팅을 선택하는 이유는 데이터 거주성(data residency), 자체 파인튜닝(fine-tune), 대규모에서의 총소유비용(total cost ownership), 매니지드 서비스에 없는 도메인 특화 모델 등이 있습니다.
기억해야 할 숫자
- TGI 유지보수 모드: 2025년 12월 11일.
- vLLM v0.15.1: 2026년 2월. PyTorch 2.10, Blackwell SM120 지원.
- SGLang 운영 규모: 40만 개 이상의 GPU.
- Ollama 처리량 격차(vs llama.cpp): 15-30% 느림. 운영 부하에서는 3배.
사용해보기
code/main.py는 결정 트리(decision-tree) 워커입니다. 하드웨어 + 규모 + 워크로드가 주어지면 엔진을 선택하고 그 이유를 설명합니다.
산출물 만들기
이 lesson은 outputs/skill-engine-picker.md를 만듭니다. 제약 조건이 주어지면 엔진을 선택하고 이전 계획(migration plan)을 작성합니다.
연습문제
- 쉬움: 자신의 하드웨어 / 규모 / 워크로드로
code/main.py를 실행합니다. 출력이 직관과 일치합니까?
- 중간: 인프라가 H100 12대와 AMD MI300X 8대로 구성되어 있습니다. 어떤 엔진을 고릅니까? TRT-LLM이 왜 후보에서 빠집니까?
- 중간: 팀이 2026년에 "우리가 익숙한 도구"라는 이유로 TGI를 쓰고 싶어합니다. 이전(migration) 근거를 설득력 있게 제시합니다.
- 중간: Ollama 개발에서 vLLM 운영으로 넘어갈 때 양자화, 구성(configuration), 관측 가능성에서 무엇이 바뀝니까?
- 어려움: P99 접두사 길이가 8K이고 테넌트(tenant) 간 재사용이 높은 RAG 제품입니다. 엔진을 고르고 Phase 17 · 11 + 18과 함께 스택으로 구성합니다.
핵심 용어
| 용어 | 흔한 설명 | 실제 의미 |
|---|
| llama.cpp | "CPU용 그것" | 가장 넓은 모델 지원과 CPU에서 가장 빠른 성능 |
| Ollama | "노트북용 그것" | 단일 명령 설치, 개발 수준의 처리량 |
| TGI | "Hugging Face 서빙" | 2025년 12월부터 유지보수 모드 |
| vLLM | "기본값" | 2026년 폭넓은 운영 기준 |
| SGLang | "에이전트용 그것" | 접두사 재사용 강세, RadixAttention |
| TRT-LLM | "NVIDIA 전용" | Blackwell 처리량 선두, NVIDIA만 가능 |
| GGUF | "llama.cpp 포맷" | K-quant 변형이 함께 묶인 형식 |
| Production-stack | "vLLM 쿠버네티스(K8s)" | Phase 17 · 18 참조 배포 |
| Pipeline pattern | "개발→스테이지→운영" | 같은 weight 위에서 Ollama → llama.cpp → vLLM |
더 읽을거리