2026년 2월 기준 vLLM·TGI·Ollama 배포법: “로컬 개발 → 프로덕션 서빙”까지 한 번에 정리

게시 2026/02/07

By Daewook Kwon

11 분읽는 시간

들어가며

LLM 서빙은 이제 “모델을 띄운다”에서 끝나지 않습니다. 같은 GPU라도 동시성(concurrency), KV cache 메모리 효율, batching 전략, 관측성(observability)에 따라 비용과 UX(특히 TTFT/P99)가 크게 갈립니다. 그래서 팀들이 보통 다음 3축으로 도구를 나눠 씁니다.

Ollama: 로컬/개발 환경에서 가장 빠르게 “돌아가는 상태” 만들기(단순함 우선)
vLLM: 높은 동시성과 처리량(throughput)을 뽑아야 하는 프로덕션(성능/스케줄링 우선)
TGI(Text Generation Inference): Hugging Face 생태계 중심 + Docker 배포/옵션/메트릭이 잘 정리된 운영 친화형 선택지 (huggingface.co)

또 중요한 변화: vLLM과 TGI 모두 OpenAI-compatible API를 제공해(예: /v1/chat/completions) 클라이언트 코드를 거의 안 바꾸고 엔진 교체가 가능합니다. vLLM은 vllm serve로 OpenAI 호환 서버를 직접 띄우는 흐름이 문서에서 명확해졌습니다(2026-01 업데이트). (docs.vllm.ai)

🔧 핵심 개념

1) “서빙 엔진”이 하는 일: 스케줄링 + KV cache + 배치

LLM 추론 비용의 핵심은 prefill(프롬프트 처리)과 decode(토큰 생성)인데, 실제 서빙에서는 요청이 섞이면서 다음 문제가 생깁니다.

요청마다 입력 길이/출력 길이가 다름 → GPU가 놀거나(OOM 회피 때문에), 반대로 한 요청이 전체를 막는(head-of-line blocking) 상황 발생
KV cache가 커질수록 메모리 단편화/낭비 → batch를 키우기 어려움

vLLM이 강한 이유는 (대표적으로) KV cache를 효율적으로 다루는 설계(일반적으로 PagedAttention 계열로 알려짐) + 동적 스케줄링으로 동시 사용자 증가 시 처리량이 잘 늘어나는 패턴을 만들기 때문입니다. 실제 벤치마크에서도 vLLM이 Ollama 대비 높은 TPS/낮은 P99를 보였다는 보고가 있습니다. (developers.redhat.com)

2) OpenAI-compatible API의 실무적 의미

서빙 엔진이 달라도 API 모양을 맞추면 다음이 쉬워집니다.

앱 서버/프론트/에이전트 프레임워크(LangChain 등) 코드 유지
“로컬(Ollama) → 스테이징(TGI) → 프로덕션(vLLM)” 단계적 이전
A/B 테스트로 엔진/모델 교체

vLLM은 OpenAI Python client를 그대로 쓰는 예시를 공식 문서에 제공합니다. (docs.vllm.ai)
TGI도 Docker로 쉽게 띄우는 Quick Tour와 배포 플래그 흐름이 잘 정리돼 있습니다. (huggingface.co)

3) 로컬 배포 vs 운영 배포의 체크리스트 차이

로컬: 설치 단순성, 모델 다운로드/캐시, 개발 생산성
운영: 멀티 GPU(sharding/tensor parallel), shared memory, 메트릭/트레이싱, 롤링 업데이트, 자원 상한(최대 토큰/배치)

vLLM Docker 문서에서 --ipc=host 또는 --shm-size를 강조하는데, 이건 PyTorch가 프로세스 간 공유 메모리를 쓰고(특히 tensor parallel에서) 여기 막히면 성능/안정성이 깨질 수 있어서 운영에서 자주 밟는 함정입니다. (docs.vllm.ai)

💻 실전 코드

아래는 “한 대 서버에 로컬/운영 모두 가능한 최소 구성”을 목표로 잡았습니다. (모델은 예시이며, 환경에 맞게 바꾸세요)

1) vLLM: Docker로 OpenAI 서버 띄우기 (GPU)

  
# 1) HF 토큰(게이티드 모델이면 필수)
export HF_TOKEN="YOUR_TOKEN"

# 2) vLLM OpenAI-compatible server 실행
# --ipc=host 는 shared memory 이슈 회피(특히 병렬 추론에서 중요)
docker run --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env "HF_TOKEN=$HF_TOKEN" \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model NousResearch/Meta-Llama-3-8B-Instruct

위 커맨드 구조는 vLLM 공식 Docker 배포 문서의 형태를 그대로 따릅니다. (docs.vllm.ai)

이제 클라이언트는 OpenAI Python SDK로 호출:

  
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="token-abc123",  # vLLM 서버 띄울 때 지정 가능
)

resp = client.chat.completions.create(
    model="NousResearch/Meta-Llama-3-8B-Instruct",
    messages=[{"role": "user", "content": "vLLM 서빙에서 병목은 보통 어디서 생겨?"}],
    # vLLM 전용 옵션은 extra_body로 넘기는 패턴(예: top_k)
    extra_body={"top_k": 40},
)

print(resp.choices[0].message.content)

이 호출 패턴(특히 base_url + extra_body)은 vLLM OpenAI 호환 서버 문서와 동일합니다. (docs.vllm.ai)

2) TGI: Docker로 빠르게 띄우기 (GPU)

  
model="teknium/OpenHermes-2.5-Mistral-7B"
volume="$PWD/data"

docker run --gpus all --shm-size 1g -p 8080:80 -v $volume:/data \
  ghcr.io/huggingface/text-generation-inference:3.3.5 \
  --model-id $model

TGI는 공식 Quick Tour에서 위와 같은 “볼륨 마운트로 가중치 재다운로드 방지” 패턴을 권장합니다. (huggingface.co)

3) Ollama: 서버/프록시 환경에서 자주 쓰는 설정 포인트

Ollama는 로컬 앱/에이전트 개발에서 특히 강점이 있는데, 운영 네트워크(프록시)에서는 환경변수 설정이 중요합니다. 공식 FAQ는 모델 pull이 HTTPS 기반이므로 HTTPS_PROXY를 쓰는 점을 강조합니다. (docs.ollama.com)

  
# 예: 프록시 환경에서 모델 pull이 필요한 경우
export HTTPS_PROXY="https://proxy.example.com"

# (환경에 따라) OLLAMA_HOST 등도 설정 가능
# export OLLAMA_HOST="0.0.0.0:11434"

ollama serve

⚡ 실전 팁

1) “엔진 선택”을 성능이 아니라 워크로드로 결정하기

동시 사용자 1~수 명 + 로컬 개발: Ollama가 생산성 최고(설정 적음)
동시 사용자 수십~수백 + 비용 민감: vLLM 쪽이 유리한 경우가 많음(벤치마크에서도 vLLM이 고동시성에서 처리량/지연이 강하게 나오는 사례가 보고됨) (developers.redhat.com)
HF 모델/운영 기능(옵션/가이드/하드웨어 다양성): TGI 문서/가이드 체계가 탄탄 (huggingface.co)

2) vLLM 컨테이너에서 가장 흔한 함정: shared memory

증상: 멀티 GPU/병렬 추론에서 성능 급락, 프로세스 통신 문제, 예기치 않은 hang
처방: --ipc=host 또는 --shm-size를 반드시 검토
vLLM이 공식 문서에서 이 플래그를 “PyTorch가 shared memory를 쓴다”는 이유로 직접 언급합니다. (docs.vllm.ai)

3) “기본 샘플링 값이 이상하다”면 generation_config부터 의심

vLLM은 기본적으로 모델 repo의 generation_config.json을 적용할 수 있어, 서버에서 생각한 기본 temperature/top_p가 바뀌는 일이 생깁니다. 필요하면 런치 옵션으로 동작을 통제하세요. (docs.vllm.ai)

4) 관측성(메트릭/트레이싱)은 ‘나중에’가 아니라 ‘처음에’

QPS가 올라가면 “모델이 느린지, 큐가 긴지, prefill이 막히는지”를 구분해야 합니다.
vLLM은 OpenAI 호환 서버에서 metrics/tracing 관련 옵션이 계속 확장되는 흐름이 보입니다(버전별 hidden metrics, OTLP traces 등). (docs.vllm.ai)
운영이라면 Prometheus + OTLP(OpenTelemetry)까지 염두에 두고 배포 파이프라인을 잡는 게 장기적으로 싸게 먹힙니다.

🚀 마무리

정리하면, 2026년 2월 시점의 실전 배포 전략은 이렇게 가져가면 시행착오가 줄어듭니다.

로컬 개발/PoC: Ollama로 빠르게 반복
운영 배포(고동시성/비용 최적화): vLLM(OpenAI-compatible server + Docker) 중심, --ipc=host 같은 운영 플래그를 초기에 표준화 (docs.vllm.ai)
HF 생태계/문서화/배포 가이드 중시: TGI Docker 기반으로 빠르게 서빙하고, 필요 시 vLLM로 이전 (huggingface.co)

다음 학습 추천:

vLLM: OpenAI-compatible server의 세부 옵션(스케줄링/메트릭/트레이싱)과 멀티 GPU 전략
TGI: CLI 옵션(샤딩/quantization/배치)과 Prometheus 모니터링
공통: 부하테스트(동시성별 TTFT/P99) 스크립트 표준화 → 엔진 교체 시 “감”이 아니라 “수치”로 결정하기

AI, MLOps

ai mlops trend 2026-02